Scrum uses an iterative, incremental approach to deliver value to the business through the medium of the Sprint. The purpose of each Sprint is to deliver a Done, usable increment. It sounds straightforward, but it can be tricky to achieve. Here are the three steps to Done in Scrum: ensure your Scrum Team has a workable Definition of Done, a well-refined Product Backlog, and uses the Sprint Retrospective to identify improvement opportunities.
Creating a Definition of Done
The first step to getting to Done is having a shared understanding of what is meant by Done. A Definition of Done (DoD) is a common understanding of all the work the Developers need to complete for each Product Backlog item. As the 2020 Scrum Guide poetically puts it, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
A DoD might include ensuring that unit tests passed, code review is completed, code is merged into the main code branch, or that the codebase is integrated into any other systems.
A good DoD provides transparency for the customer and Developers. Suppose Developers know, for example, that unit testing and code review are required for every story before it can be considered Done. In that case, they may size the Product Backlog item differently, or they may approach the Sprint Planning event differently. Having greater clarity on what Done means helps team members conduct a better and more effective Sprint Planning meeting, which can help ensure that the Scrum Team can deliver a valuable, usable increment by the end of the Sprint.
There are many ways to have a conversation about a Scrum Team’s DoD. First, if the Scrum Team's organization already has a DoD, they should adopt that as a minimum. Alternatively, if the Scrum Team is working together with other Scrum Teams to support a product, all Scrum Teams should share the same DoD. If this is not the case, then the simplest way to have this conversation is to dedicate one Sprint Retrospective event to discuss what to include. The Scrum Team can revisit this discussion regularly to continue reviewing and improving the team’s Definition of Done.
Scrum Masters who are interested in learning more should consider participating in the Professional Scrum Master II class for a helpful activity to engage their team in creating a Definition of Done.
Product Backlog
The construction and ordering of the Product Backlog are critical to ensuring that Scrum Teams can deliver a Done increment each Sprint. If the Developers do not size the Product Backlog items such that they can complete them within one Sprint, the Scrum Team will be unable to deliver a Done increment reliably.
The Scrum Team's success depends on sizing the highest ordered Product Backlog items according to what the Developers can complete within a Sprint. So, if the Scrum Team chooses a Sprint duration of two weeks, the Developers should size each Product Backlog item so the team can complete it within that time. Smaller is better—break Product Backlog items into multiple, smaller items during refinement.
Additionally, each Product Backlog item should deliver a unit of value to the customer. This means that you should NOT break Product Backlog items out by role (e.g., separate Product Backlog items for “development” work and “testing” work.) Instead, each Product Backlog item must meet the Scrum Team’s Definition of Done independently, including all development, testing, etc., that may be necessary.
Using the Sprint Retrospective
The purpose of the Sprint is to deliver a Done increment; if the team is not achieving this, they should discuss it at the Sprint Retrospective to find and address the root cause. There are many ways to conduct a productive Sprint Retrospective, but for this particular issue, I find the “Five Whys” activity most useful.
Here’s how to conduct the Five Whys exercise:
If a team is not creating a Done increment each Sprint, write it as an issue and place it at the top of a whiteboard (shared electronic whiteboards are great for this purpose).
Next, the team asks why that problem exists, writing that answer in the box below.
Then, the team asks why again, but this time in response to the why they just identified.
Continue this process until the team identifies an actual root cause, which usually becomes apparent within five steps.
Once the team has identified the root cause, they brainstorm ways to address it and prioritize the action items to resolve the issue(s).
Conclusion
Delivery of value in smaller, usable increments is logical, but that doesn’t mean it’s easy to. If your team is struggling to deliver a Done usable increment each Sprint, the root cause could be an unclear Definition of Done, improperly sized Product Backlog items, or another issue. Have the team discuss it at the Sprint Retrospective and identify actionable improvements.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
Applying Professional Scrum
Introductory class for those new to Scrum
Professional Scrum Master
Geared towards Scrum Masters coaching teams
Professional Scrum Master II
Advanced class for Scrum Masters
Professional Agile Leadership
For leaders and managers of Agile teams
Professional Scrum Product Owner
For Product Owners
Both public and private classes are available. To learn more, contact Mary Iqbal.
Comments