# Estimating Project Size

## You're doing it wrong

• These slides
• The Agile Samurai: Chapters 7, 8, 9

## Why Estimates Don't Work

An estimate is the most optimistic prediction that has a non-zero probability of coming true. Tom DeMarco, Controlling Software Projects, Prentice Hall, 1982
• If you can't trust programmer estimates of how long something will take, what can you do?

## Story Points

• A measure of relative effort
• Points are not a measure of time
• Points are not comparable between teams or projects

## Step 2: Sort

• Easiest to hardest, team consensus

## Step 3: Assign points

• Left to right, Fibonacci only, round up if necessary
• A 2 + a 3 should be about a 5

• 1 x 1 + 1 x 2 + 4 x 3 + 5 x 5 + 1 x 8 = 48
• That's how much work you have to do

## Velocity

• Sum of points for stories done in last iteration
• Done means "tested and deployed"
• No partial credit!
• Don't average over previous iterations
• Remaining points ÷ velocity = how many iterations needed to finish

## Velocity Charts

• Simple visualizations of progress in story points
• Each iteration:
• Subtract points for stories done
• Add and subtract points for stories added and removed from backlog
• Plot

## Burn-Down Charts

• Plot remaining points
• Use most recent velocity (not average) to predict completion
• Panic and rescope early!

## Burn-Up Charts

• Each iteration: plot total points in backlog, total points completed
• Shows interaction of scope and true velocity
• The only line you can control is the backlog size