With this post I would like to start a series of articles under the name “Scrum answered”. In each article I will cover one Scrum topic and respond to questions which I was asked during my career as Scrum Master and Agile Coach. The first article will cover Definition of Done related questions.
What is the difference between Definition of Done and Acceptance Criteria?
Answer for developers – the same as between Java and JavaScript, those are two totally different things.
Definition of Done explains what “Done” means, so that everyone involved into development has the same understanding.
Very often it is a bullet point list describing general things which need to be done to consider the product as finished and ready for production. Common things on the DoD list are:
- Code covered by unit tests;
- Code approved by other developers;
- Automatic tests prepared;
- User manual updated;
Such list has multiple purposes. First, it defines basic quality criteria for the product we develop. Should we cover code with unit tests or not? Do we need automatic tests for that? Should we run performance or security testing? Definition of Done should answer such questions and provide guidelines on expected quality. Definition of Done will be totally different depending on the product purpose and expected reliability – just think of a weather forecasting web site versus heart pacemaker controller.
Second, the DoD is useful during Sprint Planning as it provides input on what should be included in the estimate. For example, preparation of user manual in one language can take 2 hours, but if in Definition of Done you agreed it’s three languages manual, the effort will probably go up to 5 or 6 hours.
Third, the Definition of Done provides transparency. Whenever anyone is asked to assess if the delivered product is done, he or she should just verify against each point from the DoD list.
Acceptance Criteria are something very different and, in most cases, have only one thing in common with the Definition of Done – they’re shaped as a bullet point list.
Simplistically, AC are a method of requirements description which is widely used in Agile world.
They’re a bullet point list describing in SMART way (see User Story defined in 3 acronyms) how the product will look like after requirements are implemented.
As an example, let’s assume you run a blog and it already has some posts, but there’s no possibility to comment on them. Your new requirement in a form of User Story would be: as a reader I would like to comment an article in order to ask questions to the author or to share my own opinion.
Acceptance Criteria for the requirement could be:
- Comment module at the end of each article.
- Both logged in and non-logged in users can post comments.
- A non-logged user must fill in at least ‘Comment’ and ‘E-mail’ fields in order to post a comment.
- Email format is validated.
- Logged-in users do not need to fill e-mail box.
- Entered comment is immediately visible under the article.
Does every Sprint Backlog Item must obey Definition of Done?
No, it doesn’t need to. Why so? Basically, because Definition of Done is not referring to tasks but to Increment.
The whole idea of Scrum and all iterative or incremental development methods is to deliver a working and potentially releasable product in each iteration.
User perspective is that it’s the product as a whole that matters, not individual tasks done by the team. It’s therefore the product that must meet the “Done” state.
Who is responsible for creating Definition of Done? Who is an owner of the DoD?
This is a very tricky question and Scrum Guide won’t give us a clear answer, or at least leaves a space for various interpretations. On one side the Development Team is mentioned to be responsible for creating DoD when it does not yet exist in the organisation, on the other it is the Scrum Team who is responsible for expanding and changing it. It is a bit incoherent and misleading in my opinion. Let’s me explain why.
The Development Team is responsible for keeping quality of Product, you can even think of the them as of a stakeholder focused on quality (see Quality vs quantity). On the other hand, it is a Product Owner who defines vision of the product and within this vision also some quality requirements depending on the product specifics. The Development Team provides technology input and Product Owner provides vision and system users expectations towards quality.
Definition of Done should be then forged as combination of these two areas, and so in my mind it’s a mutual effort of the whole Scrum Team to create and maintain the Definition of Done.
Can we change Definition of Done?
Yes, you can, and you should. With time your team becomes more mature and the product more complex. As this happens the Definition of Done should be constantly worked on and changed to be more detailed and stricter. This is a general direction, but most important is to remember to include the Definition of Done into your inspect and adapt loops and review it on sprint basis.
We have more than one team working on the product. Can we have more than one Definition of Done?
Yes and no. Or maybe better no and yes.
No, because perception of “Done” should be the same for every person involved into product development. As in previous questions – Definition of Done refers to the whole product, not a single requirement nor even single area covered by one team. It describes “Done” state of an Increment which is delivered jointly by all teams. Imagine that every team is creating one piece of a puzzle. Increment is a picture being built from these puzzles and Definition of Done refers to the picture – so the end result – not to each puzzle separately.
Yes, because every team can add additional points to the Definition of Done. Key point is that the ‘general’ Definition of Done (one shared among all the teams) needs to be sub-part of a single team’s DoD. There is nothing wrong with paying a bit more attention to some areas of the system and maintaining higher quality there. It is also a common situation that one team is strengthening quality by expanding Definition of Done and after few Sprints all other teams follow and incorporate this change to the ‘general’ Increment DoD.
Just one more comment here – this is a practice.
Remember that the Scrum Guide is a one team framework and gives no theory for any scaled organisations.
Whenever you want to work with more than one team you should either scale Scrum using home rules, either implement one of scaled Scrum frameworks like LeSS, SAFe or Nexus.
That’s all for today. Should you have other questions about Definition of Done, feel free to ask leaving a comment. Next week I will answer questions about the Daily Scrum.