In our previous post, we discussed some of the main concepts regarding Scrum and its terminology. We also showed you how high level-planning works in Agile frameworks. This time, we’re going to write about something that deserves its own post: Estimation.

If you work in software development, sooner or later there will be a time when you have to estimate for a task or a project.It’s a dreaded moment for everyone involved.

Developers hate it because they usually have to estimate tasks that are hardly defined to any degree. Meanwhile, managers hate it because poor estimates create a lot of headaches. Managers constantly have to battle schedule and budget problems which these estimates inevitably create.

Regardless of the project type, the person who will do the actual estimation will need to give this information to the client so that the client can make educated decisions. The same goes for software development. Estimation itself is completely independent from project management methodology. The only thing that differs are the techniques and the metrics used.

In traditional waterfall models, projects are broken down into modules and then – in better circumstances – into work packages. When the work packages of the project have been identified and verified, development teams start estimating them in man-hours per day and week. Once they have an estimate for all work packages, they summarize these hours, which may be communicated to management or the client.

This is called bottom-up estimation. If the company’s project managers are more knowledgeable or there is a PMO present who can supply the right tools, they will use a technique like the Critical Path method (we will discuss this method in a future post) to model the project’s forecasted progress, task dependencies and calculated floats between tasks.

This also takes resource availability to calculation. If the team uses a three-point system in their estimation along with Beta distribution, you’re in “estimation heaven”. The main problem of this process is that it takes a lot of time and thus costs a lot of money. It’s also difficult to explain to clients, so these techniques usually get used infrequently.In some cases, companies even fall back to inaccurate and impossible estimations (not of the time, but it does happen).

Scrum does this a bit differently. Scrum teams estimate in Story points (SP) instead of hours. The main difference, in comparison to estimating in hours, is that Scrum teams don’t have to give exact time estimations on a given task, but instead estimate the effort needed to complete the task. Story points are a relative metric, which shows the approximate effort and complexity that will go into the task or story,. This is all well and good, but all businesses revolve around money and story points can’t be converted to money or time. (As always, time = money) There are formulas for doing so, but that’s an entirely different discussion.

Companies using agile frameworks need something more to convince their clients and  management – this is where team velocity comes in. We’ve discussed this concept in the previous post. This is the capacity of the team, namely, how many story points they can complete in a sprint, which is always a predetermined timeframe (usually 1, 2 or 4 weeks).

If an agile team tells management that the feature they have requested is estimated at 13 story points, they will find people scratching their heads. But if the same team tells the client that in one sprint they can complete four or five similar sized features, then it is an entirely different story. Clients will also be more receptive of this idea.

It’s very important to note that there is no correlation whatsoever between story points and time. A lot of beginner teams fall into this trap, which is very tempting. Although there’s obviously some kind of connection between the two, meaning that a higher story point number will probably mean more work and more time, but this isn’t always the case. Remember, story points represent a combination of effort, complexity and even doubts. The best example would be the following hypothetical conversation between two developers:

“Maybe it will take you 4 hours to do this and 8 hours for me, but we both agree that looking at this task compared to the rest, this is definitely a 13 SP story.”

When it comes to estimates in Scrum, teams can only use predetermined values. These usually come in the form of a modified Fibonacci sequence (there are more systems, but this is the most widely used) with the following numbers: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. With these numbers, Scrum teams can compensate for the uncertainties stemming from the complexity and effort that is not always known beforehand.

The previous conversation illustrates this perfectly. The higher the number, the higher the uncertainty is about the story,  which means the story requires either more decomposition or more clarity.

Estimation accuracy

When it comes to estimation accuracy, humans are simply not good at it. Thankfully, there are many tools and techniques to help teams achieve better estimations. Just because we’re bad at it, doesn’t mean we shouldn’t try, right?

When it comes to estimation accuracy and quality, there are three main classes:

  • Rough Order of Magnitude (ROM)
  • Preliminary
  • Definitive

In more scientific circles these are classified in reverse order ranging from 1 to 5, where Class 5 means the lowest accuracy and Class 1 is the highest. In this context, Class 5 is the Rough Order of Magnitude estimation. Usually, a Class 3 estimation (Preliminary) is enough to calculate a budget, especially because uncertainty will be its greatest at the start of every project. The following figure offers more explanation:

You can clearly see on this figure that as time moves forward, uncertainty is decreasing, but it never disappears and adversely accuracy increases.

In most projects, there simply isn’t enough time to get to a Class 1 estimation. Achieving this is counterproductive, since the required definition level of the project is usually achieved near its end.

As we’ve said before, Scrum uses relative sizing. With respect to accuracy, it is easier to compare one task to another. It is especially hard to estimate something that you only have a vague idea how to complete. Story points provide the solution for this, as they come from a predefined pool of numbers so teams can quickly come to a consensus about which numbers to use in certain situations.

For example:f a previous registration form was 13 story points, then a whole cart page with all its functionality will be around 2 to 3 times that and the closest number that can be used from the modified Fibonacci sequence in this case will be 40. A good advice for teams is to select one story so they can know its story point worth (because the team did it before) and use that as a benchmark for the rest of the stories.

Story points usually take three main aspects into consideration:

  • Complexity: These are the things that the team know they can solve, but still need to figure  out.
  • Effort: This is basically the volume of the task. Even if the team knows exactly what to do, they still have to do it. This takes effort.
  • Uncertainty: These are the things that the team is not sure about. They might have a vague idea of how to do it, but they are not sure. As projects progress forward, these uncertainties slowly disappear. Otherwise, if they’re not handled correctly, they lead to project failure.

As we’ve stated within the beginning of this post, the next step after estimating story points is figuring out the team’s velocity. This is hard for fresh or newly formed scrum teams, as they won’t have an idea.There is no historic data to base their assumptions on.

The easiest method in these moments is to guess a reasonable velocity for the first few sprints and use the yesterday’s weather technique. This involves paying close attention to the team and the speed at which they can complete their stories for 2 or 3 sprints and take the average of their total throughput. The number you receive will be the team’s velocity. This technique can be used for more developed teams as well because team velocity can change over time for a variety of reasons. Knowing your team’s capacity is paramount in project success.


Taking everything into account, there is no “silver bullet” when it comes to estimation. Both agile and waterfall uses a wide array of tools and techniques to combat uncertainty and poor estimation accuracy.

At the end of the day, all teams and managers must decide what is best for them and perfect those methods as they move forward. Our best advice is to keep a record of your estimations and keep going back to them and revise them as necessary. This way, you’ll have a historic database of certain features you’ve already built and completed. This will allow teams to perfect themselves and always have something to benchmark their estimations against.

In the next post, we’ll discuss the most common tools and techniques used for estimation in agile and how they compare to waterfall.