Estimate a user story in seconds: rate its complexity, effort, and uncertainty and get a Fibonacci estimate with the math shown. Then run planning poker with your team and export the whole backlog.
Moderate. A few moving parts or some logic to think through.
Small. A few hours.
Low. A couple of small questions, easy to answer.
(3 complexity + 2 effort) / 2 = 2.5 on a 1-5 scale, which lands on 3.
Story points are the unit agile and Scrum teams use to estimate how big a user story is. Instead of guessing hours, the team agrees on a relative size: a 2 is a small, well-understood change, an 8 is about four times bigger, and a 21 is too big to plan with confidence. Story point estimation blends three things into one number:
Because points are relative, two developers who work at different speeds can still agree that a story is a 5. The link to calendar time comes later, from your team velocity - the points you actually finish per sprint.
Rate the story from 1 to 5 on complexity, effort, and uncertainty. The calculator averages complexity and effort, then adds a bump for uncertainty - 0.25 for some unknowns, 0.75 for high, 1.25 for very high - because unknowns make work bigger, never smaller. The resulting score maps onto the Fibonacci sequence: around 1 is a 1 point story, 3 is a 5, and anything near 5 is a 13 or a 21. The math is shown under the estimate, so you can see why a story landed where it did and argue with it.
At 13 points and up, the calculator tells you to split the story. At very high uncertainty, it suggests a spike - a short, time-boxed investigation - before you estimate at all. Add each story to the estimates list, and the tool totals the backlog and, with your velocity, forecasts how many sprints it takes.
A calculator is a good starting point, especially for a new team without a shared sense of size. Over time, the most accurate method is comparison: keep a few reference stories (a known 2, 5, and 8) and ask whether the new story is bigger or smaller.
Every scale here is non-linear on purpose. Estimates get less precise as work gets bigger, so the gaps between values grow too - nobody can tell a 7 from an 8, but everyone can tell a 5 from an 8.
Planning poker, sometimes called Scrum poker, is how teams agree on story points without the loudest voice setting the number. It takes a few minutes per story:
In Planning poker mode, add your team, tap a seat, and each person picks a face-down card - the next person is up automatically, so one laptop or phone can go around the room. On a video call, share your screen and enter the cards people send you privately in chat. After the reveal, the tool shows the average, the median, a suggested estimate, and whether the team has consensus or needs to talk. For teams in one room, Card deck mode turns every phone into a set of planning poker cards. This tool does not sync votes between devices - it runs entirely in your browser, with no signup and no data sent anywhere.
Points are only useful if they stay attached to the work. Download your estimates as CSV and import them into a t0ggles board with Import Tasks. Add a Number custom property called Story Points first, map the column once, and every task arrives with its estimate - ready to filter, sort, and plan sprints with the whole team in real time.
Writing the stories is the step before estimating them: the free user story generator builds stories with acceptance criteria you can paste straight into planning poker. And once the sprint is planned, give it a name with the sprint name generator and close it out with a retrospective.
Copy a reference table, a planning poker agenda, or a readiness checklist into your team docs.
Agree on what each number means once, pin it in your team space, and point every story against it.
STORY POINT REFERENCE - [Team name]
1 - Trivial. One obvious change, no unknowns.
Example: [fix a typo in a label]
2 - Simple. A known pattern, a few hours of work.
Example: [add a field to an existing form]
3 - Small but real. Some logic, about a day.
Example: [new filter on a list view]
5 - Medium. A few moving parts or a couple of open questions.
Example: [password reset via email]
8 - Large. Several days, touches more than one area.
Example: [export invoices as PDF]
13 - Very large. Split it before it enters a sprint.
21 - Too big to estimate. Break it down or run a spike.
? - Not enough information to estimate.A 45-60 minute agenda for estimating a backlog with the whole team.
PLANNING POKER - [Sprint / date] Before the session - Product owner picks the stories, top of the backlog first - Each story has a clear title and acceptance criteria - Reference stories (a 2, a 5, an 8) are visible to everyone For each story (aim for 3-5 minutes) 1. Product owner reads the story and answers questions 2. Everyone picks a card privately 3. Reveal all cards at the same time 4. If the cards are far apart, the lowest and highest voters explain 5. Re-vote once. Still split? Take the higher number or park the story 6. Record the estimate and move on After the session - Stories at 13+ get split before sprint planning - Stories with "?" go back to the product owner with questions
Run each story through this before it gets a number.
READY TO ESTIMATE? [ ] The story says who it is for and what value it delivers [ ] Acceptance criteria are written down [ ] Designs or examples are attached (if UI work) [ ] Dependencies on other teams are known [ ] The team understands how to test it [ ] It is small enough to finish in one sprint Any box unchecked = the estimate will be a guess. Fix the story first, or vote "?" and say why.
An estimate in a spreadsheet goes stale the day the sprint starts. A board keeps story points next to the tasks, the owners, and the due dates your whole team sees. Try t0ggles free - no card required.