I like time estimates when building software. This isn’t a popular opinion, but time estimates have some valuable uses so long as they aren’t abused.
Time is the most valuable resource anyone or any company has. I like making sure my time is spent well. I want the greatest return possible on any of my time investments. In software this means working on the features that provide the most value for the time spent.
It’s impossible to calculate the exact dollar amounts provided by features, so let’s use an arbitrary measurement of value called utility.
Feature A will provide a utility of 10.
Feature B will provide a utility of 20.
So Feature B will provide more value and that means we should work on it first right?
Well not if Feature B is going to take 2 weeks and Feature A is going to take 2 hours. Calculating the return of anything requires a numerator and a denominator. Utility is our numerator. Time is our denominator. When taking time into account we realize that Feature A is much more valuable given how much time we need to put into it.
Time estimates are also useful in situations where deadlines are legitimate. Conferences don’t wait around for software releases. I’ve built software that was tied to a TV show launch. TV shows and movies don’t wait around for software releases. If you need software that works with taxes, the IRS definitely won’t wait around for a software release.
Estimates are useful here because a blind priority list doesn’t always reflect proper value. Let’s say Features A, B, and C are deemed the most important features. That means they’ll be worked on before Feature D. However, what if the value from Features A, B, and C is only realized if they are all complete? What if they’re near useless individually? Time estimates will give you an idea of whether getting all three done in time for a deadline is realistic. If it isn’t then all three need to get cut.
So why do developers hate time estimates? Many developers make time estimates for themselves anyway. A few minutes to fix a typo. A few hours or days to fix a bad database query. What’s wrong with just communicating these internal estimates?
The problem is in the way time estimates are treated. They’re called “estimates for a reason. They’re not called “exact-imates for a reason. While developers have some sense of how long a task will take, they will most likely be wrong. This post from Michael Wolfe is the best analogy I’ve seen on why.
If you are looking at a map of the US and draw a line between San Francisco and Los Angeles, it will have a distance of X. But this line is at a high level and won’t take into account the actual paths taken which add to that distance. The more detailed the map, the more twists and turns get revealed. Every level of detail added adds more distance. You will only get a perfect measurement of the distance needed when you actually make the trip.
The same is true of software development. The only way to perfectly determine how long something will take is to actually build it. At that point, you’re not creating a time estimate anymore.
Developers will always get the exact time estimate wrong, but they will often get the magnitude of the work right. Something that will take minutes to fix may take 3 minutes or 10 minutes, but it won’t take a day. Something that takes a few days won’t take months. There are exceptions of course, but this should be generally true. Fortunately, effective project management can be done with just the magnitude. Getting an approximate return on time investment is better than working on things blind.
Using time estimates for more than project management is where things start to get bad. I’ve met many managers who like to tie accuracy of estimates to performance. This is the point where developers stop making decisions solely on what benefits the project. This is the point where they start making decisions based on how they will be rewarded.
Time estimates create some perverse incentives when tied to performance. Quality of work becomes less important than time taken. Normally this trade off would be discussed by a team to decide if quality or time was more important. When time estimates are tied to performance, that conversation is less likely to come up. The decision will just be made without being brought up to the team.
The end result is that time estimates will start to be less valuable. A lack of communication makes it hard to manage projects. That reduces the benefits gained from time estimates. And metrics are a poor way to evaluate developers so there is no value gained when trying to evaluate performance anyway. Regardless of the temptation to do so, time estimates should never be used for performance reviews.
Top comments (1)
I've found that time estimates for stories are too easily converted into commitments by those who should know better.
So instead of making time estimates, I've been happier with shirt size estimates, with a simple association of effort.
As things get bigger, it becomes fuzzier. For XXL, our (release) cycles are about 13 sprints.
So for the Product Owner considering the Product Backlog, knowing if something is XL of "3-ish sprints" versus "12-ish sprints" may make a big difference.
But here's where too big is just too big: some XL that may seem 3-ish sprints may easily turn out to be harder than expected, and turn into 12-ish sprints. And some XL that may seem 12-ish sprints may turn out to be easier than expected and be done in 3-ish sprints.
The problem is that the feature is just too darn big, and if possible ought to be broken up into several smaller features.
(The above is for stories. Time estimates for tasks should be done in hours, and ideally of a scope that is possible to get one-or-two done every day. Plan the work; work the plan.)