EECS 394 Software Project Management Chris Riesbeck Estimating Thursday, May 19, 2011
Estimation � People are really really bad at it. � http://tuomaspelkonen.com/2010/04/12-problems- with-software-estimation-2/ � See Chapter 7 of The Agile Samurai for the background and a description of Planning Poker 2 Thursday, May 19, 2011
3 Thursday, May 19, 2011
Fool me once, shame on you. Fool me six times, shame on whoever set that schedule. 3 Thursday, May 19, 2011
The Problem Manager project estimates are often extremely unrealistic. 4 Thursday, May 19, 2011
The Problem Manager project estimates are often extremely unrealistic. We need it now! It can’t be that hard! People work best under pressure! 4 Thursday, May 19, 2011
The Problem Manager project estimates are often extremely unrealistic. We need it now! It can’t be that hard! People work best under Programmers are no better… pressure! 4 Thursday, May 19, 2011
5 Thursday, May 19, 2011
6 Thursday, May 19, 2011
“Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty.” Todd Little. IEEE Software May/June 2006 7 Thursday, May 19, 2011
“Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty.” Todd Little. IEEE Software May/June 2006 7 Thursday, May 19, 2011
“An estimate is the most optimistic prediction that has a non-zero probability of coming true.” Tom DeMarco, Controlling Software Projects , Prentice Hall, 1982. “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty.” Todd Little. IEEE Software May/June 2006 7 Thursday, May 19, 2011
Classic Project Estimation Work Breakdown Structures bottom-up estimation total project effort = sum of pieces + slack http://www2.cit.cornell.edu/computer/robohelp/cpmm/ Phase2_Process_Descriptions.htm 8 Thursday, May 19, 2011
Historical Project Data • Boeing 777 flight software (mid 1990’s) • 30 suppliers, 9 million person hours • 2.5 million lines of new code • 1.6 million lines of COTS Managing megaprojects. Walt Gillette IEEE Software July 1986 9 Thursday, May 19, 2011
Historical Project Data • Boeing 777 flight software (mid 1990’s) • 30 suppliers, 9 million person hours • 2.5 million lines of new code • 1.6 million lines of COTS • Finished on time • only 120,000 lines of nonessential functionality deferred at initial delivery Managing megaprojects. Walt Gillette IEEE Software July 1986 9 Thursday, May 19, 2011
Each supplier had to forecast their expected SLOCs, along with a schedule for the planning, coding, test preparation, and software testing… We did not accept their plans until they could show support for all necessary program dates. Managing megaprojects. Walt Gillette IEEE Software July 1986 10 Thursday, May 19, 2011
Each supplier had to forecast their expected SLOCs, along with a schedule for the planning, coding, test preparation, and software testing… We did not accept their plans until they could show support for all necessary program dates. Boeing’s extensive software development database showed that flight-essential software can be achieved at a rate of about _____ SLOC per person- _________ (the overall rate to plan, code, create tests, run tests, modify/fix code, and pass tests). Managing megaprojects. Walt Gillette IEEE Software July 1986 10 Thursday, May 19, 2011
This one metric ... caused most suppliers to double or triple their software staff within the project’s first quarter. Managing megaprojects. Walt Gillette IEEE Software July 1986 11 Thursday, May 19, 2011
Agile Estimation � Estimate relative size not real time Story points � Determine points � time empirically as project progresses Velocity � Estimate points doable for one iteration not whole project Timeboxes � Planning poker � type of Wideband Delphi estimation Planning poker � The wisdom of the crowds � http://en.wikipedia.org/wiki/ The_Wisdom_of_Crowds 12 Thursday, May 19, 2011
Planning Poker Give every developer cards with fixed point counts. 0 � 1 2 5 13 20 ? bigger = less accurate 3 8 For each story, each developer turns over a card with their estimate. If different, low and high explain their reasons, then play again. If no quick convergence, pick higher value. 13 Thursday, May 19, 2011
Planning Poker Problems � Story points are a tricky concept � A measure of size but not real time � One number has to incorporate � size (lines of code) � complexity (trickiness) � uncertainty about solution (novelty) � uncertainty about problem � One person's 5 is another's 8 � Works better with experienced teams 14 Thursday, May 19, 2011
Sizing instead of poker http://blog.technicalmanagementinstitute.com/2009/06/story-sizing- a-better-start-than-planning-poker.html 15 Thursday, May 19, 2011
Sizing instead of poker Sort your story cards by relative effort. 1. Pick an "average" sized one. Put it on the wall. 2. Pick another. Put it to the right if bigger, left if smaller. 3. Repeat #2 with each story, readjusting as you go. http://blog.technicalmanagementinstitute.com/2009/06/story-sizing- a-better-start-than-planning-poker.html 15 Thursday, May 19, 2011
Sizing instead of poker Sort your story cards by relative effort. 1. Pick an "average" sized one. Put it on the wall. 2. Pick another. Put it to the right if bigger, left if smaller. 3. Repeat #2 with each story, readjusting as you go. Assign story points. 1. Assign 1 to the leftmost story. 2. Go right until some story seems twice as big. Assign 2. 3. Repeat #2 for succeeding Fibonacci values. http://blog.technicalmanagementinstitute.com/2009/06/story-sizing- a-better-start-than-planning-poker.html 15 Thursday, May 19, 2011
Recommend
More recommend
