Theme

Estimation process with Story points on Rocken

Written by

in

Content

🎯 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.

  • change text on PDF

  • change button color

  • fix a typo

  • adjust a couple of CSS styles

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.

  • adding a field to an existing form

  • add validation to the field

  • change an existing API response

  • small config changes

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.

  • create a CRUD form with list and validation

  • update an API

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.

  • building a filtered list with pagination, but with small amount of fields in filter panel

  • multi-step user flow

  • batch operations

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.

  • implement Orders

  • filter on the page with a big amount of new fields from scratch

  • complex multi-step forms

  • role-based access management

  • notification services

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.

  • rewriting a core system module

  • migrating to a new framework

  • Migrating some small data

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.

  • Build profile page in CRM from scratch

  • Rewrite core architecture

  • Major subsystem replacement

  • multi-country localization from scratch

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.

  • Building a multi-tenant SaaS infrastructure from scratch (authentication, user management, billing)

  • Replacing an entire legacy CRM system and integrating it with third-party services (salesforce, HubSpot, etc.).

  • integrate with X28

  • implement Task Manager with ready design and with description but in one task

∞ (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.

  • change architecture (Vue2 → Vue3)

  • full platform redesign or migration

  • implement BI board from scratch

  • new business initiative with no scope

  • research project without clear objectives

✅ 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

  1. Estimate the Whole Story, not just your work. Consider BE + FE + QA + Design + Risks together.

  2. Think Relatively, not in hours or days. "How big is this compared to other stories we’ve done?"

  3. Focus on Complexity, Effort, and Risk, not duration.

  4. Speak Up if you see hidden risks, dependencies, or gaps.

  5. Ask Questions if you don't understand the story.

  6. 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

  1. PO/AC Explains the Story - team clarifies scope.

  2. Each Role Thinks Through their perspective - raises risks, questions, and assumptions.

  3. Estimate Silently - Reveal Simultaneously (Planning Poker).

  4. If the numbers are spread out - discuss why (e.g., BE thinks it's simple, QA sees regression risk).

  5. 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?

Comments

Leave a Reply

More posts