Design, Develop, Create

Tuesday, 11 October 2016

Exercise: Estimating User Stories

This exercise demonstrates task size estimation using ‘story points.’ A story point is a unit-less measure of size and complexity for a story. More important than the estimate is the discussion the group has about the story. This activity helps a group understand what tasks and proposed solutions might mean/be before attempting to implement them.

Understand the ‘planning poker’ technique for task/story estimation for high tech development project and to obtain useful estimates for (iteration) planning.

Familiarisation with ‘user stories’ and the ‘story card’ method for capturing goal driven requirements.
Planning poker cards or index cards with range of numbers (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, & coffee)

Budget up to 45 minutes to run the whole exercise (for a class size of ~50). Arrange class into groups from 4 to 7 people.
  1. Allocate 1” for everyone to read through the ‘local’ rules for planning poker below.
  2. Discuss planning poker rules to clarify understanding.
  3. Allocate 2” for everyone to read the scenario carefully (don’t make personal estimates yet).
  4. 25” for planning poker rounds.
  5. 15” for debriefing discussion.
(Local) Rules for Planning Poker; adapted from (Cohn, 2006)
  1. The dealer picks up the next story and asks: “Ok, how many story points will this story take?”
  2. Team members think about the story and come up their own estimates. Nobody speaks the estimate just yet.
  3. Members place a card from their decks face down on the table, with a value equal to or close to their estimate.
  4. When everyone’s card is on the table turn the cards over at the same time.
  5. Each person explains what he or she thought the story required, maximum of 3 minutes discussion.
  6. Taking account of new information the cards are played again (and perhaps again) until rough convergence is achieved or one developer’s proposal and estimate is agreed upon.


Discussion points
  • Did you identify duplicate entries?
  • How did you handle user stories that did not follow the “As a… I want to… so that…” pattern?
  • Were some user stories too ambiguous to estimate?
  • How did the teams make sense of the stated requirement?
  • Did the teams seek clarification from the product owner?
  • How were divergent estimates treated?
  • Describe your ‘feelings’ about the process? Fair, political, honest, dominated, contentious, accurate, shared, personalised, ideas, support, attack…
  • How did the team arrive at a shared interpretation of the estimated value?
  • Did you attach a concrete meaning for the estimate figure? Dimensionless, people, complex-standalone, similar to or like something else, hours, days, small-medium-large, easy-difficult…
Cohn, M. (2006) Agile Estimating and Planning, Upper Saddle River, NJ, Pearson Education.