Smarter ideas worth writing about.

Where's the Delivery? Common Increment Impediments

Tags: Agile Enablement

Six months into an agile transformation I have a director ask me a compelling question:

“Why is it taking so long to get things delivered? Isn't that why we did this?”

Me, quietly thrilled: “We didn’t empower, enable, or expect teams to produce an Increment at the end of each sprint.”

Director: “But the teams get to Done each sprint. They meet their definitions of done. That was a big deal in Sprint Review.”

“Yes, they worked hard and most teams meet their Definition of Done on most work each sprint.”

“So why aren't we delivering?”

“Easy. The teams' definitions of done are not Done. They aren't an Increment.”

“There's a difference?”


“Well what do they need to start producing an Increment that we can deliver?”

“I have a good idea. Why don't we talk to some Scrum Masters and Product Owners? They can give you specifics and its better coming from the source.”

An Increment is foundational Scrum, defined clearly by the Scrum Guide

"The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the Increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in usable condition and meet the Scrum Team’s definition of “Done.” An Increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The Increment is a step toward a vision or goal. The Increment must be in usable condition regardless of whether the Product Owner decides to release it." (Scrum guide)

Usable can mean many things. The Director clearly expects usable to mean 'ready to be released'. The Scrum Guide clearly states that an Increment should be ready for a release decision by the Product Owner (AKA usable). A teams’ Definition of Done is simply what the team has determined it can complete within a sprint. The difference is significant

New teams usually start with some gaps between their sprint Definition of Done and a decision-able, usable Increment that could be released. Teams quickly find ways to improve their Definition of Done and get as close to an Increment as they are capable and enabled to be, and then stall out when they hit Increment Impediments outside their influence.

Common Increment impediments include

  • Incomplete testing: Unit, Functional, User Acceptance, Performance, Penetration, Regression
  • Manual processes: Testing, data validation, build and release
  • Divided responsibilities: Database Administration, Services, Encryption, Environment Management, Testing, Build and Release administration, UI/UX
  • Security: User permissions and access, application security tools and requirements
  • Technical Debt: Inflexible applications, expensive infrastructure, legacy systems
  • Coupled Systems and Code: Spaghetti code, shared environments inevitable merge conflicts, inconsistent definitions of done within shared code, inconsistent branch and merge practices.
  • Big Bang Releases: Large Release overhead, dictated release schedule
  • Skill Debt: Skills missing from the team, SME bottlenecks, little practical experience with modern tools
  • Customer Access: Feedback loops, user acceptance testing

Those increment impediments are common for a reason. They are usually hard to incorporate into a team’s skill set, require changes to organization policy, or are simply so large that they can’t fit into a sprint. A Scrum Team is often not capable of resolving these impediments themselves and need allies and attention from their stakeholders in the organization to resolve them and improve their Definition of Done.

What’s holding This Team back?

Ask the Scrum Team. They can provide a clear view of their impediments.

A backlog of increment impediments is a useful tool in aligning people to this common goal. Here are some things to consider in your backlog/plan to remove Increment impediments:

  1. Anyone with profit and loss accountabilities for a team’s product is a stakeholder in removing Increment impediments. Activate them as soon as possible.
  2. The Scrum Team should Identify and clearly state each impediment. They own the Increment. They should state the problem. Example:

  3. The Scrum Team and stakeholders should collaborate on the business value and relative effort of resolving each impediment. In the Example shown: Data Validation was considered very valuable by the Scrum Team because early data validation would help them avoid data conflicts in their shared. The Stakeholders made the case, however, that User Acceptance Testing in this application would often impact what data best suited each screen in the integrated Increment. Everyone agreed that more value existed in UAT right now and that data validation was still very valuable. That discussion revealed that UAT should happen after each PBI was integrated to the shared Master code base so UAT participants could see how each piece linked to the whole application. Stakeholders were surprised that this wasn’t already happening. They immediately agreed that integration to the master code base for the application was the most valuable impediment to remove as it was the pre-requisite to so many others.
  4. The Product Owner should prioritize the Increment impediments, even if they are technical. If the team and stakeholders agree of the business value and effort of resolving each impediment, the Product Owner is in a perfect position to prioritize which impediments to resolve first and activate Both Groups in resolving them.
  5. The Scrum Master should ensure that the impact of Increment impediments on the scrum team is transparent to all.
  6. The Scrum Team and stakeholders should tackle impediments to the Increment one at a time, regardless of who has the most influence to resolve them. Resolving impediment one by one provides a clear view of its impact.
  7. The Scrum Team commits to add to its Definition of Done as Increment impediments are resolved and their skills allow.
  8. Scrum Masters can collaborate to find shared impediments across Scrum Teams, providing more value for each teams’ Increment.
  9. The Stakeholders should be ready to tackle process changes, fund architecture or technology changes, and talk about the impact of reducing Increment Impediments in the organization.

How do we get to an Increment and real, frequent delivery?

First, I encourage anyone in an organization with profit and loss accountabilities to understand exactly what is impeding a team’s ability to produce an Increment and participate in its resolution. A clear understanding of the costs, priority and architectural decisions required to create an Increment within a sprint creates an approachable backlog for Product Owners, Scrum Masters and Stakeholders to achieve together. That backlog requires a few things:

  • A clear Definition of Done for the Scrum Team
  • A clear definition of an Increment for your product
  • An assessment of the work required to get to an Increment
  • The right group of Stakeholders to resolve each impediment
  • A working agreement between the Stakeholders, Product Owner and Scrum Team on how they will work together to resolve the impediments

Second, measure the impacts of each impediment on delivery. Communicate the evidence of each impediments impact at removal. Achieving an Increment may be a long play. Measuring the impact to the team and the organization provides consistent motivation through the tough impediments.

Third, gain interested allies along the way.

How can I Motivate Stakeholders to Help Us Get There?

Increments are powerful. Increments are the compelling reward of doing Scrum. Increments give you the transparency to Be Agile as an organization. There are clear metrics, measures and visuals you can get from delivering Increments that are a compelling case for profit and loss accountable stakeholders. Curious about what you can get with a true Increment? Stay tuned. I’ll share my experience with Increments and strategic business decisions in my next post.


About The Author

Project Services Consultant

Summer is an active member of the Agile Advisory Services group at Cardinal Solutions in Columbus, a trainer, LeSS CP, SAFe SPC4 and agile practitioner of more than 10 years.