Agile 2010 Day 1 Review

For the third year in a row, I was lucky enough to get a talk accepted at Agile 2010 and the support from Suncorp to send me along to speak. I was also honoured to assist Greg Smith in co-producing the Project Management stage for the conference. Whilst its a been a few weeks since the conference (I took some time afterwards to explore Florida and the south-east of the United States) I wanted to ensure that I posted my notes.

The sessions I attended on day 1 were as follows:

Patterns for Customer Interaction

Linda Rising led this session, and whilst I was looking forward to seeing Linda speak, this session was way to drawn out to fit the 180 minute timeslot and as a result I left part way through. The customer interaction patterns are available on Linda’s website, here are my notes for the part I was present for:

  • common sense is not very common
  • Christopher Alexander, a building architect, came up with the idea of patterns, gives us a name for something so that we can talk about that idea
  • Einstein got 10 hours of sleep per night, the average these days is 7 hours, short term memory drops when less than 7 hours

Foundation patterns

  • it’s a relationship, not a sale – we are always focussed on the the task af hand, but handing over the solution is just the beginning, a customer does not know until they see it
  • know yourself – believe in your own capabilities, agile is a methodology that starts by knowing it’s values, what is your mission
  • know the customer – learn about your customer, know as much about them as you can
  • build trust – difference between trust and respect

Agile Estimating & Planning: From Basics to Brain Stumpers

Mike Cohn presented on the Project Management stage to a standing room only crowd (I was sitting on the floor at the side of the room). The presentation is available here.

  • release planning – looking ahead 3,6 or 9 months
  • sprint planning – break down, 2 hours of planning
  • good plan – when done you can look back and be happy with it
  • “do the planning, throw away the plan” – Mary Poppendieck
  • anchoring – tendency for an estimate to be as long as the estimate you last heard
  • estimate size then derive duration – separate the steps, estimating the size is hard (try it out, compare to other examples)
  • story points – how long will it take based on complexity and uncertainty, story points are relative – example walk to a building in 1 unit of time, next building in 3 units of time, holds true if I am walking or on crutches
  • relative estimation with 100 stories in a backlog – get team to randomly read the backlog, start with a couple of the smallest stories – find a good 2 and a 5, then compare as you go
  • calculate confidence in historical velocity, throw out observations after 8 or more sprints (the top and the bottom sorted velocity) (Mike has a calculator for this)
  • sick and vacation for most teams – normally can predict that things will be the same now and in the future
  • common sense trumps all when calculating velocity
  • to determine the finish, give management a velocity range – low velocity will definitely get to, aim for the medium and the most we can hope to achieve
  • velocity for a new team – forecast velocity
  • get a backlog, break stories into tasks and hours, agree they can commit, repeat until iteration full for the first sprint
  • may want to pull items off the backlog randomly
  • if you can’t use a real team, find a substitute team
  • best option is to use historical data or stall when somebody wants an answer of when
  • work will be done in natural order, typically always turns out logically
  • story points only for stories, assume right person will always do the work, estimates will balance out across the team
  • get team to do personal math on how many hours they can commit to the iteration
  • drive by commitment, not by velocity (backend the velocity)
  • story points are a useful long term measure, not short term
  • use exercises to get team useful in estimating, takes Mike 1 day
  • velocity usually stabilizes within 3-5 sprints
  • express point velocity as a range, take a guess, calculate a range percentage based on other teams standard deviation

What happens to velocity if team size changes?

  • if team size changes are consistent, don’t do anything
  • stop changing team members around – study that teams need a new team member every 3 years to stop being stagnant
  • keep spreadsheet of percentage changes over 3 iterations – team from 6-7 people went down 10 percent, then down 5 percent and then up 13 percent
  • fixed scope and time
  • multiply low and high velocity by date and give a range
  • everybody is doing some sort of contract development, going with bottom velocity makes you a short term hero with long term risk – trade off of short term hero and long term risk, where do you want the pain?
  • long term estimation > 6-9 months, treat like a budget, look st epic feature level stories and see if it us credible to do it in a quarter
  • look at velocity and see if cards look too big
  • typical successful team can do about 1 to 1.5 stories per person per sprint


  • what’s my realistic worst case – 90% certainty, what’s my best case and find a buffer in the middle of the overall
  • give 50% and 90% numbers
  • to get a buffer add all of the 50s and some of the 90s – sample buffer
  • do this when there is a high cost of being wrong – front page news, heads will roll – do not use all the time
  • if you don’t have experience, stall and get some
  • re-estimate when things take longer than you thought – re-estimate those cards when you know they are bigger and you know where they are, don’t reestimate random screwups, get customer to reprioritise


  • which card do you do first, whole backlog should represent the entire size, work in natural order, if wrong we switch points, if horribly wrong might need to re-estimate
  • do technical stories rarely, pulls value away from story, only if large infrastructure beast that might need it’s own sprint

Throughout the session, Mike ran a great example of estimating, giving the audience some trivia questions and getting us to answer with a range estimate (for example, how may airplanes did the US military own in 1913?). It’s amazing how far off some of our estimates were! (if you were wondering, the answer to the example was 23 aircraft, I was way off!) There were also a number of other exercises around estimating that can be seen in the presentation.


2 thoughts on “Agile 2010 Day 1 Review

  1. Pingback: Размисли и още нещо » Blog Archive » Полезни връзки от Agile 2010 в Orlando

  2. Pingback: Twitter Summary September 2010 « CDS 43

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s