We started this Scrum foundation series explaining we see four underlying concepts of the Scrum framework. In the past series of mails we covered the three pillars of Empiricism, the Scrum Values, and a Self-Managing and Cross-Functional Team.
The concept Done is the fourth of these concepts. It needs a self-managing, and especially a cross-functional team, a team living the Scrum Values, to make it work in a way that it brings the needed transparency with regards to the quality of your solution/product.
👉 A solution (Product/Increment/Service) the team labels as Done, meaning the solution meets the required quality measures, is ready to be released in the hands of the users, in their day-to-day life.
Being Done = meeting the required quality measures = a new Increment exists = a production release is possible.
So how does the Increment relate to the concept of getting to Done at least by the end of every Sprint?
It seems this is the most straightforward relation we could have… Not Done means there is no new Increment. Final.
Users expect that when they use your product, that they can count on it. That there are no unexpected issues occurring. They want a quality product. Not Done means not reaching this expected quality level.
Presenting a version of the product that is not Done brings a false feeling of product availability to the customers, to the users. When an Increment is not Done, transparency is reduced, a lot. Customers, users, don’t know what it means if the product is not Done. What work is still outstanding? How much more investment will this take? And not only the users are in the dark, the team also doesn’t know exactly what amount of effort is still needed. They have a guess, an assumption.
When an issue occurs while using the product, is this happening because something was not finished, was not Done? Or because what is listed in the Definition of Done has just shown a gap that we now need to close?
When work is not Done, but shown anyhow during the Sprint Review, and stakeholders indicate they like what they see and want to release it to the users, what is the impact of the remaining work? Is it dangerous to give it to the users? How much effort still remains to finish the job before the release is possible?Â
When work is not Done, does it need to move to the next Sprint? Or is that item no longer useful and does the team need to rollback all the work they performed for that specific item?
Have we now moved closer to the Product Goal? Or not really?
Summary:
When the Increment does not adhere to the agreed upon Definition of Done, there are all of a sudden a lot of open questions people – both Scrum Team members as well as stakeholders – will ask. And more often than not, it will be hard for the team to answer these questions satisfactorily. Not Done = No new Increment that is releasable.
Prompt:
Together with your Scrum Team, evaluate how you can improve the use of your Definition of Done to ensure the expected quality level is delivered in the hands of the users, and to ensure a correct transparency exists about the state of the product.
We hope you will find value in these short posts and if you are looking for more clarifications, feel free to take contact.
PS. Next week we’ll look at the use of Done and the Product Owner.
Â
If you want to take a deeper dive into the core concepts we are covering in this blog series, then surely check out our Professional Scrum MasterY workshop. We have some scheduled in the coming period.
Â
Don’t want to miss any of these blog posts? Have the professional Scrum foundations series weekly in your mailbox.