Estimation is used in product delivery to help understand when a work item, project or feature will be ready to use. The team doing the work will analyse what needs to be done and estimate using the preferred unit (level of effort, time, story points, T-shirt sizes, etc.). These estimates are used to determine and use velocity for sprint planning or might be used for setting expectations with clients or customers who are wondering, “when will this be done?”.

It’s rare that estimates are ever exactly accurate. This is why agile teams lean toward measurements of complexity, such as story points or probability forecasting, rather than specific time estimates.

Background

In traditional development, project managers typically focus on detailed scope up front, so that the cost, estimates, and time are precise and set before kicking off a project. The problem with this approach is that as new things are discovered, scope changes and impacts everything else, making the estimates obsolete.

In agile projects, a common approach to estimation is for development team members to arrive at a high-level estimate for each story in the product backlog during a working session called the “backlog refinement”. Scrum teams often, but not always, estimate using story points, which helps in finer estimation during sprint planning. This helps the team to get started, rather than wait for all the project details to get finalised. Kanban teams, who don’t prescribe to scrum events such as sprint planning, may devote more time during backlog refinements to reach an agreed upon estimate for upcoming work.

It’s important to note that story points shouldn’t be used to compare teams. Skill level, experience, familiarity and other factors will set individuals and teams apart from one another. For example, one team might estimate a backlog item as 5 points, but a team that has more familiarity or expertise in a relevant tool might estimate the same item as 3 points, and that’s okay!

Estimation meetings have a reputation for being tedious and tiring affairs that distract from “real work”, like coding, writing or designing. What’s more, doing estimation meetings as a remote or distributed team can be difficult. Many teams aren’t any better with agile estimating than they are with traditional estimating, leading many people to reject the notion of estimating entirely.

That leads to the question: If agile estimating doesn’t work any better than traditional, why bother estimating at all? Well, estimating can work… but only if you understand why you are doing it.

Why do we estimate?

The truth is that estimating isn’t about estimating at all! Estimating is about creating a shared understanding of the requirements and solution.

When teams have problems estimating, it’s almost never an estimating problem. It’s a shared understanding problem. The Agile Manifesto gives us principles that can help solve shared understanding problems, such as “business people and developers must work together daily” and “the most efficient and effective method of conveying information to and within a development team is face-to face conversation”.

Let’s combine these principles with the Scrum Guide, specifically the pillar of “transparency”. In the context of Scrum, transparency means not just that everyone on the team has visibility of the work in the backlog, but more importantly that the work is well understood by by everyone

Estimation techniques

What & when?

Estimation will be similar but look a little different between sprint and product backlogs.

A sprint or team backlog will include stories or work items such as user stories that will be worked on by the team. These are the smallest units of work that contribute to a larger feature or project and are often estimated in story points during delivery.

A product or program backlog includes features or projects and are larger efforts than user stories or bugs that individual teams can work on. These are usually estimated before delivery starts to assess viability and priority. These items tend to have more unknown variables, so estimating them using a larger scale unit is recommended, such as T-shirt sizing during a discovery phase.

Story points

Estimate = Risk + Complexity + Effort

Story points are a unit of measurement, just like time and money. Time measures duration, money measures value, and story points measure the estimated size of a piece of work, where size is the sum of multiple factors.

The value of story points is rooted in the experiences of the team. One hour represents the same amount of time worldwide, but story points are more like money. There’s no universal value of currency and there’s no one world currency. Most countries have their own currency primarily for use within their own borders.

Story points are your team’s currency, since they’re used to discuss, size up, and reflect on work within your team, not to communicate or be compared between teams. Relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing from scratch. For example, even though we don’t know the exact height of the London Eye, we know that compared to a house, it’s taller. Compared to the Gherkin, it’s shorter.

Steps to introduce (or reintroduce) story points on your team

1. Find the simplest, most routine task in your team’s backlog
2. Estimate that task as 1 story point
3. Boom! You now have a foundation for comparing other work items in your backlog. Go forth and begin your relative estimations.

If your team agrees that a work item will take more than a couple of weeks or a sprint to complete, you’ll want to work together to break that work item down into multiple tasks that fit into your sprint or other reasonable amount of time, determined by your team.

T-shirt sizing

Another common agile estimation technique is T-shirt sizing. This is usually used at a project or feature level that will later be broken into digestible stories able to be estimated more granularly.

T-shirt sizing is similar to story points in that they are relative. It’s useful to take a quick, simple, routine project or feature that your team has expertise in and estimate that as “small”. From there, you can compare other projects or features that are more complex as medium, large or XL.

In summary, the most important thing to remember about estimation is that it’s used to create a shared understanding of the requirements and solution. Whether you’re estimating a feature, story or bug, collaborate as a team to come to a relative estimation that will set everyone up for success.

Want more estimating and agile delivery tips or coaching? Get in touch with one of our Agile Delivery experts today!