# agile 2010 estimation games

Post on 18-Dec-2014

11.441 views

Embed Size (px)

DESCRIPTION

"Estimation Games" presentation at Agile 2010 by Pascal Van CauwenbergheTRANSCRIPT

Les Jeux de lEstimation

Estimation GamesPascal Van CauwenbergheNayima1

His Blog: blog.nayima.beNAYIMAWe make play work

Consultant. Project Manager. Games Maker.Portia and Pascal introduce themselves by sharing a bit about their background.2Estimate the height of the highest place in BelgiumIn meters or feet

3# 1: Always give a range Never give them a number

# 1: Numbers are for factsRanges are for estimatesI estimate Between 650 and 700mOr Between 0 et 4000mI know its 694m (2092 ft)Estimation exerciseOne result per tableChoose one of three collaboration techniquesIf you cant choose, let the Post-It choose for youRED Post-ItEstimate as a group, come to consensusGREEN Post-ItDivide the work among youYELLOW Post-itFirst estimate individuallyThen combine the estimates as a group

Estimation exercise 1Surface temperature of the sun (in degrees C)Latitude of Shanghai (in degrees)Surface area of Asia (in km2)Birth date of Alexander The Great (year)Dollars in circulation in the US in 2004 (in $)Volume of the Great American lakes (in litres)Global revenue of Titanic (in $)Length of the Pacific coastline (Ca, Or, Wa) (in km)Number of books published in USA, 1776 to 2004Weight of the largest whale (in tonnes)

This quiz is from Software Estimation by Steve McConnell (Microsoft Press)(C) 2006 Steve McConnell. Used with permissionTimes up!10 min7An estimation jokeAn engineer, a mathematician and an accountant are sitting at the barThe barman asks: Whats 68+73 ?Engineer: 141Mathematician: 68 + 73 = 73 + 68Accountant: Usually its 141, but what do you want to do with the number?Why estimate?What is the expected error margin?#2 Always ask what the estimate will be used forWhat have you committed to?Based on what information?Cone of uncertainty400%25%Watch out: this is the best possible case!#3 Estimation != CommitmentGetting an estimate wrong doesnt hurt13Estimating money (individually)How much money is there in this room?Counting only cash dollarsRe-do the estimation, but this timeCount the number of people: NCount how much money you have on you: MEstimate how much money the average person holds, based on M: M1-M2Compute the amount: N * M1 N * M2What can you count?Number of stakeholdersNumber of goalsNumber of eventsNumber of business processesNumber of high-level user storiesNumber of detailed user storiesNumber of screens....#4 First try to measure, count and computeEstimate only when necessaryEstimating money (in group)Estimate as one group per tableCombine individual estimations into a group estimatePlanning Poker style: announce estimates, low/high estimators explain, againTake min and max for a range that covers all estimatesTake average of min and max for a range that covers much of the estimates...Aggregate estimatesIndependent estimatorsFor example, by playing Planning PokerIndependent estimation methodsFor example, by combining:Comparison with previous projectExpert estimationCounting high level stories#5 Aggregate independent estimatesWisdom of the CrowdsThe law of large numbers (or: statistics is on our side, for once)If we estimate with an error of x%The estimate of each scope item will have an error of x%But...Some items will be over-estimated, others under-estimated (maybe....)=> The error on the total estimate is < x%The law of 15Have about 15-20 same-sized elements at each planning horizonProgram, Project, Release, IterationEnough for the law of large numbers to have an effectBut not too many, easy to manage#6 Use the law of large numbersDecompose Just enough, just in timeSprint CommitmentSprint BurndownRelease BurndownVelocity Chart

Re-estimation and calibrationFirst estimation:Relative estimate (1 point, 2 points, ...)Calibrate with previous projects (16-22 points per iteration)Re-estimate during the projectCheck if relative sizes are okRe-calibrate with measured velocity

