Definition of Done

The Sprint has just ended. The team has completed a lot of work and they feel comfortable going into the review meeting. The Product Owner has been working with the team, although not on consistent basis, but the collaboration is getting better. The team has been asking quite a few questions and the Product Owner was able to answer most of those questions during the Sprint. The Product Owner has felt that the team has made good progress. The Definition of Done has been agreed a few Sprints ago and it’s been visible. The team has been keen to complete all the work according to the Definition of Done.

The review meetings kicks off. The team and the Product Owner discuss the work completed during the Sprint. The discussion is lively. The Product Owner looks excited. She starts to discuss about the release schedule and the road ahead.

The Product Owner asks enthusiastically, when can we ship? Suddenly, the mood starts to change. The comfort level goes down. Team starts to get edgy and Product Owner starts to get irritated. According to the team, they have completed the work according to their Definition of Done. But, it’s still not ready to be shipped. Further work is needed.

The Product Owner is confused and frustrated. She thought the work was done and ready to be shipped. The team explained what was already completed, and what remains to be done. Later it turns out, the team would require another three Sprints to complete all work to make the product increment shippable. Ouch!

I have observed this situation in several teams. Typical causes which lead to these kind of situations are

1. Incomplete Definition of Done
2. Definition of Done is Static
3. Ignoring undone work
4. Missing Definition of Done

Incomplete Definition of Done

Several team tend to use a common pattern while coming up with their definition of Done. They look at the typical activities they carry out during the Sprints and they include all those activities in their Definition of Done. Then they include some of the commonly missed activities. And they complete their Done Definition and put it up in their team area. And they get to work.

More often than not, this Definition of Done does not list all the work needed to ship an increment. It misses the ‘potentially shippable’ bit. 

Definition of Done is Static

Many Scrum teams come up with a Definition of Done when they start, or when they realize they need to come up with one. They discuss it within the team, deliberate and identify a list of item they need to include in their Definition of Done. They post their Definition of Done in a visible place and live happily thereafter. Except, that they don’t.

Their Definition of Done doesn’t evolve. They don’t retrospect around their Definition of Done. They forget the inspect and adapt principle. They consider their Definition of Done a definitive document. They stick to it as they move forward and obey it religiously. In reality, Definition of Done should be a living document. It should evolve as the team moves forward and learns more. Items listed in Definition of Done must be refined and the team must add new items whenever applicable.

Ignoring undone work

I have seen this pattern repeatedly. This happens in the team having some sort of Definition of Done, and in the ones without one. Teams go on to build functionality every Sprint, moving towards a release goal. They keep adding new features and fixing bugs as they move along. However, they don’t have a Definition of Done following which they can develop a potential shippable increment. They ignore release related tasks, and keep building what’s termed as technical debt.

Teams should complete all the tasks during the sprint, or they should add those as undone work in their product backlog, in the light of their Definition of Done. Instead several teams tend to ignore the tasks they couldn’t complete during the sprint(undone work). When the release time comes, they ‘suddenly’ realize all the undone work they have accumulated over all the previous sprints. The result is that they need several ‘stabilization’ sprints at the end to be able to release.

Missing or ignored Definition of Done

If there is one thing that keeps Scrum teams from having a shippable increment every sprint, it is missing Definition of Done. Either the team doesn’t bother to come up with one, or they did and it’s gathering dust somewhere. The team has no idea of what amount of work is Done. The Product Owner can not evaluate what’s done and what’s still to be completed. Every one is playing blind. Disaster in the making. Very long stabilization ‘phase’ follows, or the verdict, that Scrum doesn’t work.

Teams must consider the level of Done at several levels, i.e.

1. At item (user story) level
2. At Sprint level and Release level

At item (user story) level

The Done definition is captured by acceptance criteria. The story or item must include the acceptance criteria. Both the Product Owner and the team must have a clear understanding of what’d needed to be done to complete this story.

At Sprint and Release level

Every Sprint should produce a shippable product increment. This should be the aim. But if this is not the case and the team is working to get there, the team should have a Definition of Done which reflects this. They should keep improving their Definition of Done as they learn more and more. And they must account for all the undone work they have accumulated. The team must keep in mind release related tasks that must be carried out

Learn more about Scrum, Product Owner role and Agile in one of Scrum Certification Master Courses.

© Faisal Mahmood

Google+