If you have ever planned a trip with a lot of transfers, changing planes, and trains, you understand the importance of estimating your time. You would probably have to take into account possible delays, traffic jams, and other forces you can’t control, such as weather. The trip that was supposed to take 3 hours could take 5 or even 8, you never know.
The same happens in software development, where estimation is one of the key factors that can make or break it. In Agile, estimation is used to assess the possible duration of the project and its budget, and if done inaccurately, the team can face serious issues and even fail. Simply estimating the scope of the project with hours is not an option anymore. But fear not, there’s a solution called “story points.” Fortunately, this is how we have been estimating the development time at IntelliSoft for more than 16 years, and we know a whole lot about story points in Agile, and what poker has to do with it, so keep on reading.
Table of Contents
What Are Agile Story Points?
Talking about story points would make no sense without explaining what the terms “user story” and “product backlog” are.
A user story is the explanation of the features that a user wants to have in the system, and it is usually informal. It is the smallest unit of work in an agile framework. User stories are often expressed in one sentence and have the same stricture:
“As a [persona], I [want to], [so that].”
For example, “As a marketing manager, I want to be able to automate our team’s processes, so we can focus on more important tasks instead.”
This sentence helps understand the person’s issue and the desired outcome, and it explains what the software should do – automate marketing tasks.
Next, let’s move on to what a product backlog is.
A product backlog contains a list of every user story that needs to be worked on and implemented into the product. In other words, it is the inventory that contains the smallest pieces of Agile – user stories.
What about story points, then? Where do they fit? They are assigned to each individual user story to express how much time and effort are needed to do that job. They assess the difficulty of the task, the higher number meaning greater difficulty.
Story points estimate three main factors:
- Amount of work
- Complexity
- Risks or uncertainty
Keep in mind that story points are not final numbers – they are merely estimations, all having a certain degree of uncertainty, and can be updated during the course of development.
Story points are actively used in Scrum and other Agile methodologies, replacing the traditional way of estimating with money and time. They are the tool to determine the velocity of teams. This might be a new word for you, so we’ll explain. Velocity means the speed of teams and how fast they can implement a certain scope.
You’re probably thinking: Why complicate everything? Can I just use time estimates instead?
Of course, you can, but story points are far more accurate and allow you to calculate team velocity and estimate the work that should be done more objectively.
1. Calculating team velocity
When you start a project, you would probably want to know its cost. Unfortunately, it’s almost impossible to estimate the costs and detailed scope, and all you can do is guess. However, you probably already know when the project will go live, so that’s the only factor that you can build your estimate on and control the process.
This is where team velocity comes into play – by calculating it, you can visualize the efficiency of your Agile team and the speed at which they are progressing. These estimations can help you make better predictions about your project schedule.
How do you estimate velocity, and what is it? Velocity demonstrates the amount of work that has been done in each sprint. It’s the completed story points divided by the number of sprints.
For example, if your team finishes 100 story points in 4 sprints, then their velocity will be (100/4) = 25 points per sprint.
2. Estimate without specific time commitments
Agile doesn’t guarantee that everything will go according to plan and that you will face no issues. Like any project, Agile projects also have some pitfalls from time to time, especially taking into account how difficult it is to estimate everything.
When you use time estimates, you can only estimate the approximate time a task will be finished. It can be finished faster or, as often happens, much later, leading to bottlenecks, shifts in the schedule, and frustration.
Story points, on the other hand, don’t make any definite commitment (there’s no “due next Tuesday” or “should be finished in 4 hours 38 minutes”). Instead, story points allow you to estimate the effort into a specific task and adjust the number during the process if needed.
For example, when developers get asked about the time they need to complete a certain technical task, they can name a certain number of story points rather than contemplate how many hours and minutes this task will take. Story points help reduce stress and organize the process better.
3. Story points aren’t subjective
Time estimation is always about subjectivity, as you can’t know for sure how long it will take to complete a certain task. For example, a senior developer can assign a task to a junior or middle developer and estimate that it will take them 7 hours to complete. However, a junior developer might finish this task in 12 hours.
To eliminate this problem, teams use story points. An entire team discusses how many story points each task might take, taking into account everyone’s opinions, making it less likely that delays occur and deadlines aren’t met.
Related Readings
- Story Point to Hours: Which Estimation Approach to Choose?
- 12 Benefits of Outsourcing IT Support Services for Businesses
- Assembling Your Dream Design Team: A Comprehensive Guide
- Who Does What? Understanding Roles in a Software Development Startup
Benefits of using story points
Story points in Agile make estimating efforts much easier and simplify the sprint planning process. They also have other benefits, including:
- Facilitate faster planning. When you calculate the value of one story point, you don’t take this value out of nowhere. You compare the story point to already estimated story points, making planning much faster. This relative scoring method allows you to estimate time more effectively, which is essential for your team’s progress.
- Create more meaningful deadlines. With traditional time estimation, you can never create meaningful deadlines; all you can do is set a deadline and hope for the better. With story points that are more nuanced, the deadlines make more sense.
- Consider risk and unpredictability. With story points, you always consider risks and unpredictable events that might occur. For example, if implementing a specific feature into a product involves changing its old, brittle code, then this risk should be taken into account when assigning story points.
- Builds consensus and boosts collaboration. When assigning story points, an entire team is involved and they can discuss the scope of work and decide who gets more story points and why. For example, if one team member thinks that a task will take 3 story points, and another person estimates 10, it’s a great chance for them to talk it through and discuss why they estimated that way. This can mean that one person understands the complexity of the task better, but the other one is more efficient. Estimating story points give your team a chance to build consensus and communicate better with each other.
- Help estimate better in the long run. Story points are super adaptable and reusable. For instance, if you have already finished your first sprint according to a story point matrix, you can use your insights to reevaluate the original story point values and come up with more accurate estimations.
3 Key Factors That Affect Story Points in Agile
Story points are assigned according to the effort needed to implement a backlog item. What does “effort” mean, exactly? There are three factors that influence story points in Agile, so let’s focus on them.
How much work needs to be done (story size)
Each project is different; one may require more work than another, and so do the backlogs. For example, a backlog item “I want to automate the reporting process” differs from “I want to automate all marketing processes.” Of course, the second one will take more time and effort.
As a result, the second backlog item will get more story points because automating all marketing tasks is not as easy as building software for automated reporting. That’s why it is essential to create backlogs accurately, as it influences all the future processes in the team and allows estimating time more efficiently.
Risk and uncertainty
Software development without risks and uncertainty is a fairytale; you want to believe in it but realize it’s impossible. Every project has risks, and it’s critical for the team to know about them and build their work around them.
For example, some product backlog items might require using new frameworks that your team is not familiar with. This increases the risk and will require more story points as the team should learn about the framework first.
Complexity
The way you estimate story points is also influenced by the complexity of a specific backlog item. For example, when your team needs to develop a website with 200 basic text fields not connected to one another, it can’t be called a complex task, so it will get fewer story points. On the other hand, building a website with 200 different fields, including calendar date fields, checksum validations, phone number fields, and so on, will be more complex.
In the second case, the task is more complicated because all these fields should be interconnected and interact with each other. As a result, they will be more difficult to implement, and it will take more time. Moreover, there’s a chance that something goes wrong and some interactions don’t work, so developers need to make backups and fix these issues. All of this additional complexity should be estimated and reflected in story points.
How Story Points are Calculated in Agile
The estimation process in Aglie usually follows the same 4 steps, so let’s walk through them and figure out how to do it.
Step 1.Identify a Base Story
The first thing you need to do is find the Base Story. To do that, you need to understand that story points include three elements: risk, complexity, and repetition. Risks are either unclear demands, uncertainty in the future, or dependence on 3rd parties. Complexity is the effort you need to put into developing a particular feature. Finally, repetition is about monotonous tasks without complexity and risks.
To find the Base Story, look for one elementary task that meets the internal standards of the Definition of Done (the agreement between a product team on the conditions that should be met to consider that the backlog item is done). Next, assign this task one story point.
Step 2.Create a Matrix for Estimation
You can create estimation matrices using two types of scales: the linear scale (1,2,3,4,5…) or Fibonacci sequence numbers (0.5, 1, 2, 3, 5, 8, 13…).
Usually, teams use the second option because it allows to see the difference between story points better. For instance, the difference between 6 and 7 doesn’t seem significant, but if you take 1 and 5, it becomes more apparent.
The most popular estimation technique is planning poker, which we will cover next.
Step 3.Start planning the poker
Planning the poker is like voting with cards with Fibonacci sequence numbers. This estimation technique focuses on general consensus. You can either use cards with 1, 2, 3, 5, 8, 13, 20, 40, and 100 numbers on them or your own units.
Here’s what happens during the estimation meeting:
- Every estimator receives a set of cards with numbers or other estimation units.
- Each backlog item is presented separately, one at a time, and estimators discuss them.
- After the discussion, each estimator selects a card with a specific story points Fibonacci number.
- Just like during poker, everyone reveals their cards at the same time.
- If the estimates match, then the value is assigned.
- If they do not match, there’s further discussion to meet a consensus.
The story point estimation matrix with look something like this:
Step 4.Calculating team velocity and planning project schedule
After the estimation meeting, the team creates a sprint backlog and the work on the stories begins. During this step, team velocity is calculated. It helps measure the team’s productivity by showing the number of backlog items delivered successfully in an iteration.
To calculate your team velocity, add up all the story points of the completed stories. At first, it might seem complicated to do during the first few sprints of the project, and you might notice that your team velocity is constantly changing. However, velocity will stabilize as your team gets better at estimations.
Conclusion
Story points might initially seem complicated, especially if you have never stumbled upon them. Fortunately, it’s not even close to being as difficult as you imagine. The majority of companies these days use story points in Agile because it’s a quick and clear way to understand how much effort is required to complete specific tasks. Estimating hours is no longer a smart option because it can lead to bottlenecks and missed deadlines. Story points, on the contrary, provide both developers and their clients with more accurate estimates and help manage teamwork better. It’s high time to start using story points in your company, and we can help you with that, so just contact us.
