Estimating for software development tasks and projects is a controversial topic. People feel strongly on both sides. Here's how we see it.
What's behind asking for estimates?
First, let's talk about the reasons for wanting estimates:
- To plan an implementation – Estimates give the business a forecast of when an important story will go to production. The business may need to plan a marketing roll out, user training, or all kinds of other things that hinge on the software being ready.
- To prioritize the work – Estimates give the business the denominator needed to calculate return on investment for ranking stories. The idea is that the highest ROI stories should be worked first.
- To manage a portfolio of projects – Estimates help the business decide where to invest money and developers' time by knowing which projects will take months or years. This is the same ROI idea as above, but at the project level instead of the story level.
These are all legitimate business needs, and estimating is meant to help with those needs.
So what's the problem with estimates, and why is the #NoEstimates movement gaining traction?
What's wrong with estimates?
How many jelly beans are in this jar? Who knows!?!? Estimating is hard, time consuming, and almost always wrong.
Story points and t-shirt sizes tell the business a story's relative complexity (or uncertainty) so it can be prioritized. But because they don't help estimate time to production without the headache of adding up points, sizing the sprint, and filling the sprint with points, they are almost immediately converted to hours/days/weeks. A couple releases into the project and the team or management will be converting these units, which are intentionally obscure, into a number they can use to plan a delivery date.
Further, estimates become commitments, which in turn, drive negative behavior. Once people know 3 story points or a medium t-shirt size means one week of coding, you're on the hook for delivering in a week. If you don't pull it off, you start making excuses or blaming the business for not giving clear enough requirements or changing their mind, other developers on your team who didn't help enough, all the meetings you had to go to, that day you had to leave early to pick up a sick kid, and on and on.
People feeling bad about not getting a story done "on time" has a corrosive effect on individual and team morale and the quality of the software. Developers start skipping automated testing and code refactoring when they are under pressure, and the software gets worse and worse over time due to neglect.
Then there is the problem of developers estimating way too much for stories. To mitigate feeling bad about not getting work done in the amount of time estimated, developers give themselves lots of room. Sometimes it's from experience, knowing it's not realistic to expect to work 8 hours a day for the next 5 days on this story. But if all estimates you are hearing are "2 weeks" or "8 points" or "large", you know the team is avoiding committing to their estimates because they've been burned by them. Estimates are inherently inaccurate, but if you get to this point, they are completely useless.
Finally, once those estimates become commitments, which happens as soon as you say them out loud, not meeting your commitments erodes trust between the software delivery team and the business. That's hard to recover from, and the teams or departments can end up resenting each other instead of cooperating to build a great products.
Ways to avoid estimating
Estimates have problems, but they also meet important business needs. Are there other ways to meet these same business needs without resorting to estimates?
Usually. Let's go back through the reasons for estimating and talk about alternative options.
To plan an implementation
We're really talking about predictability - how long until the business can start getting the benefit from this story? You don't need story points or t-shirt sizes to estimate this. Instead, you can get the average number of stories the development team moves to production each release. This is cycle time. If the team completed 10 stories last release and 12 the release before that, the team is averaging 11 stories a release.
The business wants to know "when is this going to production?". You can assure them that if their story is in the top 10-12 stories in the backlog, there is a 70% chance it will go to production this release and a 95% it will go to production next release. The higher in the backlog, the sooner it will be delivered. If the business needs a date, figure out how many calendar days you average between releases and how many releases out that story is. It's up to the business to prioritize the stories, so they can move a story up to the top if they really need to increase the odds that story will be delivered in the next release.
There is no estimate for this important story or any of the other stories on the board. The idea is that over time, the team will complete an average and a standard deviation of that average of stories, and you can give that to the business to predict when something will land in production so they can plan.
If you're thinking, "Hang on – some stories are to tiny and some stories are huge.", you're right. The big stories with lots of unknowns can be broken up into smaller stories, and you are probably doing this already. But even this may not be needed. You'll always have outlier stories that are very big or very small, but you'll also always get regression to the mean, too. If you plotted each story's cycle time after the story was completed, you should see a normal distribution (given enough stories). Take advantage of this and just count the stories completed per release and give this information to the business so they can predict.
To prioritize the work
The business wants to prioritize high value, low cost stories. For example, if we have two stories that will both save the business $5,000 a month, you should work on the one that takes one week before you work on the one that takes one year.
This is an exaggerated example, but do you really need to ask the delivery team for an estimate before you can proceed? Why not just ask the team to rank the two stories on difficulty to implement? Most teams can very quickly compare story A to story B and tell you which will take longer. If the value is the same, you don't need an estimate, you just need to know which one to start with.
Maybe two stories with the similar values is unrealistic. What if one story brings in $5k a month in new sales and another story will bring in $50k a month in new sales. The team talks about it, and the $5k story is simpler to implement than the $50k story. Which one should the team work on first?
If the benefit is 10x, then the cost would have to be 10x or more to wait on starting the $50k story. So the real question is for team is, is the $50k story 10x longer to implement than the $5k story? The team won't know, and they can make some guesses, but the guesses will be wrong. If you can't tell which story has the better ROI, they are close enough. Pick one and start.
Getting the projected value of a story is rare. Sometimes it's done for entire modules or epics. If so, that's great for helping prioritize. But if the story value hasn't been estimated, there is no sense in asking the team to estimate time/cost. Stories don't have the same value, so how does the estimate of time/cost help prioritize?
The key to prioritizing stories is starting with the value of the stories, with highest value at the top. The cost/estimate only matters when comparing stories that may have similar values and wildly different times/costs. Don't forget, when calculating ROI, you are dividing a guess by a guess, so don't let the math give you a false sense of precision.
To manage a portfolio of projects
The same approach on stories makes sense for managing a portfolio of projects. Project A hopes to save the company $1M-$2M a year. Project B will increase sales up to $5M a year. Which one should the developers work on?
You can't be sure, but if you ask the delivery team, they can almost surely tell you which project sounds like more work. If they can't tell which one is more work, they are probably in the same ballpark. If that's the case, go with the higher value one.
These aren't estimates so much as they are comparisons. You are trying to answer the question, "Is Project A much easier than Project B? Or the opposite? Or are they about the same or we can't tell?".
If the business wants to know when a story will be in production, figure out how many stories the team pushes to production each release, check where that story is in the backlog, and give the business a few probabilities for when it will be in production (e.g., releases are every two weeks, we average 10 stories per release, there are 6 stories in progress or ahead of this one, so it should be in the release after this week's release in two and a half weeks). If that's not soon enough, move the story up higher in the backlog.
If the business wants to know time/cost for a story in the form of an estimate to prioritize the work, ask if the value of these stories has been estimated. If it has, work on the highest value ones and only compare difficulty between stories that are about the same in value as a tie breaker. If no value hasn't been estimated, the business should still have the stories in the backlog in priority order, so what difference does it make if it takes a shorter or longer time if the business has said this is the most important thing to work on. Prioritize stories and projects primarily by value, not cost.