Percent-done is the only number in engineering that never goes down. That should bother you more than it does.
Watch it move. A developer says 50%, then 75%, then 82%, then 84%, climbing toward finished and never arriving. They are not lying to you. They know two things you can verify yourself: the denominator is growing as they learn what the work actually is, and the number cannot go backward without a conversation nobody wants to have. So they increment it a little at a time and hope to catch up. Meanwhile the status roll-up becomes the sentence every executive has heard: what you have to understand is, we are basically almost done, even though everything still looks in progress. Estimates get treated as truth, done gets claimed off a branch or a staging box, and nobody in the building can tell you how fast the team is moving.
The fix is not a better estimate. It is a different instrument. Percentages are what you say. A working thing running in production is what you can show. So stop asking how far along someone feels and hold the work up in front of a real audience on a date that cannot move. The demo is the yardstick, and nothing counts until it is real.
Set the beat
Put a recurring demo on the calendar with a real audience and an immovable date. At Strella that was every Friday, to the CEO and the COO. Not a status update, a demo of the specific thing that now worked. The date is the whole point, because committing to show real progress every week reverse-engineers everything upstream of it: a backlog worth showing, the right people on the right work, and increments small enough to finish. You change the rhythm first, and the rhythm changes the code.
Make done binary, and done means production
A story is done or it is not. Never a percentage. And done has exactly one definition: shipped to production, where a customer can use it. On the developer's machine is not done. In staging is not done. On the branch is not done. Claiming done from a staging box is the same theater as the 82%, just one step later and better dressed. Break work down so every story is completable in a few days and small enough to ship, because only shipped, working software counts.
Quantize the board
Every story sits in one of three states: not started, in progress, done. The unit is the whole user story, never the tasks inside it, because task counts move as you learn (which is the denominator problem again wearing a different hat). And in progress is not one column. It is at least three, Development, Test, and In Review, each with entrance criteria strict enough to act like a diode. Work only flows forward. Do that and the board turns from a standup prop into arithmetic: Feature Foo has thirty stories, fifteen in the backlog, five in progress, ten done. That is a third of the way, and I can see it without calling a meeting.
Read the velocity
Count what actually shipped, beat over beat, and the team's true speed becomes something you can observe instead of something you negotiate. One ratio carries a surprising amount of that: in-progress stories divided by engineers, which tells you how loaded a team is at any altitude, from a single feature up to the whole portfolio. Roll it up and the bank book becomes a general ledger. I can see which teams are falling behind and which ones have room to help (yes, I have read Fred Brooks, I know that is not always possible), and my time with my directs goes to what we do next instead of to reporting status with performative confidence.
Watch the acceleration
Everything above is the rear-view mirror. It tells you where the team has been. The windshield is the rate of change: not the velocity, the change in the velocity, along with dwell time (how long a story sits in one column before it moves). Healthy teams speed up and their dwell drops. When tech debt, a support fire, or a clumsy new process starts to bite, those two numbers go retrograde first, well before a single date slips, while every status report still says green. A little deceleration is a summer Friday. A sustained one is my cue to go and look, and I get to look while there is still time to help, instead of after the date is already gone.
What it bought
Strella was a Series A in chaos when I got there: the team had the motions but not the machine, daily standups and plenty of work in progress with no clear line from the churn to anything shipping. We installed one fixed beat and killed percentage reporting in the same week, and then we shipped every single week. The eighteen-month plan delivered in four months. Three SaaS products in market, one of them a shipping-optimization product we added along the way, running across three continents once we integrated with the partner that took the company worldwide. On the customer side of it, inventory shrink dropped by about half.
None of that came from working harder. It came from the beat. A weekly demo forces increments small enough to finish, and only work that finishes compounds. From the outside, folding eighteen months of plan into four looks like heroics. It is the opposite: what a team produces when it stops burning energy on status reporting and on re-planning work that was never sized to land.
The pattern has held everywhere I have run it. A four-person team that grew Azure DevTest Labs past thirty. A 200-plus organization running the $1B IoT platform at Microsoft. Dexcom, where it bent around regulated med-tech tooling and still worked. Four very different environments, one instrument, and in none of them did it depend on a particular cast of characters.
Percent-done is a story. Done is a demo.