User story estimation – 6 Best practices for a valuable, inexact, and misunderstood exercise

In agile product development, particularly in Scrum, it is common to estimate the effort to implement user stories. Most of the time, user story estimation is done with story points along a Fibonacci series. Estimating user stories is a valuable but inherently subjective and inexact process. I also believe it is often misunderstood. 

Before we get into the details, let´s first establish the reasons for estimating a story after it is written.

Email address:

Leave this field empty if you're human:

Why even estimate the effort?

I believe that we sometimes overdo it with the estimations. We treat something that is inherently subjective as an objective measurement. Nevertheless, I believe there are some good reasons to estimate. Four stand out to me: 

1. Planning
2. Signaling that a story is ready for implementation
3. Quality gate 
4. Support in prioritization

Planning

In the short term, effort estimations are helpful when planning a sprint. They can be used to understand if what the Product Owner prioritized for the sprint is at all feasible. In the mid-term, once the team has established a more or less stable velocity (i.e. an average number of story points completed in the last x sprints), this number is useful in planning upcoming sprints. This can be helpful, e.g. to understand if a roadmap is still valid. 

Some teams conduct high level estimates for epics as well. We do this once per quarter with t-shirt sizes. We do this to understand what is feasible to do in the upcoming quarter. It is the main input to our quarterly planning and works really well for us.

Signaling that a story is ready

Most of the time, the estimation of the story is the last thing that happens in the refinement process. After estimation, the story is ready to be implemented. As such, the act of adding an estimate to a story becomes a signal that the story is fully understood and refined. The team is ready to implement it. Any story that has an estimate can be put into the sprint.

Quality gate

User story estimations are done jointly by the entire team. Thus, they serve as a quality gate to ensure that everybody has the same understanding of what needs to be done. Estimates that differ significantly between team members are a cause for discussion. More often than not, it then turns out that one of the team members has understood an aspect of what is required differently than the others. The estimation makes this transparent.

Prioritization support

The last point is very obvious, but still worth mentioning. Estimations help in prioritizing for effectiveness. Only when it is estimated does the PO have a clear picture of what the effort is for creating a certain impact (which can also be estimated, e.g. with key stakeholders). This then enables prioritization of stories with the best ratio of impact to effort.

Best practices in estimating user stories

There are many methods to choose from when estimating stories or tasks (Planning poker is probably the most prominent). I will leave the details of those to others and instead focus on some best practices that I have found to be useful:

• Provide boundaries
• Take the higher estimate
• The team estimates
• Estimations are not written in stone
• Uncertainty = higher estimate
• Estimates != commitments

Let me explain one by one.

Provide boundaries 

Story points are a subjective measure of necessary effort. The more experience the team has, the easier it is to use them. They can, however, be a bit unintuitive at first. What I have found to be very helpful for newcomers in the team is giving some guidance on the scale. This means translating the top and bottom of the scale to something less abstract.

In our case, eight points is the maximum we assign and one is the minimum. For newcomers that are unsure we then have a rule of thumb that eight means one person is busy the entire sprint. One point means half a day (give or take). This usually makes it much easier to get into the habit of using story points. 

Take the higher estimate 

In case of differing opinions, always take the higher estimate. Of course, you need to first understand if the differing estimates stem from diverging understanding of what needs to be achieved. If this is not the case and the difference comes from e.g. a difference in skill, always take the higher estimate. 

If then the more experienced/skilled person implements the task, he or she will likely be done quicker than the estimation predicted. Thus, the team has created some buffer for things that may turn out to be more complex than assumed. The buffer can also be used to pull additional things to the sprint. Then the team will complete more than they committed which is a good source of motivation. 

The team estimates

The people who will implement the task or story are the ones to estimate. This is very straightforward but extremely important. No Product Owner, no scrum master, no stakeholder is allowed to estimate. If anybody other than the developers estimate the stories, it will kill any sense of ownership from the team.

Estimations are not written in stone 

The team can update the estimates during the sprint to reflect the actual effort. This is not necessarily needed and depends on the preferences of the team.

I generally tend to keep estimations as is. Minor deviations in the actual effort will in the long run offset, in my view. Only if there is a significant scope change, e.g. dependency overlooked or unforeseen behavior, do we generally change the estimate. 

Others may update the estimate after the implementation is complete to reflect the actual effort. It depends on the developers. If they prefer to update them, that’s perfectly fine. The only thing I would mention here is that it should be done very efficiently, i.e. without much discussion or using some fancy process.

Uncertainty = higher estimate 

In case of uncertainty, I recommend increasing the estimate by one level. In case the estimate is three story points and the team is uncertain, e.g. on if the proposed solution will work or on if the data is in the format it should be in, we tend to increase the estimate to five points. 

If uncertainty is extremely high, we tend to either give it the maximum allowable points or – and this is the better solution – timebox the task. The outcome of the timebox, if it is not completed, is then often times an estimated story.

Estimates != Commitments 

Estimates are our best subjective guess on the needed effort. They are not to be treated as definite commitments on how long something will take. Product development is inherently uncertain and estimations are the same.

It will happen frequently that a story with a low estimate will take an entire sprint. At the same time, many stories with a high estimate will be done in a couple of days. Treating the estimates as commitments will lead to nothing positive. It will only lead to frustration for the stakeholders that the “commitments” are not kept and to frustration for the team because they will constantly be pressured and asked about the “commitments”. It needs to be avoided at all costs.

Story points are not an absolute measure

I believe there are really good reasons to be estimating user stories. We are, after all, currently doing it for each and every one. Regardless, I find it extremely important to remember that user story estimations are inherently subjective and an inexact science. It always bothers me when we treat story points as an SI unit. 

You can, of course, calculate the number of story points you had in the last sprints and then account for holidays, vacations, self dev time, buffer, meetings, and whatever else might come up. After spending significant time and energy you might then come to the conclusion that you have 18,93 story points available for the next sprint. 

Alternatively, you could also take the average of say 25 points you had in the last sprints and then just remove one story because of an upcoming holiday. Neither method is more or less correct. However, the latter is much simpler and more efficient. 

Efficiency is key

Speaking of efficiency…For the above reasons, I suggest being efficient in user story estimations. Do as much as is necessary to fulfill the team’s needs but not more. I don’t see any reason to try and make this process artificially more correct with some sophisticated manner of estimating. 

For us, this means we estimate each story without using any fancy methods. Once we are done discussing all aspects of the story, every team member says what they would estimate and then we generally take the highest. In case of large deviations, we will discuss again. Most of the time the user story estimation itself takes no longer than 10 seconds.

I believe estimating user stories makes sense but only when it is done with common sense.

Coverphoto by Susan Holt Simpson on Unsplash