How to Estimate Story Points in Agile?
A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.
In most cases a story point uses one of the following scales for sizing:
• 1,2,4,8,16
• X-Small, Small, Medium, Large, Extra-Large ( known as “T-Shirt Sizing”)
• Fibonacci sequence: 1,2,3,5,8,13,21
However, it is tough to identify a story from the scales assigned to them. In order to do that each team would have to find a baseline story. It does not necessarily to be the smallest one, but the one that everyone within the team can resonate with. Once determined, sizing of all the user stories should be initiated by comparing them against the baseline.
While estimating story points, we assign a point value to each story. Relative values are more important than the raw values. A story that is assigned 2 story points should be twice as much as a story that is assigned 1 story point. It should also be two-thirds of a story that is estimated 3 story points.
Now let us understand sizing in detail:
First, let us start with the importance of sizing. Sizing is beneficial as it:
– Gives us an overview of the scope of work
– Uses multiple perspectives to determine the size of work
– Clears out that we can’t be exact
– Rectifies false assumptions
Sizing is done ideally by the Agile delivery team (normally scrum team) For eg. consider a task of traveling from Delhi to Mumbai. The duration of the travel depends on the mode of transport (Think mode of transport as the technology with Flight taking 2 hours and Car 22 hours). If you choose to travel by the road, your driver’s route knowledge (domain knowledge) is required to reach on time. Duration is dependent on multiple factors, but the distance is approx 1400 Kms which is constant and doesn’t change. Now, replace the distance with size. Size is easy to estimate, but not the duration.
Sizing is done considering:
• The amount of work to do
• The complexity of the work
• Risk or uncertainty in doing the work
• Time / Duration
An estimate of effort/duration isn’t possible in Agile, unlike traditional projects. This is because the duration is dependent upon:
– Technology / Tools
– Domain Knowledge
– Skill-set [technical expertise] of developers doing the work
Outlined below is the relative sizing process:
1. List all the stories to be sized
2. Put them in order from smallest to largest
– Take the first user story
– Then take the second user story
– Decide which is bigger and put the bigger one above
– Then take the next one and decide where it fits relatively to the other two
– Then take the next one and do the same
– Repeat the process until all the stories are now in the list (in a sequence from smallest to largest)
3. Size the stories
– Start from the bottom and give that story a number 2 story points. Giving ‘2’ provides you the room to give a smaller story ‘1’ if discovered at a later stage.
– Look at the next story and decide how big is that story as compared to the first one
– Continue until you have a size on each story
– Use these set of numbers [influenced by Fibonacci] while sizing:
1, 2, 3, 5, 8, 13, 21
Note:- we can use T-shirt sizes XS = 1, S = 2, M = 5, L = 13 , XL = 20, XXL = 40
Now let us understand Story points vs hours
A story point is a high-level estimation of complexity involved in the user stories, usually done before sprint planning, during release planning or at a pre-planning phase. Story points along with sprint velocity provide a guideline about the stories to be completed in the coming sprints.
The hour based estimation, on the other hand, is a low-level estimation used to represent the actual effort in man hours needed to complete all the tasks involved in a user story. Hour based estimation should be used when the task estimations are provided in hours.
In fact, story points and task hours serve different purposes at different times and we should avoid relating them to one another for better execution of the sprint and the release. As the diagram below illustrates, we would recommend not emphasizing on the story points during sprint planning and focus more on estimating the time needed to complete all the tasks involved in the user story.
Hope the blog was helpful and you will now be able to estimate story points more accurately for your Agile projects. Do let me know your queries in the comments below.
Very precise and helped me in a way that I can explain to the team. It becomes hard when the team has no idea what Story Point is all about. I don’t agree to the point that Story points are misleading, instead the way they are used might be misleading. Teams should not get into a competition mode with other teams trying to display higher velocity. Story point estimation will tell a team how much work can be done in a Sprint. This is my point of view.
why do we need story points , when we can mention 0.5 day , 1D , 2 D as a effort estimation?
Using story points gives you predictability based on a teams historic performance. And relative estimates are easier to do than absolute.
Great read! I have two question regarding the example given below:
If team A takes 1 day (1 user story point) to deliver a functionality on a existing software while team B takes 8 days (8 user story points) to deliver a similar functionality to an existing software.
Why does team B has a greater velocity than team A over a similar functionality being delivered to an existing software?
Does ‘Busy’ > ‘Productive’ becomes true?
Technically Team B would have higher velocity but we need to consider that the evaluation of story points between teams are different. In the above example each of Team A’s story points are worth more complexity. While Team B story points are worth less complexity. It can be said that team B has a higher velocity of getting less complex work done compared to team A.
It comes down to how relative the story points are to complexity. It must be understood that the “T-shirt sizing” estimator evaluates complexity of a project relative to the complexity of all the other work to be done.
It shouldn’t be said that Team B has a higher rate of completion of work (velocity) with equal complexity compared to Team A.
Story points should be relative to the team and not to the amount of time (days) it takes to complete each task. You cannot relate time to story points. If you are then use hours instead of story points. Team B will have a greater velocity but the amount of deliverable work will be the same when it comes time for the sprint review.
Very to the point article. Really helped in understanding story points
Very crisp and precise way of explaining. Thanks for this. Should scrum teams include QA effort also in the estimated effort? Ideally story estimation should include Dev and QA estimates.
Yes That’s true
Very nice and informative.
Informative article. I have a question –
Should the scrum team consider QA effort/Capacity as well, when assigning story points?
It’s related to complexity of the story point and that can be in terms of Dev and QA, so ideally Qa should be there while estimating a user story.
Informative article. I have a question –
Should a scrum team consider QA effort/capacity as well, while assigning story points?
@Doug Kimzey. Your comment really made me think a lot. How do you usually do it, or rather what do you use instead?
Good article. I must confess that I am not at all a fan of story points. Velocity is a bad idea and extremely misleading. Lumping or aggregating different story point values into a velocity does not really capture the fact that a team will probably have higher velocities for 2 story point tasks and 5 story point tasks. This will drive a great deal of sprint-to-sprint variation in velocity. Using an average velocity will not give you a stable predictions of the capacity of a team for future work. Every team will have a different velocity for each distinct story point level. This is similar to the problem of using LOC per day (or sprint).
You have presented a very good description of story points. But, I honestly think that using story points as a measure of work completed is a bad practice. Teams who take on the higher story point tasks are perceived as lagging behind the teams that have lower story point tasks. People personally invested in story point usage tend to be surprised when a sudden mass exodus finally occurs. This is no exaggeration – this does happen.
Straight to the point. Very crisp and clear.
At last I understood what is story point in Agile.
Short and crisp with relevant basic information to start off for a newbie in Agile.
Thanks for this post! I thought it was a really good distillation of story points and how to estimate them, explained in a simple yet useful way. I really enjoyed it.
Nicely explained with simple examples.
Very informative.