Content
- Content
- 🎯 Main idea / Goal
- 🔎 Three key factors of story points
- 🔢 Fibonacci Story Points Scale with Descriptions
- ✅ Quick Summary Table (Task Size + Story Points + Meaning)
- ✅ Visual Metaphor for Sizes
- ✅ Effort & Complexity Progression
- ✅ General Guidelines for Everyone
- 🤝 Instructions by Role
- ✅ The Estimation Process
- ✅ Questions to Ask During Estimation
🎯 Main idea / Goal
Provide a team-wide, relative estimate of the entire User Story based on effort, complexity, risk, and uncertainty, not just your own role.
Each team member brings their perspective to the story, but the final estimate reflects the story as a whole, not just individual pieces.
Three key factors of story points
-
Task complexity (logic, integrations, challenges).
-
Scope of work (how much needs to be done).
-
Uncertainty (risk level, need for research).
Fibonacci Story Points Scale with Descriptions
For Planning Poker & Team Estimation Alignment
|
Story Points |
Task size |
Complexity |
Risk/Uncertainty |
Effort |
Dependencies/Coordination |
Testing/Validation |
Examples |
|---|---|---|---|---|---|---|---|
|
1 SP |
Tiny |
Trivial. No complexity or decision-making. |
None. Fully understood. |
Minimal. Quick fix or trivial task. |
None. Completely isolated. |
No or minimal validation needed. |
|
|
2 SP |
Very Small |
Simple. Slightly more complex than 1 SP. |
Very low. A known task with little ambiguity. |
Small. Requires attention but simple to complete. |
Rarely requires others. Mostly solo work. |
Basic validation or a quick QA check. |
|
|
3 SP |
Small |
Moderate complexity. Some logic or conditions. |
Low-to-moderate. May need clarification. |
Noticeable effort; requires thinking and accuracy. |
Coordination with 1-2 people may be required. |
Tests beyond happy path. Edge cases considered. |
|
|
5 SP |
Medium |
Complex. Involves multiple components. |
Moderate risk. Known complexity with a few unknowns. |
Significant effort. Requires structured work. |
Coordination across multiple roles (FE/BE/QA). |
Extensive testing, multiple scenarios. |
|
|
8 SP |
Large |
High complexity. End-to-end feature with layers. |
Medium-to-high risk. Integration points or uncertainties. |
High. Full-feature scope across systems/components. |
Multi-role coordination, possibly with external teams. |
Full regression, performance tests, cross-browser/device checks. |
|
|
13 SP |
Very Large |
Very complex. Heavy cross-system interactions. |
High risk. Many unknowns and dependencies. |
Very high. Multiple working sessions likely. |
Multi-team collaboration, dependent services/systems. |
Regression, integration, and edge-case testing required. |
|
|
21 SP |
Huge |
Extremely complex. Broad system impact. |
Very high risk and uncertainty. |
Huge effort. Not realistic to complete in one sprint without decomposition. |
Significant cross-functional team coordination. |
End-to-end testing, multiple integration environments. |
|
|
34 SP |
Epic |
Epic-sized. Ambiguous scope, high complexity. |
Extreme uncertainty. Requirements not fully clear. |
Too large for a sprint. Requires further discovery and decomposition. |
Coordination across product teams, stakeholders, multiple teams. |
Discovery required before defining test strategy. |
|
|
∞ (Infinity) |
Unknown / Undefined |
Completely undefined scope. Total ambiguity. This signals “NOT READY FOR ESTIMATION”. There’s too much uncertainty, unclear scope, or missing dependencies. Requires discovery work or PoC. |
Maximum uncertainty. You lack enough information to estimate. |
Impossible to estimate until clarified. |
No clarity on dependencies, stakeholders, or technical approach. |
Testing unknown; cannot define acceptance criteria yet. |
|
✅ Quick Summary Table (Task Size + Story Points + Meaning)
|
Story Points |
Task Size |
What It Means |
|---|---|---|
|
1 SP |
Tiny |
Super simple, no complexity or risk. |
|
2 SP |
Very Small |
Simple, clear task, minimal dependencies. |
|
3 SP |
Small |
Basic task, some logic, minor coordination. |
|
5 SP |
Medium |
Moderate complexity, cross-component work, more planning. |
|
8 SP |
Large |
Complex task, multi-role coordination, possible unknowns. |
|
13 SP |
Very Large |
Very complex feature, high risk, requires multi-team collaboration. |
|
21 SP |
Huge |
Too big for one sprint, needs breakdown or special attention. |
|
34 SP |
Epic |
Epic-level work, needs discovery, not sprint-ready. |
|
∞ (Infinity) |
Unknown / Undefined |
Completely unclear, impossible to estimate without clarification/research. |
✅ Visual Metaphor for Sizes
|
Size |
Example Metaphor |
|---|---|
|
Tiny |
Screwing in one lightbulb. |
|
Very Small |
Hanging a single picture frame. |
|
Small |
Assembling a basic IKEA chair. |
|
Medium |
Building a full IKEA table set. |
|
Large |
Renovating a room: paint, flooring, and furniture. |
|
Very Large |
Renovating a house: plumbing, electric, interior. |
|
Huge |
Building a house from scratch. |
|
Epic |
Building an entire apartment complex. |
✅ Effort & Complexity Progression
-
1-5 SP ➔ Typical small-to-medium stories, normal in sprints.
-
8-13 SP ➔ Larger features; only one or two per sprint, requires confidence and clarity.
-
21 SP+ ➔ Signals “Break this down!”.
✅ General Guidelines for Everyone
-
Estimate the Whole Story, not just your work. Consider BE + FE + QA + Design + Risks together.
-
Think Relatively, not in hours or days. "How big is this compared to other stories we’ve done?"
-
Focus on Complexity, Effort, and Risk, not duration.
-
Speak Up if you see hidden risks, dependencies, or gaps.
-
Ask Questions if you don't understand the story.
-
The Final Number is a Team Decision, not individual votes.
Instructions by Role
🟦 For Backend (BE) Developers
What to Think About
-
How complex is the business logic?
-
Are there new APIs to build or integrate with?
-
Are there external services, data transformations, or heavy database work?
-
Do you need to coordinate with other teams (DevOps, Design, other services)?
-
Are there tech debts, refactoring, or architectural decisions required?
-
Are there performance or scalability concerns?
How to Estimate
-
Focus on technical complexity, but consider how your work impacts FE, QA, and Design.
-
If the BE work is tricky, but FE/QA is simple - still account for the whole picture.
-
If something is uncertain, flag it - might need a Spike or higher estimate.
🟧 For Frontend (FE) Developers
What to Think About
-
Is the UI complex (custom components, animations, responsiveness)?
-
Are we using new technologies or frameworks?
-
Do you need to create new components or refactor existing ones?
-
Is cross-browser or mobile responsiveness important?
-
Are there API integrations and error handling considerations?
-
Does the story depend on BE or Design being ready?
-
Any theme settings (dark mode) or localisations?
How to Estimate:
-
Think about complexity, reusability, and coordination with BE, QA and Design.
-
If there’s UI uncertainty, or a design isn’t finalized, account for it in risk.
-
Don’t forget QA testing time, if you’re involved in frontend bug fixing.
🟩 For QA Engineers
What to Think About
-
How many test cases and scenarios need to be covered?
-
Are there edge cases, complex workflows, or 3rd party systems?
-
Is test data preparation required?
-
Can the feature be automated or will it be manual testing only (if automated - we should create another task)?
-
Does this story introduce regression risks for other features?
-
Will there be environment setup or integration testing?
-
Is performance testing needed?
How to Estimate:
-
Estimate test effort and risk in the context of the entire story.
-
Even if QA is small, if the story’s risky - raise your estimate!
-
Ask about tech complexity, BE/FE changes, and design if unclear - it all impacts testing effort.
🟪 For Designers (UX/UI)
What to Think About
-
Is the user flow already designed, or do we need to create it from scratch?
-
Are there wireframes, mockups, or prototypes to deliver?
-
Is there UI complexity (animations, responsiveness, accessibility)?
-
How many iterations/reviews are expected?
-
Will user testing or validation be needed?
-
Is the design dependent on BE/FE feasibility, requiring back-and-forth?
How to Estimate
-
If the design is not finalized, factor in time for iterations - raises the team risk.
-
Bring up any UX challenges or dependencies early - they impact BE/FE work.
-
If design requires tight collaboration with devs - mention this!
-
Even if your work is "done," the impact of design on devs/testing raises complexity - call it out.
✅ Summary for roles
|
Role |
Primary Focus in Estimation |
|---|---|
|
BE |
Complexity of business logic, integrations, data processing, dependencies. |
|
FE |
UI complexity, component building, API integrations, cross-device compatibility. |
|
QA |
Testing effort, scenarios, automation, regression risks, test data, environment complexity. |
|
Design |
UX complexity, iterations, handoff readiness, UI feasibility, user testing, design-developer loops. |
✅ The Estimation Process
-
PO/AC Explains the Story - team clarifies scope.
-
Each Role Thinks Through their perspective - raises risks, questions, and assumptions.
-
Estimate Silently - Reveal Simultaneously (Planning Poker).
-
If the numbers are spread out - discuss why (e.g., BE thinks it's simple, QA sees regression risk).
-
Re-estimate after discussion - aim for consensus.
✅ Questions to Ask During Estimation
-
Do we fully understand the story?
-
Is the definition of done (DoD) clear?
-
Are there unknowns/risks that might increase effort?
-
Do we need a investigation?
-
Can we break this into smaller stories?
