The eternal debate of agile teams. Spoiler: they are not the same thing, and confusing them is expensive.
Choosing a unit comes before choosing among the agile estimation techniques for sprint planning, and it shapes every Planning Poker session that follows. Here is what each unit measures, why "one point equals four hours" fails, and how to answer a manager or client who needs dates and budgets anyway.
What is the difference between story points and person-days?
Story points and person-days answer different questions. A person-day, also called a man-day, is a unit of time: one person working for one day. An estimate in person-days predicts how long the work will take for a given person or group. A story point is a relative unit of effort: it compares a backlog item with reference stories the team already knows and combines volume, complexity and uncertainty, without naming a duration. The key difference is that a person-day estimate depends on who does the work, while a story point estimate does not. Mike Cohn shows that one point can mean 2 hours for an experienced developer and 8 for a junior one, so points should not be converted to hours with a fixed rate. Teams that need dates or budgets convert at team level instead, through velocity: the points completed per sprint, measured over several sprints, turn a backlog into a number of sprints, then into calendar time and cost.
How do story points and person-days compare?
| Criterion | Story points | Person-days |
|---|---|---|
| What is measured | Relative effort: volume, complexity, uncertainty | Time spent by one person |
| Depends on who does the work | No: the team agrees on one value | Yes: a senior and a junior give different numbers |
| Stability over time | Stable: a 5 stays a 5 as the team improves, velocity rises instead | Decays: estimates must be redone when skills, team or context change |
| Reflects uncertainty | Yes, through the widening gaps of the scale | Rarely: one number hides the risk |
| Use in planning | Team velocity and release forecasts | Staffing, budgets, contracts and billing |
The stability row is the least obvious and the most useful. In his comparison of story points and ideal days in Agile Estimating and Planning, Mike Cohn notes that story point estimates do not decay: when the team gets faster, the stories keep their size and the velocity goes up. A person-day estimate made a year ago, before the team learned the codebase, is simply wrong.
Why did agile teams stop estimating in days?
They started with days. In Story Points Revisited, Ron Jeffries recalls that early Extreme Programming teams estimated in "ideal days", then multiplied them by a load factor, typically about three, to get real time. Stakeholders kept asking why a one-day task took three days, so the team renamed the unit "points".
Cohn's comparison explains why the change stuck. Ideal days are easier to explain outside the team and easier to estimate at first, but one person's ideal days cannot be added to another's. Story points can: the whole team agrees on a single value per story.
Person-days also make people look interchangeable: if one developer needs three days, two should need one and a half. Fred Brooks answered that in The Mythical Man-Month (1975), with what became Brooks's law: "Adding manpower to a late software project makes it later."
Why doesn't a fixed points-to-hours rate work?
In Don't Equate Story Points to Hours, Mike Cohn takes a team of two. Superstar is four times as productive as Junior. Over a 40-hour sprint, the team delivers 25 points: 20 for Superstar, 5 for Junior. For Superstar, a point is 2 hours. For Junior, 8 hours. For the team, 3.2 hours.
None of these is "the" conversion rate. For Cohn, the relationship between points and hours is a distribution: one-point stories cluster around some duration, two-point stories around roughly twice that, with overlaps between neighbouring values. Freezing "1 point = 4 hours" brings back everything points were meant to avoid: the estimate starts depending on who will pick up the story, and a precise-looking number hides a wide range.
How do you convert story points into time, then?
You convert at the level of the team and the sprint, never story by story.
- Measure velocity over at least three sprints, and keep a range (lowest and highest) rather than a single average.
- Size the remaining backlog in story points, for example during Planning Poker sessions.
- Divide the backlog by each end of the velocity range to get a number of sprints.
- Convert sprints into calendar time and person-days using the team's capacity: people times working days per sprint.
A worked example, with illustrative numbers: five developers, two-week sprints (10 working days), a velocity between 20 and 25 points, and a release of 120 points. That gives 120 ÷ 25 = 4.8, so five sprints at best, and 120 ÷ 20 = 6 sprints at worst: 10 to 12 weeks. Each sprint uses 5 × 10 = 50 person-days of capacity, so the release costs 250 to 300 person-days. Present it as a range.
For budgets, Cohn suggests the same logic in money: divide what the team costs over a period by the points it delivered in that period to get a cost per point. Ron Jeffries adds a caution worth repeating to stakeholders: predicting dates from points is, in his words, "at best a weak idea". He prefers small slices and close release dates. Our sprint planning guide shows how velocity feeds each sprint.
When are person-days still the right unit?
Person-days remain the right tool when the question is really about time or money:
- Fixed-price contracts and quotes, where a client buys a budget, not a velocity.
- Staffing and capacity: holidays, part-time members, onboarding.
- Reporting to non-agile stakeholders who plan in calendar time.
- Tasks inside a sprint, if the team breaks stories down. Mountain Goat Software recommends Planning Poker for backlog items rather than for those tasks.
The healthy pattern is to keep story points inside the team and translate at the edge, with velocity and capacity, rather than asking developers to estimate in days.
Frequently asked questions
How many hours is one story point? A story point has no fixed number of hours. Mike Cohn's example shows one point taking 2 hours for one developer, 8 hours for another and 3.2 hours on average for the team. The link between points and hours is a distribution, so teams convert through velocity over a sprint, never story by story.
Can you convert story points into person-days for a client quote? Yes, at team level. Measure velocity over several sprints, divide the backlog by the velocity range to get a number of sprints, then multiply by the team's capacity in person-days per sprint. The result is a range of person-days for the whole release, not a rate applied to each story.
What is the difference between ideal days and person-days? An ideal day is a day of uninterrupted work on a single story, with everything needed at hand. A person-day is a real calendar day of one person, with meetings and interruptions. Early Extreme Programming teams multiplied ideal days by a load factor of about three to get real time, then renamed them story points.
Should a team estimate stories in points and tasks in hours? Many Scrum teams do. Story points size backlog items for velocity and release planning, while hours or days can help the people who split a story into tasks during sprint planning. Mountain Goat Software recommends using Planning Poker on backlog items, not on the tasks of the sprint backlog.
Sources
- Mike Cohn, Don't Equate Story Points to Hours, Mountain Goat Software
- Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005
- Mountain Goat Software, Planning Poker
- Ron Jeffries, Story Points Revisited, 2019
- Fred Brooks, The Mythical Man-Month, Addison-Wesley, 1975
New to the concept? Start with what a story point is, then see how to estimate an agile ticket.
Estimate in story points, not days
Ready to size your backlog in relative effort? Create a free Planning Poker session, share the link and let your team vote at the same time. No sign-up required. See all the features, including CSV and PDF export of your estimates.
