Iteratively Delivering Large Quantities of Nothing

Earlier in my career, I worked with a team that, on paper, looked great. They had two-week sprints, predictable velocity, solid flow metrics, Jira was up to date, and standups were consistent. By every internal metric, they were doing Agile right.

Every sprint review was the same: a list of completed stories, a summary of progress, and... nothing users could see, interact with, or benefit from. The work was real, and the features were fine, but it was taking them 10 weeks of delivery before a user could tell anything had changed.

The turning point.

We were in a coaching session, and I was doing my best to explain outcome-based sprint goals. The idea of focusing on outcomes over outputs wasn’t landing, until their supervisor leaned back and said:

“So after two weeks of development, we should be able to tell a user what to click on and what’ll happen when they do?”

It was a bit of an oversimplification, but it reframed everything. It's not about metrics and ceremonies. It's about value—tangible, testable, user-facing value. After this, the team started asking the question "What will the user see when we finish this?" during sprint planning.

The result? Not only did they deliver value every sprint, they also learned that in some cases, what they shipped was all the user actually needed. Had they delivered their perfect version in 10 weeks, they would've basically wasted 8 weeks of development time and never known it.

Iteration Without Value Is Just Waterfall

It’s easy to fall into the trap of looking productive while avoiding actual delivery. You can run sprints, update Jira, and check every Agile box, but if no one can use what you built, you’re just doing waterfall in two-week increments.

(Note: Before the system architects out there hit Send on their hate mail, it's totally fine if a sprint delivers non-UI work, like improved reliability, performance, or security, extended architectural runway, or mitigated risk. It just needs to tie back to a near-term user benefit.)

Agile is not about breaking work into smaller tasks and calling them stories. It's about delivering incremental value that users can see, use, and react to. The longer it takes to ship something usable, the more likely priorities shift, leadership pivots, or the market moves. What made sense at sprint one may not matter by sprint five.

That’s why delivery should be treated as hypothesis testing. You’re not aiming for a perfect, feature-complete system right out of the gate. You’re aiming to validate that you’re building the right thing. It still needs to be well-engineered (tested, deployed through pipelines, supported by rollback plans) but it also needs to be usable now, not after every single piece ties together perfectly.

If I’m getting mauled by a mountain lion on the trail, a rock within reach may not be the best deterrent, but it's better than waiting around for something perfect.

What can the user do now?

If your team looks good on paper but isn't delivering something usable every sprint, ask this simple question during sprint planning:

After this sprint, what can a user do that they currently can't?

If the answer is vague, internal-only, or non-existent, you're not delivering value. You're just organizing delay.

And if you're stuck in that loop and need a way out? Give me a call.