Mr Nobody
Published in

Mr Nobody

photo by Jose Antonio Gallego Vázquez

Software estimation — how to predict the future

Estimation has become a bit of a controversial topic in software development. The leading thoughts today are that, rather than attempt to estimate a large project, you should break it down into tiny two-week nuggets of customer value that can be shipped independently. And I agree — if you can do that, you probably should! Estimates are costly to provide, both in terms of the effort required for accurate estimates and the potential for miscommunication and loss of trust for bad ones. They rely on predictability and consistency that is hard to come by in a field like software.

geek and poke

Why estimate? And when?

Estimates have a variety of purposes, from allowing contractors and consulting firms to give quotes to their clients, to allowing Product Owners to weigh the effort required between multiple potential projects.

Dealing with reality

There’s a triumvirate of concepts to consider when delivering a project with finite resources: scope, time, and quality. With a given team, there are limits to what you can achieve (scope and quality) in a given time, even if everything is done perfectly.¹

Team

Your team has its own unique abilities and skill levels at various tasks. You might have an expert in SQL and databases, or a recent graduate who has never had to build a stable API. They might have worked together for years, or only weeks. The better you know your team, their experiences, and their passions, the better you and they, will be at estimating how well they perform the tasks in front of them.

geek and poke

Scope

Scope is a measure of how much you’re trying to accomplish for your stakeholders. If you are adding a search feature, scope might be which fields will be searchable, what search options are available, what data is displayed for each result, and how the UI handles all of this.

Quality

Quality accounts for all the polish in addition to simply delivering on the Product Owner’s base requirements. Things like maintainability through unit and functional tests fall into this category. Performance and load testing falls into this category. User testing falls into this category. Supportability and logging, analytics coverage, and other peripheral requirements might fall into this category.

geek and poke
geek and poke

Time

geek and poke

Milestones — hedging your bets

Estimating is hard. You’ll probably be wrong. And we all have the tendency to be optimistic — to keep believing we’ll hit the deadline until the last minute.

geek and poke

Managing expectations

https://xkcd.com/612/

Improving your team

In the long run, the best way to improve your estimates is to improve your team’s estimation ability. Making them responsible for understanding scope and quality requirements is a great way to do this. As a team lead, my team would often sit together for each milestone and flesh out the tasks together. Would this aspect need unit tests? Would that aspect need an integration test? What are the risks with the data layer? This would give us some great insight when it came time to Story Point or estimate the the work.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adam Ahmed

Adam Ahmed

Father of two lovely boys. ex-Atlassian. Founder of https://www.mrnobody.com