Goed Opdrachtgeverschap bij In-House Softwareontwikkeling
Praktische tips om grip te houden op scope, kwaliteit en voortgang, van idee tot werkende software.
Agenda
Deze presentatie neemt je stap voor stap mee door het volledige proces van goed opdrachtgeverschap; van het begrijpen van de gebruiker tot het bijsturen op KPI's.
01
De gebruiker centraal
User stories en context modelleren
02
Werk structureren
Epics, features, stories en taken
03
Sprint-planning & schatten
Scope bepalen en sprint -1
04
Sturen & bewaken
KPI's, backlog, stuurgroep en DoD
Samenvatting: De Essentie van Goed Opdrachtgeverschap
De Scrum-cyclus biedt een robuust framework voor in-house softwareontwikkeling. Door elke fase zorgvuldig te doorlopen, blijfven jullie als opdrachtgever in controle over scope, kwaliteit en voortgang, en wordt waarde iteratief geleverd.
Product Backlog
Verzamelen, verfijnen en prioriteren van epics en user stories op basis van gebruikersbehoeften.
Sprint Planning
Definiëren van de sprintdoelstelling, selecteren van stories en gedetailleerde schatting van het werk.
Sprint Uitvoering
Het ontwikkelteam bouwt de functionaliteit, met dagelijkse synchronisatie en samenwerking.
Sprint Review
Demonstratie van het opgeleverde werk aan stakeholders en verzamelen van feedback.
Sprint Retrospective
Teamreflectie op de sprint en identificatie van verbeterpunten voor het proces.
Elke iteratie leert het team en jullie als opdrachtgever meer, wat leidt tot betere software en een efficiënter proces.
Context Model: Breng het Systeem in Kaart (DDD)
Een contextmodel op basis van Domain-Driven Design (DDD) geeft een gedeeld begrip van de systeemgrenzen. Het maakt expliciet welke domeinen bestaan, hoe ze met elkaar communiceren, en waar de verantwoordelijkheden liggen. Dit is de basis voor technische en functionele keuzes.
Bounded Contexts
Elke bounded context is een afgebakend domein met eigen taal en logica, bijv. "Contract", "Werkbon" of "Storing". Binnen de context spreken alle teamleden dezelfde taal (Ubiquitous Language).
Context Map
De context map toont hoe de domeinen aan elkaar zijn gekoppeld: welke systemen data uitwisselen, en waar integratiepunten zitten. Dit voorkomt verborgen afhankelijkheden en verrassingen laat in het project.
Het Productverhaal: De Grote Lijn Vangen
Naast individuele user stories is een overkoepelend productverhaal essentieel om de "waarom" en "wat" van het grotere geheel te communiceren. Dit verhaal, op Epic- of productniveau, creëert alignment en context voor zowel het team als stakeholders.
De Visie & Het Waarom
Wat is de ultieme missie die we nastreven en welk dieper probleem lossen we op? Dit is de drijvende kracht achter het product.
De Doelgroep
Voor wie bouwen we dit? Beschrijf de hoofdgebruiker(s), hun context en de kernbehoeften die ons product vervult.
De Kernoplossing
Hoe lost ons product de gedefinieerde problemen op? Focus op de unieke waardepropositie en de essentie van de gebruikersreis.
Verwachte Impact
Wat is de gewenste uitkomst voor de gebruiker en de organisatie? Hoe meten we succes op de lange termijn?
De Algemene User Story: Begrijp de Gebruiker Eerst
Voordat er één regel code wordt geschreven, moet het team diepgaand begrijpen wat een gebruiker doet, waarom, en welk resultaat hij verwacht. Een algemene user story beschrijft dit uitgebreid en vormt het fundament van alle verdere specificaties.
Wie is de gebruiker?
Beschrijf de rol, context en motivatie. Bijv.: "Als inkoper binnen een middelgroot productiebedrijf wil ik snel kunnen zien welke leveranciers beschikbaar zijn…"
Wat doet de gebruiker?
Loop stap voor stap door de end-to-end handeling: van inloggen tot het gewenste resultaat. Beschrijf ook uitzonderingen en randgevallen.
Wat is het gewenste resultaat?
Definieer meetbaar succes: de gebruiker heeft zijn doel bereikt, het systeem heeft correct gereageerd, en de data klopt.
Werk Opbreken: Van Epic naar Task
Goed opdrachtgeverschap vereist een heldere hiërarchie in het werk. Door functionaliteit stapsgewijs op te splitsen, wordt groot en vaag werk klein en behapbaar — zowel voor het opdrachtgeversteam als het ontwikkelteam.
Tasks
Technische deeltaken van max. 1 - 3 dagen werk
Stories
Functionele eenheden, geschat op weekniveau
Optioneel: Features
Groepen van samenhangende stories
Epics
Grote functionele blokken, geschat op sprintniveau
Het scheidingsvlak tussen opdrachtgever en ontwikkelteam ligt bij de story: de opdrachtgever definieert het wat en het waarom functioneel; het ontwikkelteam bepaalt het hoe technisch.
Sprint-Planning: Schatten op de Juiste Schaal
Schatten op het juiste niveau voorkomt over-commitment en onduidelijkheid. De schattingshiërarchie sluit aan op de work breakdown: epics op sprintniveau, stories op weekniveau.
Epics → Sprints
Schat epics in aantal sprints. Dit geeft de stuurgroep en het opdrachtgeversteam inzicht in de doorlooptijd van grote blokken functionaliteit.
Stories → Weken
Schat stories in weken werk. Bepaal daarna hoeveel stories passen in één sprint van 3 weken — rekening houdend met team-capaciteit en afhankelijkheden.
Sprint -1
De sprint vóór de uitvoeringssprint. In sprint -1 worden scope en stories voor de volgende sprint definitief bepaald en geschat. Zo start elke sprint voorbereid en zonder verrassingen.
De Backlog: Structuur en Prioritering
De backlog is het kloppend hart van het opdrachtgeverschap. Een goed gevulde en geprioriteerde backlog geeft het team altijd duidelijk wat er als volgende opgepakt moet worden — en waarom.
Backlog opbouwen met Epics
Vul de backlog op epic-niveau en schat iedere epic in sprints. Dit geeft een realistisch meerwekenplan zonder dat je te vroeg in detail afdaalt. Epics worden progressief verfijnd naarmate ze dichterbij komen in de planning.
Prioritering door de Stuurgroep
Prioriteiten worden vastgesteld door een stuurgroep met twee invalshoeken:
  • Technisch: haalbaarheid, architectuurvisie en productvisie
  • Financieel: business case, ROI en strategische waarde
  • Commercieel: Klantvraag en -behoefte
