The eternal debate of agile teams. Spoiler: they are not the same thing, and confusing them is expensive.
The fundamental difference
| Story points | Person-days | |
|---|---|---|
| Nature | Relative and abstract | Absolute and time-based |
| Varies per person? | No | Yes |
| Reflects uncertainty? | Yes | Rarely |
| Recommended use | Agile planning | Contracts, external reporting |
The problem with person-days in agile
Person-days create an illusion of precision. Saying that a feature takes 5 person-days implies that you know exactly what you're doing, how long each task takes, and that nothing unexpected will happen. In software development, that's rarely the case.
Person-days also push managers to treat developers as interchangeable resources. "If one dev does it in 3 days, two devs do it in 1.5 days." Except no: that's Brooks's law.
Brooks's law: Adding people to a late project makes it later.
Story points, on the other hand, let you…
- Estimate collectively without arguing about individual capabilities
- Measure team velocity sprint after sprint
- Spot trends (is the team getting faster? slower?)
- Prioritise without turning estimates into contractual promises
When to use person-days anyway?
In some contexts, person-days remain useful: fixed-price contracts, reporting to non-agile stakeholders, or accounting-based project tracking. In that case, you can convert velocity into a time approximation, but you keep story points internally.
