agile projects | rapid estimation | techniques | tips
Upload: cprime-project-management-agile-consulting-staffing-training
Post on 06-May-2015
5.696 views
TRANSCRIPT
Rapid Estimation for Agile and Conventional ProjectsRapid Estimation for Agile and Conventional Projects
cPrime, Inc.4100 E. Third Ave, Suite 205
Foster City, CA 94404650-931-1651
www.cprime.com
The leader in training and consulting for project management and agile development
OverviewOverview
• The purpose of this course is to teach you how to provide good estimates for project tasks, quickly, using some best practices in “expert estimation”
• You will also learn how uncertainty limits our ability to make accurate estimates, and how we can reduce the effects of uncertainty to produce better estimates
OutlineOutline
1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method
OutlineOutline
1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method
Estimation is Necessary for any Planning ProcessEstimation is Necessary for any Planning Process
• We can estimate anything that can be quantified• Time• Resources• Materials
• Common examples:• Waterfall projects estimate effort in order to predict the
schedule and cost of a project• Agile projects estimate effort in order to predict scope that can
be implemented for a fixed schedule and known resources• We may estimate effort required for
• Scope: A set of features, or requirements• Task: An activities performed to accomplish necessary work
• For convenience, we will use “task” throughout
We Create Schedules Based on Task EstimatesWe Create Schedules Based on Task Estimates
• A schedule contains a set of tasks• Example: Remodel a House
Remodel Kitchen Remodel Bedroom Remodel Living Room
• Each task takes time. To plan a schedule, we need to know • Effort required per task• Resources available per task• The logical sequencing of tasks
• We will focus on effort estimates in this course
Estimating a Single Task is ChallengingEstimating a Single Task is Challenging
• Uncertainties arise in many ways. Some examples:• Incomplete understanding of scope
• What features are assumed but not understood?• Incomplete understanding of work per scope
• What bits of work did we omit?• Imperfect understanding of how much work is required
even when the task is well understood• Variance due to skill level, materials issues, etc.
• Inability to forecast the unexpected• What if the paint is out of stock?
Uncertainty Decreases as Scope DecreasesUncertainty Decreases as Scope Decreases
• Big tasks have more uncertainty than small tasks• We can reduce uncertainty by breaking big tasks into
smaller tasks, and estimating smaller tasks.• “Remodel Bedroom” becomes
• Remove old carpet• Paint room• Cut new carpet to fit• Install new carpet
• If we study and estimate each smaller task, we can get a better estimate for the larger task to “Remodel Bedroom”
So why not Make Tasks very Small?So why not Make Tasks very Small?
• Isn’t it better to make lots of small tasks?• Won’t we get much better estimates this way?
• Only to a point• Two factors limit the usefulness of breaking work into a
large number of small tasks• First, estimating many small tasks takes too long• Second, relative error decreases with scope only so far. There is
little benefit to breaking a task with a 20% relative error into five smaller tasks which also have 20% errors.
• We’ll address the issue of “granularity” next
We Need to Pick the Right GranularityWe Need to Pick the Right Granularity
• “Granularity” means size, or level of detail.• Choose a granularity that is practical for estimation
• Too big: We can’t estimate with any reliability• Too small: Estimation of all items takes too long to be practical
• Choose granularity appropriate to the project’s stage• Initial planning needs reasonable estimates quickly
Select “coarse-grained“ tasks that are small enough to estimate with moderate confidence, large enough to work through all of them in reasonable time
• Detailed planning may be required at a later stage Break coarse-grained subsets into fine-grained tasks Estimate fine-grained tasks Aggregate to improve coarse-grained estimates Adjust plans based on results
Estimation Errors Behave in Surprising WaysEstimation Errors Behave in Surprising Ways
• Each task estimate has some uncertainty• Tasks are more likely to take longer than estimated, than
shorter• First reason is logistical: We omitted some work in our
estimation• Second reason is mathematical: There is more room for work to
grow (be over estimate) than shrink (be under estimate)• Example: Suppose we estimate “Paint Bedroom” at 3
person-days• Work can never be under the estimate by more than 3 days• Work can easily be over the estimate by more than 3 days
• This observation has important implications for scheduling
Think of Uncertainties as Factors, not IncrementsThink of Uncertainties as Factors, not Increments
• We cannot say a task should complete in “X plus or minus Y days,” and have this work for any X and Y
• We can say that a task should complete in the range described by an uncertainty factor F, between “X/F” and “X × F,” and have this work for any F• Example: “Paint Bedroom” is estimated at 3 days, with an
uncertainty factor of 2• Most likely case is 3 days• Best case is 1.5 days (under by 1.5 days)• Worst case is 6 days (over by 3 days)• More sophisticated models rely on lognormal probability
distributions and Monte Carlo methods, but this simple model shows the right kind of behavior
Errors Add Up in Surprising WaysErrors Add Up in Surprising Ways
• Suppose 10 tasks have the same estimate of 10 days• The sum is 100 days. Call this the “naïve schedule.”
• Now say each task has an uncertainty factor F = 2• The worst case is when every task is slow by 2:
• This means the project takes 200 days• Ratio of Actual to Expected = F• Not good, but not very likely
• A more typical case will have some tasks under, some over• Assume half are faster by 2, at 5 days (under by 5)• Assume half are slower by 2, at 20 days (over by 15)
• Total time is 5 x 5 + 5 x 20 = 125 days• Still significantly over the naïve schedule of 100 days
Errors Add Up in Surprising WaysErrors Add Up in Surprising Ways
• The factor-of-two uncertainty for tasks added 25% to the actual time, compared to estimate• Ratio of Actual to Expected = (F + 1/F) / 2
• Conclusion: Actual schedule will always exceed sum of most-likely task durations if uncertainty exists• We see this in a simple scenario• Expect real-life cases to be more complex, but not better• Remember, the worst case has no upper bound!
How do we Deal with Uncertainty?How do we Deal with Uncertainty?
• We cannot eliminate uncertainty, only cope with it• We cope by reducing it to a practical minimum• We design our process to handle uncertainty gracefully
• How we deal with uncertainty depends on the process• We add buffers to waterfall schedules to preserve scope• We adjust scope for agile projects to preserve schedule
What Lessons should we Learn about Uncertainty?What Lessons should we Learn about Uncertainty?
• Estimation is prone to uncertainty• Smaller things are easier to estimate than bigger things• Breaking work into many small tasks helps, but only to a point
• We may not have the time to estimate many small tasks• If breaking a task into smaller tasks doesn’t decrease the uncertainty
factor, there is no benefit to the additional breakdown• Uncertainties for small tasks do not cancel. They accumulate, which
limits the value of breaking large tasks down.• The process we are using must take uncertainty into account,
and not assume that the future can be predicted accurately
OutlineOutline
1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method
Practical Guidance for EstimationPractical Guidance for Estimation
• We will now provide some practical guidance for effective estimation
• We will cover• Standard tools and techniques for estimation, from the
PMBOK®• The Delphi and Wideband Delphi methods• A modern, and fast, version of the Wideband Delphi method
known as “Planning Poker®”
When we Estimate, we Rely on Expertise and ExperienceWhen we Estimate, we Rely on Expertise and Experience
• We rely on three basic (and overlapping) tools to produce estimates• These are described in the PMBOK®• All rely on past experience
• The three tools are1. Expert Judgment2. Analogous Estimating3. Parametric Estimating
The Three Tools for EstimationThe Three Tools for Estimation
1. Expert Judgment• Experts with experience in the field produce estimates based on
their knowledge and history of past projects
2. Analogous Estimating• Estimators identify specific analogs to the work, in past
projects, and estimate based on known effort for those analogs• Sometimes called “Affinity Estimating,” when used to estimate
many tasks quickly by comparison to known tasks
3. Parametric Modeling• Estimators build quantitative models that predict effort, based
on historical data• Useful when inputs are quantitative: Square feet of carpet,
linear miles of road, etc.• Often not possible: Software development, unique projects, etc
How do we Use Time wisely when Estimating?How do we Use Time wisely when Estimating?
• Estimation is time-consuming—Be aware of the cost!• Trade off between cost and benefits of estimation efforts
• Understand that accuracy improves with effort only to a point• More effort doesn’t always
yield better results• Avoid “analysis paralysis!”
• Good enough, now, beats best possible, later
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 51
1.21.41.61.8
22.22.42.62.8
3
Time Spent on EstimationU
ncer
tain
ty F
acto
r
• We want to get reasonable estimates quickly• How do we get good practical results from a set of experts?• How do we get those results quickly?
The Delphi MethodsThe Delphi Methods
• The Rand Corporation developed the original Delphi method for expert estimation in the 1940s• It is an anonymous, group-based, iterative forecasting method• Estimators answer questionnaires in Round 1• Estimators review anonymous answers, revise their answers• Process repeats until stopping criterion is met
Number of rounds Consensus or stability of results
• In the 1970s, Barry Boehm and John Farqhuar designed a variant that makes greater use of communication and collaboration, and named it Wideband Delphi• Like Delphi, but done in group meetings, with discussion• Holds one meeting per round, until time to stop
Delphi Methods Tap “Collective Wisdom”Delphi Methods Tap “Collective Wisdom”
• Important characteristics of this approach include• Reliance on a Team of experts, not individuals, for estimation• Avoidance of expert bias (“anchoring”)• Focus on variance to improve estimates
Reliance on a TeamReliance on a Team
• We draw on a team of estimators, not a single person, for each estimate
• The Team has more knowledge than any individual• Tapping the Team’s “collective wisdom” yields greater
understanding and better estimates than one person can provide
• Best case: Estimators are the people who will also do the work• Do this whenever possible
Avoidance of Expert BiasAvoidance of Expert Bias
• “Anchoring” refers to the tendency of estimators to defer to the judgment of someone they believe to be an expert• Team members often have different degrees of expertise in
different areas, and are aware of this• If the “expert” gives his opinion first, other estimators
may say nothing, or simply agree• We aren’t tapping collective wisdom when this happens• We’re just getting one estimate, several times
• We reduce the problem of anchoring by gathering all responses anonymously before revealing the results
Focus on Variance to Improve EstimatesFocus on Variance to Improve Estimates
• Different estimators have different backgrounds, different areas of expertise, and consider different factors for each item estimated• These differences usually lead to a range of estimates
• Discussion about why the estimates differ produces insights into assumptions and issues• These insights, once shared, usually produce convergence of
estimates over time, to more reliable values• Failure to converge indicates unresolved issues that require
further study
The Planning Poker® Method Taps Wisdom QuicklyThe Planning Poker® Method Taps Wisdom Quickly
• This version of Wideband Delphi is very quick• It is popular for Agile projects, but useful for any kind
• Planning Poker® is a Team-based iterative voting process that converges to an estimate• Purpose is to find “good enough” estimate quickly, not best
possible estimate• It uses Planning Poker® cards (or equivalent) to show
individual estimates• Cards are not anonymous, but do prevent anchoring
PLANNING POKER® is a reg. trademark of Mountain Goat Software, LLC
Estimates are Restricted to a Pre-defined SetEstimates are Restricted to a Pre-defined Set
• Only allowed values are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? • Initial integer values are from the Fibonacci sequence• “?” means “I don’t know enough to estimate”• “∞”(infinity) means “It’s so big there’s no point in estimating it”
• Spacing increases with size because absolute uncertainty increases with size• We restrict allowed values to discourage unproductive debate
(“Is it 13 or 14?” Who cares?)• Granularity may be too large if estimates are at 20 or
above• Consider breaking the item into smaller pieces
The specific sequence of values is © 2007 by Mountain Goat Software, LLC
Estimates have UnitsEstimates have Units
• Everything that we estimate has some kind of unit• Material goods have weight in pounds, volume in liters,
length in miles, and so forth• Tasks have effort-based units (e.g., person-days)• Requirements (“Stories,” in agile terms) do not have
unique units. Possibilities include• Person-days (for total implementation effort)• Function points (for complexity of software)• Story points (for complexity of agile Stories)• Units should be chosen to be what works best for the
organization, especially the estimators and implementers
Three Roles Participate in the Estimation ProcessThree Roles Participate in the Estimation Process
• Facilitator• Often provides quality control for specifications to be estimated• Runs the estimation meeting, enforces schedule, and keeps the
Team focused and moving• Keeps discussions short and productive in meetings• Re-focuses or terminates non-productive discussions
• Requirements Owner• Authors and/or is the authority on the items to be estimated• Answers questions to clarify requirements
• Team Members (Estimators)• Provide estimates• Discuss issues and ask questions to improve their
understanding
Estimation Meetings have Pre-requisitesEstimation Meetings have Pre-requisites
• Time, date, and duration of meeting are set• Decide duration (“Time box”) in advance (e.g., one hour), and
stick to it• Items to estimate have been identified• Team members have reviewed and discussed all items
prior to the meeting• Time is allocated to review the items in advance• They investigate items, as appropriate• They bring open issues and questions about requirements and
implementation to the meeting
How to Conduct a Planning-Poker® Estimation MeetingHow to Conduct a Planning-Poker® Estimation Meeting
1. Facilitator reads item to be estimated, moderates brief discussion to clarify details, and calls for estimates.
2. Each Estimator places estimate face down, hiding the value.
3. Facilitator calls for vote, and all Estimators turn over cards at the same time.
4. If all cards agree, their value is recorded as the estimate.
5. Otherwise, Facilitator asks high and low Estimators to explain their reasoning, and moderates brief discussion to clarify issues.
6. Repeat 2-5 until estimates converge.
OutlineOutline
1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method
Example Walk-Through for Planning Poker®Example Walk-Through for Planning Poker®
• We will use this technique to estimate, “How many chickens are required for a dinner party for twenty people?”
• The Facilitator is Ralph Runner• The Requirements Owner is Debbie Diner• The Estimation Team has three members
• Bob Cook• Sue Chef• Ted Baker
• We begin with the first round of voting, and follow the process through to a final estimate
Round 1 VoteRound 1 Vote
• Ralph reads the description, and the Team has a short discussion to clarify a few issues.
• Ralph counts down: “5, 4, 3, 2, 1, Vote!”• Bob has 20• Sue has 13• Ted has 5
• Ralph asks high and low voters for their reasoning.• Bob says, “I can eat a whole chicken, so we need one per
person.”• Ted says, “I thought one chicken would feed three people, and
we’d have some vegetarians.”• Sue has nothing to add.
Discussion after Round 1Discussion after Round 1
• Ralph asks Patty to respond.• Patty says, “Oh, I wrote ‘chicken,’ but I was thinking ‘squab,’ so
use squab instead of chicken. And we’ll probably have one-third vegetarians, who will get mushroom risotto.”
• Sue asks, “What’s a squab?”• Patty says, “It’s what you call a pigeon when you cook it.”• Ted says he doesn’t want to eat a pigeon. He starts to tell a long
joke about pigeons, but Ralph says, “Hey, folks, let’s stay focused!”
• Bob asks, “How many squabs does one person eat?”• Patty says, “It’s one squab per person.”
• There are no more questions, so Ralph calls for a new vote.
Round 2Round 2
• Ralph counts down: “5, 4, 3, 2, 1, Vote!”• Bob has 5• Sue has 13• Ted has 20
• Ralph asks high and low voters for their reasoning.• Bob says, “Ted was right last time. Most people won’t eat
pigeons. They’ll have risotto.”• Ted says, “Bob was right last time. We need 20 to cover late-
comers and spoilage.”• Sue adds, “Thirteen is just right for one-third vegetarians.”
Discussion after Round 2Discussion after Round 2
• Ralph asks Patty to respond.• Patty says, “I know who will be coming, and the non-
vegetarians will love the squab. I don’t want to buy extras, because the squabs are very expensive. Also, the risotto is very good, we’ll have plenty, and I’ve told everyone that it’s first-come, first-served.”
• Sue asks, “What kind of wine do you serve with squab? White or red?”• When the wine discussion threatens to drag on, Ralph reminds
everyone that they have a lot of estimation to do in a short time, and need to move quickly.
• There are no more questions, so Ralph calls for a new vote.
Round 3Round 3
• Ralph counts down: “5, 4, 3, 2, 1, Vote!”• Bob has 13• Sue has 13• Ted has 13
• Ralph says, “Great! Thirteen it is!”• He records the result, and the group moves on to the
next item to estimate
What we Learn from this ExampleWhat we Learn from this Example
• Written requirements that make sense to the writer often mean something else to the reader• Is it a chicken, or a squab?
• Implicit assumptions are revealed during discussion of high-low results. Note that none of these were mentioned in the requirements:• One squab feeds one person• A third of the guests are vegetarians• Squab is expensive, so buy no more than necessary• Squab lovers who don’t get a squab will be content risotto• Some may hate squab, but only squab-lovers are attending
• Distractions beckon, but time is limited, so the facilitator needs to keep the group focused
Try it!Try it!
• Use the Planning Poker® method for your next estimation session• Try it, and compare to your existing process• Did this take less time, or more?• Is confidence in the results higher? Lower? The same?
• Some Predictions• This method may seem awkward at first• It may feel like a game, and not serious• Everyone will quickly discover that the resulting discussions are
more enlightening than before• The process will move faster and provide results of higher
confidence• No one will want to go back to the old way
ConclusionConclusion
• Estimation cannot be made perfect• Smaller items are easier to estimate than larger items• Taking more time does not always mean that estimates are
more accurate• Estimation errors do not cancel, but accumulate• The process must take uncertainty into account• Planning Poker® provides “good enough” estimates quickly
• It taps collective wisdom, and avoids expert bias through voting• Discussion of high-low results forces assumptions, issues to surface• This method improves understanding of requirements• It produces useful results quickly
ClosingClosing
• cPrime provides Estimation card decks for use in estimation (four sets per box) or Individually priced at $4.50/deck.
• Please visit our free online elearning Rapid Estimation for Agile & Conventional Projects at:
• http://cprime.eleapcourses.com/courses/view?id=11059