How to Estimate Story Points for Your Project?

When working on an Agile project, the team plans the work for upcoming sprints by creating stories. A story defines a single functionality-encapsulated activity with description and acceptance criteria.

The sprints typically last from two to four weeks. Within that time, the team needs to understand how much content they can take into one sprint so that they can still make it within the given sprint time.

On a non-agile project, you would estimate the work usually in man-days. That means how many full-time employees do you need to complete this activity? In that case, you always think of the days and amount of people when creating estimates.

On an agile project, things are different. You no longer count days or people to calculate the final estimate. In fact, we shall forbid even calculating the effort in something like man days. Instead, you let the team convert to one generally accepted value for the story that will represent the overall estimate.

Now for what exactly the value is, this does not really matter. True, the most common representative of story estimates are the Story Points. Those are basically Fibonacci numbers starting from 0, 1, 2, 3, 5, 8, 13, 21, etc. The next value is a sum of the previous two numbers. This will help differentiate the overall complexity of the story, as every next higher number is significantly higher than the previous one.

But you don’t need to stick to story points. It can be T-shirt size estimates (XXS, XS, S, M, L, XL, XXL). If you would like to be really creative, you can introduce ZOO animals and use them for size estimation.

Either way, it is now much more about the whole team’s feeling about which number (or animal) best represents the overall complexity of this particular story. It definitely is not about time representation. In the end, the team should complete each story taken into the sprint within that sprint. So the time is already given at the beginning and is a constant number.

Components of Story Points Estimate

A story point estimation is absolutely not only about how complex/difficult a particular story is. When estimating a story, the team should consider several aspects and reflect them in the final estimation value.

The final estimation is then a value that represents a combination of all aspects formed into a single number. Here is what such an estimation shall include.

#1. Technical Difficulty

Assuming we are estimating stories for a development team, the technical difficulty of the story will be one of the first areas the team will concentrate on by default.

And this is, by all means, the right approach. The team full of technical experts should know best how to evaluate such an area of a story. Here the team can consider various approaches or hints, like:

• How this story compares to other ones already delivered from the view of technical complexity?
• How many code files will the team have to create/update in order to complete the story?
• How many additional code changes will this story generate to the surrounding system processes?
• How complex will the algorithm or process logic be to implement?

#2. External Dependencies and Risks

One would be surprised, but more often than not, the success of the stories inside the team’s sprint is dependent on contributions from other teams or persons external to the team itself.

Stories where everything the team can accomplish on its own is the easiest to estimate. Things get complicated if the team needs external help for their stories. For people outside the team, this activity won’t be a priority, naturally. The team just has to count on that factor and consider it within the estimation.

How much this factor will increase the total estimate will depend mostly on the team’s previous experience and the “level of externality”. Usually, in some sprints, the team will establish some natural unified feeling for how much this dependency on external people might complicate the successful completion of the story.

#3. Reusability Factor

The next area to consider is how much of the existing content the team can reuse in order to complete the story. Obviously, if some of the parts are already present in one way or another, it’s not necessary to build it from scratch. Rather, the team can reuse the already once created solution to build a new one much quicker.

In such a way, this knowledge can lower the total estimate, even if normally (without this reusability), the story would be more complex based on the defined content.

#4. Understanding of Own Team

One remarkable factor that no man-days-based estimate can ever consider is the self-knowledge of the team’s seniority and capability.

As the team works together and delivers several sprints, people inside will get to know each other. They will start to understand who knows what and how good she/he is at that. And once everybody knows the rest of the team, they together as a team can consider this during the estimation.

If the story is heavy on some concrete technical skill and that skill is very strongly present inside the team, it’s the clear realization of the story won’t be so much of a hassle. Or vice versa, if the needed skill is lacking within the whole team, then the team will need significantly more time to get into the topic, and they shall reflect that in the estimate.

Estimating the Story

Each story estimation should be a team effort. No single voice should predefine the complexity of the story. The ultimate goal should be to let the team discuss the estimate until all members will agree on one single value that will represent the final estimate.

The team can do the estimation directly during the sprint refinement discussion (a meeting where the stories get discussed and clarified between the team), or alternatively, they can reserve a dedicated time to do just that.

Example of Estimation Process

