ProjectConnections.

com Guideline Agile Technique Brief – Estimating

INTRODUCTION: Agile Technique Brief – Estimating

The guideline content starts on the following page.

What This Is
This technique brief discusses an agile approach to estimating the size of features for a software
development project. The approach, called Planning Poker, provides a mechanism that allows the team to
collaborate on an estimate that reflects their combined knowledge and experience.

Why It’s Useful

The approach to estimating described in this technique brief allows teams to produce useful estimates
without spending a great deal of time focusing on unattainable accuracy. The approach uses relative size
measurement instead of absolute duration estimates to avoid the variation introduced by different skill
levels of team members developing features. The use of velocity to capture the team’s ability to develop
features helps to reduce uncertainty.

How to Use It
Teams can use the following steps to determine an initial estimate of duration for a project and then
monitor progress toward that estimate as the project proceeds.
 Establish a feature list for the project.
 Gather the team together; the development members to estimate cost, the business members
to estimate benefit.
 Use Planning Poker to converge on an estimate for each feature. (Detailed instructions are
provided in the guideline.)
 Determine the desired length of the project’s iterations. The ideal length for an iteration is long
enough that the team can deliver something of value, but short enough that it is not painful for the
business to wait and change something. Typical iterations last between 2 and 4 weeks.
 Determine an initial velocity. The best way to do this is to determine how many features the
team can commit to delivering in the first iteration. Add up the story points associated with those
features and use that as the initial velocity.
 Divide the total story points included in the feature list by the velocity to determine how many
iterations will be required, then convert the number of iterations to days or weeks depending on what
is preferred by your organization. The result answer is the anticipated duration of the project.
 After the first iteration, total up the story points from the features that were completed (i.e.
accepted by the Product Owner). This is the actual velocity of the first iteration. Recalculate the
expected duration based on this new velocity.
 After the second iteration, recalculate the overall team velocity by averaging the velocity from
the first two iterations.
 Repeat after each iteration, monitoring the corresponding impact on the expected date that
the feature list will be completed.

The guideline content starts on the following page.

©Copyright 2008 Emprend Inc./ProjectConnections.com. Permission for Members’ use on their projects. Page 1
See our Terms of Service for information on PMO/group use and corporate subscriptions.
ProjectConnections.com Guideline Agile Technique Brief – Estimating

Agile Technique Brief – Estimating

AN INTRODUCTION TO ESTIMATING IN AN AGILE MANNER

Estimating is a key process for all software development projects, regardless of the methodology used.
The accuracy of the efforts always seems to be a hot button with project stakeholders, with everyone
responsible for making decisions about whether to proceed with the project expecting completely
accurate estimates. Estimates are inherently inaccurate; they are guesses of what something will be in
the future. Many people believe they can improve accuracy by putting more time and effort into coming up
with estimates. However, the nature of estimates, especially those done at the beginning of the project,
tells us that they quickly reach a point of diminishing returns. A little effort and thought will get us a
reasonably good estimate, but further effort will produce less and less accuracy for the corresponding
amount of effort. The only true way to get an accurate estimate is actually due the task you are trying to
estimate and measure how long it took.
As you wrestle with that conundrum, it is helpful to consider why teams do estimates. Teams need to
have an idea how long things will take in order to determine when the project will be done, or how many
tasks can be fit into the project time frame. On projects where the schedule is based on task completion
by specific people, task duration is the desired outcome of estimate exercises.
Feature-based approaches to projects expose some flaws in that approach to estimating, such as the
inherent inaccuracy of estimates due to uncertainty at the beginning of the project, the relatively high level
of understanding that teams have about features when estimating, and the fact that different people have
different capabilities in terms of their speed in completing tasks and delivering features. An agile approach
to estimating addresses those issues in a variety of ways as described below.

Relative Size Instead of Absolute Duration

