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!
Here’s the full transcript:
-Hi, Georg Fasching here helping you unlock your team’s genius and in this video I’m covering the definition of done.
A very important agreement in agile product management with Scrum.
This is another video in the series, Power of Three where I’m spending just three minutes sharing my top three
tips and encouragement on a particular subject.
So, in this video, we will spend the three minutes and it will start just about now, right.
So, when it comes to the definition of done, this is a very important step that you need to work out it is if you wield an insurance policy for the product owner.
It is a matter of fidelity and quality assurance and that is the first encouragement, to remember the purpose
of the definition of done.
It is to ensure that you achieve a consistent, reliable level of fidelity of a product (mumbles) item that you deliver and it is also a method of assuring the correct level of quality.
So that is the purpose.
It is important that this, the items meet the criteria that is set out in the definition of done and if the product owner can verify that the items are delivered by the team matches the definition of done, then it can be accepted and potentially released to the user and then the team has achieved a potentially shippable product increment and as it is called in the technical term.
The second thing, the second tip of encouragement that I would like to offer to you is that it is very important in the definition of done to be very specific and to
have clarity across the team because that already comes into play when the team is going through backlog grooming or actually as we should call it nowadays, backlog refinement because everything works towards the team achieving the level of quality and fidelity in the definition of done.
So it needs to be known from the outside and clear to everyone in the team.
So having that specificity and the clarity and saying exactly what it needs to match.
So for example, it needs to match all the acceptance
criteria in the story, it needs to be able to test accordingto what is expected in the story and so on, so forth, needs to be understood by the whole team and very clear.
So last, but certainly not least, it is important to appreciate that the definition of done is a living document.
So the definition of done that you might have towards the beginning of the life cycle of the product, will look very different to the definition of done that you would have grown it to over time as the product grows and matures.
So at the very beginning, as a team, when you’re really more concerned with validating key assumptions in the product, and you’re prototyping, then your definition of
done will look different to what it is once you have,
validate the product market fit and you are creating
feature of the feature that creates value for the user, that creates value for the organization and you are more in a good product delivery flow that it will have a
different definition of done and the inspect and adapt
cycle for the definition of done will be a little bit
more frequent I would presume in the beginning and it will be a little bit less regular in the future.
So in the beginning, as things change, you might review it very two to four weeks and then once things
are a bit more stable, it might be sufficient to review
it every calendar quarter.
And with that, we are at the end of time.
For the definition of done, Power of Three episode.
Thank you very much for your time.
If you have any thoughts of comments on the video, please share them down below and also please like, share and subscribe to the video and channel.
I’m looking forward to sharing more with you and all the best for the practice with your team.
Until next time, thank you very much and bye bye.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.