JIRA Story Points and Estimation
Teams need a way to judge how much work fits in a sprint. Guessing hours often fails, since two people rarely agree on exact durations. Story points offer a simpler method: compare the size of each item and give it a number. JIRA stores these numbers and turns them into forecasts.
Layman's View: Moving Boxes
Imagine a moving day with a pile of boxes. A small box takes a minute. A medium box takes a few minutes, and a wardrobe needs two people. Nobody measures every item with a stopwatch. Movers sort items into sizes and plan the day from those sizes. Story points use the same idea for software work.
What a Story Point Measures
A story point blends three things: the amount of work, the difficulty, and the uncertainty. A small login text change earns a low number. A new payment feature with unknown rules earns a high number. Points describe relative size, and they never promise a fixed number of hours.
The Common Scale
Many teams use a Fibonacci-style scale, where numbers grow with each step. The growing gaps reflect a simple truth: large items carry more uncertainty, so precise numbers mean little.
Typical Story Point Values
| Points | Size | Sample Work |
|---|---|---|
| 1 | Tiny | Change a button label |
| 2 | Small | Add a field to a form |
| 3 | Medium | Build a simple search filter |
| 5 | Large | Create a new report page |
| 8 | Very large | Add a login option with a new provider |
| 13 | Too big | Split into smaller stories |
Planning Poker
Planning poker lets the whole team estimate together without bias. Each member holds a private card with a number. Everyone reveals cards at the same moment, so nobody copies the loudest voice.
Story read aloud
|
v
Team members pick a card in secret
|
v
All cards turn over together
|
v
Numbers match? --Yes--> Record the estimate
|
No
|
v
Highest and lowest voters explain their view --> Vote again
Setting Points in JIRA
- Open the issue, or the backlog view with the issue list.
- Find the Story Points field, often labelled Story point estimate.
- Type the agreed number.
- Save the change. The sprint header shows the new total.
Teams may need an administrator to add the field to the screen when it does not appear.
Velocity: Turning Points into Forecasts
Velocity equals the number of points a team completes in one sprint. After a few sprints, an average appears. That average predicts how much work fits into the coming sprint.
Velocity Example
| Sprint | Points Planned | Points Completed |
|---|---|---|
| Sprint 1 | 25 | 18 |
| Sprint 2 | 20 | 21 |
| Sprint 3 | 22 | 20 |
The average completed work equals about 20 points. A backlog of 60 points needs roughly three sprints.
Points vs Hours
Story Points and Hour Estimates Compared
| Point | Story Points | Hours |
|---|---|---|
| Measures | Relative size | Exact duration |
| Depends on person | Little | Strongly |
| Best for | Sprint planning and forecasts | Billing and detailed schedules |
Common Mistakes
- Converting points into hours with a fixed formula, which defeats the purpose.
- Comparing velocity between different teams. Each team sizes work in its own way.
- Padding estimates to look productive.
- Re-estimating finished work to chase a higher velocity.
- Keeping stories of 13 points or more without splitting them.
Real-World Example
A team of five faces a backlog with twelve stories. In a one-hour session, they play planning poker and assign values from 1 to 8. The total reaches 56 points. Their average velocity sits at 19, so the product owner tells stakeholders the work needs about three sprints.
Summary
Story points measure relative size instead of exact time. Planning poker produces fair, shared estimates. JIRA stores the numbers and shows totals during sprint planning. Velocity from past sprints turns those totals into practical forecasts.