Story Points vs. Hours: Let’s Pretend We Care
In the project management world, story points vs. hours is akin to spaces vs. tabs for developers (tabs, obviously). Let me begin by saying that it really comes down to personal preference. In my (much too long) experience, I’ve led and been on teams that spent much more time arguing over the use of story points vs. hours than efficiencies gained by either one of them. That’s the tell-tale sign that you should just do what makes your team feel most comfortable.
That being said, it’s fun to have an esoteric argument, especially in a world where we’re constantly having real arguments over serious topics. So take this article with a grain of salt: I’m going to rant like I’m a true believer (or maybe a defense attorney?) and go all-in for — wait for it — hours.
The Basic Argument Against Story Points
[Warning, the following content is completely biased, made in jest, and cherry-picked to conveniently buttress my argument.]
The basic argument against story points is that they’re so darn hard to understand! Now, many folks will tell you they’re not difficult once you understand their definition, and what they’re used for. Sounds good purveyors of story point greatness! Let’s hear from you what a story point is:
Each Story Point represents a normal distribution of time.
- Maarten Dalmijn
Hmm… thanks Maarten, that really clears things up. (All jokes aside, Maarten’s article above has a lot more substance that I’m conveniently leaving out for my one-sided rant; you should read it.) But let’s see what others say:
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a product backlog item or any other piece of work.
- Dan Radigan, Atlassian
So… a normal distribution of an estimated unit of measure?
…a dimensionless quantity… “Nebulous Units of Time”
- Ruby Garage
Well terrific, I love using a normal distribution of a nebulous, dimensionless unit of effort to make estimates of … something.
Now, this of course is tongue-in-cheek. You can get a great agile coach to express these ideas in a way that team understands. Just give them a few days, some charts, and a bunch of examples. Our developers’ schedules are completely open for that, right?
One of the most telling things in my experience is that you can have incredibly smart developers who take an agile class, and then devolve into choosing story points on the basis of how many hours a task will take. “Is it a 13 pointer? Well, it’ll take a week, so I guess so?” If you’re fighting to not use hours, it should make you wonder what you’re fighting for.
Rebutting the Glory of Story Points
The arguments for story points are many. I think it’s more fun to attempt to tear down those arguments than to make the case for the use of hours, so here goes.
Generally, my favorite rebuttal of story points is that one of the original proponents of story points wishes they weren’t invented! But, let’s get to some specifics.
Story Points claim #1: You can estimate issues more quickly
Let’s get our cards out everyone! Look, I suppose in a well-oiled scrum team where everyone has bought in, maybe story pointing estimation is pretty efficient. But in my experience, by the time you get out your cards, go around the horn, debate on the number of story points, have that one quiet guy who doesn’t really have an opinion but is slowly cajoled to participate, argue over what a story point is, talk about why it’s in a Fibonacci sequence… you get the idea. Compare that to:
I think it’s about a 8 hour task.
You sure? I think you could get that done in 6.
OK, let’s call it even at 7.
Story Points claim #2: There’s less stress for developers as they’re not being held to specific hours
Here’s a hot tip. If you’re a project manager (or any kind of manager) and you’re harping over whether Jane was 30 minutes over her estimation, you shouldn’t be a manager. Or two or three hours for that matter. What matters is that, on average, your developers do a fairly good job of estimating how long it will take them to something. Good estimations help your product folks, sales team, support personnel, and leadership know what’s going to be delivered to the customer, when. And they don’t want to hear that it will be done in about 8 story points.
But as a manager, how on earth could you not freak your team out about hours?
By telling them they don’t need to freak out about hours. That it’s solely an estimate, but you’d like their estimates not to be too optimistic or pessimistic so that on a whole, they’re fairly accurate. Trust me, they’ll survive.
Story Points Claim #3: Story points allow for more buffer, since people often underestimate
This claim comes in multiple forms, but typically comes back to the “nebulousness” of story points allowing for more deviation, hence making people worry less about not being accurate.
Here’s the rub; even normal distributions have a peak. So sure, you might be in a standard deviation, but your mode is still wrong. If your team is underestimating, they’re underestimating. And that’s more difficult to ascertain if you’re not using a concrete measure.
How do you fix under-estimation when using hours as your measure? Add buffer time, or estimate better. Seems simpler than a dimensionless quality.
Story Points claim #4: Story points make it more difficult (or impossible) to compare between teams, so there’s less politics
I get this. But, if you’re a good manager of teams, you can and should use quantitative data about your teams in a way that is non-offensive to the participants. Good managers don’t use data to call out people; they use it to help teams grow. There are many reasons one team may be more productive than another, including:
- work to developer ratio
- training
- experience
- mix of knowledge
- team chemistry
- differences in the scope and type of work
- project management practices
And even when there are objectively better teams, good managers don’t frame it that way, but seek ways to improve the team without hurting their ego.
Still, I find this the most tenable argument, as good managers can sometimes be hard to come by.
In sum, hours are best and people who espouse story points are weirdos. Kidding. Almost all good Scrum products such as Jira, ClickUp, Monday, and Scrumfast (my company) offer different means of estimation, because there’s no “right” answer. Once you’ve been around the block and heard everyone tell you that so-in-so way is the “correct way,” you start to get a sense of what matters and what doesn’t. Is your team happy? Are they productive? Are your customers happy, and does the decision you’re making affect that (looking at you, tabs v. spaces)? Your decision between story points and hours may or may not, so choose your battles wisely.
Jerry Lupo is a successful ed-tech and start up entrepreneur. His current projects include AutonomousCA.org — which promotes an autonomous driving lane for California — and Scrumfast.com, a bare-bones online scrum tool.
For an opposing opinion and cute pups, read Maarten Dalmijn’s “What is the Easiest Way to Explain Story Points.”
