Skip to main content

Agile Story Point Estimation - By: Ankur Mistry

In my previous article, we have discussed User Story in Agile Scrum. In this article, we will learn what Story Point is and what Story Point Estimation techniques are.

Story Point in Agile Scrum
A Story Point is a unit of measurement of the overall effort needed to complete specific requirements of a product backlog item. When we have our product backlog ready and when a team is ready for next sprint, they pull the priority user stories from the product backlog and start estimation for completing the user stories.
 
Story Point Estimation
In any project, estimation plays a major role. It's very important in terms of the project budget, scope, and also to track the progress of the project against each milestone.

 
image source : https://www.youtube.com/watch?v=sCCUEtjCpCs 
 
Estimation is a Team Sport and involves all team members like all developers, designers, testers, deployers on the team is key.

The main benefits of involving the team to estimate is we are giving importance to each member, that satisfies your principles, behind the Agile Manifesto "Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done"

As the story points represent the effort to develop a story, the estimate must include all the factors that can affect it like - the amount of work to be done, the complexity of the work, and any risk or uncertainty in doing the work. When estimating with story points, make sure you consider all the above factors.

Absolute Estimation v/s Relative Estimation 
Let's take an example of estimating the following.

If we ask the amount of liquid in ml. of the glass on your left side in the below picture to the team, the answers should be different, some say 100 ml some will say 150 ml. The answers are different but not accurate.

 
Image Source:https://www.blackpepper.co.uk/what-we-think/blog/agile-vs-waterfall-estimating-planning-tracking 

Now, we will ask the 2nd question to the team, like which glass has more liquid. The answer of all the team members is - the left side glass has more liquid.

That means we are good in estimating relatively.

The idea behind the above example is that we might be bad at estimating how many hours it will take to complete a particular requirement, but we are pretty good at saying for example requirement 1 would take twice as long as requirement 2. When team estimates with the story point, they assign a point value to each item.

It's just a value to compare that is assigned - 2 Story points should be twice as much as a story that is assigned 1 Story point.
 
 
image source : https://www.youtube.com/watch?v=sCCUEtjCpCs 

How to size a Story
Sizing a story needs efforts from the team. Some of the key points to use as a guideline for estimating a requirement/story are as follow -
image source: https://www.youtube.com/watch?v=sCCUEtjCpCs 

Product Owner reads the requirement and the team identifies the simplest task and makes it a base story. The team then goes through the requirements and splits requirement into user stories.

Example "As a < type of user or role >, I want < some goal > so that < some reason >." How it will be tested

Sample questions the team should ask -
  • 'How big it is?' instead of 'how long will it take'
  • What we have to learn to deliver this story?
  • What will be the likely coding effort? Has anyone had prior experience or from the team, anyone implemented it before?
  • Is any special setup required to unit test this story?
Based on the answers, jot down the deliverable items and decide "Definition of Done" for the task.

Now, compare the story to base story. Each team member should measure or guess story points here estimation techniques come in to picture. (I will explain estimation techniques in my next article.)

Example: For design and develop login page each member should measure or guess story points, one member says 1 other say 3 or 5.

If a vast difference is found in story points estimation among team members, ask for justification now. Here, all members will justify why they choose 1 point or 3 points or 5 points. Did one person see any issue or complications the other person didn’t? or Did one person see an easy approach that others didn’t?

The team will discuss and agree on one story points based on majority after the discussion. and Team will Translate story to Sprint board.
 
image source : https://www.youtube.com/watch?v=sCCUEtjCpCs 

Different Estimation or Sizing techniques
There are different Sizing techniques available for sizing, from which a team can mutually decide to use one. Some of them are,
  • Planning Poker
  • T-Shirt Sizes
  • The Bucket System
  • Big/Uncertain/Small
  • TFB / NFC / 1 (Sprint)
  • Dot Voting
  • Affinity Mapping
  • Ordering Protocol
  • Divide until Maximum Size or Less
