Estimating and Tracking

You're all doing it wrong

Readings

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

The Problem

The Wrong Answer

http://www.total-quality-management-software.com/gantt-chart-examples.asp

Why Schedules Don't Work

Part 1: Estimation

The Cone of Uncertainty

Cone Examples

Cone Intuition

Cone Reality

Cone Implications

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?

The Agile Alternative

Relative Estimates with Story Points

Story Points

A measure of relative effort
- 1 point for the easiest stories, 2 for the next, then 3, 5, 8, ...
- modified Fibonacci numbers
- If you go much past 8 you're probably have epics that need to be split
Points are not a measure of time
Points are not comparable between teams or projects

Step 1: Put all tasks on whiteboard

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

Step 4: Add

1 x 1 + 1 x 2 + 4 x 3 + 5 x 5 + 1 x 8 = 48
That total is how much work you have to do

Why Schedules Don't Work

Part 2: Schedules vs Reality

Lies, Damn Lies, and Schedules

Hallucinatory and Harmful

Lies My Schedule Told Me

"It's on the plan, so it will happen."
"Nothing was missed."
"No need to panic."
"If things slip a little, the developers can catch up."

A Schedule Math Question

The first set of requirements slips one day.
Predict the project end date.

The Agile Alternative

Backlogs and Velocity

Backlogs

Client maintain a backlog of user stories
- most valuable stories first
- points added by developers

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

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 scope

When Scope is Too Big

Velocity does not meet scope in time	Miss deadline?
Rush to finish?	Reduce scope.

Burnup Tool

Burnup and burndown charts are often created by hand on a piece of paper on the task board.
Many agile-oriented project tracking tools generate them.
Here's an example spreadsheet to do it and a short demo

Velocity without graphs

Burndown charts are look nice and are popular, but they suggest a numeric precision that doesn't exist.

An alternative is to focus just on what stories are likely to get done.

Here's a way to do that

Here's a template spreadsheet

Schedule Math Revisited

The first set of requirements slips one day.
Predict the project end date.

Velocity Math

20 total points in backlog, predicted velocity is 5.
4 points are actually done in Iteration 1.
Predict the project end date.

But, But, But

At Last, Answers

When will the project be done?
Whenever you say it must be done
How are things going?
It's all on the velocity charts!
How many people do you need?
Five

Thanks to Hakim El Hattab for RevealJS