What Are Story Points, and How Do You Estimate Them?

Estimation is considered a critical but complex aspect of the agile development process. It should consider many vital factors that affect all employees and the project itself. Sometimes, team members may conflict in this area, but agile estimation is just an assumption, not a cornerstone.

The Story Points Concept

Story points are used to estimate the total effort required to complete a user story*. It is quite different from traditional software development planning, which focuses on hourly estimation. Dedicated teams may use such an approach during the backlog refinement or an estimation meeting to learn how much work they should do in each sprint.

You can calculate story points by building a reference story (the user story you have completed earlier), choosing your scale and estimation technique, and then calculating your project. 

Here is a basic example: your squad has to develop a web application. After passing all the above-mentioned stages, you concluded that your project has a total story point estimate of 360 and the actual sprint velocity* is 36. Thus, you should execute еут sprints to complete the development process.

*User story is an instrument used to show a particular software feature from the end-user perspective. Sprint velocity is the average number of story points the development squad completes in an average sprint.

What Do the Story Points Include?

Since we have learned the definition of story points in agile, let’s find out what they involve. Four crucial factors affect task execution:

• The total amount of tasks.
• The complexity of work. 
• The required sprint duration.
• Possible risks (if any).

Founders may doubt that combining all these aspects is straightforward, ​​but it comes through experience. You will learn how to estimate story points more intuitively, precisely, and faster. 

Elements of Story Point Estimation

When estimating features using story points, you should consider three key elements:

• Risk covers unclear requirements and random changes. 
• Complexity shows the difficulty of the development process.
• Volume defines the amount of work in a specific story point.

Agile estimation may be complicated since teams should consider various development aspects, but user story points aim to simplify this process. You need to analyze how much effort you expect to spend on a particular backlog item in contrast to other elements; thus, such an estimation is also called “relative estimation”. 

To strengthen the estimate relativity, squads can use the Fibonacci sequence, where each number is the sum of the two preceding ones (0, 1, 2, 3, 5, 8, 13, 21, etc.). You should assign these numbers to all parts of the user story. The higher the number, the more complex the user story and the more effort it will take to complete.

When using Fibonacci numbers, tasks do not have much of a difference. For example, tasks assigned to numbers 3 and 5 are different in complexity in the same way as tasks 8 and 13; therefore, you cannot express the difference two, three, or even more times. On the contrary, you should define one thing — more than, less than, or equal.

Here is a basic example: imagine holding two fruits, an apple in one hand and a grapefruit in the other. Without looking, you can probably determine that the last one feels heavier. But if we get two apples of different varieties, it would be much harder to define the heavier one. The Agile consultant Mike Cohn explains it with Weber’s Law as the difference we can identify between specific objects is given by a percentage.

Fibonacci numbers will help you prioritize the backlog successfully. You cannot know how long the project will take, but you can see tasks that can be executed faster and those that will take longer. If these tasks have an equivalent value, an agile team can start with a simpler one to gain traction for the project. 

Three Ways to Do the Agile Story Point Estimation

Product owners use many methods to do an effort estimation in agile, but we will review the most popular ones. If you implement these approaches, you can plan sprints better.

Planning Poker

This concept is straightforward: all employees get cards with the numbers 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. Then, the host chooses the task and proposes to discuss the requirements. After that, the moderator asks all participants to pick a card and put it face down. If they have done this, the moderator gives a signal to show the cards.

If the participants’ scores agree, the host records them; otherwise, the cards are returned to the hand, and the participants start the discussion again. You have to ask the following questions to those who gave different marks: 

• What difficulties do you see in this task?
• Why do you think there will be no problems during implementation?

Remember: you can agree that a set of neighboring scores can also be an agreement. However, it will be better to consider the higher score to avoid task averaging. In any case, you will be ready to prioritize different backlog items and distribute them among the agile development team.  

Swimlanes

