The purpose of Scrum is to create a useful Increment by the end of every Sprint. This is so important that people now use many terms to describe this Scrum artifact. Working. Usable. Releasable. Done. Done done.
However, many teams struggle to produce a Done Increment. Without working software or usable value, we don’t have transparency over progress and quality. We don’t have the ability to validate assumptions and learning.
In my experience, there are five common challenges to creating a Done Increment.
The Scrum Team is accountable as a whole to create a Done Increment by the end of the Sprint. When team members do not feel team ownership, or individuals only feel responsible for getting their Product Backlog item done, there is not a focus on the outcome of the Sprint.
A common sign of a lack of team ownership is a lot of WIP (work in progress). Product Backlog items in the Sprint Backlog are often “carried over” to the next sprint. Each individual is focused on getting their piece done and not looking at the whole plan, the whole team, the whole Increment. Quality issues are likely prevalent, but the team isn’t discussing them.
As a team moves through the stages of group development, they shift from coordination to collaboration. When people are collaborating, we are enabling the most creative and most effective solutions to rise to the surface. Without collaboration, solutions are constrained by the experience and knowledge of individuals.
This is closely related to team ownership, so you will often see a lot of WIP caused by team members each working on a different Product Backlog item. They may be talking to each other to coordinate the changes to the code or to ask questions and confirm the approach. However, they are not collaborating to get a piece of functionality done and then together tackling the next piece of value. Lack of collaboration can also create issues when teams try to integrate the individual work they have done. Perhaps they discover the design is not very cohesive or that it is even conflicting. Perhaps they discover a lot of refactoring, regression testing, or bug fixes remaining.
A Sprint Goal is a measurable objective set for the sprint that provides the team focus and flexibility. It is created through negotiation between the Product Owner and the Developers with support from the Scrum Master. Without a Sprint Goal, it is difficult to find focus as work emerges and the team experiences external pressures. The Developers may lose sight of what is most valuable and the purpose of building the Increment. There may even be arguments about what to work on next.
Here are a few questions to help determine if this is a challenge for your team:
The Sprint Backlog is expected to emerge during the Sprint as the Developers do the work to create the Increment. We don’t know everything about the features and functionality or the work to deliver them at the beginning of the Sprint.
So how do we balance allowing emergence with actually getting the Increment done?
A Sprint Goal is one way to ensure focus and flexibility. If you already have a clear Sprint Goal and are still struggling with too much change during the sprint, ask these questions:
Teams may have technical or process impediments slowing them down or blocking them from creating a Done Increment. It is easy to get overwhelmed by the expectations of delivering more product features faster and feel like there is no time for implementing improvements. However, removing impediments helps improve workflow and can result in higher quality and easier delivery of enhancements in the long-term.
Here are a few questions to ask regarding common impediments:
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.