The first portable synthesizer, the Minimoog
The Scrum Guide 2011 states:
The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.”
and
This Increment is useable, so a Product Owner may choose to immediately release it.
Using Scrum, we intend to create a »potentially releasable« and »useable« piece of product increment which is completely »Done« during each sprint, which means there’s nothing left to do. For example, the software behaves performant under real usage conditions and the end user documentation is written completely.
The Definition of Done is a kind of contract between the Product Development Team and the Product Owner. Together with a Product Backlog Item, it defines whether a product increment is »done«. Only »Done« product increments will be accepted by the Product Owner, otherwise the increment will be rejected.
My team currently struggles with performance issues which need to be addressed prior to releasing the product. The issue exists for quite some while now. It happened since performance was not listed in the Definition of Done yet and the team did only test with a small amount of data. Additionally the Definition of Done was neither respected on a regular basis nor was it maintained or emergent. Now it triggers stress, as improving the performance requires heavy changes under the hood while the planned release date is approaching.
During the last retrospective I grabbed the occasion to point out that the Definition of Done is a major key to success and that we need to learn how to cope with it properly. Unfortunately my team mates still did not understand the sense and purpose of the document. Is it their fault? No. It’s mine as their coach. I’ll try to communicate it once again tomorrow.
