How do you normalise your velocity estimation?

  • Article

imageWorking in our interesting, yet challenging (distributed, part-time, non-committed bandwidth) environment, the concept of planning, estimation and determining a consistent velocity has been less than ideal … often frustrating.

I am pondering over a way to better estimate and normalise our part-time delivery capabilities.

 

My current thoughts are as follows.

estimating

  1. Encourage a developer/contributor and a tester/reviewer pair per story.
  2. Team finds smallest story that can be created and validated in full day, relating it to one story point.
  3. Team estimates the remaining tasks, using the 1 story point task as a reference.
  4. Split up big stories into smaller stories that are equal or less to the part-time sprint maximum (see below).

normalise

  1. Normalise velocity estimates by estimating how many story points can realistically be delivered per pair on a part-time basis when planning the potentially shippable iteration (psi), spanning 3-5 sprints.
    image

    How did I get to 3?

    1. 260 working days per year / 12 =  21.67d/month
    2. 21.67 days ~ 21.67 story points
    3. 21.67 * 1h (part-time/day) / 8h (full-time/day) = 2.708
    4. 2.708 = ~3 story points (part-time) per pair per month

    Assuming each Ranger invests an average of 5h/week and is focused on one project only.
  2. Review and normalise the velocity estimates for each project after each sprint.
  3. Reviewed and normalised velocity is only valid for the duration of the iteration, after which team complement usually changes.

Thoughts? Ideas?