How are Done and your Product Backlog related? 🚀 (72)

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 Product Backlog support the concept of getting to a Done Increment at least by the end of every Sprint?

Remember that the purpose of the Product Backlog is to bring transparency on a possible future of your product.

Think a minute about this statement from the ScrumGuide: “Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.”. In other words, a “Ready Product Backlog Item” in Scrum means that this item can be implemented by the Scrum Team in the Increment, meeting the required quality measures, meeting the Definition of Done.

A Scrum Team, making use of the Scrum framework in a professional way, therefore will take the necessary actions before Sprint Planning to ensure they understand the items that are on top of the Product Backlog well enough so they can take these up in Sprint Planning. This ongoing activity to reach this level of transparency is called Product Backlog Refinement.

While doing these refinement activities, the Scrum Team needs to understand the definition of Done and take it into account. If not, how would they know items are small enough to fit into the Sprint, how would they know they can implement items in a Done product state?​​​

Correct, while refining items, the team needs to know 

What regression testing needs to be performed,
What additional testing is needed,
What documentation needs to be updated, 
What training needs need to be covered,
Any data management activities that need to be performed, 
Organisational standards and policies that need to be complied with?
…

I would expect this happens naturally. Yet, for teams new to a professional use of the Scrum framework, that might be new. So support them with this.

Summary:
The highest ordered Product Backlog Items are understood by the team and are small enough to be delivered in the next Done Increment, the latest by the end of the next Sprint. Therefore during Product Backlog Refinement, having the Definition of Done clearly in mind does support achieving this.

Prompt:
Together with your Scrum Team, evaluate how you can improve the use of your Definition of Done during Product Backlog Management activities, certainly during Product Backlog Refinement.

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 Sprint Backlog.

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.