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