Agile story points-based estimation is a viable alternative to time-based estimation. Agile has already established itself as a dominance methodology for software development. Over 91% of IT organizations look at Agile methodologies as a strategic priority. Also, over 66% of companies started using Scrum as a tool to manage projects.
Agile is a great tool that should be implemented properly. Even the best tools can bring unsatisfying results if they aren't used correctly.
In this article, we would like to share our knowledge and expertise about Agile story points, its history, benefits, drawbacks, techniques of calculation, and much more. As an Agile evangelists and custom software development provider, we have implemented this philosophy for 10 years in 150+ projects across 10+ industries like eCommerce or logistics. We'll provide a lot of practical information on how to calculate agile story points, use them, and some historical data on this topic.
Shifting from Time-Based to estimation using story points
Dominance of Time-Based Estimation came to an end
An original method of gauging an individual's effort was through estimating the hours spent on a task. It determined the amount of money paid for a certain task too by multiplying the estimated number of hours by the hourly rates.
Many of us understand the typical schedule as 40-hour weekly, yet the hegemony of this system is ending.
Using time for a unit to estimate the effort of a team underwent significant struggles in the wake of the notorious industrial revolution in 1817. A typical weekly schedule used to range either 80 or 100 hours.
National Labor Union suggested in 1866 that the Congress establish an 8-hour daily schedule, or 40-hour weekly schedule. Even without being put into effect, it generated a lot of public interest.
A 8-hour daily work schedule was established in 1866.
Ulysses Grant, the president at the time, implemented a 40-hour schedule that applied to federal workers. Illinois Legislature approved the 8-hour work day in 1886, but the private sector employers did not agree to this rule.
Following a workers' strike, the Haymarket Riot in Chicago, which resulted in the deaths of 12 people, occurred.
When Henry Ford pushed for a 40-hour schedule in 1926, everything changed. As a result, Congress approved the Standard Act for Fair Labor in 1938. Workers who spent more than 44 hours per week at their workplace were required to receive extra pay under the law. For the next two years, this time-based estimate grew to 40 hours, and it became part of US law.
The extra payment was a significant benefit for workers who started paying more attention to the hours of work but not the efficiency or quality of their work. Therefore, work hours became a central factor of worker's KPI and the process of estimating tasks. The same concepts applied to custom software development so managers noticed a decrease in productive results, work quality and efficiency when they evaluated their team. Plus, when workers are focused on gathering extra work hours for the extra payment, companies lose a lot of finances which affects their budget in the short and long term.
Benefits
- Uniform schedule for all team
Drawbacks
- Not focused on efficiency
- Employees are more tired and less performant
- It is built on a criteria of time, ignoring other criteria
- No consideration for factors that interrupt workflow
- Facilitates Wasted time
- More costly
Agile Story Points Established Their Supremacy
Story points revolutionized the way work is estimated because they focus on effort spent on finishing a task rather than the time spent for the same task. Since they evaluate the effort, they improve performance but also reduce the necessity of detailed planning. Unlike hour estimation, this method supports the team in understanding what necessary improvements should be implemented for an increased work efficiency.
Story points revolutionized the way work is estimated
The understanding of these points has changed over the last few decades. Companies developed their own methods of estimating work through this system, such as the Fibonacci method, the t-shirt sizing method, the bucket system, through dot voting or affinity mapping.
They were initially referred to as "gummi bears" in 1999. Ron Jeffries coined this phrase, and used it first in XP projects. Furthermore, according to Joshua Kerievs, CEO of Industrial Logic agile consultancy company, these points were also known as NUTs or Nebulous Units of Time in 2003.
Benefits
- Realistic deadlines
- More efficient planning
- Better team collaboration
- They bring a realistic perspective
- Higher adaptability to potential changes
Drawbacks
- Difficult to assign accurate completion dates
- Require previous data to establish velocity
- Hard grasp the concept
Why Story Points Matter
They don't put workers under stress and are less expensive to implement or plan. They are more precise in estimating work compared to the alternative that uses hours. By using this system, workers have a better grasp of deadlines and meet the expectations of clients and managers in a professional manner.
According to recent Microsoft research, agile estimation that is based on agile story points increased accuracy and efficiency.
Techniques to Calculate Story Points in Agile
T-Shirt Sizing
This method is one of the most accessible in terms of understanding and it is widely used by most teams.
Design cards for every t-shirt size, such as the classic S for small, M for medium, L representing large, or XL as a symbol of extra large.
The manager will then start outlining the duties and level of intricacy of the project.
Every participant will designate a size for each task in question. All the sizes assigned to the story will be shown to all participants at once.
If there are discrepancies in assigning the sizes, further negotiations will be necessary until a common t-shirt size gets picked and designated as the estimation of effort that is required for the story at hand.
Once everyone has agreed on the size, a deadline must be set. For instance, a size XS will get an hour, a size S will get two hours, a size M will get three hours, a size L will get five hours, and a size XL would get eight hours.
The Linear Sequence
A linear series of numbers is used to calculate the amount of work required for a story.
Once the project manager presents the story details to the group, each member chooses a number from the sequence to estimate the task. The same session of Q&A might be required to reach a consensus.
Additionally, it's a good idea to utilize numbers that reflect the potential complexity of the story. Complex stories require complex actions that take longer time and more effort to execute. Such tasks will be assigned higher numbers like 20+.
The Fibonacci Sequence
One of the best scales for estimating tale points is the suggestive Fibonacci series of numbers.
Each number is equal to the sum of the previous 2 numbers that came before it. In addition, every number is about 60% bigger than the one before it.
As a result, the number difference is bigger than in a straightforward linear sequence.
It becomes easier to make an estimation with numbers that have a constant and significant difference in between them as it makes estimation more clear. For instance, if a story is estimated 8 by one participant and 13 by another member, the difference is big enough to be clarified during a further discussion.
Your team members will give each task a Fibonacci number in order to determine how much work it will take to do it.
Bucket System
This approach works well when a medium-sized or big group needs to estimate a lot of stories or tasks quickly.
You can use the linear sequence with up to 21 numbers or the Fibonacci sequence, unless your project is more complicated.
On post-it notes or pieces of paper, write the numbers from the sequence you chose to use in your estimation and place them on the board -- they are your buckets. You need to but every user story into the appropriate bucket depending on the estimated difficulty of developing this story. As a guide, give a middle number from the sequence to a middle-sized task.
Once you have a reference task, pick the other stories and place them into buckets with numbers based on your estimation of how much effort they need. Consequently, you'll get the common picture of your tasks quickly and in a appealing visual way.
Affinity Mapping System
The affinity mapping system helps sort out the brainstorming phase. All the members of the team will be informed of the topic at hand. They will add their ideas individually on sticky notes.
The sticky notes with ideas will be displayed on a panel for all team members to see. They will also be grouped in similar aspects so that potential connections between ideas are visible to all members.
This system helps bring clarity to the project at hand and organize future tasks in a more efficient manner.
Steps to Affinity mapping system
To implement this method, you need to create a scale from Small to Large. Leave the sizes in between blank for now.
Without talking to each other, the team members will place their sticky notes on the scale, between Small and Large.
The participants discuss the details and clarify any aspects that could create confusion.
Once the discussion ends, the stories can be rearranged if needed.
The scale is then split in sizes such as XS, S, M, L, XL if it is created by the t-shirt size method. It can also be marked by using the Fibonacci sequence.
Once the final scale is defined, with all the sizes included on it, the team members will put the story where they consider it fits according to the effort involved in it.
Dot Voting
Dot voting can be applied as a tool that helps your team prioritize tasks. You can use dot voting to estimate the importance of a task or the effort it will take and prioritize it accordingly.
The team is shown the elements that need to be estimated. A limited set of sticky notes is distributed to every team member.
Voting will be done using these dots for the items on the table.
High-priority items are those with the most dots.
How to Convert Story Points Into Hours
One of the system's more perplexing elements is the conversion of agile story points to hours. Some companies don't even think it is required, but more cautious managers convert story points into hours. But how is that even possible? The reality is that each manager may have their own method for determining how many hours a certain narrative will require.
The typical strategy used by most managers is to watch how long it takes to finish a task and use that as a benchmark for its duration. However, this might be taken into account as the ideal time, which disregards any potential disruptions or real-time, with all its delays.
Consequently, if a story requires eight hours of effort in an ideal world, it can require three days to complete in the real world.
The typical strategy used by most managers is to watch how long it takes to finish a task and use that as a benchmark for its duration.
Ultimately, story points are relative units of measurement and it is not recommended to convert them in hours. By their definition, story points measure effort not time, which makes the attempt to do the conversion to hours challenging to say the least.
In the table below, we've put together an example of how story points could be assigned a number of hours.
| Agile story pointes | How many hours |
| 1 point | 1-2 hours |
| 2 points | 2-3 hours |
| 3 points | 3-8 hours |
| 4 points | 8-13 hours |
| 5 points | 13-21 hours |
Sprint Velocity in Story Points
The velocity of a team is measured by the number of story points they can complete during a Sprint.
The total number of finished stories or the total number of covered agile story points are two ways that teams can express their velocity. Regardless of the measurement technique, velocity represents the amount of work completed in a Sprint.
Examine the previous completed tasks to determine the velocity of one sprint. Your team needs to complete three sprints, each with a different number of agile story points. After calculating the total number of stories that were developed during all three sprints you need to divide it by three.
Example:
First sprint - 27 story points reached.
The second one - 32.
The last - 28.
When we add up the velocity of all the sprints mentioned above, we arrive at 87. In our case, there were three sprints, thus to calculate the average velocity for one sprint, divide 87 by 3 to arrive at 29. The average velocity you should target will be 29.
How an Estimation Meeting Goes
For a team, estimating the work that will need to be done in the future is a crucial stage. And how you set up such a gathering is crucial. Here are the steps that will help your team comprehend what needs to be done to complete the duties they have and bring clarity to your job.
Step 1. Gather the people who will work on the project
Discuss only with those members involved in the project. Everyone needs to have a good understanding not only of the tasks at hand but also of the method of estimation itself.
Step 2. Have clear goals
Decide on what you will estimate. Maybe you just want to estimate the next tasks or maybe you want to estimate the complete project. Also, decide on estimating the time, effort, or money involved in completing the tasks, or all of these factors.
Step 3. Decide on the estimation method
Make sure everyone in the room is familiar with the estimation method you are going to use. Clarify any potential questions before starting the estimation process.
Step 4. Estimate the tasks
Depending on the method you choose, you will use t-shirts, sticky notes, or sticky dots. Give everyone the tools they need and make sure they have a good understanding of the tasks they are estimating. Don't end the estimation session until consensus is reached.
Step 5. Register the meeting
It is crucial to record both the final estimation results and the process followed to get there. You can use this as a model to emulate and a point of reference for next estimating discussions.
Final thoughts
Businesses are realizing the efficiency of narrative points estimate notwithstanding the controversy over time-based estimation.
You must first comprehend the agile system in order to apply it correctly, but once you do, your team's collaboration will be far more effective.
Contact SumatoSoft for assistance in implementing an agile system that works for your