Failed Agile Sprints

Agile teams using the Scrum framework commit to delivering value in each development sprint. Sprints are generally 2-weeks long, and the goal is to create working software that can be deployed into production. While commitment is one of Scrum’s core values [1], in reality, teams do not always complete the work. This is commonly known as a “failed sprint.”

Failed sprints affect the team as well as their stakeholders. The measurable impact is fewer stories (scope) delivered than expected. Less visibly, team morale can suffer as well as relationships with the product owner, customers, and management. Where failed sprints are recurrent, there is often frustration and a loss of trust.

Failed sprints are more common than we would like. Identifying the root cause and correcting the underlying issues is often difficult. In this article, I explain committed delivery, ways of measuring performance, and sources of and options for addressing failed sprints.

How Sprints Work

Scrum teams try to deliver value in each development sprint. The product owner works with the customers and stakeholders to build the product backlog, which is a comprehensive, prioritized list of the items (stories) they want. As items are added to the product backlog, the development team estimates the effort to complete that work using story points.

Story points [2] are a sizing technique where teams can quickly guestimate the relative effort required to deliver an item, and then assign a numeric value (story point). Based on past performance, teams can reasonably predict their capacity to deliver work in upcoming sprints.

Defining the scope of work for the sprint is a matter of taking the highest priority stories off the product backlog and placing them on the sprint backlog (work to be completed in that sprint) until the capacity is filled.

Measuring Performance

Agile is built on the foundation of systems thinking, which promotes data-driven decision making. Sprint velocity is a key team performance measure. Velocity is the amount of work (measured in story points) delivered in each sprint.

It is easy to measure sprint velocity and variance from the plan. Sprint velocity charts [3] show the difference between the committed and the completed work (measured in story points). Teams can use this information to learn, improve, and adapt.

Expecting teams always to meet their sprint commitment creates unachievable expectations, which may lead to undesired behaviors such as sandbagging [4] performance. Mike Cohn [5] has suggested that we should expect that on-average, teams complete 80% of their sprints. Setting this expectation provides the product owner and stakeholders with sufficient confidence in the team’s ability without establishing an unattainable goal.

Why Sprints Fail

There are several reasons teams fail to meet their sprint commitments. Most often, failed sprints are a symptom of other problems. When there is a pattern of failed sprints, it is time to take corrective action. The following are common causes of sprint failure and options for improving performance:

Overconfidence

A human trait is overestimating our capabilities. A recent survey [6] found that 65% of Americans believe they are smarter than average. Overconfidence spills over into expectations of how much work we can accomplish. We can use historical data (story points delivered vs. planned) to have a fact-based conversation.

Overconfidence can be tempered by creating guidelines that limit the team’s capacity estimates. For example, the team's capacity for the next sprint cannot be higher than their past performance. If the team generally delivers 50 points per sprint, then we can expect they will continue to do the same. It is unlikely they will magically deliver 75 or 100 points in the next sprint.

Constraining capacity to historical performance also alleviates external pressures. Product owners and senior management often want to see teams increasing their velocity. Limiting increases to demonstrated performance avoids this pitfall.

Unplanned Work

An unstated assumption is that the team's efforts are dedicated to completing items in the sprint backlog. Unfortunately, this is often not true. Unplanned work gets in the way. Unplanned work is anything not accounted for during sprint planning and not listed in the sprint backlog. It includes production issues, urgent requests from management, or unexpected meetings.

We cannot eliminate unplanned work, but we can try to minimize its impact; strategies include:

Creating transparency. We can create transparency into the unplanned work by itemizing the items and the relative effort of the work. Often teams, product owners, and management are unaware of the time spent and productivity loss. Simply creating visibility into unplanned work can often reduce it.

Reserving capacity. We can reserve capacity during sprint planning for unplanned work. For example, if the team generally completes 60 story points each sprint and they spend about 5 points on unplanned work, then they should only commit to 55 points of new development.

Prioritizing the unplanned work. The product owner should prioritize the unplanned work within the sprint backlog. Making this explicit trade-off between the unplanned and planned work keeps the team focused on delivering value.

Protecting the team. One of the scrum master’s roles is to protect the team. Management requests (fire drills) are often perceived to be urgent and can derail the team's progress. Usually, these items can be handled with minimal disruption if we first consider the options before responding.

Poorly Understood Work

Agile teams strive to maximize the value delivered, which means that they want to optimize their productivity during the sprint. The team should be focused on tasks associated with completing stories—design, build, and test. In other words, clarifying stories, analyzing needs, and researching options should occur before the sprint.

To mitigate the risk that stories are not well understood, teams should actively review the product backlog. During the current sprint, the team should reserve time to review items in the backlog that will be included in the next 2-3 sprints. If they have questions, they can ask for clarification. If the story is too large, they can split [7] it into smaller stories. If the story requires additional research, they can plan a spike story [8] to analyze the problem.

Agile uses the principles of progressive elaboration. As stories move up the product backlog, they should be refined. By the time they are included in the sprint, the team should be ready to execute them.

Stuck on a Problem

We all have experienced a time where we were stuck on a problem but unwilling to admit it. Rather than asking for help, we invest more effort often with little benefit. Agile promotes a collaboration. Scrum got its name from rugby, where the team locks arms and works together to move the ball up the field.

Successful agile teams create an environment where teamwork is valued. Team members should feel safe, admitting they are stuck and asking for assistance. We also want to monitor progress so that bottlenecks and issues are identified early. Practices such as paired-programming [9] and mentoring can be used to resolve problems quickly.

Agile promotes team success. Agile practices of backlog grooming and sprint planning create the opportunity for the team to regularly review upcoming work and the team’s capacity to complete that work. The daily stand-up allows the team to identify and address problems as they arise. The sprint retrospective is a great place to review their performance and identify ways to improve for the next increment.

To learn more about our training and consulting services, or to subscribe to our Newsletter, visit our website: www.pmessentials.us [10].

Related Project Management Essentials articles:

Image courtesy of: YouTube.com