Story points measure complexity and effort together, plus a third factor most teams forget to name: uncertainty. Complexity is how hard the work is to figure out, effort is how much of it there is, and uncertainty is how much you don't know yet. A single story-point number is a blend of all three, which is why two people can both be right and still vote 3 and 8.
This article gives you a scoring rubric for the three factors, a way to turn the scores into points, and three worked stories where the factors pull in different directions.
Why "is it a 3 or an 8?" debates happen
Watch a contested planning poker round and you'll often hear three different arguments:
- The developer who voted 3: "The code is simple. It's a string change."
- The developer who voted 8: "It's in 40 templates across three repos, and every one needs testing."
- The QA engineer who voted 13: "Two of those repos have no automated tests and we've never deployed them together."
Nobody is wrong. The first person sized complexity, the second sized effort, and the third sized uncertainty. Until someone names which factor they're disagreeing about, the revote will look the same as the first vote.
The three factors
Complexity: how hard is it to figure out?
Complexity is the thinking required, independent of volume. Ten lines of concurrency code can be more complex than 500 lines of form fields.
Ask:
- How many edge cases or state transitions are there?
- Is the logic tricky (algorithms, concurrency, money, time zones)?
- Are we following a familiar pattern or designing a new one?
- How many systems does it touch, and do they interact in non-obvious ways?
Effort: how much work is there?
Effort is the volume of work across every role, even if each piece is easy.
Ask:
- How many files, screens, services, or records change?
- How much testing is required (unit, integration, manual, accessibility)?
- Is there migration, configuration, or documentation work?
- How many people or teams need to coordinate, and is deployment multi-step?
Uncertainty: what don't we know?
Uncertainty, sometimes called risk, is what could make this story much bigger than it looks.
Ask:
- Are the requirements clear and agreed, or likely to change?
- Have we used this technology, library, or API before?
- Do we depend on another team or vendor?
- Are there production unknowns: data quality, scale, performance?
A useful test for telling complexity and uncertainty apart: complexity stays the same after you learn more; uncertainty shrinks. A sorting algorithm is just as complex once you understand it. An unfamiliar vendor API stops being uncertain once you've called it. That's why uncertainty is handled with spikes and complexity is not.
Scoring rubric
Score each factor 1 (low), 2 (medium), or 3 (high). A 1-to-3 rubric is deliberately coarse. A 1-to-5 rubric invites the same false precision you were trying to escape.
| Score | Complexity | Effort | Uncertainty |
|---|---|---|---|
| 1 (Low) | Familiar pattern, few edge cases, one component | One or two files or one screen; routine tests; single deploy | Requirements clear; tech known; no outside dependencies |
| 2 (Medium) | Some branching logic or edge cases; touches 2-3 components; light design needed | Several files or screens; meaningful test effort; some config or docs | A few open questions with a known way to answer them; new-ish library with good docs |
| 3 (High) | Hard logic (money, concurrency, security, time); new design; subtle interactions | Many files, services, or records; heavy testing; coordination across teams; migration | Unclear requirements, untried tech, external dependency, or production unknowns |
Turning scores into story points
Add the three scores (range 3 to 9) and map to Fibonacci:
| Total score | Story points | Notes |
|---|---|---|
| 3 | 1 | Low on everything |
| 4 | 2 | |
| 5 | 3 | |
| 6 | 5 | Typical story |
| 7 | 8 | |
| 8 | 13 | Consider splitting |
| 9 | Don't estimate yet | Split or spike first |
Override rule: if uncertainty scores 3, discuss a spike before accepting any number, whatever the total. A high-uncertainty 8 is a much less reliable 8 than a high-effort 8.
This is a calibration aid, not a law. Once your team has reference stories it trusts, compare against those first and use the rubric when votes are spread. Some teams prefer multiplying the factors or weighting one more heavily. Multiplication inflates quickly (a 3×3×2 story becomes 18, which tells you little) and weightings tend to get tweaked until they confirm gut feel. Simple addition plus the uncertainty override is easier to defend and remember.
Three worked stories
Story 1: low complexity, high effort
Story: "Update the legal footer text and link on all customer-facing email templates."
| Factor | Score | Reasoning |
|---|---|---|
| Complexity | 1 | Text and link change. No logic. |
| Effort | 3 | 38 templates across two services; each needs a visual check in three email clients; two deploy pipelines |
| Uncertainty | 1 | Legal has approved the exact wording; templates are known |
| Total | 5 | 3 points |
What happened in poker: Round 1 came back 1, 1, 5, 5. The two 1s were picturing a single shared footer partial. The 5s knew the older service has copy-pasted footers in every template. Once that was said, the revote landed on 3 for everyone. The disagreement was entirely about effort.
Takeaway: low complexity doesn't mean low points. If a "trivial" story is touching dozens of places, effort is carrying the size.
Story 2: high complexity, low effort
Story: "Fix proration so customers who change plans mid-month are charged correctly when the billing period crosses a daylight-saving change."
| Factor | Score | Reasoning |
|---|---|---|
| Complexity | 3 | Date arithmetic across time zones, money rounding, several edge cases (leap years, plan downgrades) |
| Effort | 1 | One function in the billing service, plus targeted tests |
| Uncertainty | 2 | Bug is reproduced, but the team is unsure whether past invoices need correcting (open question for finance) |
| Total | 6 | 5 points |
What happened in poker: Round 1 was 2, 3, 8, 8. The 2 and 3 saw "one function." The 8s had been burned by time-zone bugs before. Naming the factor helped: everyone agreed effort was a 1 and complexity a 3. The remaining disagreement was the finance question, which the PO took as an action. The team revoted to 5, with a note that correcting past invoices would be a separate story.
Takeaway: complexity is what makes careful people slow down. Small diffs can still be 5s.
Story 3: moderate everything, high uncertainty
Story: "Let customers pay by bank transfer using [new payment provider]."
| Factor | Score | Reasoning |
|---|---|---|
| Complexity | 2 | Standard REST integration and webhook handling; the team has done card payments before |
| Effort | 2 | New payment option in checkout, webhook endpoint, a reconciliation job, tests |
| Uncertainty | 3 | Never used this provider; sandbox reported to be unreliable; settlement timing unclear; compliance review needed |
| Total | 7 | 8 points, but uncertainty is 3 |
What happened in poker: Round 1 was 5, 8, 13, ?. The override rule kicked in. Instead of revoting, the team created a spike: "Timebox two days: get a sandbox transfer working end to end, confirm settlement timing and webhook behavior, list compliance requirements." The original story was parked.
After the spike, they knew the sandbox worked, settlement took up to three business days (so the order flow needed a "pending payment" state), and compliance needed a specific audit log. They split it into:
| Story | Points | Uncertainty after spike |
|---|---|---|
| Bank transfer option in checkout with pending state | 5 | 1 |
| Webhook handling and order status updates | 5 | 1 |
| Daily reconciliation job with audit log | 3 | 1 |
Total: 13 points, more than the original 8. That's normal. The spike didn't make the work bigger; it revealed work that was already there. For more on this pattern, see estimating large epics.
Takeaway: when uncertainty dominates, the estimate is a guess. Buy information with a spike instead of padding the number.
How to use the three factors in a real session
Option 1: as a discussion prompt (recommended)
Keep voting once per story. When votes spread, the facilitator asks:
"Before we revote: is our disagreement about how hard this is, how much of it there is, or what we don't know?"
That one question resolves most contested rounds, because people usually discover they agree on two of the three factors. It costs nothing and doesn't change your process. More facilitation phrasing is in how to facilitate planning poker.
Option 2: explicit factor scoring
For a new team, or a story where the spread won't close, score each factor 1 to 3 out loud using the rubric and add them up. It's slower, so don't do it for every story. It's very effective for onboarding people who don't yet have a feel for the team's scale.
Option 3: tag uncertainty separately
Some teams record the single point estimate plus a confidence level (high, medium, low). That keeps the estimate simple while still flagging the risky items for sprint planning. If you use Alignlee's free planning poker, each vote already carries a 0 to 100% confidence slider, and low-confidence votes count less in the weighted result. A round where everyone votes 8 at 30% confidence is a strong hint to spike before committing. Confidence voting covers how to read those signals.
Estimating uncertainty: when to spike
Create a spike when any of these is true:
- Uncertainty scores 3 on the rubric.
- Votes span three or more Fibonacci steps (say, 3 to 13) and discussion reveals unknowns, not just different assumptions.
- Nobody on the team has done similar work.
- The story depends on an external API, team, or vendor you haven't worked with.
A good spike has a timebox (half a day to two days is typical), a question it must answer, and a defined output: written findings, a proof of concept, or split stories ready to estimate. It does not have a story-point estimate in most teams, since it produces knowledge, not product. Steve McConnell's cone of uncertainty explains why this works: early in a piece of work the range of possible outcomes is wide, and the only way to narrow it is to learn more, not to estimate harder.
Common mistakes
| Mistake | What it looks like | Fix |
|---|---|---|
| Sizing only one factor | "It's just a regex, 1 point" | Ask the three-factor question when votes spread |
| Calling uncertainty "complexity" | "We've never used this library, so it's complex" | Unfamiliar ≠ hard. Score it as uncertainty and consider a spike |
| Padding instead of spiking | Every risky story becomes a 13 | Spike, then estimate the known work |
| Using time as a fourth factor | "It's three days, so it's an 8" | Points come from comparison; dates come from velocity. See story points vs hours |
| Scoring every story three times | Refinement takes twice as long | Use the rubric only for spread or unclear stories |
| References without factor notes | Nobody remembers why the 5 is a 5 | Add factor scores to each reference story |
Add factor notes to your reference stories
When you document reference stories, include the factor breakdown. It makes the reference useful for comparison on each dimension, not just overall size.
| Points | Reference story | C | E | U |
|---|---|---|---|---|
| 2 | Add "last login" column to admin table | 1 | 1 | 2 |
| 3 | Legal footer update across email templates | 1 | 3 | 1 |
| 5 | Proration fix across DST boundary | 3 | 1 | 2 |
| 8 | Password reset via email | 2 | 3 | 2 |
| 13 | Migrate notifications to new queue | 3 | 3 | 2 |
Revisit the references every quarter. If the team now finds a former 5 easy because they know the area better, update it on purpose rather than letting it drift; calibrating story points explains how.
FAQ
What is the difference between complexity and effort in story points?
Complexity is how hard the work is to figure out: tricky logic, edge cases, new design. Effort is how much work there is: files, screens, tests, coordination. A one-line date fix can be high complexity and low effort, while updating 40 templates is the reverse. Story points combine both, plus uncertainty.
What are the three factors of story points?
Complexity, effort, and uncertainty (also called risk). Story points are a single relative number that blends all three. Naming the factors during discussion helps teams see why votes differ and which part of a story needs clarification or a spike.
What are complexity points?
"Complexity points" is another name some teams use for story points, to stress that points aren't hours. Strictly, a story point covers more than complexity: it also reflects effort and uncertainty. If you score complexity on its own, use a small rubric like 1 to 3 rather than a full Fibonacci scale.
How do you estimate uncertainty in agile?
Ask whether requirements are clear, whether the team has used the technology, and whether you depend on anyone outside the team. Score it low, medium, or high. When it's high, run a timeboxed spike to answer the open questions, then estimate the resulting stories with much less uncertainty.
Should we vote separately on complexity, effort, and uncertainty?
Usually not for every story. That's slow. Vote once, and when votes spread, ask which factor the disagreement is about. Reserve explicit three-factor scoring for new teams, onboarding, or stories where discussion isn't converging.