The purpose of Scrum is to create a potentially shippable Increment by the end of a Sprint. This is so important that people now use many terms to describe this Scrum artifact. Working. Releasable. Done. Done done. However, many teams struggle to produce a done Increment. Without working software, 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.
1. Lack of Team Ownership
The Development 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, 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.
2. Lack of Collaboration
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 functionality. 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.
3. There is Not a Clear Sprint Goal
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 Development Team. Without a sprint goal, it is difficult to find focus as work emerges and the team experiences external pressures. The Development Team 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:
- There is no sprint goal. The expectation is to complete all of the product backlog items in the Sprint Backlog. There is little focus and little flexibility here.
- The sprint goal is vague. At the end of a sprint, do all team members know with 100% certainty whether or not the sprint goal was met?
- The sprint goal is too big. Compound sprint goals (X and Y and Z) may not provide enough focus and flexibility.
4. Too Much Change During the Sprint
The Sprint Backlog is expected to emerge during the Sprint as the Development Team does the work to build 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:
- Is someone outside the Development Team assigning other work? Are Development Team members doing other work?
- Is the Product Owner changing the sprint goal during the Sprint?
- Are we discovering diverging perspectives on what a product backlog item actually means during the Sprint?
5. Impediments Are Not Being Removed
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:
- Does the environment go down frequently?
- Does the team have the knowledge and tools they need to implement automation?
- Is there someone outside the team who has to perform certain tasks or provide approvals in order to create a done Increment?