We speak with many customers and a common query is “What should be the definition of done? Is it when the product owner says it done or when the team says it’s done?” The problem arises because the decision to release the development of each ‘done’ product increment (potentially releasable functionality) is ultimately the product owner’s responsibility.
Although the Scrum Guide does not dictate this, in practise a lot of scrum teams include “product owner sign-off” as part of the definition of their done and/or have product owner sign-off as a status on the sprint board. In our experience, including this step, giving power to the product owner can be problematic. The most common issues and some pointers to help you counter them are listed below. Make sure the definition of done remains your friend – not a point of contention between product owners and scrum teams.
Product owner sign-off removes autonomy from teams because they cannot move a story to done, unless the product owner says it’s done. Consequently, this can cause delays and interfere with sprint burn-down. Teams are often frustrated as they need to wait for product owner availability to approve a story.
Solution: If all the acceptance criteria are met and all the items on the agreed definition of done is met, the team has the autonomy to move the story to done. A product owner can reject a done story at the end of the sprint.
2. Acceptance Criteria
It goes without saying that asking the question “are all the acceptance criteria met?” should be part of the definition of done. Once all the acceptance criteria are met, plus the rest of the agreed definition of done, the team then decides whether the story is done. However, this puts pressure on the product owner to create comprehensive, well defined and well understood acceptance criteria.
Solution: If acceptance criteria are missing or ambiguous, the product owner should not reject or alter a user story drastically mid-sprint i.e. at product owner sign-off. A new story should be created to cover the missing acceptance criteria after the sprint review. It can then be included in future sprints. Common sense needs to prevail here – sometimes it simply makes sense to add a small acceptance criterium to a story mid-sprint, if the team agrees it won’t influence their sprint delivery, however it should remain the exception and not the norm.
3. Travelling stories
If it is up to the product owner to sign-off stories, small or large, amendments to acceptance criteria are often added at the “product owner sign-off” stage of the sprint. This results in unfinished stories travelling from sprint to sprint, because there is little pressure on the product owner to get stories ready.
Solution: Get stories ready to get them done. Teams tend to tinker with definition of done to avoid travelling stories, rather than be more stringent on the implementation of definition of ready. It is often overlooked that a team has the authority to refuse a story that is not ready. Both the definition of done and the definition of ready should be agreed by the team, product owner and scrum master.
Acceptance criteria sit with product owner, while definition of done sits with the team. Keep talking! Keep refining! Be sensible about the definition of done, the definition of ready and when you exercise the right to reject or refuse a story! Acceptance criteria, definition of ready and definition of done are there to help the team to communicate better and to collaborate – not to cause friction. You can learn more about the definition of done in greater depth on any of the Professional Scrum training courses or through our agile coaching service.