When we talk about the difficulty of planning for software products, we tend to look at it as a technical problem. It's hard to make predictions. It's hard to navigate the potential outcomes of future events. We look at how estimates rot and how future complexity hinders predictability.
When talking to tech leaders, I'm always fascinated by the ingenious tools they develop to improve their predictions. From traditional Story Points with "reference stories" to hand-crafted estimation formulas.
I once worked with a company that devised an intricate flow chart that generated a complexity metric. "Does it touch the database? Add 2 points". Every story went through this flow, and the team included the complexity metric during the sprint planning session.
Another company I interviewed had a more personal approach. Every developer tracked how long it took to complete a ticket. Based on that, a spreadsheet calculated how "off" the developer was. The planner took into account each developer's "engineering coefficient".
"It's estimated to take five days, but given his coefficient, Bill can do it in 4".
I personally once devised a planning system with an upper and lower bound. We would get a best-case projection, a worst-case one, and an average. The closer we came to the deadline, the more those converged on the real delivery date.
These elaborate ways of getting better projections aren't exactly futile. I know cynics will disagree, but teams really can get better at estimating and projecting.
What fascinates me is how little better estimates contribute to more predictable plans. You could come up with the perfect formula, and it would make barely a dent in the future.
We could build an AI that would allow us to master estimation. In theory, we could train a model on Jira data. Not just the team's tickets but every ticket ever handled in the history of issue trackers. It would answer some complex questions. How long does it take this team to close five story points? How much do they deviate from this estimate after a month? Three months? What's the impact of touching that brittle legacy system on plan stability?
Given enough training, the model would be able to estimate a story for us. Someone would write As A ___ I Want To ___, and JiraGPT would be able to accurately predict 15 hours of work. It would even suggest which devs to assign. This isn't impossible.
But it wouldn't make a difference.
Here's a controversial statement: Most of our estimates are pretty OK. Being off by a few days is not why our plans derail.
Just like with software development, the technical is the easy part. The real challenge is dealing with humans.
Here are three common human plan-killers in software development:
Recency bias
What's new feels more important. Every one of us has made a plan to tackle their current backlog. The minute the ink is dry, someone will barge in with a new idea. "Customers would love to have an in-app chat functionality. How soon can we build this?"
People get enthusiastic about their newest ideas. They see something, feel inspired, and want to build it ASAP. Recency bias derails our plans because the most important work is already on the plan. It's the boring, less-sexy stuff that supports our product vision. Resist the urge to fast-track those shiny new ideas.
No skin in the game
In organizations where business people say "Jump" and devs ask "How high?" plans derail all the time. Developers will try to come up with a way to streamline all the requests, but as soon as their plan is up-to-date, some business stakeholders will add another feature to the board.
The problem, in this case, isn't business people requesting features. The problem is them chucking work over the wall and expecting the developers to just get it done. I see this anti-pattern all the time. "We need it now and don't care how you make it work. Just build it ASAP."
Making demands is easy for those that don't have to build the damn thing! Those that don't have skin in the game shouldn't control the plan. It's the main reason why I believe Engineering, not Product, should own the plan.
Good weather leniency
When I was a project manager, I was often involved in putting out dumpster fires. I loved working on those one-year projects that were already 14 months behind schedule. I saw the state of the project, came up with a plan to address the issues, and went to work to get back on track. In those scenarios, I usually got what I wanted. Need some extra devs? Sure! Want to cut scope? By all means. Extends the deadline? No problemo.
When things go bad, teams get the tools to get the job done.
When the kitchen is on fire, the cooks run away. When there is panic, people can’t wait to delegate. But invariably, that changes once the flames are put out. Once it started to look like a fraught project could still become some kind of success, the cooks returned to the kitchen.
It used to infuriate me. My teams would spend months cleaning up the mess, and once the finish line was in sight, leadership would take away some of the best developers to fight another fire. It felt like they were actively trying to sabotage the project.
Panic is a great driver to get things done. But if panic is the only driver, it's clear what happens when the calm is restored. You need a plan to show what will happen if we don't see our work through.
The human mind is bad at planning. It looks like our brains are designed to sabotage long-term plans. That's why it's crucial to write down and share our plans with others.
Humans are the plan-killers.
We need a written plan to keep ourselves accountable.
I think sometimes you can also be in a Situation where the ambition is beyond the skill of the team and so, you find yourself in this rolling wave planning all the time. The estimates are out, the scope is evolving and stakeholders frustrated.