Benefits of Story Point Estimation
Use of sizing technique prevents the need for frequent re-estimation. This makes the story independent of who is going to work on the same. Also, as the team experiences grows it can complete the same task in fewer hours but the task estimation/achievement remains the same. This gets reflected in form of velocity of the team.

Estimating in terms of hours will always remain in terms of work hours. Velocity will be a key point that reflects the progress of the team.

It also eases developers while estimating, as estimating in days a fear if whether they can finish in this time starts creeping in.

It acts as a team building activity as team shares, constructively criticize and debate overestimating stories.Relative estimation results are good and faster to achieve as compared to absolute ones.

Summary
  • Story points are unitless and make sense only relatively.
  • Story points are not time or hours.
  • The development team does estimation in Scrum, the ultimate goal of estimation is to gain a shared and better understanding of the item as scrum focus more on collaboration and cross-functional team.
  • invites collaboration as team behavior becomes prominent over individuals.
  • help drive cross-functional behavior.
  • Learn from past estimates.
I hope you like this article, in my next article we will discuss Relative Estimation Techniques like Planning Poker, T-Shirt Size Estimation etc. Question for Discussion: Does Scrum prescribe any particular Estimation technique?

Reference
  • https://www.mountaingoatsoftware.com/blog/what-are-story-points 
  • http://www.agileadvice.com/2015/10/13/agilemanagement/9-agile-estimation-techniques/ 
  • https://www.atlassian.com/agile/estimation
  • https://www.mountaingoatsoftware.com/blog/what-are-story-points
  • https://www.blackpepper.co.uk/what-we-think/blog/agile-vs-waterfall-estimating-planning-tracking

Comments

Popular posts from this blog

User Story In Agile Scrum - By Ankur Mistry

In this article, we will learn what User Story is and how to write one. User Story plays a major role here. It is the part of the Agile process where instead of writing comprehensive requirements, we write a short description of a feature. As the  Agile Manifesto  says 'Working Software' Over 'Comprehensive Documents'. What is User Story? User Story is a short and simple description of the feature or requirements of the project. Generally, user stories are written on sticky notes or index cards as a user or role-based perspective. User Story Template As a < type of user or role >, I want < some goal > so that < some reason >. The template identifies 3 questions - "Who", "What", and "Why". If the team doesn't know these three answers, it means they don't understand the story, and if they don't understand the story, then it's difficult to split it well.   Reference:https://mazoea.wordpres

Visual Studio Team Services - Agile - Scrum Project Management Tools

Before starting this article let's understand what is Agile and Scrum.  What is Agile Agile is a  Method  of project management that is characterized by dividing module in to tasks and t asks into short phases of work and frequent reassessment and adaptation of plans. In other words, Agile is a Time Boxed incremental software development method.  What is Scrum Scrum is an incremental agile software development framework  (Agile Framework).   Agile Scrum Process in Short. Product Backlog:  A product owner creates a customer’s wish list and prioritized it and create backlog, called Product Backlog. Sprint Planning:  In this meeting team select small part or module from the Top Priority Wish List of Product Backlog and prepare a small task list. Setting Capacity and Sprint:  Team has to deliver the tasks in 2 weeks or 4 weeks sprint, here Scrum Master bind tasks with Time and User. Scrum Master’s role:  Is to make sure team focused on its goal. End of the sprint:  

The Burn Up Charts In Scrum By: Namrata Parik

I would like to propose a less-taken path in my maiden article to track the progress in scrum. We usually do it using the burn down chart which is relatively easier to understand as compared to the burn up chart. These charts help the team and stakeholders to see and track the progress at any point in the release process or sprint. Burn-down chart provides us the information showing the progress based on the remaining hours or story points from top to bottom. (The burn-down chart can be plotted using story points, task count or the remaining effort) This chart is a plot of expected remaining and actual remaining, this is the most used chart in scrum and since it has only two lines it is considered to be a simple chart. It does not cover the scope creep. So sometimes what might look like ‘no work ‘ done by the team may actually be a result of scope creep. The chart below reflects that the team has not done any progress in Sprint 5 and 6 as the story points remain the same. Image