Jimmy Janlén "Den Scrummande Konsulten"

Fördelar med en bra DONE definition

En DONE definition beskriver som bekant vad som krävs för att teamet ska få lov att säga att dom är helt ”klara” med en User Story och för att de ska tillåtas demonstrera den på sprint demon. Typ en checklista för teamet när de utvecklar. Men…

.

En väldefinierad och förankrad DONE defintion som teamet följer disciplinerat är användbar och värdefull på så många fler sätt:

• Underlättar vid User Story estimering av Product Backlog (så att man inte glömmer bort någon aspekt)
• Hjälper teamet att bryta ner User Stories till tasks vid sprint planering
• Gör det tydligt för Product Owner och stakeholders vad teamet menar när dom säger att dom är ”klara” men någonting
• Beskriver önskad kvalitetsnivå (genom att teamet till exempel genom diskussion med Product Owner specificera vilka typer av tester som skall göras)
• Hjälper teamet hålla den tekniska skulden låg
• Ger kunden/beställaren möjlighet att vara ”nöjd” efter valfri sprint (då man vet att det som har blivit demat är helt klart och redo för paketering eller leverans)
• Synliggör  för Product Owner och att det finns andra uppgifter utöver själva programmeringen som tar tidstakeholders.

Det går enkelt att komma på många fler fördelar! Någon som behöver ytterligare inspiration? 😉

Återkommer inom kort med vad jag tycker att en ”Definition of DONE” minst borde innehålla…