This article is an excerpt from our new book. For the full guide to building a collaborative software team, pick up your free copy!
When will it be done?
Most developers dream of a world in which they could tell their boss, “the feature will be done when we finish it.” It’s not that they’re curmudgeonly (well, they might be – but that’s not the whole story.)
It’s because developers are smart. That answer is the only correct answer. Any other is a guess.
But in the real world, the correct answer isn’t always the most useful one.
Software estimation – Your guess is as bad as mine
Sometime around the late 1500s, we started using a word that sounds better than guesses: estimates.
The bigger a project is, the less accurate an estimate will be. The further away the deadline or delivery of that feature is, the less accurate its estimate will be.
And yet, those are the situations business types and customers care most about. Nobody wants to plot their course without a map.
At the beginning of a project, estimates are, at best, bad guesses. In contrast to front-loaded waterfall development, most teams now add detail about tasks as they discover more about the tasks and the project. This means that we won’t know much of anything at the beginning of a project – which is fine.
Then why bother estimating development tasks?
Estimating a task is helpful when putting together your sprint backlog. Given a set amount of time – say, two weeks – and a set budget, how can you tell which GitHub issues to tackle if not for estimates?
When paired with historical data in the form of burndown or velocity charts, your team can see how fast you’re actually going, which is an invaluable planning tool.
There’s a big difference between plotting a satellite’s course to Jupiter’s orbit and estimating a timeline for software development tasks. The former requires dozens of people with MENSA-level IQ scores and billions of dollars in funding; the latter requires something more akin to a homemade compass and a gas station map. You just need to have a general idea of where you’re going and the route you’re going to take to get there. Estimates are how you do that.
How should you estimate?
There are two main types of estimates: story point and time.
Story point estimation
People are mediocre at guessing how big something is in absolute terms, like hours or days. But we’re surprisingly good at sizing something up in relation to another thing.
For example, if you give a person two piles of beans, they probably won’t be able to tell you how many beans are in each pile. However, they should be able to say one pile is about twice the size of the other pile.
That’s the basis of story points. It’s unitless scale of measurement in which “units” are sized in relation to each other. Unlike hours or days – which are specific measurements based on consistent values – they rely on arbitrary measurements that serve no purpose other than to compare a tasks’ size with the size of your other tasks.
Agile estimation uses a point-based system because it’s fast and you don’t need to stress about how your actuals compare with your estimates. Point estimates also remind us that estimates aren’t a deadline, but the best guess.
Your priorities when estimating
Whatever your estimation method, you should prioritize two things.
Never estimate in a vacuum. Harness the wisdom of the crowd in your estimations. Your estimates will be better, and your team will like you more.
Don’t get caught up in the details, because you’re still just guessing.
Three ways to estimate software
There are a few main ways you can tackle the challenge of estimation:
Everyone on the team gets a set of cards with point estimates. When an issue is read, each engineer holds up an estimate card they feel is appropriate. The benefit of this method is discussion, not compromise: if Sarah and Tim hold up one and seven respectively, don’t give the task an estimate of four. Talking about why your estimates are so different can reveal miscommunications about scope, which is helpful.
It’s all about simplicity. Using T-shirt sizes (XS, S, M, L, XL) guarantees you won’t over-analyze things, and they’re yet another reminder that your estimates can’t be equated to measures of time. Have your team come up with a range of story points that equal an XS, S, L, and so on. If something is an XL, consider breaking it down into several smaller tasks.
Triangulation is just a fancy word for “matching like with like”.
Take your issues and choose one that’s a definite one. Take another that’s an estimate of ten. And another that’s somewhere near the middle. Now you have a basis on which to estimate the rest of your issues comparatively. Match the rest of your tasks relative to these baseline estimates: Is this issue bigger or smaller than my “one”? Keep going until all your issues are estimated relatively.
What about time estimates, then?
Back to that conversation with your boss. “When will we release this feature?” she asks.
“Well,” you reply, “it’s an extra small.”
You haven’t exactly solved her problem, have you?
Time estimates are useful only when you have enough information – which is to say that you should use them when your development team has gathered some detail and done some discovery work.
In contrast to point estimates, time estimates refer to the actual productivity of real living people. What takes Sarah three hours could take Sam two days. That’s why nobody but the people coding should be estimating time. If you’re adding time estimates, consider the issue’s scope fixed.
When and how you should estimate
Some people use time estimates; others use story points. After trying a couple methods, here’s what we’ve landed on.
First, we don’t spend time estimating tasks until we’ve done some discovery work. To keep overhead as low as possible, issues that are in our Icebox never get estimated.
At this point, our issues have been broken down into consecutively smaller chunks as we learn more about them. This probably means they’re sitting in our product backlog (the backlog pipeline with no Milestone attached.) By adding estimates at this stage, we’ll easily be able to construct our sprint backlog (that is, which issues to add to our next GitHub Milestone.)
Issues that are estimated and Milestoned automatically appear in our Burndown charts. When an issue is closed, a new data point will appear on the chart. As a result, we can see how our projected speed of work compares with our reality.
Software estimates have long been considered a challenge – but with a little practice, some experimentation, and some historical data, your team will be rewarded with more predictability and greater confidence in your development process. Are estimates worth doing? We'd guess so.
Pssst! If you haven't already, download ZenHub free to get task boards, epics, and more – directly added to GitHub.
(Or read more of our ultimate guides for tech teams.)