Tracking Progress

What Clients and Managers Really Want to Know

Readings

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

The Problem

The Wrong Answer

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

Lies My Schedule Told Me

  • The project's path to success has been resolved
  • There's plenty of time
  • All the important parts have a place in the schedule
  • The time to panic is at the end if things slip
  • If things slip, it's the developers fault
  • The developers can always work twice as hard at the end

Estimation and the Cone of Uncertainty

“Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty.” Todd Little. IEEE Software May/June 2006

Estimation in Reality

“Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty.” Todd Little. IEEE Software May/June 2006

Why Schedules Don't Work

  • A schedule is a set of commitments made at the time of least knowledge
  • “An estimate is the most optimistic prediction that has a non-zero probability of coming true.”
    • Tom DeMarco, Controlling Software Projects, Prentice Hall, 1982

But The Questions Remain

Agile Planning

  • Define MVP Backlog
    • The set of user stories needed for the Minimum Viable Product
  • Slice most valuable stories that can fit one iteration
    • Most critical to learning what product will be
  • At end of iteration, return all undone stories to backlog
    • Done means tested and deployed
  • Repeat above steps for next iteration

Agile Tracking

  • Developers assign relative effort points to every story in MVP backlog
    • 1 point for the easiest, 2 for stories twice as hard, 3, 5, 8, 13, 20
    • (Some mature teams split all stories to be equal effort)
  • Managers calculate
    • total points for stories done (tested and deployed) in an iteration
      • this is called the velocity
    • total points of stories remaining in MVP backlog
      • including stories added, removed, or modified
    • Plot progress on burn-down and burn-up charts

Burn-Down Charts

  • Quick visual of remaining points
  • Use most recent velocity (not average) to predict completion
  • Panic and rescope early!
http://rapidapplicationdevelopment.blogspot.com/2008/10/forget-burndown-use-burnup-charts.html

Burn-Up Charts

  • Shows interaction of scope and true velocity
  • The only line you can control is the backlog size
http://rapidapplicationdevelopment.blogspot.com/2008/10/forget-burndown-use-burnup-charts.html

Planning Poker

  • Delphi approach to assigning story points
  • For each story, one at a time
    1. Each team member secretly picks a card with effort points
    2. Everyone reveals their pick at the same time
    3. If choices differ, the farthest apart discuss their reasoning
    4. Repeat, until convergence
  • Details in The Agile Samurai, Chapter 7

Planning Poker Problems

  • In my experience, new teams struggle to converge on meaning of points
    • Is 3 easy or hard?
    • How many points does uncertainty add?
  • Two common fixes:
    • Equate points with ideal days (The Agile Samurai)
    • Use T-shirt sizes (small, medium, large)

Team Estimation Game

  • The team sorts story cards onto a wide flat surface, left to right, easy to hard
    • Discuss whenever opinions differ
  • After sorting, assign rounded Fibonacci numbers to piles
    • 1 to easiest, then 2, 3, 5, 8, 13, 20, ...
    • Skip numbers as appropriate
    • IMO, anything past 8 suggests epic stories or too many stories
  • For several variations on how to play, see