The estimation has been a point of concern for practitioners. However, it gets more confusing when it comes to agile ways of working since we discover requirements progressively in agile. This article’s purpose is to explore size estimation using story points. Size estimations are used for forecasting duration. We will cover this topic with the following sub-sections :
Agile Estimation
Irrespective of the project life cycle, estimation is always an estimate. We cannot predicate the exact date or time of finishing the work. You might have seen the diagram below called the Cone of uncertainty. The Cone of uncertainty primarily represents the uncertainty in our estimations. It says in the initial stage, the error in our estimation is higher, and as we know more and more about our project, we estimate better. So, over a period, our estimation will improve.
In project management terminology, the initial estimate is called rough order of magnitude (ROM) estimate, and later we get budgetary or definitive estimates.
Suppose you work in an environment where accurate estimations are made initially. In that case, you probably work in a very defined functional space with enough data to estimate things in advance. In the agile approach, we have emerging requirements; hence the estimation is also expected to emerge. Irrespective of the approach, our estimation always has some errors, and we reduce the errors by doing estimation frequently. When we have a high-level estimate, one may provide a probable estimate based on the relevant logic at that stage. Gradually when we have more product backlog items created, we estimate the product backlog items using story points; since the backlog refinement is an ongoing activity, the estimation of backlog items is also an ongoing activity.
We do have a definitive (error around +/-5%) detailed estimation for short-duration work in agile, for the work gets done in one iteration/sprint. At the beginning of each iteration/sprint, teams access what they can do in the sprint duration (usually two weeks)
Story Points
In the traditional world, we start by finalizing the scope, followed by a detailed breakdown structure and identifying activities. Once we have a list of activities, we estimate the milestones and delivery dates. But in the agile world, we spend less time estimating the items in the early stage of development because some items may get dropped and others added. Nevertheless, we still need some mechanism to quantify the work without getting into too many details, and story point estimation helps us achieve that objective.
Story Points estimation is based on the relative sizing of the work items ( requirements mostly User Stories ) in the Product Backlog. Relatives mean a team compares one work item with another and estimates whether the work item is bigger or smaller than the other. Based on the relative ranking, the team gives it a size number called story point. It is recommended to use non-linear series to ensure the size gap between big items increases to cover the uncertainty. If the work item is well understood, it is easy for the team to estimate the size with high accuracy. That’s why we have less gap in initial numbers like 1, 2 or 3, but as the work item gets bigger, the error in estimation also increases; hence the gap in sequence increases to subside those errors.
The most popular series is a modified Fibonacci sequence like
1, 2, 3, 5, 8, 13, 20, 40, and 100
The points for a given work item are decided in a group estimation activity where people share their opinion about the size of the item, and while analyzing the things, they might be thinking of various parameters or work like
As part of story point estimation, we are not estimating the effort because that will be dependent on factors like sequence or who is doing what, but we are estimating the volume, the uncertainty, the complexity, the external dependency, and other factors and based on that we are coming up with a relative judgement.
Story Point Estimation using Planning Poker
Planning Poker is a technique that gives an approach to facilitating a brainstorming session to estimate the work items/stories using story points. This technique usually follows these steps :
In Planning Poker, we are applying the Wideband Delphi technique, where we get an individual’s judgment without being influenced by others, followed by discussion and agreement on estimation. Each individual selects the card based on some assumptions that need to be shared; the goal here is to have a shared understanding of the user story/work item, and that’s the utility of this planning poker activity. Let’s say a story is estimated, and most estimators give an estimation as 8 story points, but only some members give 5 and 13 story points. These members are to share their analysis, and there may be some discussion. After this discussion is complete, everyone reselects their cards, and this time, they may have different estimates based on the points discussed. This process repeats until the team arrives at a consensus.
Story Points vs Hours
Effort estimation in person-hours (also called man-hours) is done with high accuracy expectations. Therefore, managers and teams are under high pressure to develop as accurate estimates as possible. As a result, they spend time figuring out how long it would take to complete tasks and usually come up with a fixed value in hours, days, or months. Such estimates are absolute estimates since they are done for a given work item in days or months.
Story Points are relative estimates independent of the skill or experience of team members and do not estimate the work in absolute numbers like days or months. Story points give a high-level estimate for planning and forecasting.
Here are a few reasons why should not be equated story points with effort:
Who will work on the User Story? – Whenever you talk about the effort, it directly relates to the question of whose effort. It is easier to say how many hours or days work will take if we know who will work on that and what all skill set that person will have. In the case of estimating in Story Points, we are still determining the people who will work on it.
The development Sequence of work is not yet identified.– Product Backlog Items / User Stories are made from the user’s perspective. When we do effort estimation, it depends on the solution and implementation sequence, the time needed to develop an item depends on which other things are already developed in the product.. While doing story point estimation, we don’t know which story will get developed and when.
The Definition of Done (DoD) is evolving -The definition of done may change over a period based on the improvement required. The time/ effort needed to do a given story will change with the change in the Definition of Done, but since the story point estimation is relative, it is not impacted by the change in the Definition of Done.
Improving technical/domain understanding:– The development Team’s understanding of the domain and other product development areas is improving daily. Therefore, the same work done today and done after one month may take a different time for the developer. Story points are relative, so the relative ranking of the size does not change, but the absolute estimate of doing the work will keep evolving.
Product is evolving – Development of a few initial stories may take extra time as we must implement everything from the start, but as the project grows, it may take less time. However, with the increasing complexity of the project, the estimation may increase as we must take care of existing factors too.
Team Dynamics- There is always a probability of new member addition or an existing member leaving the team. Predicting team dynamics in advance is challenging, and estimates based on the current team dynamic may not be absolute.
After reading these points, you may have an idea that it is difficult to estimate and equate story points with hours because hours are progressively discovered, and story point estimations are usually done ahead of time.
At the same time, it will not be correct to say that there is no correlation between story point and effort. While doing story point estimation, team estimates that 1 story point work is half the 2 Story Point work or 2 pointers will take less than half 5 pointers. So, there must be some co-relationship, but there cannot be a linear one; we can’t just say all the 2-pointers will take 20 hours. But if 5-pointers are taking Developer-X to Y hours, the 2-pointers are expected to take 50% of that time or less. Based on historical data, we can analyse and come up with the average effort taken for a specific story point in past. This data may help you in forecasting how much time a given set of user stories will take in the upcoming iterations. However, this correlation is not fixed. As our Definition of Done (DoD) improves, we can obverse a left shift or right shift in the average effort taken for a specific story point.
Effort estimation in person-hours (also called man-hours) is done with high accuracy expectations. Therefore, managers and teams are under high pressure to develop as accurate estimates as possible. As a result, they spend time figuring out how long it would take to complete tasks and usually come up with a fixed value in hours, days, or months. Such estimates are absolute estimates since they are done for a given work item in days or months.
Story Points are relative estimates independent of the skill or experience of team members and do not estimate the work in absolute numbers like days or months. Story points give a high-level estimate for planning and forecasting.
Here are a few reasons why should not be equated story points with effort:
Who will work on the User Story? – Whenever you talk about the effort, it directly relates to the question of whose effort. It is easier to say how many hours or days work will take if we know who will work on that and what all skill set that person will have. In the case of estimating in Story Points, we are still determining the people who will work on it.
The development Sequence of work is not yet identified.– Product Backlog Items / User Stories are made from the user’s perspective. When we do effort estimation, it depends on the solution and implementation sequence, the time needed to develop an item depends on which other things are already developed in the product.. While doing story point estimation, we don’t know which story will get developed and when.
The Definition of Done (DoD) is evolving -The definition of done may change over a period based on the improvement required. The time/ effort needed to do a given story will change with the change in the Definition of Done, but since the story point estimation is relative, it is not impacted by the change in the Definition of Done.
Improving technical/domain understanding:– The development Team’s understanding of the domain and other product development areas is improving daily. Therefore, the same work done today and done after one month may take a different time for the developer. Story points are relative, so the relative ranking of the size does not change, but the absolute estimate of doing the work will keep evolving.
Product is evolving – Development of a few initial stories may take extra time as we must implement everything from the start, but as the project grows, it may take less time. However, with the increasing complexity of the project, the estimation may increase as we must take care of existing factors too.
Team Dynamics- There is always a probability of new member addition or an existing member leaving the team. Predicting team dynamics in advance is challenging, and estimates based on the current team dynamic may not be absolute.
After reading these points, you may have an idea that it is difficult to estimate and equate story points with hours because hours are progressively discovered, and story point estimations are usually done ahead of time.
At the same time, it will not be correct to say that there is no correlation between story point and effort. While doing story point estimation, team estimates that 1 story point work is half the 2 Story Point work or 2 pointers will take less than half 5 pointers. So, there must be some co-relationship, but there cannot be a linear one; we can’t just say all the 2-pointers will take 20 hours. But if 5-pointers are taking Developer-X to Y hours, the 2-pointers are expected to take 50% of that time or less. Based on historical data, we can analyse and come up with the average effort taken for a specific story point in past. This data may help you in forecasting how much time a given set of user stories will take in the upcoming iterations. However, this correlation is not fixed. As our Definition of Done (DoD) improves, we can obverse a left shift or right shift in the average effort taken for a specific story point.
To conclude, the basic thing we need to keep in mind is that estimation is an ongoing process of finding an estimate. Estimation can be done based on different estimations techniques, and estimates of similar work may vary with the maturity of the project and our knowledge gain.
Our blog on “What is Agile Coaching?” highlights our views on the Agile Coaching. In ...
Are you contemplating a career as an Agile coach? Wondering if it has any potential? ...
Are you overwhelmed with the number of agile certifications from different educational bodies? Yes, your ...
A Simple User Story As an Agile evangelist with over 13 years of overall rich ...
