What makes a good Definition of Done?
For Agile development teams using sprint practices and ceremonies, the Definition of Done represents an agreement on what constitutes a completion of the user story or the minimum viable product (MVP).
(1) The list of criteria placed on a Definition of Done should be obvious, and it should be agreed by everyone on the Scrum team. This makes it transparent to everyone on the team and easy to understand.
(2) Items on the list representing the definition of done should be specific, quantifiable, measurable, etc. For instance, “the product owner marks the status of the user story to ‘Approved'” versus “the product owner likes what she sees.” Keep it simple but make it also specific!
(3) Don’t wait until your last sprint to put together your Definition of Done! Put the list together near the beginning of your project. As the team is usually still forming and self-organizing near the beginning, you don’t get a good read until after a couple of sprints or weeks. So, I think it’s better to wait a sprint or two before putting this together.
(4) A good example of one created by Mike Zagami identifies one used when multiple teams or disciplines are involved. For instance, creative UI vs. developers vs. testers, etc. Since each of these disciplines may be involved in the current sprint, each one identifies their own set of criteria that gets added to the Definition of Done. The result is an indication of commitment from each of the team members.
(5) Make the Definition of Done visible or posted in a common spot. Some teams have it on a whiteboard or wherever they conduct their standups. Another common place is a shared website.
(6) The Definition of Done doesn’t have to be a static document. Different disciplines come on/off the project, and so the criteria may need to evolve. Just as teams self-organize, the Definition of Done improves as the team evolves. It represents the maturity of the self-organizing team.
What happens if a user story is not completed in the sprint? The cause of this may be that the user story hasn’t been broken down correctly into MVP. The user story may still be an ‘epic.’ Another consideration is that the user story should have involved more staff members to work on it. Consider next time breaking the user story down into smaller PSI (potentially shippable increments). If two different disciplines are involved on the same user story, then it wasn’t been broken down thoroughly.
If the story was not properly estimated or ‘pointed,’ then the fault may be that the staff member has not properly identified obstacles in the daily standup. Or the Scrum Master or Product Owner has not been successful in removing the obstacles.
What happens if the product owner does not approve the user story? If the user story is completely rejected, then you lose velocity. But maybe there is PSI which can be approved with technical debt. This is a promise to deliver or complete the missing components of a user story in a future sprint. Taking on debt is not desirable, but just like personal financial debt which is inevitable in our lives, it has to be managed properly.
In other words, just as you pay down your financial debt, you should manage your technical debt in the same way. Identify the technical debt (as a future user story) and address it upcoming sprints. This way, the product owner can accept or approve the user story with technical debt, and the team doesn’t lose the velocity.
What do you think? Share your thoughts on forming a Definition of Done…
Tech Galavant 
Leave a Reply