Software Estimation

Software Estimations Tend to Fail But That's Fine

Luis Ortiz

Jul 7, 2022 — 8 min read

Estimating the amount of effort or time a task will take always seems inaccurate, so why do it anyway? Meeting with the team to do estimates may consume some hours as well. There even exists a #NoEstimates movement that aims to eradicate it.

While some consider estimating a waste, it remains a regular practice in Agile organizations. It has some relevant advocates, such as Jacob Kaplan-Moss, co-creator of Django, a Python web framework widely used worldwide. It's not just Jacob: Ken Schwaber and Jeff Sutherland, founders of Scrum, also consider estimations essential to improve software development workflows.

We could spend all this article putting together quotes from experts who support the idea of performing estimations. Still, instead of that, we want to give a quick overview of it and how you can leverage it to improve your operations.

Topics to check

What is effort estimation?
a. Roles and responsibilities
b. Impacted areas
How to estimate
a. Story Points
b. Velocity
c. Story Points vs. hours
d. Estimations are not commitments
Estimation techniques
a. Planning Poker
b. T-shirt Sizing
c. Affinity Grouping

1. What is effort estimation?

Simply put, it is the practice of estimating how much effort the completion of a work item might take. Estimating was broadly described in the first version of Software Estimation: Demystifying the Black Art, published in 2006 by Steve McConnel. The following quote can represent one of its central ideas:

"The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." In this sense, we can consider estimates as a tool that can help assess the risks involved with any task or project.

It's critical to understand the point of estimating effort before doing it. First things first, estimations aren't the same as commitments. That's essential advice by Mike Cohn, founder of Mountain Goat Software. He considers this confusion a common problem amongst several organizations, causing friction between business and development teams.

He uses a simple yet powerful metaphor to clarify that point:

It isn't the same as asking your partner to estimate at what time he might be getting out from his painting lessons than to request him to commit an exact hour when he'll be ready to be picked up. He might estimate to be done at 5:15 pm, but would commit to being out at 5:25 pm, having a time buffer to deal with any unexpected event.

As you can see, estimates aren't the same as commitments but may function as their foundation.

a. Roles and responsibilities

Before digging deeper into the mechanisms of estimation, it's critical to understand who is responsible for which part of it. We'll base the dynamics around the structure of a primary Scrum team, implying there is a Product Owner (PO), a Scrum Master (SM), and a Development Team -which includes Developers and QA Testers.

The Development Team is first on the line when estimating the effort the tasks might take. They will be the ones performing them, having the required expertise to do so.
Testers' opinions must be considered at the same level, as any feature or service must pass QA, which may require building scripts for automated tests or even manual reviews.
The SM may influence estimations indirectly by considering high-level circumstances that Developers or even Testers could overview. SM's big picture perspective and technical experience support come in handy.
The PO shouldn't influence estimations but may bring further detail or clarity about the tasks, potentially increasing their complexity.

Estimations are done during an Estimation Session event and should be attended by the Development Team and the Scrum Master. The Product Owner isn't required to be present, but its input can enrich developers' estimates, so we suggest the PO participate whenever possible.

b. Impacted areas

Each organization has its approach to managing budgets, costs, and pricing. A digital agency that works with different products from several clients has different needs than a start-up focused on a single development and its variations. But regardless of the context, estimations have a direct impact on the finance and operations areas.

Traditionally, development teams estimate how much effort a task might take using Story Points (a system we will discuss later). After the first sprint or work cycle ends, Story Points are used to calculate Velocity, the number of completed Story Points per Sprint.

Velocity will help the Scrum Master to understand performance and detect blockers and anti-patterns.
It also gives the Product Owner, Project Manager, or external stakeholders a concrete idea of how much can be achieved over a certain period.
Accurately measuring Velocity can serve as a foundation for establishing costs, influencing other indicators, such as the Return on Investment (RoI) or even contractors' compensations.

To dig deeper into the usage of Story Points for calculating Velocity, we must review the estimation process first.

2. How to estimate

The Product Owner (PO) is in charge of putting together the Product Backlog, which contains the work items needed to deliver the product. Then, during planning, the whole team agrees on which tasks will be worked on during the next work cycle, consolidating the Sprint Backlog.

The Developers review the Sprint Backlog to estimate the effort they think each item might take. Story Points are the most used indicator, but there is no universal way of calculating this; all systems are subjective and depend on circumstances such as the nature of the project, the team's maturity, each member's experience, etc.

a. Story Points

As an abstract representation of how much effort a task may require, they usually are represented by numbers for establishing sizing correlations. You might feel tempted to use a numerical scale, like thinking of 0 as the lowest effort and 9 as the highest effort possible.

However, many teams use the Fibonacci sequence instead with good results. Why? Let's consider another piece of advice from Mike Cohn.

