This is a HOTLY contested topic. One of the reasons is that story estimates tend to get used for multiple purposes that have very different implications:
- Story estimates are used to see how much work can be fit into the sprint you’re planning.
- Story estimates are used to track how much the team did during the sprint, to adjust how future sprint capacities are estimated.
- Story estimates are used to track how much to “credit” the team with compared to previous sprints (velocity). It’s actually a pretty bad practice to “credit” the team with work output, and much better to have some measure of the outcomes of that work, or value added. But it’s still the norm because people would rather use less meaningful but easier to compute numbers than more relevant but hard to quantify numbers.
Methods for calculating story points may be good for one, both, or neither of these purposes.
The main advantage of story points is that they can encompass more “costs” of the story than just time. For instance in one job factored in expected level of effort, expected level of risk, and confidence in the requirements all into one number. That means you can indicate that a story LOOKS like it will be pretty easy but there are some unknowns we may not have answers on in time, or we can do the coding but some other group we need to coordinate with might not be ready in time, we can code this story fairly easy but testing will be a b*tch, etc.
Using story points has another advantage, in that it steers away from a rough guess of “time to completion” that gets treated as a promise/expectation. Lots of things can happen in a sprint, and any time you throw out a time estimate people want to tattoo it on your arm. Even if your organization has some notional translation of story points to hours/days, it’s seen as less of a promise of completion time this way.
This “cost” of the story is an important factor. The Product Owner knows what the benefits of each story will be, but to best prioritize stories, they need to know the cost side too. If time to compete is the only factor considered, you may find a lower success rate due to those other missing factors being left out.
The main advantage of estimates in time is that it’s easier to visualize, and easier to use in planning. “We have 130 person hours in this sprint based on team size and availability, so let’s put 95 hours of stories in the sprint”. It’s also easy to see how well you met your estimates afterwards, because your unit of measure is 100% objective. The fact that it’s easy doesn’t make it a good measure though.
There are other options besides story points and numeric story estimates:
- “T-shirt sizing”: You rate stories as Small, Medium, Large, X-Large. That’s it, no numbers at all. With fewer options to categorize stories into, it’s much quicker to get to a consensus. There are other variants that focus on using a very limited number of size options but this is the general term.
- No estimates at all: The team develops a feel for how much work can fit into a sprint without qualifying individual stories. This is obviously more appropriate with mature teams working on mature products where most of the stories are pretty small.
- Relative sizing: This is an interesting exercise where no numbers are assigned at all, but the stories are rank ordered along a continuum. so the quick wins would be at one end and the bigger stories would be at the other.
What works in your company? How do you balance out these concerns?