EECS 394 Software Project Management Chris Riesbeck Estimating - - PowerPoint PPT Presentation

Chris Riesbeck

EECS 394 Software Project Management

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 pressure! Programmers are no better…

4

Thursday, May 19, 2011

5

Thursday, May 19, 2011

6

Thursday, May 19, 2011

7

“Schedule Estimation and Uncertainty Surrounding the Cone

• f Uncertainty.” Todd Little. IEEE Software May/June 2006

Thursday, May 19, 2011

7

“Schedule Estimation and Uncertainty Surrounding the Cone

• f Uncertainty.” Todd Little. IEEE Software May/June 2006

Thursday, May 19, 2011

7

“Schedule Estimation and Uncertainty Surrounding the Cone

• f Uncertainty.” Todd Little. IEEE Software May/June 2006

“An estimate is the most optimistic prediction that has a non-zero probability of coming true.” Tom DeMarco, Controlling Software Projects, Prentice Hall, 1982.

Thursday, May 19, 2011

8

Classic Project Estimation

http://www2.cit.cornell.edu/computer/robohelp/cpmm/ Phase2_Process_Descriptions.htm

Work Breakdown Structures

total project effort = sum of pieces + slack bottom-up estimation

Thursday, May 19, 2011

• 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

Historical Project Data

9

Thursday, May 19, 2011

• 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

Historical Project Data

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

12

Agile Estimation

Estimate relative size not real

time

Determine points time

empirically as project progresses

Estimate points doable for one

iteration not whole project

Planning poker

type of Wideband Delphi

estimation

The wisdom of the crowds http://en.wikipedia.org/wiki/

The_Wisdom_of_Crowds

Story points Velocity Timeboxes Planning poker

Thursday, May 19, 2011

Give every developer cards with fixed point counts.

Planning Poker

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. 1 2 3 5 8 13 20 ?

bigger = less accurate 13

Thursday, May 19, 2011

Planning Poker Problems

14

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

Thursday, May 19, 2011

Sizing instead of poker

15

http://blog.technicalmanagementinstitute.com/2009/06/story-sizing- a-better-start-than-planning-poker.html

Thursday, May 19, 2011

Sizing instead of poker

15

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

Thursday, May 19, 2011

Sizing instead of poker

15

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

• 1. Assign 1 to the leftmost story.
• 2. Go right until some story seems twice as big. Assign 2.

Assign story points.

• 3. Repeat #2 for succeeding Fibonacci values.

Thursday, May 19, 2011