Story Point Estimation Examples: 12 Worked Stories

Abstract scales click faster with concrete examples than with more theory. This page walks through twelve realistic backlog items - a mix of features, bugs, and technical work - each sized with the reasoning a real team might use, on both the Fibonacci and t-shirt scales. For the theory behind any of this, start with the complete story points guide.

A note before the examples: none of these numbers are "correct" in any universal sense. They're illustrations of reasoning, not a reference table to copy into your own backlog - your team's actual estimate depends on your codebase, your history, and your calibration, exactly as the full guide explains.

1. Add a "remember me" checkbox to the login form

Fibonacci: 1 · T-shirt: XS

The UI change is trivial, the underlying session-extension logic already exists for other flows, and the acceptance criteria are unambiguous. Nothing here requires discussion - a story like this usually gets near-unanimous votes on the first round.

2. Let users export their order history as a CSV

Fibonacci: 3 · T-shirt: S

Moderate but well-understood: a query against existing data, a CSV serialization step, a download button. The team's spread on a story like this is usually tight (2-3-3-5) with maybe one voter flagging "what about orders with 10,000+ line items?" - worth a quick scope clarification before finalizing.

3. Integrate a new payment provider's checkout flow

Fibonacci: 8 · T-shirt: L

Real complexity: unfamiliar API, new error states, PCI-adjacent handling, and testing that likely requires a sandbox environment with its own quirks. This is the kind of story where asking the highest estimator first usually surfaces the actual risk - often something like "the sandbox doesn't support the failure cases we need to test."

4. Migrate the checkout service to a new internal API gateway

Fibonacci: ? (spike first) · T-shirt: not yet estimable

Scope is genuinely unknown until someone investigates what the new gateway requires and what breaks. Voting a number here would be theater - the honest move is a timeboxed spike to produce a scope, followed by a real estimate on the resulting, now-understood delivery story.

5. Fix a rounding error in cart total calculations

Fibonacci: 2 · T-shirt: XS

Known cause (a floating-point rounding issue), known fix (round at the right step in the calculation), low regression risk if the fix is scoped tightly. Bug estimation is usually this simple when the cause is already diagnosed - the complexity only shows up when the cause is unknown.

6. Investigate why checkout occasionally fails for international addresses

Fibonacci: sized in hours, not points (investigation story) · T-shirt: n/a

This is a bug with an unknown cause - the honest move is a timeboxed investigation ("spend up to 3 hours identifying the failure pattern"), not a point estimate on a fix nobody has diagnosed yet. Once the investigation produces a diagnosis, the resulting fix gets its own, now-estimable story.

7. Refactor the notification service to remove a deprecated dependency

Fibonacci: 5 · T-shirt: M

Technical debt with a reasonably well-understood scope: the team knows what needs to change, roughly how many call sites are affected, and has done similar refactors before. If the scope were murkier - "we're not sure how deep this dependency runs" - this would start with a debt-focused spike instead.

8. Add role-based permissions to the admin dashboard

Fibonacci: 13 (flag for splitting) · T-shirt: XL (flag for splitting)

A 13 or an XL is a signal, not a comfortable estimate. This story likely spans multiple roles, multiple screens, and both frontend and backend changes. Good splits here: by role (admin first, then editor, then viewer), or by screen (permissions on the user list first, permissions on settings second). See splitting user stories for the full pattern list.

9. Update the onboarding email copy for clarity

Fibonacci: 1 · T-shirt: XS

A content change with no logic behind it. Stories like this sometimes get an unexpected high vote from someone who knows the email template system is fragile - which is exactly the kind of hidden knowledge the estimation conversation exists to surface.

10. Add real-time collaborative cursors to the shared document editor

Fibonacci: 21 → split before estimating · T-shirt: XXL → split before estimating

This shouldn't be estimated as a single story at all - it's an epic wearing a story's clothes. A first pass at splitting: (a) broadcast a user's own cursor position to others, (b) render other users' cursors in the editor, (c) handle cursor position during concurrent edits, (d) handle reconnection/staleness. Each of those is independently estimable; the whole thing as written is not.

11. Add a "dark mode" toggle to account settings

Fibonacci: 5 · T-shirt: M

The interesting complexity here usually isn't the toggle itself - it's auditing every existing screen for hardcoded colors that won't respect a theme change. A team that has already built dark mode support into its design system might vote this a 2; a team retrofitting it onto years of ad-hoc styling might vote an 8. The spread on this exact story, more than almost any other on this page, depends entirely on what the codebase already has in place - which is exactly why the same story produces different honest estimates on different teams.

12. Send a Slack notification when a high-priority ticket is created

Fibonacci: 3 · T-shirt: S

Well-scoped integration work: a webhook, a message template, a condition for "high-priority." The most common source of disagreement on a story like this isn't the code - it's the acceptance criteria. "High-priority" needs a precise definition before voting starts, or the team ends up estimating three different imagined versions of the same ticket. This is a textbook case for a Definition of Ready gate.

Summary table

What these twelve stories have in common

Notice the pattern: every story that got a clean, fast, low-spread vote had clear acceptance criteria and a known technical approach. Every story that produced a wide spread, a spike, or a "please split this" flag was missing one of those two things. That's not a coincidence - it's the entire mechanism behind reliable estimation. Backlog refinement exists specifically to convert stories from the second category into the first before they ever reach a sprint-planning session.

A second pattern worth noticing: Fibonacci and t-shirt sizes track each other fairly closely across all twelve examples - a 1 is almost always an XS, a 5 is almost always an M. That correlation is normal and expected; it's why teams can move between the two scales without much friction. Where the two genuinely diverge is at the edges: t-shirt sizing has no equivalent of "spike this" or "hours, not points" for the trickiest items (6 and 4 above), because t-shirt sizing was never designed to capture that kind of scope uncertainty - it's built for speed on roughly-understood work, not for flagging work that isn't understood at all. That gap is one of the practical reasons Scrum Poker with Fibonacci remains the default for sprint-ready stories even on teams that use t-shirt sizes further up the backlog. The full comparison across all seven major techniques - not just these two - is in agile estimation techniques.

Estimate your own backlog

Reading worked examples only goes so far - your team's actual calibration comes from estimating your own stories, not someone else's. Create a free room, pull five real items from your backlog, and run them through a proper round: private votes, simultaneous reveal, discussion only on the spreads. If you want a quick starting point before the team votes, the story point calculator turns a few ratings into a suggested card.