The software development industry is fast and dynamic. Frameworks, such as Scrum or Kanban, are extremely popular. And what’s inside of those frameworks? Sprints, story-points and velocity. Most estimation models that exist today focus on short-term capacity arrangements. But what about the long-term planning?
Financial Department: An Elephant in the Room
When I talk to developers, I often hear: Short cycles are enough, releases should be tiny, or no need to plan far ahead. When I then talk to product managers, they agree completely. But, meanwhile, they still ask for a delivery date. Or arrange for quarter or annual planning to scope work for the months ahead.
There is no contradiction.
Development, indeed, is best in short cycles, whereas business results will be evaluated in quarters or years. And delivery dates are important. This is just how a stakeholder mindset works, and thus the financial budget cycles follow.
Realities of Long-Term Estimation: “Let’s Do It, but Pretend like We are Not Doing It”
Because of the mainstream idea that long-term planning is not important or even “harmful,” but also because it’s still needed, many people prefer to do it in a stealth mode. Here are some tactics that I’ve seen:
Never share any roadmaps but keep all plans and commitments in one’s head
Create estimates but never share any assumptions that stand behind them
Schedule a big “scrum” event that would arrange plans for the next three months
Communicate delivery dates to clients or stakeholders based on a “gut feeling”
This is all so that everyone can say that the bullet was dodged and no rigid Waterfall was used. We can successfully claim we’re truly Agile!
Guesstimates at Work
When the process is weak, the results are weak, too. Many companies struggle with not delivering projects on time, employees burning out trying to chase unrealistic goals, and stakeholders expressing concerns over missed commitments [1]. It’s a natural result of a non-disciplined, “imitated” process of long-term roadmap planning.
The problem is: Many “gut feeling” estimates are biased [2]. They express an opinion of a person who can be too optimistic. If they forget the assumptions that stand behind the estimate, it becomes useless. If it’s in someone’s head, no one else can reach it, like in the case when the person got sick or left the company. Unrecorded or poorly evaluated estimates quickly become unusable or confusing.
What Should We Do to Make Estimates Real?
Fixing the process is very simple. We should introduce a structured and disciplined process of long-term planning on a top of Agile development cycles [3]. The process should be Agile too, call it Agile Roadmapping, with risk management, proper recording, continuous reviews, alignment and adjustments along the execution journey. We should log all work that we do for all initiatives and features, so that we can use it as a historical reference for future planning. We should account for expertise, nature of work (AI or not), and record all uncertainty and assumptions for our estimates, along with the scope that those estimates represent. Record this information to the place that everyone can reach and edit.
Summary
We can’t make software development absolutely chaos free and deterministic. But we can make it much more comfortable and predictable. Pretending that long-term planning doesn’t exist will not help the situation but make it less transparent and practical. On the contrary, what benefits most is a discipline in our selection of planning methods, estimation techniques, and practices of recording and logging data. This is the best path to transform organizations for better outcomes.
All-In-One Solution for Honest Roadmaps
If you need a complete all-in-one solution to build reliable roadmaps check out the method developed by our team of experts: https://honestroadmaps.com.