Measuring Progress: The Value of Working Software

Back to Basics Series – Principle 7

Working software is the primary measure of progress.

https://agilemanifesto.org/principles.html

What Does It Mean?

This principle is deceptively simple: the best way to know if we’re making progress is by seeing real, usable software in the hands of users. It’s not about counting story points, tracking velocity, or completing checklists. Progress is tangible when the software actually works and delivers value.

Agile flips the traditional notion of “progress reporting” on its head. Instead of dashboards or status reports, the measure is real outcomes.

My Experience

I’ve worked with companies obsessed with metrics like velocity and burndown charts. Those numbers looked great on paper, but when the release finally hit users, the feedback wasn’t flattering. Features were incomplete, misaligned with user needs, or never even made it into production.

On the flip side, I coached a team that prioritized delivering a minimal, working version of each feature every sprint. Even if it wasn’t fully polished, they got feedback early, fixed issues, and iterated. By the end of the quarter, they had software that actually solved problems for users—progress they could see, measure, and celebrate.

Why This Matters

Focusing on working software keeps teams aligned with what truly matters: value delivered to customers. When we fixate on metrics, process, or artifacts instead, we risk losing sight of the end goal.

Teams that measure progress by working software:

  • Identify problems early.
  • Adapt features to actual user needs.
  • Avoid wasted effort on deliverables that don’t matter.

Teams that measure progress by points or documents:

  • Chase the wrong targets.
  • Celebrate work completed, not work that matters.
  • Risk delivering irrelevant or low-value features.

The principle is a reminder: if it’s not working software, it’s not progress.

Take It to Your Team

For your next retrospective or sprint review:

  • Look at the work delivered in the last sprint. Did it produce working software?
  • Ask: How do we know this actually delivers value to the customer?
  • Brainstorm one small change to ensure that every sprint includes something tangible and usable for users.

This isn’t about shipping unfinished products—it’s about using working software as your true north for measuring progress.

Leave a comment