Estimating

Introduction

An estimate is a prediction of what will be delivered, how much it will cost, and when it will be delivered.

Estimating supports decision-making throughout the life of a project, for instance:

• To evaluate the business case.
• To plan the constituents of the next release.
• to decide what can be worked on in the next timebox.

The iterative and incremental approach of Agile means that estimates made early in the project will be base on limited knowledge – with this being enhanced throughout the lifecycle as understanding grows of the work that's required.

The Four Estimating Principles

1. Know the purpose

You must understand why you are estimating and only estimate when necessary, for instance to make a decision or change direc.

The purpose of the estimate should drive the level of detail, the time to be spent on it, and the techniques used. The key here is to do just enough to satisfy the need so that a decision can be taken.

2. Challenge and validate the estimate

Estimates should be created collaboratively and validated by the use of more than one technique.

And they should also be checked regularly throughout the project, based on experience and feedback.

3. Expect change & uncertainty

Projects have to deal with uncertainty and unknowns, and estimates must acknowledge that by being upfront about any risks and assumptions that have been made.

4. Take ownership

The project team should create the estimates as they have the knowledge and will be responsible for delivering the work.

That said, those responsible for steering and leadership must decide how much estimate risk they are willing to accept.

Estimating Approaches

1. By Analogy

A project is estimated by reference to its relative size, compared with similar work that has been delivered by the team and the organisation.

Any equivalence regarding the following factors should be considered when deciding which project to benchmark against:

• The number, size and nature of the business requirements.
• The possible solutions and its architecture.
• Its use of tools and technologies.

Estimating by Analogy is a good approach to use when the speed of producing an estimate is more important than its precision, e.g. to decide whether an idea is worth taking forward in the pre-project stage.

This approach focuses on assessing a product or service based on its external features — with just enough understanding to estimate size without needing to analyse every detail.

The main elements of a product or service are identified here, such as the key delivery components and the high-level requirements. These are then sized using techniques such as Story Points or T-Shirt Sizing (see the next section), and measures of effort or speed of delivery are applied to give an overall estimate.

Given the inherent uncertainty of using this style in early phases, the estimate is often provided as a range, e.g 125-175 days, or $100,000-$150,000.

The benefits of this approach are its speed and focus on the full scope of the estimate, rather than the detail.

This approach involves breaking down the product or service into the detailed work steps needed to deliver it – with the level of decomposition being adjusted according to the precision that’s required.

Each step is then sized (for instance in person-days) and subsequently aggregated to give an overall estimate.

This approach is best used when detailed information is available, and the estimating and planning horizon is short, for example when estimating for a two-week timebox.

The benefits of this approach are that it provides a good understanding of the product or service and the work that’s required, and that it may offer a more accurate basis for planning.

Estimating Techniques

The following techniques can be used to support these approaches

1. Story Points

This technique may be used for top-down estimating.

A Story Point is an abstract number that's assigned to reflect the perceived effort to complete a User Story, based on its complexity, risk, and the likely effort required.

Planning poker is a popular, consensus-oriented way of calculating Story Points, using relative estimates to size User Stories against each other.

Here members of the delivery team are each given a deck of cards with values representing Story Point numbers in a Fibonacci-like sequence, e.g. 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, and Infinity.

Once a User Story has been discussed, each person chooses a card from their deck showing the number that matches their Story Point estimate for the work that's required.

When everyone's ready, all the participant's cards are revealed simultaneously, and any significant differences (typically the highest and lowest estimates) are discussed.

The process is repeated until consensus is achieved around one or two points on the scale (in which case the higher number should be used). If that isn't possible, then the User Story should be put aside, pending further information

This activity continues until every User Story has been estimated — following which these steps are carried out:

The benefits of this technique are that it:

• Creates a forum for discussing and understanding the requirements.
• Allows the team to participate in the estimation exercise, and in a way that's independent of their individual capabilities. Doing so tends to improve the accuracy of estimates, especially as they're the people they'll be doing the work.
• Provides a sound basis for measuring progress once the project is under way.

2. T-Shirt Sizing

This technique may be used for top-down estimating.

The benefits of T-shirt Sizing lie in its simplicity and because the estimates can be revalidated and adjusted throughout the delivery lifecycle.

A drawback is that it can't easily be used in velocity calculations to demonstrate progress and a projection of future delivery.

3. Days effort

This technique can be used for bottom-up estimating.

It's particularly useful where the estimating horizon is short, the scope of the work is well-understood, and the estimators are the people that are responsible for delivery — for instance, at the start of a four-week timebox.

The benefits of this technique are that it provides additional insight to the work that's required and can be used to measure progress once the timebox is underway.

Author

Agile Business Consortium

The Agile Business Consortium is the professional body for business agility. We’re all about community – whether you’re a multinational working through a large-scale transformation, a new start-up, or a contractor, we can support you to achieve more, to grow more, and to build your business agility. As a global not-for-profit organisation that’s been around for over 25 years, our knowledge and experience around agile competencies and behaviours can offer you the guidance you need to reach your agility goals. Together with our partners, we create and share agile research, case studies, resources and tools that help you compete in today’s uncertain world. A registered not-for-profit, we’re the world’s longest-standing agile-orientated organisation. We’re the brains behind AgilePM®, AgileBA®, AgilePgM®, AgilePfM™ and AgileDS™. Based in the UK, we have members in over 30 countries around the world.

Email:

[email protected]

Phone:

+44 01233611162

Twitter:

@Agile_Biz

Website:

agilebusiness.org

LinkedIn:

https://linkedin.com/company/agile-business-consortium