A swimlane is a horizontal categorization of tasks in the agile board. You can use this element to allocate different task types (users, workstreams, software features, etc.). However, swimlanes are also useful to estimate the story point in the agile model. Let’s review it in more detail:

1. First, you should prepare stickers with the task names and an agile board with Fibonacci numbers.
2. Next, the Scrum Master asks the team which task is the simplest (in terms of complexity, volume, and risks) and places it in a column with 2 story points.
3. Then, the Scrum Master asks employees which of the backlog tasks is 2-3 times more complex than the previous one (using the same estimation elements) and then places it in a column with 5 story points.
4. After that, the agile team members distribute tasks on the board by themselves and explain their assessments.
5. The final part is the analysis of each column and the task comparison.

As with planning poker, a complete consensus is not required. The host can agree with the team that when two different estimates of one task appear, the larger one is considered. Thus, evaluating in swimlanes allows you to discuss the backlog and provide the team with an understanding of each task.

T-Shirt Size 

This agile estimation and planning technique involves T-shirts in different sizes, from XS to XL, to evaluate the user story features. First, you can estimate some tasks already completed from previous sprints, take the simplest, and call it XS. After that, start “trying on” the future tasks for it: 

• S = XS + XS
• M = S + S
• L = M + M, etc.

In some cases, the XXL size can be used to describe a task that needs to be decomposed into smaller ones.

The Product Owner presents the task concept and vision to the employees, and all squad members blindly give their assessments to the Scrum Master. Then, the participants who gave the highest and lowest marks should provide arguments for their points. After listening to them, team members agree on whether they are ready to raise or lower their rating based on these opinions. Finally, the team must reach a common view.

Nine out of ten IT startups fail due to mediocre management, so you should ensure that you do this correctly. Learn why management is crucial in a software development company here. 

Story Points vs Hours

Story points are a high-level estimation measure that covers tasks to be performed in the following sprints (together with the sprint velocity). You can do this at the pre-planning stage (while working on processes related to the project start), before planning a specific sprint, or during the long-term planning stage (while scheduling 4-5 sprints ahead). The hourly estimate, on the contrary, represents the actual effort in man-hours needed to complete the particular user story. You have to use it when the task estimation is provided in hours. 

Both concepts cover different purposes, so you should not compare them and focus more on evaluating the time required to execute the backlog items. 

Story Point Benefits and Drawbacks

You should plan your development process to avoid missed deadlines or delayed tasks; in this case, story points will help you do this properly.

Benefits of the Story Point Estimation

Dr. Jeff Sutherland, co-creator of Scrum, believes that story points are a fast and cheap alternative to hourly estimates. Let’s review the most compelling advantages of this measurement unit. 

• Story point estimation in agile covers the relative effort, allowing you to evaluate the software development progress quickly and accurately. 
• You can use them to estimate already completed tasks.
• There are no specific amounts of time to evaluate.
• Story points help you accept the uncertainty of the agile development evaluation process.

Finally, you can plan sprints to manage the entire project execution. 

Weaknesses of the Story Point Estimation

But story points have some drawbacks.

• Story points are influenced by the entire development process, demonstrating risk, complexity, and repetition together; therefore, you cannot point out one specific factor.
• When converting user story points in agile into an hourly estimate, inaccurate information may appear. 
• Averaged story point information cannot be 100% true.
• Small tasks cannot be estimated using story points.
• When the agile team reduces, you should update your estimation to ensure everyone follows the same track. 
• Estimation is a squad responsibility, so keep it stable. 
• Do not ignore incorrectly made story points; in that case, organize a retrospective meeting to talk about them. 

Although critics prefer pointing out the agile disadvantages, most people agree on the story point estimation value. Thus, it is indispensable for getting objective data for further analysis. At Rocketech, we implement advanced techniques to estimate software development projects properly. Thus, you will be sure about effective task execution while creating marketable software. And if you want to try a productive collaboration experience, contact us for more details.