About software estimation and planning

Some of my random opinions about software estimation and planning…

• Software development is inherently complicated and difficult to estimate. You only really know that if you’ve been a software developer on a reasonably big project. No manager can judge that (even though they try all the time).
• Estimates should not be a goal. They are just a means to end up with good breakdown that allows teams to work efficiently by pairing up and/or swarming.
• More planning and persisting on estimates is not going to make the plans more realistic. It’s just going to annoy people or force them to give you estimates not based on anything. And don’t even dare to use the word “more accurate estimates”.
• High level estimates are fine though. They should give you a sense of size and allow you to build a decent roadmap. Roadmaps are fine too. They can help you understand the order of things and highlight the dependencies. It also creates a sense of control and predictability.
• Make such high-level plans visual and alive. Use roadmap diagrams and share the plan at a place that stimulates collaborations such as Confluence, but avoid tools like Markdown diagrams, Azure DevOps or Word for that.
• Make sure your backlog has an absolute priority across all the teams. That’s the only way to make sure the bigger goals are met. I’ve seen too many situations where a projected ended up with team-specific backlogs where one team was scrambling to get that important feature done and the other teams were picking their noses.
• Do have team estimate the work for the next three weeks, but never more. Changing priorities, technical implementation details, new insights, leavers & joiners will all affect the work. I’ve seen many teams spending a lot of time on breakdowns and estimates only to discover that by the time to started working on that they were completely out of context and needed to restart all investigations.
• Relative estimates are much easier to do. Just try to estimate the height of a big building. It’ll be obvious that something is about half the size of another.
• User stories are not requirement documents. They are just a placeholder for teams, business people and product owners to collaborate on building the right thing. If you disagree, read “Scrum/XP from the Trenches” by Hendrik Kniberg, “The Art of Agile Development” by James Short or “Agile Estimation and Planning” by Mike Cohn.
• Understand that a great developer can be 10 times as productive and efficient as a mediocre developer. Also understand that the tools they prefer to use can have an equal effect on their productivity.
• If the process or the planning tools gets in the way to remain flexible and make those plans a reality, change the process and/or the tools. Azure Devops is an acceptable tool for work item tracking, but is horrible for building breakdowns and capturing notes during development. Use Github, OneNote or Confluence for that.
• And the same can be said about the team structure. If they haven’t been set-up in a way to work on the right things at the right time with the right people, change the structure.
• Accept that plans will change instead of fighting change. Thats why agile development was invented in the first place. Respond to a change instead of following a plan. That doesn’t mean you can’t have some kind of budget and remain control. Just make sure your backlog is properly prioritized.

So what do you think? What are your biggest issues with planning and estimations. Let me know by commenting below.

About me

I’m a Microsoft MVP and Principal Consultant at Aviva Solutions with 26 years of experience under my belt. As a coding software architect and/or lead developer, I specialize in building or improving (legacy) full-stack enterprise solutions based on .NET as well as providing coaching on all aspects of designing, building, deploying and maintaining software systems. I’m the author of Fluent Assertions, a popular .NET assertion library, Liquid Projections, a set of libraries for building Event Sourcing projections and I’ve been maintaining coding guidelines for C# since 2001. You can find me on Twitter and Mastadon.