Story Points Estimation

Software development projects can be estimated in various ways. Estimating work effort in Agile projects significantly differs from traditional methods of estimation. One of the most reliable ways is using so-called story points. This type of estimation may seem not the easiest one, but in the Agile project management environment, it provides benefits to both developers and customers.

The story points approach is based on historical data with the aim to compare features of one project to features of a previous similar project to get a precise estimate.
What is Agile estimation? How do story points work? Why are story points better than hours? Finally, how do you do estimation in Agile? Here we describe the essence of the story points system and share some common techniques for Agile estimation. Let’s dive in!

What Is Story Point in Agile?

Story point a is known as a unit of measure that is used in Agile project management to express an estimate of the overall effort that you need when implementing items in a product backlog or any other piece of work.

Estimating with story points requires assigning a point value to every single item. It is not important what raw values we assign but the relative values do really matter.

You assign 2 points to a particular story and it means that it should be twice as important as a story that you assign 1 point. Additionally, it should be two-thirds of a story that is estimated as 3 story points. Is it obligatory to use values 1, 2, and 3? Not really. You can assign 100, 200, and 300 points or even millions. The ratios do really matter and actual numbers are don’t.

Story point estimation is usually performed during Backlog grooming (backlog refinement session). The backlog is evaluated by the Agile team that is responsible for the actual development and testing.

What Story Points Include?

Story points are the efforts to develop a story, so an estimate performed by a team must contain everything that can affect the outcomes. This may include:

• The amount of work to do
• Work complexity
• Uncertainty in doing the work or possible risks

All these factors must be considered while estimating story points.

Combining These Factors

Combining the amount of work, risks/uncertainty, and complexity together to provide an estimate can be a real challenge. However, this is possible as effort is the unifying factor. Estimators should consider how much effort they need to do the amount of work described by a product backlog item. They should also think about how much effort to include for dealing with the uncertainty/risk inherent in the backlog item. This is often done by considering the risk occurring and the possible impact if the risk does occur. The complexity of the work to be done should be also considered. So, all three factors must be combined.

How to Perform Agile Estimation?

It is better to start Agile estimation by determining a baseline story. The team should not select the smallest story, but the one that every team member can resonate with.

After defining the baseline user story, you have to initiate the sizing of all the stories by comparing them against the baseline one. Performing the estimation of new stories you will pick a story and ask:

• Will this one take longer than the reference story 1?
• Or will it be less than reference 2?

When estimating story points, a point value should be assigned to each story.

The estimation based on story points includes three components:

• Risk: Meaning that the risk of a particular item/project includes vague demands, changes mid-task, or dependence on a 3rd party.
• Complexity: That is defined by how difficult the feature is to develop.
• Repetition: It is determined by how familiar team members are with the feature and how monotonous tasks are within the development process.

Estimation Techniques

Which are the Agile estimation techniques? Here we list the most popular techniques starting with the famous Planning poker.

1. Planning Poker

The basement of this Agile estimation approach is the use of story points to estimate the difficulty of tasks.

Planning poker is based on the Fibonacci sequence, where the user stories point values can be assigned as 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. All of them have different levels of complexity for a certain project.

During the session, all team members involved in the estimation process should sit together. Every participant gets special cards with story point values. Then a leader figure (or a customer) reads out the user story and describes all features and requirements. He or she will be engaged in discussion with the team members who are estimating (and they, in turn, will discuss with one another). The questions for clarification to the owner or customer can be asked at this stage.

After discussions, estimators choose a card with the story point that they think needs assigning to the project. If the point estimations match up, it can be considered as the final estimation. If there is no match, the estimators who gave the lowest and highest points share their reasons to continue the discussion and get a consensus.

Planning poker is not perfect for large teams, or when there are many items for estimating.

2. Dot Voting

Ordering the items in the product backlog is not always as easy as it may seem at a glance. The Dot voting approach enables Agile teams to sort items from highest to lowest priority. It allows them to know where to focus their efforts.

You have to visualize all of the stories on a board or a simple wall. Your notes should contain the description of stories and should look unique to let voters easily distinguish them. Attendees should be given 4-5 dots to deal with (a good idea is to use stickers or markers). They should place the dots on the stories that they would like to start working on and distribute them according to the options.

Then the facilitator should order the user stories from the most preferred to the least preferred ones (the more dots or marks – the more preferable the user story is). You can also divide items into three categories with high, middle, and low priority. Then the team members should vote on the high-priority stories again until they reach a consensus.

3. T-shirt Sizes

When you are looking for a T-shirt for an office, vacation, or other need, you consider multiple sizes to choose from. You probably have one of the following sizes: XS (extra-small), S(small), M (medium), L (large), XL (extra-large ), and so on.
The T-shirt sizes model in Agile estimation uses these sizes raw as story points for the size of the project. This is a pretty informal model and actually a useful way of thinking when you need to estimate something. The technique provides a quick and rough estimate of how much work is expected for a certain project. Sizes can be converted into numbers. This is decided through collaboration and discussion in order to understand everything that needs to be done.
When estimators offer the sizes that do not match, the whole team shares their opinions with the aim to achieve a consensus.

4. Affinity Mapping System

Affinity mapping is a good technique to use for a smaller team. This model requires silent relative sizing. Therefore, you have to place two cards on opposite sides of a wall (small and large). The Product Owner should provide all estimators with a subset of items and should stay during the process to clarify anything if needed. Estimators should place items on the wall in accordance with each item’s perceived size. The size depends on the effort expected to complete them. The location of wall items then can be changed. After editing the wall, team players can finalize backlog items in their positions. If you are using a powerful project backlog management tool, then it can help you ensure that the finalized estimations are saved.

