We had Mike Cohn of Mountain Goat Software give a seminar on Agile Estimating and Planning this week. Here are my notes.

  • Strategy – planning at corporate level
  • Two mental models for strategy
    1. Focus on maintaining a fit between capability and market (inflexible, leads to generic strategies)
    2. Strategic intent (flexible, challenging shared vision, flexible means of meeting)
  • Planning – making a map (good) vs. tracing a route on a map (bad)
  • Focus on ever-changing agendas of strategic issues, challenges and aspirations
  • Types of uncertainty
    • Project (have never delivered exactly what you planned)
    • Means (language, db…)
  • Two views of addressing uncertainty
    • Traditional: eliminate uncertainty ahead of time (massive requirements)
    • Agile: uncertainty is removed throughout the process incrementally
  • Iterations
    • Are experiments
    • The quicker and cheaper, the better
    • Should be of a fixed length of 2 -4 weeks to get developers into a regular rhythm
  • Planning at a Release level
    • Conditions of satisfaction (user stories, budget, schedule)
    • Release planning (what is in, when)
  • Iteration
    • Conditions of satisfaction (user stories, tests (scope of user story))
    • Iteration planning
    • Development
    • Product increment
  • An important skill of Agile groups is to be able to split features down into small components that can fit in your iteration length
  • Feedback
    • Test velocity (how much gets done per interation could affect release planning)
    • Feature desire (customer might not want something as a result of a new one)
  • Notion of emergent design. Which is one of the things that makes the whole Agile movement sit wrong with me I think.
  • Release is multiple interactions
  • Velocity is a measure of progress
  • Agile teams plan at three different levels
    1. Daily – measured in promises (“I will do X”)
    2. Iteration – measured in hours / task
    3. Release – measured in storage Case Points
  • estimate size; derive duration
    • Waterfall – size -> calculation -> duration
    • Agile – 300 story points -> velocity = 20 -> 300/20 = 15 iterations
  • Story Points I like this measurement a lot from this brief overview of it
  • Measures the ‘bigness’ of a task
  • How hard, how much is it
  • Measured in *relative* values (bigger task, has bigger number)
  • Pros of SP
    • Estimates do not decay. A SP of 4 today, is still a SP of 4 next week, month, year.
    • Are a pure measure of size. I remember one estimation meeting where the developer was asked if the number of days given was in days or days
    • Are additive
    • There are studies (and no, I haven’t hunted them down) to show we are better at relative estimating than absolute estimating
  • Leave code a little better than you found it. With this little tidbit, I already have a bug ready to log against a couple of our source code files first thing Monday morning… 🙂
  • Building story points
    • Start with a ‘2’
    • Then a ‘5’ or ‘8’
    • Now have basis for comparison
    • Compare stories to multiple things (bigger and smaller)
    • Use a defined list of points so everyone knows about what they are
    • Stay mainly in 1-10
  • Planning poker (interactive approach to estimating) – group estimating using numbers on cards
  • Release planning
    • Size estimate of each story
    • Velocity
    • Need to plan story points for current iteration and for next iteration. Lump everything else in current iteration + 2
  • Do not estimate velocity, use empirical evidence
  • Release plan changes at every iteration depending on the velocity of the previous iteration
  • Work on stories in order of priority
  • Burndown charts
    • Y axis: work measure (hours, story points)
    • X axis: durations
    • Iteration burndown chart (how much work think is left)
    • Release burndown chart
    • Release burndown bar chart – can explain incidents on the regular chart
    • Shows net progress
    • Raises questions, they does not answer them
    • Facilitate early discussions
    • Makes it impossible to lie
  • Velocity lets you extrapolate finishing points (at lowest, current, best velocity)
  • Velocity is used for release planning, not iteration planning.