Delivery Diagnostics

When delivery stalls, the instinct is to work harder. Add more people. Stay later. Push the sprint. The discipline is to diagnose first.

Most teams I work with aren't slow because they lack effort. They're slow because multiple small friction points are compounding - and nobody has stopped to identify which ones actually matter. This framework gives you a structured way to find the root cause before you prescribe a fix.

When to run a diagnostic

Don't wait for a crisis. If you see two or more of these signals in the same iteration, it's time:

Signal	What it might mean
Velocity declining over 2+ iterations	Fatigue, scope creep, technical debt, or unclear stories
Stories carrying over consistently	Over-commitment, underestimation, or blocked dependencies
Bugs and rework increasing	Quality practices are being skipped under pressure
Team morale dropping	Chronic overwork, lack of autonomy, or persistent blockers
Stakeholders surprised by progress	Communication gaps or misaligned expectations
"It feels slow but I can't explain why"	Multiple small friction points compounding

The diagnostic process

Step 1: Gather the data (30-60 minutes)

Collect these metrics for the last 3-5 iterations:

• Stories committed vs. completed - are you over-committing or under-delivering?
• Carry-over stories - which stories keep not finishing? Why those specifically?
• Cycle time (story start to done) - are stories taking longer? Which ones?
• Bug count and rework rate - is quality slipping?
• Blocker frequency - what's stopping the team from making progress?
• Pairing rate - has it dropped off? (Often a leading indicator of fatigue.)
• Retro action item completion - are you identifying problems but not fixing them?

If you don't have clean data, that's itself a finding. Teams without visibility into their own performance can't self-correct.

Step 2: Identify the pattern (30 minutes)

Look at the data and ask: what story does it tell?

Pattern	Data signature	Likely root cause
Overcommitment	Committed >> Completed, every iteration	Planning without velocity data; pressure to promise more
Scope creep	Stories grow mid-iteration; "done" keeps moving	Vague acceptance criteria (tighter story writing helps); requirements aren't agreed upon
Technical debt drag	Cycle time increasing on similar-sized stories	Accumulated shortcuts are slowing new work
Dependency blocking	Specific stories blocked repeatedly	External teams or approvals creating bottlenecks
Quality erosion	Bug count rising; velocity looks okay but outcomes suffer	TDD or reviews being skipped under time pressure
Team fatigue	Velocity declining gradually; pairing drops; retros feel flat	Unsustainable pace; too many priorities
Communication gaps	Stakeholders surprised; stories rejected in demos	PM not connecting team work to business context

Step 3: Form a hypothesis

Write it down in this format:

We believe the primary delivery issue is [pattern], caused by [root cause]. Evidence: [cite specific data points]. If we're right, we'd expect to see [what would happen without intervention].

Writing the hypothesis forces precision. "We're slow" becomes "We're over-committing by 30% every iteration because we plan from aspiration instead of last iteration's actual velocity."

Step 4: Design a targeted intervention

Pick the one thing most likely to address the root cause. Not three things. Not a process overhaul. One focused change.

Root cause	Targeted intervention
Overcommitment	Cap next iteration's commitment at last iteration's actual completion
Scope creep	Require written acceptance criteria before stories enter planning
Technical debt	Allocate 20% of each iteration to debt reduction; track it visibly
Dependency blocking	Escalate with a specific ask and deadline; protect the team's other work
Quality erosion	Reintroduce pairing for complex stories; make test coverage visible
Team fatigue	Reduce scope by 25% for one iteration; protect time for recovery

Step 5: Measure the result

Give the intervention two iterations. Then check the data again. Did the pattern change? If yes, keep going. If not, your hypothesis was wrong - go back to Step 2 with new information.

The meta-diagnostic

If you run diagnostics and the team keeps cycling through the same problems, the issue isn't at the team level - a product audit and reset can help you see structural patterns. Look one level up:

• Is leadership changing priorities faster than the team can deliver?
• Are organizational processes (approvals, compliance, vendor reviews) creating structural delays?
• Is the team staffed for what they're being asked to deliver?

These organizational patterns require different interventions - usually conversations, not process changes.

A real example: the 12 weeks hiding in the handoffs

At Kaiser Permanente, a $350M portfolio "felt slow," but nobody could point to where the time went, exactly the "it feels slow but I can't explain why" signal at the bottom of the table above. The instinct in an organization that size is to add process. We did the opposite and gathered the data first.

The diagnostic surfaced a pattern no single team could see from inside its own sprint: cycle time was bleeding out in the gaps between teams, not within them. Last-minute ADA compliance requirements triggered rework cycles, dependencies were chronically underestimated, and backlog-quality issues slowed everything downstream. None of it showed up as a line item until value stream mapping made the handoffs visible.

One portfolio took its mapping findings and cut 12 weeks from its delivery cycle, not by working harder, but by fixing the three specific handoffs the data named. That is the whole point of diagnosing before prescribing: the fix was precise because the diagnosis was. (Full case study.)

Try this today

Pull up your last three iterations' data. Compare committed vs. completed stories. If there's a consistent gap, you've found your first diagnostic signal. Start there.