Why Can the Last 2% Hold Up the Whole Feature?
Part 2 of 3
"There's only a little bit left. When will it be finished?"
It's a fair question. The feature's been sitting at 98% for a while, most of the work is done, and surely the last bit is quick?
Sometimes it is. Once somebody makes the decision that lets it happen.
Small decisions are the hardest thing to explain in a programme report. The effort to implement them can be tiny next to everything built around them, and their effect on whether anything can go live can be enormous.
What does 98% actually mean?
On one programme we had a new form built on an existing CRM data structure. We understood its purpose and knew it would be fairly simple. What the business hadn't settled was which fields it should contain. We could make sensible assumptions about names and email addresses, but sensible assumptions don't finish a form and its API. The journey crossed four systems, and while the teams could test individual pieces and check the page against the design, nobody could validate the journey end to end, or complete the security testing that hung off it.
A dropdown elsewhere on the programme was the gentle version of the same problem. It needed a subset of values from a long CRM field, nobody had confirmed which, so we built it with the full list in the meantime and carried on. Annoying, contained, and fine.
Same size of decision, very different size of consequence. The size of a decision is a poor guide to the scale of work it can hold up.
Look at the feature plan for the form and it's an honest account of progress. Design done, front end and back end largely built, specification nearly complete. Nobody invented any of that. But a percentage can't tell you when something becomes usable. The client sees a small distance to the finish. Engineering sees a small amount of work it can't yet do. QA sees a journey it can't validate. One number is being asked to describe three different experiences.
Why was it green?
Because it was nearly done and only waiting on one little decision, and the decision wasn't urgent. So it sat at green on the weekly status report. Then it sat there the week after, and the week after that, with the number not moving.
At first it's a success, 98%, everyone's pleased. Then it becomes a bit uncomfortable to repeat. Then it becomes a bit of a joke. That levity is necessary, because teams need it, but it can also underplay how serious things are getting. Sitting at 98% in month three or four of a fifteen-month programme is a comfortable place to be. By month nine or ten there isn't much runway left, and 2% plus QA stops being a problem for later.
Image photo: Anete Lusina / Pexels
What gets lost between the tickets?
The original estimate might allow a day to build an API once the behaviour's known, and most of that day may already be spent. What it doesn't capture is the engineer coming back to it, checking whether an answer has arrived, asking whether the ticket reflects the latest position, switching to something else, and rebuilding the context a week later. Testing has its own version. Validating the available pieces early is useful and not wasted, but you still have to allow for the integrated checks, and for repeating some of them once the final decision lands.
Accounting for every interruption would create more administration than insight. Assuming fragmentation costs nothing makes the remaining estimate look better than it is.
We worked around unresolved decisions by progressing other work and building as far as we responsibly could. That kept people busy, and it also left more and more work parked near the finish line. "Stop starting, start finishing" is a lovely slogan. It's less useful when finishing needs answers the engineering team doesn't own.
What did I do about it?
First, a confession. This came up casually. Often flippantly, often at the end of a sprint demo: "we're just waiting on the field confirmations." That's as much my responsibility as anyone's, because plenty of the time I was the one saying it, in exactly the same easy tone.
The client was already keeping a list of outstanding questions, so another list wasn't going to help. What helped was making the consequence visible, in the room where it mattered. A sprint demo is a good moment to show what's been built and why other things haven't. So I'd say it plainly: we're still waiting on a decision on the form fields for this one, and we can't progress the rest of the feature without it. A BA would take a note, the call would end, and it would join the list as it always did. But now most of the people who needed to make that decision had heard, out loud, what they were holding up. I was careful not to put the BA in a bad position. It was very rarely them alone, and the point was never to name someone, only to show everyone what the question was costing.
That meant five or ten micro conversations, not one hour-long meeting to refine and agree and fail and repeat. Another workshop won't resolve an approval bottleneck unless it changes who can decide, or gives them what they need to decide. If we already know the people in the room won't have the authority and the session can't get us to an authorised answer, scheduling it as a decision-making meeting just adds another wait.
It also helped to bring a recommendation alongside the question. "We'd suggest this option, for these reasons, can you confirm?" gives someone something to say yes to, which is a much easier job than starting from a blank page. And telling the UAT teams what was missing, and why, meant a partly testable feature didn't just look like a delivery team running late.
Some decisions sped up. Others still needed wider input, and visibility didn't change that. It just made it easier to see which to chase first.
The useful question at 98% isn't "what's left?" It's what's stopping this becoming something people can use, who can unblock it, and when the programme needs them to.
Next: approval rights, the sensible idea that is also very good at stalling a deadline.
Earlier in this series: Part 1
Comments