5. Bucket Model

The Bucket technique is based on placing different values on a table. The placements are called “buckets”, however, simple cards can be used as well. The typical values system includes 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100, and 200 points (they can be expanded if necessary). According to the method, estimators take available user stories and choose which buckets each item falls into. They need to place cards with the items into the buckets. Then they collectively discuss the features and requirements of each card. All items must be placed in the buckets upon consensus.
Then estimators take the remaining cards and place them in buckets that they believe the items should sit in (even without consensus). When someone does not agree with a certain item placed in a certain bucket, the whole team discusses this point. The Bucket technique can be used if you have a large number of items and a big team.

Time as a Unit of Measure: Is It the Right Option?

You may say that hours or days are standard units of time that have been used for hundreds of years. However, in simple words: your hour is not the same as our hour. When we ask two developers to estimate the same task, we’ll probably have two different answers. Some of the differences can be surely explained by gaps in the understanding. However, all developers have different knowledge and experiences. That’s why it will take more or less time to do the same work.

Story Points Versus Hours

Story points serve for expressing an estimate of the overall effort required to fully implement a backlog item or any other piece of work.
The points are related to the amount of work, work complexity, and risk or uncertainty. Over time, breaking down work into smaller chunks helps Agile teams to understand how much they can reach in a specified period of time and get consensus.
Dates do not account for the non-project-related work (meetings, emails, interviews, etc.), and they have an emotional attachment to them. Relative estimation removes the emotional attachment.
Story points reward Agile teams for solving problems based on difficulty, not time spent. It allows focusing on shipping value, not spending time.

The Advantages of Using Story Points

With the help of story points, teams can:

• Estimate issues quickly. Estimation relates to already completed backlog items. It looks faster than estimating without references.
• Estimate without making a time commitment. If you estimate in hours, you consider the precise time commitment, and the story points estimation is less exact.
• Consider uncertainty as the Story points system specifies an unknown time range.
• Plan sprints ahead with accuracy. It helps you to better manage the time expectations of stakeholders for future work.

Common Mistakes Related to Using Story Points

1. When teams equate story points to just uncertainty, complexity, or value. Story points are about effort. Uncertainty, complexity, and risk influence effort, but each alone is not enough to define it.
2. Moving from story points to hours. When teams move from story points to hours, they stop benefiting from the speed of relative estimation. Working in hours, they have a risk of giving commitment. It provides a false sense of accuracy as they reduce a story point with a time range of 10–20 hours to a precise number like 14 hours.
3. Averaging the points. The point is not to be 100% accurate but to be accurate enough to plan ahead of time. Averaging may lead to losing a valuable discussion.
4. Adjusting story point estimates during sprints. There is no need to adjust the story point estimate at the start of working on an issue. When the estimate is inaccurate, it is part of the final sprint velocity. It is not a big problem if estimations are sometimes off.
5. Applying story points to small tasks.
6. When you move an unfinished PBI to the next sprint, you do not need to re-estimate. The estimation can not be accurate but it is not a problem. The team will know all the necessary tasks to complete the issue.
7. When the story point estimation is adjusted just because a specific developer will work on it. Story pointing is done by the whole team. The team should get an agreement on how much work it represents and use this for planning. There is no need to adjust the story points because a specific person will do the work.
8. Focusing on the expert. Performing Planning poker, you face a risk that your team may listen mostly to the obvious expert in the room. In order to resolve this, let the expert elaborate on the work and then have the rest of the team estimate without the expert.
9. When incorrectly story-pointed issues in the retrospective are not discussed.

What Are the Ways to Make Agile Estimates as Accurate as Possible?

1. Improve collaboration with the Product Owner

A Product Owner is responsible for backlog prioritization. He/she captures business requirements but does not always understand the details of implementation. The proper estimation will give the PO new insight into the level of effort for each work item (which then will feed back into their assessment of each item’s relative priority).

Breaking down work items into small pieces and estimates with the help of story points helps Product Owners to prioritize all areas of work professionally. And once they have estimates from the developers, Product Owners often reorder items on the backlog.

2. Consider estimation as a team sport

It’s crucial to involve everyone on the team (developers, testers, designers, deployers, etc.) as every team member may bring a different perspective on the work required to deliver a user story.

Two More Tips for Better Agile Story Point Estimation

1. Use Fibonacci sequence numbers

Assigning items with a linear scale means using integers that aren’t differentiated enough to clearly define an estimate. Fibonacci sequence numbers eliminate those minor jumps. With their help, it looks much easier to decide if an item equals 3 story points or 5 story points.

2. Use a matrix

After deciding to apply the Fibonacci sequence, you should define a baseline for each story point. This baseline should be included in the matrix as 1, which sets the standard for what the least amount of complexity, risks, and repetition looks like in practice. The matrix will help you to measure effort more accurately. So, remember this instead of judging items based only on time.

Final Words

Well-planned estimation is crucial for project planning and management. The robust estimation techniques described above (such as Planning poker) use cards or dots having values or numbers printed on them and then assign them to the stories for relative size estimation. With the help of the relative sizes estimated for the product backlog items, estimating or calculating the budget required for the project becomes clearer and easier. Hopefully, now you know a lot more about estimations of Agile projects. If you have any questions, feel free to ask them.