Gouden regels voor de backlog
  • Elke epic heeft een duidelijke eigenaar
  • Schatting is verplicht vóór plaatsing op de roadmap
  • Top 3 sprints zijn altijd gedetailleerd uitgewerkt
  • Backlog refinement is een vaste ceremonie
KPI's om op te Sturen
Twee kernmetrieken geven het opdrachtgeversteam continu inzicht in de kwaliteit van het ontwikkelproces: Fault Slip Through en Sprint Estimation Precision. Door hier actief op te sturen, verbeter je zowel de voorspelbaarheid als de kwaliteit van de opgeleverde software.
Fault Slip Through (FST)
Meet hoeveel defecten pas door de klant of eindgebruiker worden ontdekt, in plaats van tijdens de teststap. Een hoge FST signaleert dat de definitie van klaar (DoD) onvoldoende wordt nageleefd of dat acceptatiecriteria te vaag zijn omschreven.
Doel: FST zo laag mogelijk — streven naar 0% kritieke fouten in productie.
Sprint Estimation Precision
Meet hoe nauwkeurig het team de sprint-scope schat ten opzichte van wat daadwerkelijk opgeleverd wordt. Een grote afwijking wijst op te ambitieuze planning, onduidelijke stories of onvoorziene technische complexiteit.
Doel: Precisie boven 80% — afwijking kleiner dan 20% van de geschatte capaciteit.
Sprint Reviews en Definition of Done
Een sprint review is geen formaliteit, het is het moment waarop je beoordeelt of het geleverde werk daadwerkelijk voldoet aan de afgesproken standaard. Een scherpe Definition of Done (DoD) maakt dit objectief en consistent.
1
DoD opstellen
Definieer samen met het team wat "klaar" betekent: code review, geautomatiseerde tests, documentatie, en acceptatietest door de Product Owner zijn minimumvereisten.
2
Review voorbereiden
Elke story die gereviewd wordt, moet aantoonbaar voldoen aan de DoD. Het team demonstreert het werkende systeem in een realistische omgeving — niet op localhost.
3
Feedback vastleggen
Bevindingen uit de review worden direct vertaald naar backlog-items: bug fixes, verbeteringen of nieuwe inzichten worden geprioriteerd voor de volgende sprint.
4
Retrospective koppelen
Koppel de sprint review aan een korte retrospective: wat ging goed, wat kan beter? Zo verbetert het proces continu en leert het team sprint over sprint.
Samenvatting: De Essentie van Goed Opdrachtgeverschap
Opdrachtgeverschap is een doorlopend proces van begrijpen, structureren, sturen en verbeteren. De combinatie van de juiste tools, heldere afspraken en consistente ritmes zorgen voor kwaliteit en voorspelbaarheid.
Begrijp de gebruiker
Uitgebreide user stories en DDD-contextmodel als fundament
Structureer het werk
Epics → Features → Stories → Tasks met helder scheidingsvlak
Plan en schat realistisch
Sprint -1, 3-weekse sprints, schatten op het juiste niveau
Stuur op KPI's
FST en Estimation Precision als kompas voor kwaliteit en voorspelbaarheid
Betrek de stuurgroep
Technische én financiële sturing voor de juiste prioriteiten