DONEness - Concepts and Practice
DONEness is an absolutely critical concept for a Scrum team. It helps to define the conditions that software must satisfy in order to for us to consider a new or changed software feature "finished." Lacking a clear definition, the state of "doneness" is frequently defined by the individual developer and can usually found to be lacking sufficient rigor to consistently result in a high quality software product (in truth, many quality management systems also define "exit criteria" to help us understand the state of completion, but it's my experience that these criteria frequently lack relevance for the typical developer).
For DONEness to work properly in a Scrum team, there are several steps we need to take:
- The DONEness definition needs to be posted visibly in every team room. It needs to be impossible to enter or exit the room without seeing the posted DONEness definition.
- The DONEness definition needs to be used during backlog grooming to support proper estimation. In other words, while asking the question, "how complex is this backlog item?" we must consider the complexity of the feature, of the supporting documentation, of the testing needs, etc.
- The DONEness definition needs to be used during Sprint Planning to ensure that the Scrum team lists all of the tasks needed to achieve DONEness. In inexperienced teams or teams working with a new definition of DONEness, you should see tasks for many if not all of the applicable DONEness criteria. In more experience teams that have begun to internalize or have successfully internalized DONEness, you will see fewer specific tasks, but the team will do the work anyway.
- The DONEness definition needs to be used by the Product Owner during Sprint Review to help verify that DONEness was properly achieved. I don't necessarily recommend going over all of the DONEness criteria for each backlog item reviewed, but I do recommend to Product Owners that they randomly select items from the list to validate.
Continue with Levels of Doneness.