Agile Estimation Techniques and Process

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• Contrasting Traditional and Agile Estimation Techniques
• The Importance of Whole-team Estimation
• Copyright

Estimating software is a mystery for most teams. Teams can spend huge amounts of time breaking down features to create their estimates, but the actual time needed is usually a vastly different number. The issue lies in two areas: techniques and expectations.

Most teams use traditional estimation and capacity-planning techniques. Traditional techniques are dependent on constants and repetitive work. A traditional planning process wants to know how much time it takes to build a widget, how many machines are available to build the widgets, and how many hours a day the machines can be used for building the widgets.

As you probably know, each piece of software is unique, and it’s difficult to estimate something that is being built for the first time. We never build the same widget twice. It’s also hard to treat a developer like a machine and predict their output on a daily basis. Communicating this to sponsors and stakeholders is also challenging; many experienced software professionals still believe incorrect estimates are more closely tied to incompetence than to the realities of software development.

Agile estimation techniques won’t remove uncertainty from your early estimates, but they will improve your accuracy as the project proceeds. This is true because Agile estimation methods take actual work into account as the project progresses. Your work mix may be diverse, but if you measure at an aggregate level you can still identify an average that you can use for estimating your capacity. We’ll demonstrate this process as we follow the Auctionator through its development iterations.

The estimation process covered in this chapter is based on the teachings of Mike Cohn in Agile Estimating and Planning. Mike is a founding member of the Agile Alliance and one of the most knowledgeable estimation experts in the Agile community. We highly recommend reading Agile Estimating and Planning to gain a deeper understanding of estimation techniques.

Let’s start by seeing how a project team usually gathers the information needed to create estimates.

Contrasting Traditional and Agile Estimation Techniques

An average software project begins when a team or person outlines a project and receives approval to go forward. The project may be started by a product manager with an idea for an existing product, or by a customer request, or by the signing of a contract.

In the early stages of a project, someone guesses how long it will take to deliver. This person may be a salesperson, project manager, or development manager. They may make a guess based on their experience, or they may have some quick chats with seasoned employees and solicit their opinions.

When the timeline guess is in place, the project begins. If the project is related to a product, there may be marketing requirements to reference. If the project is for a customer, there may be a statement of work to reference. In either case, it’s common for an analyst team to convert the information into functional specifications.

After the functional specifications are completed, a conversation begins with the development team, designs begin to evolve, and some teams may document a technical design and architectural plan. When this work is complete, the development team provides estimates based on the anticipated approach. The team also estimates their capacity by resource type. Then the estimates, capacity, and known dependencies are entered into a project plan. At this point, the team has a schedule that they feel confident in, and they share it with the stakeholders.

This exercise may take several weeks or months to complete. If a project is timeboxed, the team may find that there isn’t enough time to deliver all the features for which they created functional specifications, designs, and estimates. The team then has to scope back the features for the project to meet the timeline, realizing they’ve wasted valuable time in estimating features that won’t be pursued.

Agile estimation techniques address the shortcomings of this method. You don’t design and estimate all your features until there has been a level of prioritization and you’re sure the features are needed. You used a phased approach to estimation, recognizing that you can be more certain as the project progresses and you learn more about the features.

At a high level, the phased process looks like this:

1. Estimate the features in a short, time-boxed exercise during which you estimate feature size, not duration.

2. Use feature size to assign features to iterations and create a release plan.

3. Break down the features you assigned to the first iteration. Breaking down means identifying the specific tasks needed to build the features and estimating the hours required.

4. Re-estimate on a daily basis during an iteration, estimating the time remaining on open tasks.

Agile estimating is also different in that you involve the entire team in the estimation process. Let’s take a moment to look at the value of whole-team estimation.

Note

Are Traditional Estimation Techniques Really That Bad?

For some software projects, requirements rarely change and timely delivery isn’t critical. Other times, a project sponsor may be more interested in schedule accuracy than delivering while a need still exists. In still other cases, a long-term, fixed-bid contract must be supported, and you can’t risk identifying additional expenses after the contract is signed. In these and many other instances, traditional techniques are worthy and valuable.But if you’re reading this book, there is a good chance you have volatile requirements, your customer needs to receive valuable software soon, and you must deliver your project in a lean method with limited waste. If this is true, you need an Agile estimation process.

