Over and over again, I've watched a sprint go sideways in the most predictable way possible. Our team pointed a sprint at 8 points and went home only to find the next morning a stakeholder had done some "math". He took our historical average, decided that one point was worth about four hours, and announced that 8 points times 4 hours meant 32 hours of work, so the feature would ship Thursday. He was nice enough to put it in an email to our client.

Thursday came and we shipped way less than half of it. The client was annoyed, the stakeholder was annoyed, and the team got the dreaded "why did you miss your estimate" conversation even though nobody on the team had ever promised Thursday. We had promised 8 points over a two-week period. Somebody else turned that into a calendar date, and this is what blew up.

That whole mess comes from one misunderstanding, and it is worth clearing up because it will save you the same email. The TL;DR is that story points measure effort, not time.

Effort belongs to the task. Time to the person.

As an example, let's think about a ticket to add pagination to a search results page. The complexity of that ticket is a property of the ticket itself. There might be some database work, some query changes, some front-end wiring, a couple of edge cases around the first and last pages. That bundle of complexity stays about the same no matter who picks it up.

That being said, the time it takes to complete the ticket is a different animal. If I wrote the original search code, I might knock it out in an hour. If you joined the team last month and have never touched that part of the codebase, the same ticket could eat two days while you read code, ask questions, and figure out where things live. It's the same complexity, but the clock times are miles apart.

That is correct and not an error in the estimate. Time depends on the task plus the specific person plus what kind of week that person is having. A senior who wrote the module moves fast. A junior learning the domain moves slowly. None of that changes how complex the pagination ticket is.

This is the reason we point work instead of putting hours on it. Points describe how complex a task is or the level of uncertainty a team has about the change. Hours describe a specific human on a specific day, and humans and days are not constant.

Life happens, and points do not punish you for it

I'm not a fan of "hour estimates"; say you told your lead a ticket was six hours of work. Then you have a bad week because you are moving, a family member is in the hospital, or you barely slept for four nights straight. Instead of six hours, you take ten hours. Now you are "over," and there is a number that says you "failed".

Points sidestep that problem. A 3-point ticket is a 3-point ticket whether you were sharp that week or dragging. Your personal velocity absorbs the bad week without any individual estimate looking like a broken promise. You are not on the hook for the difference between your good-week self and your rough-week self, because you never estimated in a unit that assumed you were the same person every day (because you're not).

The mechanics: the scale, the poker, the anchor

Teams should estimate points based on a Fibonacci-ish scale (1, 2, 3, 5, 8, 13), and then if it feels bigger than 13 break it up into smaller pieces until it's ideally in the <5 range. The increases between numbers "grow" on purpose. A 1 and a 2 are both small and well understood, so the difference is small. By the time you are looking at a 13, you're staring at a big chunk of work with a lot of unknowns, and you honestly cannot tell a 13 from a 14. The widening gaps bake that uncertainty right into the scale. You are not allowed to pretend a huge task has fine-grained precision, because the numbers you are given will not let you.

The standard method for landing on a number is "planning poker". Everybody on the team looks at the ticket, and everyone estimates the ticket at the same time so nobody anchors on the loudest voice in the room. If I say 3 and you say 8, we are not both wrong; we are seeing different things. Maybe you know about a gnarly integration I forgot, or maybe I know a helper already exists that does most of the work. The difference in opinion allows you to talk it out, surface the difference in opinion, and then re-vote.

To keep everyone measuring with the same ruler, pick a reference story. Grab a task the whole team remembers, something like "we added the CSV export last quarter," and call that a 3 forever. Now when you point new work, you are asking "is this more or less complex than the CSV export," not "how many hours is this." Reference stories keep the whole team calibrated to the same scale, so my 3 and your 3 mean about the same thing.

How you get predictability back: velocity

None of this means the business gets to fly blind. You get predictability back at the team level through "velocity".

Velocity is the number of points your team completes in a sprint, averaged over several sprints. For your last three sprints, you shipped 18 points, 22 points, and 20 points. So your velocity is around 20. That average swallows all the per-person time variance, so you don't have to model any of it because you're measuring what the team as a whole delivers, and you can plan against that.

So if you have 60 points of work in the backlog and your team runs about 20 points a sprint, that is about three sprints. That is a forecast built on your team's throughput, and it (mostly) holds up because it never pretended any one developer's time was fixed.

That being said, if you're a team of less than five, plan for a huge variance in velocity sprint to sprint. 25% or even 50% of your team being "down" can have a huge impact on your team.

Do not convert points to hours

Which brings us back to the stakeholder and his cursed email. The moment you multiply points by an hours-per-point number, you have thrown away the entire reason to use points. You have taken a unit built to ignore individual time variance and forced it back into a unit that depends on individual time variance.

I understand that's not always what a lead or stakeholder wants (I've had to sit through multiple explanations about what a "sprint" is with someone from sales). If a lead or stakeholder needs a date, the honest path is velocity, not a conversion rate. Points per sprint, averaged over time, tells you when a backlog gets done. A points-to-hours multiplier is only going to lead to disappointment.

Next time you sit down for planning poker, resist the urge to think in hours. Ask one question instead: is this more or less complex than our reference story? Then trust your velocity to handle the rest, and if anyone tries to turn your 8 points into done by Thursday, send them a link to your team's velocity chart (and this article).