Agile Planning & Estimation
Why Planning Fails
• A critical problem with traditional approaches to planning is that they
focus on the completion of activities rather than on the delivery of
features.
• A traditionally managed project’s Gantt chart or work breakdown
structure identifies the activities that will be performed.
• This becomes how we measure the progress of the team.
• A first problem with activity-based planning is that customers get no
value from the completion of activities.
• Features are the unit of customer value.
• Planning should, therefore, be at the level of features, not activities.
Why Planning Fails
• A second problem occurs after a traditional schedule has been
created and is being reviewed.
• When we review a schedule showing activities we do so looking for
forgotten activities rather than for missing features
• Further problems occur because activity-based plans often lead to
projects that overrun their schedules.
• When faced with overruning a schedule some teams attempt to save
time by inappropriately reducing quality.
Why Planning Fails
Some of the reasons why activity-based planning leads to schedule
overruns include:
• Activities don’t finish early
• Lateness is passed down the schedule
• Activities are not independent
Features Are Not Developed By Priority
• Another reason why traditional planning fails to consistently lead to
high-value products is because the work described by the plan is not
prioritized by the value to the users and customer.
• Many traditional plans are created with the assumption that all
identified activities will be completed.
• This means that work is typically prioritized and sequenced for the
convenience of the development team
• Traditional thinking says that if all work will be completed then project customers have no preference about the sequence in which that
work is done. This leads to the development team working on features in what appears to the customer as a relatively haphazard order.
Then, with the end of the project approaching, the team scrambles to meet the schedule by dropping features. Since there was no attempt
to work on features in a priority order, some of the features dropped are of greater value than those that are delivered.
We Ignore Uncertainty
• A fourth shortcoming with traditional approaches to planning is the
failure to acknowledge uncertainty.
• We ignore uncertainty about the product and assume that the initial
requirements analysis led to a complete and perfect specification of
the product.
• We assume that users will not change their minds, refine their
opinions, or come up with new needs during the period covered by
the plan.
• Similarly, we ignore uncertainty about how we will build the product
and pretend we can assign precise estimates (“2 weeks”) to imprecise
work.
Identify Each Activity
• We cannot hope to identify every activity that will be needed in the
course of a project.
• Yet we often fail to acknowledge this in the plans we create.
Uncertainty is Important
• Even with all this uncertainty, schedules are often expressed as a
single, unqualified date: “We will ship on June 30,” for example.
• During the earliest part of a project, we are the most uncertain. The
estimates we give should reflect our uncertainty.
• One way of doing this is by expressing the end date as a range. “We’ll
ship sometime between June and August,” for example.
• As the project progresses and as uncertainty and risk are removed
from the project, estimates can be refined and made more precise.
Summary
• After looking through this list of problems with traditional approaches
to planning, it’s no wonder that so many projects are disappointing.
• Activity-based planning distracts our attention from features, which
are the true unit of customer value.
• A variety of problems then lead to the likelihood of delivering late
against a schedule derived from an activity-based plan.
• With good intentions, project team members view multitasking as a
possible cure but are eventually forced even further behind schedule
because of the hidden costs of multitasking.
Planning Onion
• Most agile teams are only concerned with the three innermost
levels of the planning onion. Release planning considers the
user stories or themes that will be developed for a new release
of a product or system. The goal of release planning is to
determine an appropriate answer to the questions of scope,
schedule, and resources for a project.
• At the next level is iteration planning, which is conducted at the
start of each iteration. Based on the work accomplished in the
just-finished iteration, the product owner identifies high priority
work the team should address in the new iteration.
• Finally, there is daily planning. Most agile teams use some form
of daily standup meeting to coordinate work and synchronize
daily efforts
Estimating Size with Story Points
• Story points are a unit of measure for expressing the overall size of a
user story, feature, or other piece of work.
Velocity
• In order to understand how estimating in unitless story points can
possibly work, it is necessary to introduce a new concept: velocity.
Velocity is a measure of a team’s rate of progress.
• It is calculated by summing the number of story points assigned to
each user story that the team completed during the iteration. If the
team completed three stories each estimated at five story points,
then their velocity would be fifteen. If the team completed two five-
point stories their velocity would be ten.
Velocity Corrects Estimation Errors
• Fortunately, as a team begins making progress through the user stories of a
project, their velocity becomes apparent over the first few iterations.
• The beauty of a points-based approach to estimating is that planning errors
are self-correcting because of the application of velocity.
• For example, suppose a team estimates a project to include 200 points of
work.
• They initially believe they will be able to complete 25 points per iteration,
which means they will finish in eight iterations.
• However, once the project begins their observed velocity is only 20.
• Without re-estimating any work, they will have correctly identified that the
project will take 10 iterations rather than 8.
Deriving An Estimate
The three most common techniques for estimating are:
• Expert opinion
• Analogy
• Disaggregation
• Each of these techniques may be used on its own but they should be
combined for best results
Planning Poker
• At the start of planning poker, each estimator is given a deck of cards. Each card has written on it one of the valid estimates. Each
estimator may, for example, be given a deck of cards that read 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
• The cards should be prepared prior to the planning poker meeting and the numbers should be large enough to see across a table.
Cards can be saved and used for the next planning poker session.
• After their questions are answered, each estimator privately selects a card representing his or her estimate. Cards are not shown
until each estimator has selected.
• At that time, all cards are simultaneously turned over and shown so that all participants can see each estimate.
• It is very likely at this point that the estimates will differ significantly.
• This is a good news. If estimates differ, the high and low estimators explain their estimates.
• It’s important that this does not come across as attacking those estimators.
• Instead, you want to learn what they were thinking about.
• As an example, the high estimator may say, “Well, to test this story we need to create a mock database object. That might take us a
day. Also, I’m not sure if our standard compression algorithm will work and we may need to write one that is more memory
efficient.”
• The low estimator may respond with, “I was thinking we’d store that information in an XML file—that would be easier than a
database for us. Also, I didn’t think about having more data—maybe that will be a problem.”
Why Planning Poker Works
• It’s worth spending a moment on some of the reasons why it works so well.
• First, planning poker brings together multiple expert opinions to do the
estimating. Because these experts form a cross-functional team from all
disciplines on a software project they are better suited to the estimation
task than anyone else.
• Second, a lively dialogue ensues during planning poker and estimators are
called upon by them to justify their estimates. This has been found to
improve the accuracy of the estimate, especially on items with large
amounts of uncertainty.
• Third, studies have shown that averaging individual estimates leads to
better results.