In the Fibonacci sequence, numbers progress in an additive way, with each number being the sum of the two preceding ones.
Eventually, differences between numbers become more prominent, making it easier to differentiate sizes.

He uses the following example:

Consider you hold a one kg weight in one hand and a two kg weight in the other. It might be easy to distinguish which is heavier without even looking at the size. But if those two weights were 20 kg and 21 kg, it would be harder to know which is heavier.

In both cases, the difference is just one kilogram, but as weights get heavier, the difference between them needs to be bigger for your brain to perceive it.

b. Velocity

After tasks are estimated, it's time to see how things unravel. At the end of the sprint, the Story Points of all the completed assignments are summed up. The result is the number of points the team can deliver per sprint, which is the team's Velocity.

Think of this scenario:

After a two-week sprint, the team accomplished 32 Story Points. You can expect that quantity to be similar for the following work cycle, so you'll plan based on it. You won't try to fit tasks that sum up 45 Points and exceed your capacity.

Essentially, Velocity expresses how much work the team can handle during a period. It's helpful to forecast delivery times and capacity, and highly useful for scheduling and budgeting purposes.

Some key takeaways here:

Velocity tends to consolidate as the team gains experience working together.
A 'high' Velocity doesn't mean the team delivers more value or drives better business outcomes. Those variables depend on more complex contextual factors.
Do not try to measure each teammate’s Velocity. It should always point to team performance.

c. Story Points vs. hours

When thinking about estimations, we have all asked ourselves: Why not use hours to estimate how much a task will take? It would seem to be the most intuitive way, but when dealing with unpredictability, it gets near impossible. How can anyone know how many actual minutes it will take to accomplish?

The context may change even if someone has already performed a similar task in the past. Maybe there's a new framework that can help to enable a feature in half the time as six months ago, but after testing, you notice it isn't compatible with another component, so now you've got to fix that too.

Reality is never black and white. Jacob Kaplan-Moss, the co-creator of Django, uses an estimation methodology revolving around time. He doesn't use hours but days vs complexity, composing a sizing matrix that is more similar to using the Fibonacci sequence than assigning a simple numerical scale.

You can learn more about Jacob Kaplan-Mosss's estimation method here.

d. Estimations are not commitments

Say it loud and clear: Estimations are not commitments. That is another reason to avoid using hours to estimate, but this topic goes deeper. It's usual in some companies that managers consider estimates as committed deadlines, using them to assess individuals' performance.

That, along with other anti-patterns, caused the birth of a #NoEstimates movement, sparked in 2012 by Woody Zuill's No Estimate Programming Series blog post. Since then, it has motivated the debate about how truly necessary is it to estimate, which we may explore deeper in another post.

3. Estimation techniques

Agile practices are executed because they bring value to the team, the product, and the customer. In that sense, it's understandable that some projects can be delivered without estimations. It all depends on their maturity and the complexity of the requirements. But generally speaking, estimating is a good practice, especially for starters.

According to PMI, there are three main estimation techniques.

Planning Poker - Uses the Fibonacci sequence and is the most popular.
T-shirt Sizing - Intended to group similar items playfully.
Affinity Grouping - For clustering tasks based on complexity similarity.

a. Planning Poker

We essentially defined the Planning Poker method when we discussed using the Fibonacci sequence for estimating. James Grenning first coined it in 2002 and it then was broadly popularized by Mike Cohn.

As previously stated, the numbers from the sequence are used to rate the complexity or estimated effort each task may take. Low-numbered tasks tend to be more transparent and more straightforward, while the highest number relate to requirements that are not yet well understood.

b. T-shirt Sizing

If you want to keep numbers out of the formula, you can use the T-shirt Size criteria to estimate how easy or hard a task may be. You can establish as many sizes as you want, but we suggest sticking to Small, Medium, Large, and XL.

c. Affinity Grouping

This method requires the team to use the complexity of a task to estimate another, and so on. This method may be less concrete but can be used when the team has a good project domain.

Try for free the ScrumPoker add-on for Jira or Confluence and easily estimate, using your preferred technique. Get it for Jira or Confluence.

In conclusion

Estimations are an essential practice in software development. Even if they're one of the hardest to master, they have served so many times to deliver successful products that choosing between keeping or dropping them seems like a false dichotomy.

The discussions sparked while estimating are also meaningful due to how they propitiate collaboration and a collective mindset to solve issues. Getting peers to talk more frequently about workarounds is a great asset. If estimates are going to fail at the end of the day, why not aim for other benefits?

Are you adopting or looking to improve your Agile practices? Is your team remote? If your answer to any of these questions is ‘yes’, you should check out our products for distributed teams. We focus on making communication more effective and easier for remote teams.

Check out our tools:

Stay on top of our upcoming releases:

And subscribe to our blog below!