The Importance of Whole-team Estimation

Every year, Best Buy Corporation tries to predict how many gift cards will be sold at Christmas. The typical process is to solicit the opinion of upper management and internal estimation experts to forecast a number.

In 2005, the CEO of Best Buy decided to try an experiment. The CEO followed the normal process for obtaining the estimates but also sent an email to approximately 100 random employees throughout the company, asking them how many gift cards they believed would be sold. The only information provided to both groups was the sales number for the previous year.

After the Christmas season was completed, the predictions of both groups were reviewed. The expert panel was accurate within 95 percent of the actual number of cards sold. The random group of employees was accurate within 99.9 percent of the number of cards sold (see Figure 14.1). How did a random group beat the internal estimation experts?

In his book The Wisdom of Crowds, author James Surowiecki makes a case that a diverse set of independently thinking individuals can provide better predictions than a group of experts. Surowiecki qualifies this assertion by stating that the diversity needs to be in the way a group views problems and the heuristics each individual uses to analyze a problem or question. For example, a person’s age can greatly influence their perspective on an issue.

Figure 14.1 Best Buy Corporation realized improved estimation accuracy by querying a large, diverse group of employees. The diverse set of employees consistently delivered better estimates than the in-house estimation experts.

Surowiecki’s work draws many parallels to the issues with estimating software development. We often get together a group of specialists or experts to estimate the work that needs to be completed. These experts may be managers or leads who facilitate the work of their various teams. The fact that all the experts may be a part of management limits their diversity in opinion. And the fact that these experts may work together frequently may lead to standardized thinking, also known as groupthink.

In an Agile environment, you increase the accuracy of your feature estimates by estimating the features together as a team. Estimates aren’t limited to managers or leads but also include developers, testers, analysts, DBAs, and architects. The features are viewed from various perspectives, and you merge these perspectives to create a common, agreed-on estimate.

Entire-team estimation has additional benefits beyond diverse opinion. First, you get estimates from people who are closer to the work. Team members’ opinions may be diverse, but they provide better estimates because they know your existing code, architecture, and domains and what it takes to deliver in your environment.

A second benefit is team ownership of the estimate. If a manager provides the estimate, they hope the team supports the estimate and buys into it. If the team provides the estimate, they’re immediately closer to owning the estimate, and they feel more responsible for making the dates they provided.

Moving to team-based estimation isn’t easy. Managers may not welcome additional input, and team members may be reluctant to challenge the experts and instead echo whatever the experts say.

It will take time to overcome these hurdles, but you can do one thing to expedite the change: when you perform team-based estimation, have the meeting facilitated by an indirect manager such as a project manager or ScrumMaster. This person can treat all people as equals regardless of title and proactively query team members who are reluctant to contribute. You can also use the planning poker process discussed in the next section to prevent one person’s estimate from influencing another’s.

Note

My Team Is Huge; How Can I Involve Everyone?

We’ve worked with development teams that included 20 people or more. It’s difficult to involve a group this size in one estimation session. The teams we’ve worked with have addressed this issue in three ways.

Some teams send a lead to the estimation meeting. Instead of providing estimates, the lead records the information about the features and then returns to their team to review the features. The lead may represent development, QA, business analysis, implementation, or other functional areas. The functional areas then do their own storypoint estimation for the feature, and the lead takes that estimate back to the smaller leads-estimation meeting.

A second way we’ve seen this addressed is via conference phone. A small group of leads or other representatives discuss the features with the customer, and other team members listen in over the conference line and put in their perspective on how large the feature is.

Finally, some companies assign features to subteams within a team at large and allow the subteams to estimate the features they’re assigned. A project manager or other resource then aggregates the information from several teams into one release plan.

Previous article: Prioritizing the Backlog

Continue on to the next article: Estimating with Story Points

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.