1. Choose an estimation tool for the team to use, something like Planning Poker, Miro board, or similar.
2. Place a story on the board. Let the team discuss final thoughts or questions about the story. Make sure the whole team has full awareness of the story and they are ready to estimate.
3. Start the estimation. Each team member is requested to choose a number from the Fibonacci scale.
4. Once all have been estimated, look together at the results. Start the discussion. Usually, the team will separate between two to three numbers. Let the people from the lower end give reasons why the estimate should be this low. Then let the people from the other end elaborate on why the final estimate should be this high. The goal is to put on the table all the arguments, considerations, and facts so that the whole team is on the same page in understanding what this story includes.
5. After the discussion is over, let the team estimate again. Most of the time, the team will now convert to one or two distinct numbers. Repeat the discussion again. Depending on the concrete case, either the team will agree on the final number from the two alternatives, or you will decide on another estimation round.
6. The estimation is over only if all team members are absolutely fine with the final estimate. It should be an agreement of the whole team, not just a few individuals. Potentially, every story can be later assigned to anybody from the team. That’s why it is important everybody is in agreement on how complex the story is.

Sprint Plan Commitment

The team now has a backlog with stories that already went through the estimation sessions. Ideally, the stories have been assigned (apart from the final estimate value) also a priority so that the team knows which stories will come next into the next sprint.

Here comes the planning session, where the team will pick some of the stories for the next sprint. The decision on which stories to pick should be based on the following:

✅ Stories with the highest priorities the team considers first.

✅ An experience of the team of how many story points they are able to finish within a sprint. This knowledge only comes with the time and experience of the team. You need several sprints to fine-tune and get a proper understanding of this capability.

✅ You should not only consider the total story point number and priority. Another consideration is how the skills inside the team will spread across selected stories. For example, if the team has only two front-end developers, they might not choose only stories consisting of front-end development only. That would lead to overutilizing the two guys while the rest of the team is not so much. So the knowledge of the team comes hand in hand with the effectiveness of sprint content creation.

Velocity Factor

Above all sits the velocity of the team (for the upcoming sprint). This number isn’t related to the total amount of story points in any way. However, it indicates how much the team will be available for work for the upcoming sprint.

In order to be able to precisely plan the content for a sprint, we put both aspects together:

1. Team velocity – Measured in days. One member of the team is available for one full day equals one in the team’s velocity. For example, a team of 10 fully available for a sprint lasting 2 weeks equals a team capacity of 100.
2. Usual amount of story points completed within a sprint – Measured in story points. This number comes from previous experience and is closely related to team velocity.

It takes time and practice to find the sweet spot.

Benefits and Common Mistakes

It’s surprising how much the teams are willing to complicate for themselves the process along the way of transformation to an agile team. It literally feels like you need to “get it” before you can start working in that mode.

This first step is, unfortunately, also the most difficult one. In some cases, it takes even years, especially in strictly conservative corporate environments, where the time alone gets stuck in time.

Anyway, this is what will happen once the team “gets it”:

• You no longer need to calculate people or days in order to know when something can be completed.
• The team will learn to create stories only as much complex so that they fit inside a sprint. If a story is more complex, it gets automatically split into more stories.
• The team has good estimates of each piece of work, and once they plan it for a sprint, you know exactly when it is due.
• It will increase the reliability and predictability of the team.
• All people inside the team will be “on the same frequency”. They will look at a story and will understand similar things. Maybe after some time, they don’t even bother to estimate. They see the number in their head, and since all of them see the same number, they can commit to stories in a sprint even without this explicit estimate.

And this is what usually happens if the team is still unable to understand the process or way of working:

• They somehow still stick to the old fashion man-days estimates. They convert everything to days or people involved. Story points or Fibonacci numbers mean amount of days, either directly or indirectly, via various transformations.
• Leadership compares the teams based on the number of story points delivered each sprint. This is as much wrong as it could get. A substantial fact is then not understood: Each team estimates the story points differently. There is absolutely no reason for making an effort to synchronize two teams to estimate their stories in the “same way”.
  • While one team’s story point means drawing a circle, for another team, it might mean drawing a house with a flat roof, four windows, and two doors. And it’s totally fine.
• Sometimes the teams tend to estimate almost everything between two to four different numbers. Maybe because they fear that a story has the number 123, somebody will think it has something to do with the number of days. But the fact is Fibonacci scale has an infinite amount of numbers. We don’t need to limit ourselves just to estimates of 3, 5, or 8. We surely can (and maybe we create the stories already with that purpose in mind to be that complex, in which case this is fine), but we definitely don’t need to.
• Estimation is driven by senior people who will predefine the expectation of the whole group. We should never allow influencing the estimation by one team member. Everybody has an equal right to express his/her opinion and be listened to.

Final Words

Switching to agile estimation from the more traditional approaches is not always easy and takes to accommodate—both for the teams as well as the leadership above. In order to make it work, both sides must understand the process. If one of them does not understand, the transition period is a difficult road full of contradicting expectations.

But once all transforms, some magical things will start to happen. The teams will be able to better estimate and plan their work, and the leadership will have more predictable releases and roadmaps to rely on.

Next, check out unhealthy processes that can ruin your sprint.