If I were to summarize the purpose of a Sprint, I would say that it’s to deliver a Done, usable increment that meets the Sprint Goal.
What is an Increment?
Developers deliver an increment at the end of each Sprint. The Increment is the sum of all of the completed Product Backlog items. As the 2020 Scrum Guide puts it, “The moment a Product Backlog item meets the Definition of Done, an Increment is born.”
The Increment that is delivered should be a step towards the Product Goal, and is added to all previous increments. Each Increment must meet the Definition of Done.
What is a Definition of Done?
A Definition of Done is a common understanding of all the work the Developers need to complete for each Product Backlog item before considering it Done. A Definition of Done might include ensuring that unit tests passed, code review has been completed, code has been merged into the main code branch, or that the codebase has been integrated into any other systems.
Why is a Definition of Done important? It helps ensure transparency between the Scrum Team and its stakeholders. It ensures that everyone is clear on the meaning of a given Product Backlog item as Done. Additionally, the Definition of Done makes sure that the Scrum Team delivers a completed, usable, potentially releasable increment each Sprint.
If a Definition of Done exists for the IT organization of the Scrum Team, then the Scrum Team should adopt that as a minimum. If no Definition of Done exists, then the Scrum Team should create its own.
Why does getting to Done matter?
Frequently delivering a Done increment has many benefits, including improved visibility, a greater ability to change and adapt, sooner delivery of business value, and earlier risk reduction.
Greater visibility
One of the most significant differentiators of Scrum over other complex work methods is the ongoing interaction between the stakeholders and the Developers. (For example, one of the four values identified in the Agile Manifesto revolves around customer collaboration). The delivery of a Done increment facilitates greater visibility because Stakeholders have a concrete example of the work that the Scrum team is delivering. It’s one thing to see a progress report describing the percentage of work completed; it’s quite another to see the frequent delivery of working software.
Ability to change direction
The Scrum Team gets feedback on whether it’s headed in the right direction by delivering value sooner. According to Pendo, a software platform that helps companies gain insights about their products, 80% of software features are rarely, if ever, used. By delivering value in smaller increments, the Scrum Team can learn from its stakeholders which features are useful - and which features are not useful. In turn, the Product Owner can update the Product Backlog to focus on the most critical functionality for the customer. Focusing on the highest value work, the Scrum Team limits investment to the duration of the Sprint. If what they deliver is NOT useful, the team has only invested a short amount of time developing that functionality. It can easily change direction to focus on something that might be of greater value to the customer.
Delivery of value to the customer sooner
Using traditional development methods, the customer has to wait for EVERYTHING to get done before they can use ANYTHING. With Scrum, the Developers focus on delivering the most valuable work to the customer in smaller increments rather than in one large deliverable. This allows the customer and the business to start receiving value sooner.
Reducing risk faster
Because Scrum delivers end-to-end functionality sooner, the Developers can identify any integration issues much earlier than with traditional methods, saving a lot of rework! This benefit is SIGNIFICANT, particularly for larger initiatives with long-range goals. Delivering end-to-end functionality–but less of it, in smaller, more frequent deliveries–is a game changer.
How do you get to Done?
Sounds great, right? But how do you get to Done each Sprint? To get started, ensure that your Scrum Team has a workable Definition of Done, a well-refined Product Backlog, and is using the Sprint Retrospective to identify improvement opportunities.
Creating a Definition of Done
The first step to getting to Done is having a common understanding of what is meant by Done. There are many ways to have a conversation about a Scrum Team’s Definition of Done. I recommend Scrum Masters participate in the Professional Scrum Master II class for a helpful activity to engage their team in the discussion. Alternatively, the Scrum Master should bring up the Definition of Done in the Sprint Retrospective for further clarification and discussion.
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 correctly, the Scrum Team will be unable to deliver.
To position the Scrum Team for success, ensure that the highest ordered Product Backlog items are sized according to what the Developers can complete within a Sprint. What does this mean? If the Scrum Team chooses a Sprint duration of two weeks, each Product Backlog item should be sized such that it can be completed within two weeks, even if it requires multiple Developers to complete. Smaller is better regarding sizing Product Backlog items.Product Backlog items may be broken into multiple, smaller Product Backlog 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
There are many ways to conduct a productive Sprint Retrospective (check out our article for Ideas for Scrum’s Sprint Retrospective Event). The purpose of a Sprint is to deliver a Done, usable increment that meets the Sprint Goal. If the Scrum Team is not meeting this goal each Sprint, use the Sprint Retrospective to identify actionable improvements to how the Scrum Team works.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.