Agile approaches to estimating resolve the issues mentioned above by estimating features in terms of
relative size instead of absolute duration. By measuring the features in terms of size, you eliminate the
reliance on knowing who will be working on a feature when estimating it. For example, when people
describe how big a house is, they usually talk in terms of square feet, not the time it takes to build it. A
house of a certain square footage could take a wide range of times to build depending on the team
working on it and the environmental conditions. The same thing is true of features, except features tend to
be less concrete (figuratively and literally) than houses. Square foot estimates for houses usually are
determined following the creation of a blueprint. With features, the need for an estimate comes long
before the equivalent of blueprints could be practically developed, so the teams’ understanding is much
less developed.
That’s where relative sizing comes into play. By expressing the size of one feature in comparison to
another feature, the team is able to quickly determine size to a satisfactory level of detail and move on to
the next feature. Think of t-shirt sizing. You do not need to know the exact neck, chest, and sleeve
measurements of a shirt to know whether it will fit if you know that a Large generally fits you well. By not
having to be so exact with your sizing, you avoid the temptation to spend more time than necessary trying
to come up with estimates.
To reinforce the relative nature of size estimates, and because features are often described in agile
projects via the use of User Stories (see our “Agile Technique Brief – Requirements Cards”), the unit of
measure for the size of a feature is the story point. Because story points represent relative measures,
they could be called anything—feature points, gummi bears, thingies, or ULUM (unit-less units of
measure). The absolute value of a feature’s story points is not as important as its size relative to other
features, so a feature that is 2 story points is twice as big as a feature that is only 1 story point. When
estimating using story points it is helpful to use a scale that will quickly show clear relative differences in
sizes. One scale that is commonly used is a modified Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40,
100.

Velocity – Getting from Size to Duration

So how do we get from the size of a feature to knowing how long a project will take? Agile methods use
the term velocity—or the number of story points that the team can complete in an iteration, along with
iterations of consistent length, to determine the overall duration. Here’s how it works:

©Copyright 2008 Emprend Inc./ProjectConnections.com. Permission for Members’ use on their projects. Page 2
See our Terms of Service for information on PMO/group use and corporate subscriptions.
ProjectConnections.com Guideline Agile Technique Brief – Estimating

 Total number of story points in feature list = 100

 Velocity = 20 story points/iteration
 Iteration length = 4 weeks
After some fairly straightforward math, you can see that the team should be able to complete the current
feature list in 5 iterations, or 20 weeks.
The use of velocity overcomes the problem of different people on the team being able to complete tasks
in different time frames, as well as not knowing who will do the work to realize the feature. Velocity is
determined based on the actual experience of the team, so it also removes some of the uncertainty
involved in estimates by basing a measure on “yesterday’s weather,” or the team’s performance in
previous iterations.
How do you determine velocity if the team has not worked together before? This is a common issue at the
beginning of the project, when the team has estimated the feature backlog and has to estimate when they
can deliver the finished project. One approach I have seen work is to estimate an initial velocity based on
the features they feel they can commit to in the first iteration. (See the Agile Technique Brief – Planning
for a description of commitment based planning.) This velocity estimate can be used to provide a rough
guess of how many iterations will be required to finish the feature list. This estimated completion date
should be delivered with the large caveat that the team will most likely need to revise their velocity after a
couple of iterations so they can use a velocity number based on actual experience rather than guesswork.
The use of velocity also assumes that iterations are of a constant length. If the team at some point along
the line chooses to change their iteration length, they most likely will need to change their velocity as well,
since the time period over which they are trying to realize features is changing.
Note that the definition of velocity is the number of story points that the team can complete in an iteration;
but the team cannot get partial credit. They have to actually produce a running, tested feature in order to
gain credit for all the story points associated with that feature. If they get a feature 90% complete by the
end of the iteration, none of the story points for that particular feature are added into the velocity
calculation.

Estimates Belong to the Team

As we have mentioned before, it takes different people a different amount of time to complete a particular
feature. Those differences also apply to their impression of the size of particular features, so it is helpful to
find an estimating technique that incorporates input from multiple team members. If you just have one
person estimating a particular feature, their personal filters, experience, and expectations of time required
will heavily factor into their resulting estimate. In order to get a more realistic estimate of the feature, it is
best to have the entire team involved in the estimation process so that as many information points as
possible can be incorporated into the estimate. The technique described in the next section is a good
approach for quickly gathering input from multiple members of the team.

A HELPFUL TECHNIQUE FOR ESTIMATING – PLANNING POKER

Agile teams use a variety of methods to establish relative size estimates via input from multiple team
members. One of the more popular, Planning Poker, is described below.

How to Play Planning Poker

