Learn the purpose and value of defining the term ‘done’ in agile product management
Establishing the definition of ‘done’ for a sprint item is a very important step of agile product management. See it as an insurance policy for the product owner (and thus the end-user) and a measure of fidelity and quality assurance. It is the balancing act to the team’s Definition of Ready.
It ensures the team executing the work are consistent in their delivery. The product owner can use it as a benchmark to assess whether the team have delivered exactly as agreed when they pulled the work into the Sprint. If they have then the feature can be formally accepted by the PO and released to the end user, leaving the team with a warm, fuzzy feeling of the value they delivered.
It’s equally important to be very specific in your definition of done. Be as clear as possible and be sure every member of the team understands the criteria for ‘done’ in the same way. Some examples of criteria are as follows:
Once everyone’s on the same page, communicate your own definition of done to the relevant stakeholders and product owners for maximum transparency. The clarity of your alignment with the stakeholder landscape, and product owners of related product areas, should improve as a result of this too.
Just like the definition of a ‘ready’ item for Sprint Planning, the definition of a ‘done’ item is ever evolving. These are definitions that are jointly owned by the Scrum Team. Scrum’s event’s offer good opportunities for a potential need to update the definitions.
You can expect your ‘done’ definition to be very different at the beginning of your product’s life cycle compared to the end. That said, don’t be afraid to grow it and mature it, which begs the question how often should you update it. Your inspect and adapt frequency for this agreement might be once every 2-4 weeks at the start of the product life cycle, and once a quarter once things are more stable, your mileage may vary depending on context.
“Your definition of done will be different when you’re validating and prototyping to later on when you’ve achieved product market fit”
The reason for this is simple. At the start, the team are far more concerned with validating key assumptions of the product through prototyping. Speed is of the essence. For testing many assumptions some very low fidelity prototypes by the team may be sufficient. By the end of the early days, the team will have (hopefully) achieved product/market fit. It is now time to gradually upgrade fidelity and quality levels as appropriate.
I hope these tips help you to understand and establish your own definition of ‘done’ for your backlog. As a result, the increased clarity between team members will improve understanding, reduce risk and enable them to deliver real value consistently.
If you have any questions or topics you’d like me to cover, leave a comment below or send me a message through my website. Thanks for reading. See you next time!
Please log in again. The login page will open in a new window. After logging in you can close it and return to this page.