Delivery is the only Measure of Progress in Scrum

As a social technology, Scrum has remained steadfast in its ethos for over 32 years, enabling teams to generate value through adaptive solutions to complex problems. Yet, a subtle distinction in its guidance often trips up practitioners - Scrum explicitly mandates a Done Increment but implicitly mandates Delivery. This distinction, though subtle, holds profound implications in a modern context where DevOps has reshaped the landscape of software delivery.

TLDR;

Modern software engineering practices have made it easy to ship to production and validate that your product is of a quality level that would allow it. I would expect every Scrum Team to:

• deliver working software to at least some subset of real users every iteration, including the first
• turn feedback from users into concrete work items on timelines shorter than one month
• change the requirements based on user feedback

At a very minimum, I expect them to deliver their increments to production at least once per Sprint, preferably continuously.

Delivery as the Fundamental Measure of Progress

Scrum Teams are measured not by what they start but by what they finish, and more importantly, by what they deliver. A Done Increment is only as valuable as its ability to drive change and provide feedback in the hands of real users. Anything less is just inventory.

It’s time to shift the focus: delivery is not an afterthought, it is the measure of progress. In the 1990s, releasing software to production was a cumbersome, risky process, and the Scrum Guide was written in that world. Today, with modern DevOps capabilities, continuous delivery is not just possible, it is expected.

If a Scrum Team is producing Done Increments but not delivering them, they are not actually doing Scrum, they are simply simulating progress.

Done Is Not Enough

A Done Increment, according to Scrum, meets the Definition of Done: it is properly tested, meets quality standards, and is potentially shippable. But potential is not value, realised value comes only from delivery.

The distinction between Done and Delivered is simple:

• Done means the work meets an internal quality standard.
• Delivered means the work has been put into production and is creating impact.

If an Increment remains in staging or internal QA, it does not matter how refined or polished it is, it is not delivering value.

Why This Matters

The speed of market responsiveness defines competitive advantage today. A product that remains undelivered provides no feedback, no learning, and no adaptation. Organizations that mistake Done for Delivered risk falling behind more responsive competitors who understand that speed to value is everything.

A feature sitting on a shelf has the same business impact as a feature that was never built.

Delivery is what separates successful Scrum Teams from ineffective ones.

How to Ensure Delivery Becomes the Default

Scrum Teams must reframe their Definition of Done to include deployment while ensuring that they don’t inadvertently compromise it. Every Sprint should result in increments that go into production. Here’s how teams can bridge the gap:

1. Automate Everything

   If your release process requires manual intervention, it is a liability. CI/CD pipelines eliminate constraints and ensure every increment is delivered safely and efficiently. Don’t end up like the Knight Capital Group or CrowdStrike.

2. Treat Delivery as a First-Class Citizen

   The goal of every Sprint should not be to produce an increment, it should be to deliver value. A backlog item is not complete until users are benefiting from it.

3. Inspect User Impact, Not Just Internal Quality

   Sprint Reviews should not be about demonstrating functionality in a staging environment; they should be about real user impact. What changed for the customer? What insights did we gain from their usage?

4. Break Down Barriers

   Silos between development, operations, security, and compliance must be removed. Cross-functional teams should be fully empowered to deploy without external dependencies.

5. Make Undelivered Work Visible

   Track work that is “Done but not Delivered.” If work is piling up, ask why. This is an issue of flow, not just completion.

Remember usable working product is how we manage risk and deliver value. If you are not delivering, you are not managing risk, and you are not delivering value.

Conclusion

In 2025, there is no reason why a Done Increment should not be delivered. The tools, practices, and knowledge exist. The only thing standing in the way is outdated ways of thinking.

Delivery is no longer just an aspiration, it is the fundamental measure of progress. The ability to deliver frequently, safely, and reliably is what makes a Scrum Team truly professional.

The question is no longer “Are we Done?” but “Have we Delivered?”