It is difficult and tricky to estimate something accurately, especially when it comes to abstract notions like work and effort. It gets even more challenging when you need to gauge the effort for a job you have never done before. And that is why we often make our estimates wrong. This is when the relative estimation of user stories with Jira story points proves to be helpful.
Hint: If you are new to story points, please take a look at The relative side of Agile: using story points for estimations. This article explains story points in detail.
Relative estimation at a glance
Normally, when we attempt to estimate work, we subconsciously break down an individual task into smaller constituent parts. And then consider each part separately to come up with the final time estimate. While this is not the wrong way to go, a decomposition process can take some time and lead to inaccuracies.
The relative estimation is different. First, we do not estimate each task in isolation. And second, we do not use absolute values like days and hours. Instead, we could use unitless values, such as Jira story points. To estimate backlog items (tasks or stories), we compare them to other items we have already completed. These items are called baseline tasks. To explain this concept better, we will use a distance running analogy.
The absolute runner
Let’s say you want to pick up running and wonder how long it would take you to run different official distances. These include a marathon which is roughly 26.2 mi (42.2 km); a half-marathon (13.1 mi or 21.1 km); and a 10K run (6.2 mi). The marathon is the longest; the half-marathon is twice shorter; whereas the 10K run is about 4 times shorter than a marathon.
However, you have never run a 10K before, let alone any longer distance. This means you have no reference point. You do not know your fitness level either. So what do you do? You could start running and measure your time. Bit by bit, you would manage to run 10K.
As a next step, you would use your 10K run time and multiply it by two to get a rough half-marathon estimate. Then, you would do the same for a marathon that (theoretically) takes about 4 times longer. So, eventually, you would know your estimated time for running 26.2 mi. Right?
—Yes. No. Maybe.
Comparing effort 1:1 using absolute values
Well, first of all, this approach is very time-consuming. And second, although it is easy to multiply the distance and time accordingly, you cannot be so sure about other variables. There are several risk factors that can affect your performance during the marathon.
For instance, your stamina level will drop significantly, and you will struggle to keep a regular pace. You could also experience cramps, dehydration, injuries, and mental exhaustion. Plus, running 10K requires a lower fitness level when compared to a marathon.
So, in the end, you cannot precisely measure the time it will take you to reach the finish line. But just because the absolute values might not work, it does not mean you cannot carry out your estimations. Jira story points allow for a relative and unitless measurement of the effort you will need to run each distance. And although they will not tell you right off the bat how long you will be running, you will get a sound idea of the “size” of the undertaking.
The relative runner
Let’s go about your run differently. We will start by taking the shortest distance and determining the effort it would take to run it. And then assign it a relative value which, in the Agile world, is (among others) a story point. For example, a 10K run will take 5 story points. This number is totally arbitrary, and you can assign any value to it, even 50. But working with smaller values is simply easier.
Second, we will consider a half-marathon. Theoretically, it should take twice as much effort. Therefore, when we compare it to the 10K run, it could be worth 10 points.
And finally, a marathon is about 4 times longer than a 10K, so we could give it 20 story points. However, since it is the longest and most demanding run, it carries more risks than a 10K. So we will give the marathon 22 points to account for those risks. Those 2 extra points really mean that we will need to put more effort into dealing with those risks. And, consequently—into completing the run.
Each diamond represents a story point. The top running distance, a marathon, received 2 extra diamonds (story points).
As you can see, we have not used a time unit anywhere. And yet, we managed to estimate the effort needed for each run. At the same time, we avoided committing to unrealistic deadlines that typically come with (absolute) time units.
Jira story points estimation
You can apply a similar concept of using story points to estimate your Jira Agile projects. To be more precise, you can compare one task or story to another to estimate it. Moreover, you also account for various factors that could increase the effort a team member needs for task completion.
- Amount of work—some tasks require more work than others (even if they are simple and monotonous).
- Complexity level—some features are more difficult to develop (there could be less coding but more research).
- Repetition—developers completing several similar tasks are more likely to complete them more efficiently.
- Risks—there could be stories that carry major risks (e.g., dependencies).
There are several ways of estimating story points in Jira. The two most common methods are the Fibonacci sequence and the Planning Poker. Let’s present each of these in detail.
Fibonacci sequence
It might be tempting for your team to assign backlog item numbers according to a linear scale. However, the difference between two neighboring integers is too subtle to define an estimate. Imagine looking at a task you have never done before and estimating it for 5. Then you get another one and say 6. How does this 1 point make a difference exactly? And how can you be sure if 1 point is enough if you are new to these tasks?
To eliminate the vagueness from estimates, teams often use the Fibonacci sequence. In this sequence, the consecutive integers are the sum of the two preceding ones. And thus, you get 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, and so on. (You may modify this sequence and start as low as 0.5.) So if you compare 3 to 5 or 5 to 8, you surely can “feel” the relative difference better between 5 and 6. Therefore, the Fibonacci integers in Agile give teams and Project Managers a realistic way to approach estimates using Jira story points.
As you may remember, story points in Jira represent the amount of work, complexity, and risks one needs to complete or implement a work item. Therefore, based on the Fibonacci sequence, the higher the number, the more complex and risky the work. We can also assume that the amount of work required for completion will also be higher.
How to use the Fibonacci estimation in Agile
Typically, an Agile team identifies the smallest user story—This story will serve as the baseline. Then, they assign a minimal story point value (1 or 0.5) to their baseline.
For example, 1 story point could mean that the amount of work, complexity, and risks are minimal. Therefore, your team can deliver this user story within a day or a few hours. On the other hand, a user story worth 13 points would mean it is complex, carries some uncertainties and will take several weeks to complete.
Using the Fibonacci sequence, each member compares backlog items to the baseline and assigns a point value. When done, everyone reveals their estimates and discusses them until everyone agrees about each item. Over time, as your team members will work through items with the same point values, they will better sync their estimates. And consequently, the estimation process will take less time.
If your team is new to relative estimations and the Fibonacci sequence, you could try using the table below as a starting point. Eventually, you will work out your own “sizings” with the respective point values.
Estimating with the Fibonacci sequence – a starter table.
Planning Poker for estimating Jira story points
Planning Poker is a collaborative gamified exercise where players (developers) use cards to play it. The game helps team members reach a consensus on each item’s correct story point approximation. Moreover, it encourages them to ask questions and discuss each item. This way, they can understand the item they are estimating better.
This Poker game variation utilizes the Fibonacci integers instead of diamonds or spades. Each member receives a deck of cards with story point values printed on each card. Those values can go in line with the standard Fibonacci sequence. Or, they could follow one of two different flavors of this sequence—a modified series of numbers (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) or a series of doubled pairs (1, 2, 4, 8, 16, and 32). The modified series might work for your developers if they need bigger numbers to reflect the greater amount of uncertainty that typically comes along with larger stories.
You can use a modified version of the Fibonacci sequence for your Planning Poker sessions.
Hint: If you do not have a physical deck or you manage distributed teams, then not a problem. There are many great digital alternatives that will help you run the estimation session with distributed and asynchronous teams. For example, Agile Poker for Jira or Planning Poker.
How to play Planning Poker
1. The game begins with the moderator (most commonly a Product Owner, but could be a Manager or even a client) explaining the top backlog item. Players are then encouraged to ask questions to clarify the scope and expected business values. If they believe there should be some changes to the item description or acceptance criteria, the moderator captures them progressively. Please note that during the discussion, the players should focus solely on discussing the item—not the story points values.
2. When the players are ready to estimate, they choose the card with the story point value they believe best reflects the effort needed for this item. Next, they place that card on the table face down.
3. When everyone on the team has selected their cards and put them on the table, they simultaneously flip them to reveal their values.
4. At this point in a game, there could be two outcomes. The ideal outcome is when each team member reveals the same value for the backlog item. The second scenario is less optimistic and takes place when the players assign different values for the same item. If that happens, the players discuss their estimates. They should be specifically interested to hear from colleagues who selected the highest and lowest values.
5. When the estimators finish their debate, they return to point 2 and go through steps 3 and 4 to estimate the item again.
6. When they manage to reach a consensus and unanimously estimate the item, they start the game all over again. The Planning Poker is over when the players estimate all items in the backlog.
Jira story points and relative estimation: a few points to note
Relative estimation is one of the several estimation methods Agile teams have at their disposal. It uses story points as units which helps Agile teams avoid some of the pitfalls they could experience when estimating with absolute values. For example, time units often cause estimators to seek unwarranted precision and confuse their estimates for commitments.
However, relative estimation alone is not free from challenges. Therefore, there are a few things to bear in mind when estimating with Jira story points.
Developers without the core expertise
If the Poker Planning game is for the whole development team, how can every member estimate work that is not part of their primary area of expertise? For example, a UX designer will have very little idea about estimating work that involves writing a backend or frontend code.
First of all, Planning Poker, or relative estimation in general, is not a voting game. Developers settle on the Jira point values based on the common consensus, not the estimate given by most team members. As such, the estimation process is driven by discussion.
It means that the greatest credit is given to the person with the most relevant skills or experience. So although everyone participates in the estimation process, not everyone can equally convince the group members about the number of points they have estimated.
On the other hand, team members without the core expertise for a particular task can still greatly contribute to the discussion. Since they have been doing the estimates together for a while, they can point out things others might have overlooked. Moreover, by sheer asking questions, they can help their colleagues to realize factors they have not thought about earlier.
For example, a UX designer might remember that the programmers worked on a similar feature a few months ago, and the completion took longer than was initially estimated. In such a case, even without direct technical input, every developer can help to make estimates more accurate.
Jira story points inflation (estimation anti-pattern)
Story points inflation is when a team estimates a backlog item (typically a user story) with a relatively larger value than they would do the same for the same item in the past. As a result, the team’s velocity artificially increases, even though they do not actually complete more tasks.
One of the reasons behind the story point inflation is the pressure being put on teams to deliver more points with each Sprint. Let’s say the team is debating over a user story. Some say it should be 3, while others say it should be 5 points. Bearing in mind that stakeholders expect more points to be delivered, the team eventually leans toward 5 story points.
A few Sprints later, they estimate a similar user story and compare it to a past item they have previously estimated for 5 points. Since the new item seems to take more effort than the 5-point one, they give it 8 points. The consequence is twofold. On the one hand, the estimate for a base item increases. And on the other—it also increases for other backlog items.
You can partially remedy this situation by triangulating the estimates of your team. The triangulation method involves comparing the item against two boundary ones. If the story received 5 points on a Fibonacci scale, then you would compare it to stories your team estimated for 3 and 8 points, respectively.
Summary
The main goal of relative estimation is not to focus on Jira story points (or any other units) and their values alone but to help determine and adapt the product plan and vision. After all, the team estimates the work to maximize their effort and deliver as much value as possible—but in a realistic way.
The reason is that the number of points depends on many different factors and changes as the knowledge in the team increases. For instance, the number of points will vary when a new person joins the team or a current team member leaves. So the bottom line is that the Jira story point value can change, even for the same task. Which is why it should not be the main focus. Instead, this relative unit should be seen as the guide for the team toward executing the product vision, not as the goal itself.
