Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

How to Estimate a Story

Article by Quick Scrum

What is a Story Point?

Story points represent the relative sizing of the user story. It is a unit of estimation used by Agile teams to estimate User Stories.

When the product owner wants some features to be developed he/she desires to know how soon the team can complete the features and how many resources it will take to complete the work. From the developer’s perspective it’s next to impossible to predict the exact time in which he/she can complete the work. The person can, however, give a rough estimate in terms of how much time it might take to complete the work. Note that instead of “will” the developer chose to use “might” because he/she is not absolutely “sure” about the time factor but “feels” it might take that much time. This is user story estimation in a nut shell.

You don’t give an exact number explaining how complex the story is and how long it’ll take to develop – you give a rough “estimate”.

We are good at comparing size, so estimating a story using fibonacci series sequence (0, 1, 2, 3, 5, 8, 13, 20, 40, and 100) gives more clarity of its complexity and relative sizing in terms of development. It is helpful to have a set of stories nearby to make comparison and recommendation to set priority.

Here are the examples of relative sizing and its estimation points to develop following vehicles:


Consider following factors while estimating stories

  • Complexity : Consider the complexity of the story.

  • Risk : Consider the team’s inexperience with developing this story.

  • Implementation : Consider the implementation factors.

  • Deployment : Consider the deployment requirements.

  • Interdependencies : Consider other outside issues.

Who should be involved in story Point estimation?

All team members who are responsible for getting a story done should ideally be part of the estimation.

Advantages of using story points for estimating work

  • Story points are a measure of relative size and complexity.

  • Story points are unit less, meaning as a scale, they are only valuable to compare against each other within the same team.

  • Estimating in story points allows/encourages everyone, including business people to participate in the estimation process (using Planning Poker).

  • Estimating in story points is fast and easy.

  • Story points initiate high-level discussions about everything that is involved in a project.

  • Earned points can be used to generate the teams velocity which can be used to predict future work capacity.

Steps to estimate stories

For each story to be sized, do the following as a team (Product Owner, Scrum master & Team member).

  1. Identify base stories

Identify one or multiple base or reference story against which you would do relative sizing of the backlog. This story is picked from current product backlog or a different story which we have done earlier. But what is important is the understanding of this story is same among everyone on the team. Team should be confident of this base story.

2. Talk through the detailed requirements

Product Owner will answer questions and provide explanation about what exactly this story entails.

3. Discuss and note down points

These can be bullet points on the story card or text in the “notes” section of a tool. This is best done by Scrum Master who can add these details as and when discussions are on.

4. Raise questions if any

During discussion, question may arise and must be clarified the same time. Such as

  • Requirement : Any doubt about story requirement? Raise an alert. Ask product owner to give more clarity.

  • Technical Feasibility : Can story be delivered using current technology? Any unforeseen technical challenges must be surfaced.

  • Acceptance Criteria : Team must clarify the check list to be fulfilled to mark story as accepted.

  • Dependency : Does this story have external dependencies? If yes, that must be understood and resolved quickly.

  • Expertise : Do we have enough skills to deliver the story? Team must have internal skills to deliver story otherwise delivery might be delayed or not done properly.

5. Agree upon estimated size

Every team members must agree upon estimated size decided for a story.

  • No labels