DoR staat voor Definition of Ready en DoD voor Definition of Done. Dit is een set van expliciete afspraken die het scrumteam opstelt. Er wordt beschreven wanneer een taak of user story klaar is om te verwerken in een sprint – ready – en wanneer een taak is afgerond – done – en klaar is voor een release. Klinkt simpel toch? Toch zijn er een paar belangrijke spelregels bij het opstellen hiervan.
Wanneer ben je ready?
Lastige vraag. Dat verschilt namelijk per team. In de DoR staan de afspraken waaraan een taak of user story moet voldoen voordat een sprint kan beginnen. Deze zijn besproken met de product owner en goedgekeurd door het hele development team. Wat het oplevert? Een soepele doorloop. Het team heeft namelijk minder vragen en hoeft geen aannames te doen of lang te zoeken naar een vaag omschreven probleem.
Wat staat er dan in de DoR?
Een DoR bevat randvoorwaarden voor het omschrijven van user stories en bugs. Een paar voorbeelden;
- User stories bevatten een heldere wens (één of meerdere acceptatiecriteria, SMART onderbouwd)
- Elke user story heeft een inschatting op waarde (uren of story points)
- Een bug moet een reproductiescenario bevatten
- De prioriteit van een bug of user story moet worden aangegeven
Waarom kunnen we niet zonder?
Zonder DoR hebben onze developers geen handvatten om aan de slag te gaan. Ga je toch aan de slag zonder DoR – bijvoorbeeld door de druk om snel te leveren – dan is de kans groot dat een oplevering niet voldoet aan de verwachtingen. Garbage in, garbage out, noemen we dat. Het gevolg? Onvoorziene uitloop, hoge kosten en ontevreden klanten.
Wanneer ben je done?
Als een taak of user story door kan naar de productieomgeving en daarmee live kan gaan. Het is belangrijk om deze ‘eindstaat’ te definiëren. Daarvoor is de DoD. Ook dit zijn afspraken tussen de product owner, het developmentteam en de scrum master. Heldere verwachtingen over de kwaliteit en functionaliteit, daar draait het om.
Wat staat er dan in de DoD?
Een DoD bestaat uit randvoorwaarden voor wanneer een user story of taak af is. Een paar voorbeelden om dat te illustreren;
- Alle acceptatiecriteria van een user story zijn voldaan
- Alles moet getest zijn op zowel test- als acceptatieomgeving
- Wanneer een verandering op productie staat wordt ook hier getest
- Als er een aanpassing is gedaan aan de applicatie moet er een nieuw versienummer gekoppeld zijn
- Het uitrolplan moet uitgevoerd zijn
Waarom kunnen we niet zonder?
Zonder een DoD kan een taak of user story onvolledig of verkeerd uitgerold worden op de productieomgeving. Heb je bijvoorbeeld een mooie functionaliteit gemaakt, blijkt de hele module niet zichtbaar in de applicatie. DoDzonde…
Bij Bitfactory in de praktijk
Alle neuzen dezelfde kant op. Dat is een voorwaarde voor succesvolle (door)ontwikkeling van applicatie. De DoR en de DoD spelen daarin een belangrijke rol. Tuurlijk, afspraken verschillen per project. Maar om er zeker van te zijn dat we niets vergeten, hebben we bij Bitfactory een standaard DoR en DoD gemaakt voor ontwikkelsprints én servicedesk werkzaamheden. Want ook in beheer en doorontwikkeling willen wij consistente kwaliteit en service leveren.
Onze product owners en servicedesk managers zijn getraind in het opstellen van de juiste eisen en onze developers kijken kritisch naar issues te met de DoR ernaast.
Wil je meer weten over onze DoR en DoD? Neem gerust contact op, onze product owners of service managers vertellen je er graag meer over.