1. Gather the team members that will be developing the feature together, along with someone
knowledgeable about the business aspects of the features that are being estimated.
2. Prepare a deck of cards for each member that includes a card with each of the following numbers
in the Fibonacci sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100. You can create decks using index
cards, or there are a couple of places where you can purchase specially made decks, such as at
Mountain Goat Software (http://www.mountaingoatsoftware.com/products/cards).
3. Pick a feature from the list and briefly discuss it. The key here is briefly—you don’t want to spend
a great deal of time dissecting the feature; remember the law of diminishing returns on estimating
—more work will not provide a corresponding increase in accuracy.

©Copyright 2008 Emprend Inc./ProjectConnections.com. Permission for Members’ use on their projects. Page 3
See our Terms of Service for information on PMO/group use and corporate subscriptions.
ProjectConnections.com Guideline Agile Technique Brief – Estimating

4. Once everyone feels they have a relatively clear idea of what the feature is all about, everyone
picks a card from their hand reflecting their thought on the feature size. The team members
should keep the card to themselves so they don’t overly influence others’ choices.
5. When everyone has a card picked, everyone flips their card over at the same time.
6. If there are differences in the cards, the people with the outliers—the highest and lowest values—
are asked to indicate why they chose that particular number. The conversation continues, again
briefly until people think they have decided on a new estimate.
7. Everyone picks another card, waiting for everyone to pick before showing their card.
8. Repeat steps 5–7 until a consensus is reached. That consensus is the number of story points
assigned to the feature.
9. Repeat steps 3–8 for each feature on the feature list without an estimate.

Why Planning Poker Works

Planning Poker brings together multiple people to discuss and jointly determine an estimate of feature
size. The effect of this is that different viewpoints and opinions are raised and incorporated into the overall
estimating process, providing everyone involved with more information than if they had estimated by
themselves. It doesn’t hurt that it is more fun that typical estimating approaches, so it eases the burden of
going through a long features list to create estimates, and will most likely keep the team members
engaged throughout the entire activity.
Other estimating techniques used by agile teams share those characteristics with project planning, but try
to simplify even further by removing the need for a deck of cards, or for trying to explain the Fibonacci
sequence. Some teams find these methods satisfactory, and others find them inadequate for sufficiently
differentiating between features of similar size. The best approach for a particular project comes down to
the characteristics of the project and the project team.

ESTIMATING NUANCES
As with most agile techniques, Planning Poker is rather straightforward, but there are nuances that can
make the technique even more useful in the overall project.

Re-Estimating
Although the use of velocity to convert from feature size to an idea of time helps to reduce a great deal of
uncertainty involved in agile estimating, there will be times where the team realizes that the feature took a
much longer or shorter time to realize than they original expected. The trick when this happens is to
decide when it calls for a re-estimation of the feature’s size, and when the difference in expectations was
due to other factors outside of the feature itself.
Generally speaking, the team should only re-estimate a feature or set of features when it becomes
obvious that the relative size of a feature or features has changed. This occurs when a team gains a
better understanding of the complexity of a feature that changes its size in relation to other features. You
may find when making this type of re-estimation that multiple features need to be re-estimated—those
features that all share the same characteristic that proved to be more difficult, or easier, than originally
assumed.
You don’t want to re-estimate if you find that all features are taking more or less time to realize than you
originally thought. In this case, the team’s velocity is different than you originally anticipated, so you need
to let a change in velocity account for this error.

There’s Value in the Outliers

One aspect of Planning Poker that does not gain as much recognition as it should for the value it provides
is the discussion of outliers when the team is trying to converge on an estimate. During this discussion,
team members will often identify pieces of information influencing their estimate that are very useful when
developing the features. These pieces of information could be risks inherent in the feature, assumptions
that are being made to reach a specific estimate, or constraints on the team’s ability to deliver that
particular feature. I have found it very helpful to record those key pieces of information along with the
feature, for future reference.

©Copyright 2008 Emprend Inc./ProjectConnections.com. Permission for Members’ use on their projects. Page 4
See our Terms of Service for information on PMO/group use and corporate subscriptions.
ProjectConnections.com Guideline Agile Technique Brief – Estimating

Using Planning Poker for Benefits

The discussion in this technique brief has focused on using Planning Poker to estimate the size of
features, primarily from a cost perspective. The same approach can be used to establish relative
estimates of the benefits delivered by various features. The approach would work the same way, but the
people doing the estimating are the members of the team that have insight into the business side of the
project—the users, customers, product owner, and stakeholders on the team, and the measure they are
estimating is the amount of benefit the feature provides. Estimating relative benefit in this fashion is
helpful in cases where the team wants to determine the relative value delivered by features for
prioritization purposes, but does not have a way to clearly define a dollar benefit contributed by each
feature.

SUMMARY
Agile estimating provides a way for teams to effectively establish estimates of the size and benefit of the
features included in a project. Planning Poker is a technique that teams can use to gather the thoughts of
the entire team and quickly reach an estimate based on the most relevant information available at the
time. This approach estimates the size of features and allows the team to determine and refine its velocity
based on actual experience to determine how long a project will actually take and determine when certain
features can actually be delivered.

©Copyright 2008 Emprend Inc./ProjectConnections.com. Permission for Members’ use on their projects. Page 5
See our Terms of Service for information on PMO/group use and corporate subscriptions.