When Your Sprint Falls Behind: The Shortest Processing Time Strategy That Agile Teams Wish They'd Known Earlier

Picture this: It’s Thursday of your two-week sprint, and you’re staring at a board full of “In Progress” stories with none marked “Done.” Your Product Owner is asking about delivery commitments, your developers are stressed, and stakeholders are losing faith in your team’s ability to deliver predictably.

Sound familiar? If you’re a CTO or Scrum Master, you’ve lived this nightmare. But what if I told you that factory floor managers solved this exact problem decades ago?

The Manufacturing Lesson Your Agile Training Missed

In manufacturing, when production falls behind schedule, there’s a proven strategy called Shortest Processing Time (SPT). It’s simple: when you’re late, prioritise completing the quickest tasks first.

Why does this work? SPT maximises the number of completed items in any given timeframe. More completed items mean more value delivered, more stakeholder confidence, and crucially – more learning about your team’s actual capacity.

But here’s where most development teams get it wrong: they apply SPT blindly to story points or time estimates, ignoring the real value equation.

The User Story Priority Matrix When You’re Behind

When your sprint is failing, you need a different lens for prioritisation. Here’s the framework I use with my CTO clients:

1. Step 1: Separate Your Stories Into Three Buckets

• Quick Wins (≤ 2 days, high business value)
• Essential Foundations (any size, but critical for sprint’s qualitative goal)
• Everything Else (can potentially wait for next sprint)

2. Step 2: Apply Modified SPT

Within each bucket, prioritise by effort required. This has to be a quick scan, you did the planning, you must have a feel for the effort. If this prioritisation takes too long, it beats the purpose. And importantly,  never sacrifice an Essential Foundation for a Quick Win that doesn’t support your sprint goal.

3. Step 3: The Hard Conversations

This is where most teams fail. In the long run, you will build trust with your Product owner if you have those Hard Conversations about what gets dropped.

Why This Matters Beyond Sprint Success

When you successfully apply SPT thinking to failing sprints, you achieve three critical outcomes that directly impact your bottom line:

1. Stakeholder Trust: Consistent delivery of working software, even if reduced scope

2. Team Confidence: Success breeds success; completed stories motivate teams

3. Data-Driven Capacity: You learn your team’s actual throughput, not theoretical capacity

The Common Pitfalls (And How to Avoid Them)

Pitfall 1: Story Point Obsession

Don’t just chase the lowest story points. A 1-point story that delivers no business value is worthless compared to a 5-point story that unlocks customer value.

Pitfall 2: Ignoring Dependencies

SPT assumes tasks are independent, as your user stories should be (if you are struggling with making your User Stories independent, you will be interested in my workshop). Map dependencies before applying SPT principles, if your User Stories are not independent.

The Bigger Picture

Shortest Processing Time isn’t just about sprint recovery – it’s about building predictable delivery capabilities that scale with your business. When stakeholders trust your team’s delivery commitments, they make better strategic decisions. When your team consistently delivers complete work, they build the confidence to tackle bigger challenges.

---