Ensure consistency of relative estimatesBuild in internal consistencyDemonstrated in XP GameAnalyse large errors in retrospectivesSome variance is normalKeep a library of representative reference storiesEstimate relative to referencesAdd stories that were mis-estimated!Velocity of the first projectTake a similar, finished projectEstimate relatively in Story points: N pointsWe know it took M mandaysDecide how many mandays per iteration: KVelocity = +/- K * N/M points/iteration

Attention: M is complete costNo Twilight Zone or Murky Zone!#7 Calibrate your estimates with real velocity dataProject data > Company data > Industry dataEvil Estimation GamesGuess the number Ive got in my head!An awesome team like you can do better than that!This time itll go so much faster, because we learned so much from the previous project!This project will be very different!If we just work a bit harder, well increase velocityI could code this in half the time!If we lower the estimate, the project will be done faster (this actually works in some circumstances...)Q: Why are there so many pointy haired-bosses?A: because there are so many Dilberts31#8 Never negotiate estimatesAlways question the reasoning and assumptions behind estimates#9 Never negotiate commitments#10 Solve problems togetherMake assumptions explicitQuestion assumptionsOffer optionsThe Options exerciseEstimate of the project: 5-6 monthsConference in 3 monthsWe need to make a great impression on prospectsI want to show all our functionalityWhich assumptions are we making?What options can you offer?Roadmap OR Kanban?Our dilemma:Product manager needs to publish a credible long term roadmap for customers, partners and integratorsDevelopment team has flow-based process without estimation, planning or velocity trackingWe cant have both, can we?Yes we can!TODO create CRD36Roadmap AND KanbanRoadmap with customer goals, not featuresProduct Manager estimates value of achieving each goal => priorities of roadmapProduct Manager determines budget per goalQuick feasibility check by teamEach release, PM and team find a way to achieve release goals within release budgetWatch flow, ensure release goals are metSummaryRanges for estimates. Numbers for facts.Always ask what the estimate will be used forEstimation is not CommitmentMeasure, count, compute before estimatingAggregate independent estimatesUse the law of large numbers (large ~= 15)Calibrate estimates with measured velocityNever negotiate estimatesNever negotiate commitmentsSolve problems together

Estimation exercise 2Surface temperature of the sun (in degrees C)Latitude of Shanghai (in degrees)Surface area of Asia (in km2)Birth date of Alexander The Great (year)Dollars in circulation in the US in 2004 (in $)Volume of the Great American lakes (in litres)Global revenue of Titanic (in $)Length of the Pacific coastline (Ca, Or, Wa) (in km)Number of books published in USA, 1776 to 2004Weight of the largest whale (in tonnes)

This quiz is from Software Estimation by Steve McConnell (Microsoft Press)(C) 2006 Steve McConnell. Used with permissionTimes up!6 min39AnswersSun: 6000 CShanghai: 31 degrees NorthAsian area: 44,390,000 kmAlexander was born in 356 BCDollars in circulation: $719.9 billionGreat Lakes: 6.8x10^23 litresTitanic: 1.835 billion $Pacific Coast: 1293 kilometresPublished books: 22 millionWhale: 170 tonnes

This quiz is from Software Estimation by Steve McConnell (Microsoft Press)(C) 2006 Steve McConnell. Used with permissionAnd the winner is?Life is like a box of tasty Belgian chocolates!Software Estimation Steve McConnellpresentation42 |

Session RetroWhat Went WellWhat Went WrongQuestions?Lessons LearntThank You!for your Gift of Feedback

We are constantly striving to improve. Give your Gift of Feedback by completing a session retrospective.

Everyone take a sheet of paper. Split it into 4 quadrants.In the top left quadrant, note down all the things that went well.In the top right quadrant, note down all the things that went wrong.In the bottom left quadrant, note down your puzzles such as outstanding questions you have as a result of the attending the session.In the bottom right quadrant, note down your lessons learned.

43

MerciThank Youwww.agilecoach.netwww.nayima.beblog.nayima.be

If you want to know more46

Recommended