The cure for bad estimates
What can we do when developers systematically underestimate and misinterpret their tickets?
Every manager who struggles with planning, struggles in the exact same way. They have a result in mind and try to guide the developers to reach that goal on time. They’ll put their engineers in the starting blocks, show them the route of the race and fire their guns. Ready. Set. Code!
That never seems to go as intended.
When the engineers finally pick up their tickets, they begin raising basic questions that should have been answered weeks ago. They'll ask about edge cases and design choices. Simple things seem to turn complicated as soon as fingers hit the keyboard.
And so managers manage. They reduce sprint commitment. They pad estimates. They add some buffers. They write tomes with acceptance criteria and design specs. They'll spend ages refining and tweaking PRDs to spoon-feed the solution. And still, somehow, in the last 500m, some extra kilometres are added to the race.
Why is that? What can we do when developers systematically underestimate and misinterpret their tickets?
The answer does not lie in better estimates. Or at least, that's not the angle to attack this problem. The root cause of systematic underestimation is a poor understanding of the problem. Bad estimates and late questions are just symptoms of that issue.
Developers who don't understand the problem they are asked to solve, can't solve that problem efficiently. They are exploring the problem and the solution at the same time. And for every solution they uncover, they have to ask permission. That's worse than a trial-and-error approach! Of course, that's not as productive as we would like.
The way out of this is to ditch the specification altogether. Stop writing PRDs. Stop the functional analysis. No more upfront solutioning. Write problem descriptions instead.
A problem description is a document that gives developers the tools to instantly understand the customer's need without containing a blueprint for the solution. At the start of the focus block, pitch the problem to the developers and let them come up with the solution.
When engineers are treated as problem-solvers instead of typists, those pesky edge cases and what-if questions are uncovered much sooner. We find out an integration is a lot more complicated at the start of the race instead of in the last 500m. Maybe we can skip it altogether? Engineers who understand both problem and solution are so much better at getting their estimates right.
It’s often easier said than done. Designing a solution requires maturity from the engineering team. And staying away from specification demands a lot of willpower from product managers. But whenever I've implemented this approach, without exception, the results have been stellar. Fewer bugs and misunderstandings. Improved productivity. But most importantly, predictable planning.
In my experience, developers who understand the problem and tell me it will take the next two weeks to solve, solve said problem within two weeks.
Don't take my word for it. Give it a shot.
For your next feature, write a problem description instead of a PRD. Let your team figure out the solution and watch the magic happen.