agile projects | rapid estimation | techniques | tips

43
Rapid Estimation for Agile and Conventional Projects cPrime, Inc. 4100 E. Third Ave, Suite 205 Foster City, CA 94404 650-931-1651 www.cprime.com The leader in training and consulting for project management and agile development

Upload: cprime-project-management-agile-consulting-staffing-training

Post on 06-May-2015

5.693 views

Category:

Art & Photos


0 download

TRANSCRIPT

Page 1: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 2: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 3: Agile Projects | Rapid Estimation | Techniques | Tips

OutlineOutline

1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method

Page 4: Agile Projects | Rapid Estimation | Techniques | Tips

OutlineOutline

1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method

Page 5: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 6: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 7: Agile Projects | Rapid Estimation | Techniques | Tips

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?

Page 8: Agile Projects | Rapid Estimation | Techniques | Tips

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”

Page 9: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 10: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 11: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 12: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 13: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 14: Agile Projects | Rapid Estimation | Techniques | Tips

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!

Page 15: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 16: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 17: Agile Projects | Rapid Estimation | Techniques | Tips

OutlineOutline

1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method

Page 18: Agile Projects | Rapid Estimation | Techniques | Tips

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®”

Page 19: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 20: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 21: Agile Projects | Rapid Estimation | Techniques | Tips

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?

Page 22: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 23: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 24: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 25: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 26: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 27: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 28: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 29: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 30: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 31: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 32: Agile Projects | Rapid Estimation | Techniques | Tips

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.

Page 33: Agile Projects | Rapid Estimation | Techniques | Tips

OutlineOutline

1. The Relationship between Uncertainty and Estimation2. Techniques for Expert Estimation3. Example of the “Planning Poker®” method

Page 34: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 35: Agile Projects | Rapid Estimation | Techniques | Tips

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.

Page 36: Agile Projects | Rapid Estimation | Techniques | Tips

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.

Page 37: Agile Projects | Rapid Estimation | Techniques | Tips

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.”

Page 38: Agile Projects | Rapid Estimation | Techniques | Tips

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.

Page 39: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 40: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 41: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 42: Agile Projects | Rapid Estimation | Techniques | Tips

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

Page 43: Agile Projects | Rapid Estimation | Techniques | Tips

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