Story Points
· Soup analogy:
o new restaurant
o soup for starter: cup or bowl?
o Small or large Coke?
o Don’t need to know how many grams are in a cup or bowl, but waiter might hold out hands to demonstrate rough size; not saying I’d like 200ml of soup, 15 fl oz of soup & 3oz of bread.
· Agile estimates = similar
· Large Coke = bigger than small Coke, but smaller than extra large one.
· I’m thirsty and past experience is that large coke has been about right size.
· In agile planning: is story/task 1 bigger or smaller than story/task 2?
· Story points = relative
o “Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work.”
o Raw value = unimportant (i.e. x could be 3 or 6 and wouldn’t matter because everything else is relative around it)
o Story worth 2 points should be twice as big as story of 1 point and 2/3 the size of a 3 point story.
o No set formula = amount of dev effort involved + complexity + inherent risk + etc.
· How to get started:
1. Select one of smallest stories = 1 point
2. Select story in middle and = 5 points (Cohn prefers all stories to be between 1 and 10, so would use 5 for middle story)
è Then estimate all other stories based on these baselines
· Task: dog sizes (not weight)
· Often don’t have full spec (details only come out during iteration); but still need estimates (terriers & poodles vary depending on breed, but you make assumptions and average out).
· Velocity
o Essential part of story points!
o “Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points… that the team completed during the iteration”.
o Used to measure guess of what team will complete next iteration (assumes iteration is same length, has same team, etc).
o Velocity means that, regardless of values used (e.g. is baseline 1 or 2 points), then estimates work.
o Add up all story points for all desired features = total size estimate for project
à divide by velocity
= number of iterations needed to complete.
o Key tenet of agile estimating and planning is that we “estimate size but derive duration”
o Sometimes have to estimate velocity (see ch.16)
o More iterations you do, more accurate velocity
o Self-correcting (example)
§ Total project = 200 story points
§ Velocity est. = 25 à 8 iterations to complete project
§ Velocity of early iterations = 20
§ à re-estimate that need 10 iterations (without having to re-estimate all stories)
§ Example = decorating house from floor plan without dimensions.
§ “The beauty of this is that estimating in story points completely separates the estimation of effort from the estimation of duration.” ß both are related but allows estimates to be separate (first establish size/effort… then apply time).
§ “You are no longer estimating the duration of a project; you are computing it or deriving it”
· Discussion point: “It’s fairly easy to estimate that two things of very similar size are the same. Over what range (from the smallest item to the largest) do you think you can reliably estimate? Five times the smallest item? 10 times? 100 times? 1,000 times?!
HOW DO YOU ENSURE 1 STORY POINT = SAME IN EACH ITERATION? OTHERWISE VELOCITY DOESN’T WORK!
Ideal Days
· Ideal time & elapsed time different (uses American football analogy)
o ideal = “time something takes when stripped of all peripheral activities” (4x15 min quarters)
o elapsed = “amount of time that passes on a clock” (3 hours)
· Both have uses: ideal = for refereeing; elapsed = for telling wife how long you’ll be out!
· Almost always easier and accurate to predict duration in ideal time.
o Football analogy
§ Ideal = 60 mins (maybe 62.5 mins using historical data to include overtime)
§ Elapsed = ? (wildly different: injuries, penalties, TV game (ads), weather…)
o People know with sport, that a TV guide estimates a game being 3 hours but are not surprised if runs short or long. May get frustrated or annoyed, but not surprised!
è Why are we surprised when software project has estimate of 12 months but takes 13?!
· Ideal time differs from Elapsed time in dev b’cos of natural overheads (answering email, support, interviewing, attending meetings, sick leave, demos, personal issues, phone calls, training, technical problems, bug fixing, release process, other interruptions, switching between tasks, etc).
· “5 days” usually means “5 days if that’s all I do without any interruption (so it will actually take 2 weeks)”
· Ideal estimates assume:
o Story being estimated is only thing you’re working on
o Everything you need will be on hand when you start
o There will be no interruptions
· “When considerations of organisational overhead are ignored, ideal days can be thought of as just another estimate of size, just as story points are.”
è Use velocity to turn ideal days into estimate of duration
· Use aggregate estimate (dev, test, acceptance); otherwise lose team spirit & estimating takes longer