User Story Estimation Technique — One of the recommended ways

Kaustav Chakraborty
4 min readJun 30, 2019


In an Agile Development Practice, a development team tends to size or estimate their user stories after going through a round of analysis. It consists round of discussions with business and tech team before coming to a common conclusion and understand the complexity of the functionality. Because each and every functionality needs an estimation to understand the effort which is required. Which is also proportional to the average completion time. Story estimation helps team to plan their release and finding an approximate release date well.

In an ideal Agile world, a user story goes through the below cycle before going to production,

Story Development Life Cycle

We understand the complexity, effort of a story and provide some subjective unit to them based on a commonly understandable sequence. This subjected unit of estimation called Story Points.

To come up with the story points, we do User Story Estimation.

What is user story estimation?

Story Estimation is a process where the agile team comes together and discuss the various aspect of a user story (business value and technicality). Based on the discussion every individual will come up with story points. Which includes effort, complexity and unknowns. Then the team assigns X point to the story based on mutual agreements.

How should we assign the estimated point?

Most commonly, an agile team picks Fibonacci Series as a story point sequence. Also we can denote the sizing (like t-shirt sizing) along with the story points. The definition of sizing might vary based on team to team. For an example,

Story Sizing Chart

Let’s say, you are developing an email platform, where stories would be,

Example 1.0: Email Application story estimations

Consider the following factors during estimation:

  1. Complexity: Consider technical complexity of the story.
  2. Risk: Consider team’s inexperience on technical front
  3. Unknowns: Consider the unknowns of the story. This could be avoided as much as possible with proper technical analysis.
  4. Implementation Strategy: Consider the implementation factors.
  5. Deployment: Consider the tasks and requirements for deployment.
  6. Dependencies: Consider other issues like dependency on other story, etc.

The team should be present to estimate the story. Which primarily includes — Business Analyst(s), Quality Analyst(s), Designer(s) and Developers.

Steps to estimate stories

To estimate each stories, it is recommended to do the following as a team including Business Analyst(s), Quality Analyst(s), Tech Lead, Developers, Product Owner and Scrum Master.

  1. Identify base stories

Base stories are the ones which gets estimate initially. Mainly by following Triangulation Exercise of Story Estimation, one identifies stories having different weights in it. These stories becomes the base stories of your project.

To do relative sizing of backlog stories, it is a best practice to identify the base stories first. These base stories should consists of majority of different sizes which you are going to consider for your project. These stories can be picked up from the current backlog or the initial ones which got already played as part of early iterations. What important is, this stories should be equally understandable by each member of the team and agreed on the sizing.

Do not forget your roots.

2. Understand the detailed requirements

Product owner / Business Analyst / Client will provide the exact requirement of the story. They will be the only person who are accounted to provide answers of any open questions before story estimation.

3. Tech analysis

It is very important to note down all the possible points and approach which are required when the story is in play. When the detailed tech analysis are present on the story (i.e., API response pattern, steps to implement, blockers etc), it becomes easy to understand for the tech team to estimate the story well. This can be done by tech leads, developers of the team.

4. Discuss on open questions, if any

During the sizing, these questions might get raised,

  • Design Requirements: Go through the design mock up and understand what else we need to learn before the story estimation.
  • Testing: You need to know whether any special setup for unit testing is required. Also how much work is involve to help the customer to automate the functional tests for this story?
  • Dependency: Does this story has any external dependencies?

5. Mutual agreement on estimated size

Every team members have to agree upon the estimated size of the story. If team has any disagreement, we should understand the points and try to incorporate the same on the estimation.

A good read on Story estimation technique by ThoughtWorks

You should follow these for every story. It will help you to plan the releases and iteration goal. It also reflects team’s velocity (Total pointer story can be played in an iteration) per iteration.



Kaustav Chakraborty

I help early stage startups to set their infrastructure practices, Sr. Software Engineer @ HelloFresh (