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 poposed in 1866 for the first time.
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.
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 for Estimating Complexity in Agile Projects
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.
It’s essential to remember that these sizes represent relative complexity and effort, not specific time frames. Some teams may choose to convert these sizes into time estimates, but those conversions will vary depending on the team and project.
The Linear Sequence
A linear sequence from 1 to 10.
While less common than other methods, some teams may use a linear series of numbers to calculate the amount of work required for a story. This approach provides a straightforward way to rank stories but may need more nuanced understanding of complexity found in other methods.
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 is required to reach a consensus.
Keep in mind that using a linear sequence might not capture the nonlinear nature of complexity found in development tasks. Some teams might find this approach suitable for their specific context, while others may prefer methods like the Fibonacci sequence that better reflect the complexity of development tasks.
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
The Bucket System is a participative and visual agile estimation technique designed to assist teams in quickly gauging the effort needed for a multitude of tasks or user stories.
How It Works:
- Determine Point Scale: Decide on a sequence of numbers representing the complexity or size of tasks. The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) is a popular choice. Write these numbers on post-it notes or cards.
- Reference Task: As a starting point, select a user story or task and assign a mid-range number from your chosen sequence to denote its anticipated complexity.
- Individual Estimation: Each team member privately assesses each task, determining its complexity relative to the reference task. They then place their estimate (using a post-it or marker) next to the corresponding number on the board.
- Group Discussion and Consensus: After everyone has placed their individual estimates, the team congregates to discuss any discrepancies. The aim is to understand different perspectives and, ultimately, reach a consensus on the complexity value for each task.
- Finalize Estimates: Post discussion, adjust the tasks’ positions based on the team’s agreement. If needed, re-evaluate any tasks where the consensus was challenging to reach.
This method is helpful when a team, especially a smaller one, needs to quickly gauge the relative complexity of a large number of tasks without getting bogged down in detailed time-based estimations or extended discussions.
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.
Story Points vs. Other Estimation Techniques
| Technique | Description | How to use | Pros | Cons |
| Story Points | A unit of measure for expressing the overall complexity of a task. Often follows the Fibonacci sequence or other nonlinear scales. | Team members collectively determine the number of story points for each task, considering complexity, risk, and effort. Discussions and negotiations might be needed to reach a consensus. | Reflects various aspects of complexity, promotes team collaboration, widely accepted in Agile development. | Can be abstract and difficult to understand initially, requires a shared understanding among the team. |
| T-Shirt Sizing | Using clothing sizes like XS, S, M, L, XL to represent the relative complexity of a task. | Assign a size to each task based on complexity, then discuss and reach a consensus with the team. | Simple, intuitive, and encourages team discussion. | Lack of precision can lead to confusion if misinterpreted as time estimates. |
| The Linear Sequence | Utilizing a linear sequence of numbers (e.g., 1-10) to gauge the complexity of tasks. | Team members select a number that represents the task’s complexity, then negotiate until consensus is reached. | Straightforward, easy to understand. | May not capture nonlinear nature of complexity, lacks nuance compared to other methods. |
| The Fibonacci Sequence | Employing the Fibonacci sequence where each number represents relative complexity. | Assign a Fibonacci number to a task, then discuss to align on the appropriate number. | Reflects the nonlinear nature of complexity, fosters precise estimation. | Can be confusing for those unfamiliar with the sequence. |
| Bucket System | Placing tasks into ‘buckets’ based on complexity, using linear or Fibonacci sequences. | Write numbers on a board, then place tasks into the corresponding bucket. | Visual, quick for medium-to-large groups, works with various sequences. | May become cumbersome with too many tasks. |
| Dot Voting | Using dots to vote on the priority or complexity of tasks. | Distribute sticky notes, then vote on items to determine priority or complexity. | Democratic, helps in prioritization, encourages team participation. | More about prioritization than complexity, may not align directly with story point estimation. |
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.
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 | 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 company!
Let’s start
If you have any questions, email us info@sumatosoft.com
