How to Measure Progress in a Software Project

"Working software is the primary measure of progress."

This simple sentence from the Principles behind the Agile Manifesto has deep implications.

To understand it, first notice what it doesn't say. It doesn't claim that measuring progress involves estimating backlog items, where the sum of incomplete items equals the time to completion.

Nor does it suggest that measuring progress is about assigning story points to backlog items, where the velocity per sprint multiplied by remaining story points equals the number of sprints to completion.

In fact, it says nothing about estimates or sizing. There is no mention in the entire Agile Manifesto of anything you could use to make a projection of any kind. Read it if you don't believe me. It's not there.

Instead, the Agile Manifesto takes a novel approach and boldly asserts that working software is the primary measure of progress. A seemingly obvious statement, almost tautological, but its ramifications are significant.

The Agile Manifesto is a reaction to a time when estimates and projections were a central focus of software development. Managers and developers spent months planning and estimating, trying to figure out how long a project would take. They desperately wanted to make this paradigm work. They tried everything. But they failed. Their software projects constantly ran over time and exceeded budgets.

But the Agile Manifesto proposed a new way. Its great innovation was to move away from projections entirely and rely on the only thing you could know for certain: the state of the software you had working at a given moment in time. You could run it, test it, even give it to a customer. It was the incontrovertible truth. You could take it to the bank.

Pairing that with the practice of delivering software frequently, Agile created a new way of measuring progress. Evaluate the state of your software, code some more (but only for a few weeks), then begin the process again.

It's a simple idea, but powerful.

With a customer, it goes like this: code something, get some feedback, code something else, get more feedback. Continue until the customer is satisfied.

Think of a swimmer in the ocean: they put their head underwater and swim for a while; they stop and tread water, looking around to see where they are; they decide which direction to swim next; they repeat this process until they get somewhere significant.

In Agile, "simplicity—the art of maximizing the amount of work not done—is essential." You don't waste time on things you're never going to build. You focus only on the next target. When the (sometimes internal) customer finally says, "Yeah, that's going to work for us; we'll call you if we need anything else," everything you could have built vanishes into the ether, never more than a passing fancy. Leaving no estimates, architecture diagrams, or meeting minutes.

And if you ever start coding the wrong thing, because you get feedback quickly, you don't waste much time before changing course. (And is it really wasted time if you've efficiently determined what your customer really needs?)

But what happened to this innovative new way of measuring progress? Sadly, Agile (in name only) practitioners have returned to estimates and projections—product backlogs, velocities, burn-down charts, cycle times, etc. We are back to diverting our attention to things we might never build. Back to sizing, going to meetings, and navel-gazing. We've dressed up old, waterfall processes in shiny new jackets with the word 'Agile' written across the back. But, the inevitable results will be the failed projects we tried to escape decades ago.