Story points: how to size work without guessing hours

Story points say how big a piece of work is next to others, not how long it takes. Where they come from, how to use them, and when to count stories instead.

5 min read

Story points are a number a team gives to a piece of work to say how big it is compared with other pieces. They do not measure hours. A 5 is bigger than a 3 and smaller than an 8, and what a 5 means is settled by the team that uses it.

#Where they come from

Story points come from Extreme Programming. In Story Points Revisited, Ron Jeffries, an early practitioner of the method, describes how it went. XP teams first estimated stories in time. Then they used "ideal days", the time a pair would need without interruptions, and multiplied by a load factor of about three to get real time. Stakeholders found the day counts confusing, so the teams began to call them "points". Jeffries says he may have invented the term and, if he did, he is sorry now. Mike Cohn's Agile Estimating and Planning (2005) helped spread the practice.

Scrum does not require story points. The Scrum Guide does not mention them. It says the Developers who will do the work are responsible for sizing it, and leaves the way to them.

#Why people use them

There is little hard research behind story points. The reasons teams give are practical.

Comparing is easier than predicting. It is hard to say "this takes two days". It is easier to say "this is about twice that other story". A relative scale lets a team agree without arguing over hours.

The conversion comes from your own history. People are optimistic about their own time. In a 1994 study by Roger Buehler, Dale Griffin and Michael Ross, students predicted their senior theses would take 33.9 days on average and took 55.5 (Journal of Personality and Social Psychology). Points avoid a promise in hours. You add up the points your team really finished in recent sprints, and that total, called velocity, tells you how much to take next time.

They cover the whole team's work and the doubt. A point scale includes testing, review and the unknown. The bigger the number, the less certain it is.

Jeffries himself now deplores their misuse and prefers to cut stories until each is small. That is a fair alternative, and it comes back below.

#How to use them

Here is how a team might see it. "Add a remember-me checkbox" is a 2. "Reset a password by email" is a 5, with email, expiry and tests. "Export reports to PDF with layout" is a 13 and probably needs splitting. If the last three sprints finished 18, 22 and 20 points, the team plans about 20.

Use planning poker to agree on the numbers together.

#Mistakes to avoid

• Turning points into hours. "One point is half a day" turns a relative scale into a bad clock.
• Comparing teams' velocity. Each team's points mean something different. A bigger number does not mean more got done.
• Judging people by velocity. When points become a target, people size up to hit it.
• Giving partial credit. Count a story when it is done, and not before.
• Re-estimating after the fact. Changing the numbers once the work is finished hides what you learn.
• Letting each person use their own scale. The value of the number is that the team shares it.

#When it is the wrong tool

• When your items are about the same size. Count the items. Jeffries prefers cutting stories small to sizing them.
• For personal tasks. If you need a duration, use minutes.
• When a client pays by the hour. They want hours, so estimate hours.
• When the points add nothing. Jeffries says to drop them if they do not help, and keep them if the team likes them.
• For a brand-new team. With no sprints behind you there is no velocity. Finish a few sprints and watch what you complete.

#In Prior

Choose Agile · Scrum or Agile · Scrumban under Project type when you create or edit a project. Tasks of that project are then sized in points instead of by priority.

• Set the points. The task details have a Story points row, a row of cards: 0, ½, 1, 2, 3, 5, 8, 13 and 21, plus Clear. The task composer has a Points pill with the same deck. A value outside the deck, such as 4, gets its own card. Points go from 0 to 999 in steps of 0.5. The hint says it: "The size of the work, not the time it takes."
• See the size. A points chip replaces the P1 to P4 glyph on cards and rows: three bars, with one lit up to 1 point, two up to 3 and three up to 13. Above 13 the chip shows a coral "!", because the story should be split. A task with no estimate shows empty bars and reads Not estimated. Priority is still editable.
• Estimate together. The Planning Poker tab writes the agreed value onto the task. See the guide to planning poker.
• Split what is too big. The poker table offers Split the task, and Prior AI proposes the pieces if your account has Pro. See Split a story.

In a Scrum project, cycles become Sprints. Each sprint card shows progress such as "13 of 21 pts done" and how many tasks are "not estimated", and the sprint editor shows the points you have committed. The Velocity summary above the cards is the average of the done points in the last three finished sprints, rounded to one decimal. Until a sprint finishes it reads "Finish a sprint to see your velocity".

Points are kept when you switch a project back to Kanban or Standard. They are hidden, not erased. They also travel with sync, the data export and the MCP tools, and a numeric Linear estimate becomes story points when you import. For the full reference, see Story points and Cycles and sprints.