Customer’s Shoes: Release Planning

Goal: Practice release planning from a customer’s perspective.

Time: 20-60 minutes.
(Use only the most important stories, or cut down to small teams, to make the game play shorter.)


Introduction:

Introduce the idea of story cards and release planning. Explain that customers produce stories, split them, and prioritize them, while programmers estimate stories and determine the velocity. Explain how the game will be played.


Material:

  • Deck of pre-defined story cards. They have a story on the front and both a story and an estimate on the back. Some stories need to be split, so their estimate says “See envelope n.”
  • Envelopes to contain the “split” story cards.
  • Envelope containing the velocity. (Somewhere around 1/10 of the total estimated points.)

Setup:

  • Divide into teams of 2-6 people each. Each team designates a moderator/”programmer”; the rest are customers (together).
  • For “large” stories, keep the parent story with the rest of the deck, but put the “children” in the corresponding envelope. The moderator keeps the envelopes.
  • Turn the cards so that estimates are face down, and mix them up.
  • Deal the cards evenly among the customers. (They should not look at the estimate.)

Play:
1. Exploration. (~20 minutes)
Start with the customer to the left of the moderator, and go around the circle. Each customer reads one of their cards, and describes what it means (taking at most 30 seconds per card). The customer passes the card to the moderator.

When it’s the moderator’s turn, they look on the back and publish the estimate. There are three cases:

  • Estimate available: read the title and the estimate. Put the card “estimate up” in the middle of the table.
  • Need clarification: read the title, and ask the customer to give a little more explanation (<30 seconds worth). (There may be some “prompting phrases” to help them along.)  Then publish the estimate as before.
  • Too big: read the title, and say it’s too big. The card says “see envelope n”; open the envelope and distribute those stories to customers for future rounds. Set the parent story and the envelope aside.

Continue until all stories have been estimated.

2. Prioritize. (5-10 minutes)
The customer team prioritizes the cards – high, medium, low (“Must have”/”Should have”/”Could have”). Come to a consensus on which cards are in which pile.

3. Declare Velocity. (1 minute)
The moderator opens the velocity envelope and declares the velocity.

4. Choose Release. (10-15 minutes)
The customers will define a release – several iterations worth of activity. The release will contain all, and almost only, the high-priority stories.

Lay out the cards into columns representing iterations, so that each iteration has (at most) the declared velocity. The first iteration should try to “cover” key aspects of the whole system. The other iterations should be in decreasing order of importance (but don’t get hung up on it).

Answer the question, “How many iterations will it take?”

5. Debrief. (5 minutes)

  • Who writes the story cards?  [The customer]
  • Who estimates the stories? [The programmers]
  • What do the programmers do if they don’t know how to estimate a story? [They do a “spike”; we didn’t demonstrate this]
  • What happens if a story is too big? [The programmers ask the customer to split it.]
  • Can the customer refuse to split it? [No]
  • Who determines the velocity? [The programmers]
  • Who decides what story has what priority? [The customer]
  • Who determines what’s in a release? [The customer]
  • What if the release takes too long? [The customer can choose different stories, choose to split stories, try to grow the team, or find a different team to work with]

Sample 1 – Bookstore:

Electronic version: Story card fronts and story card backs (PPT) for the bookstore stories below, courtesy of Gerard Meszaros. He warns it’s tricky to get cards printed and aligned front-and-back, and suggests printing to stickers instead.
 

  • Order the featured book of the day. (2)
  • Shopping cart. (2)
  • Check out. (1)
  • Order any book. (3)
  • Show “in-stock” status. (3)
  • Search for books. (Needs clarification – 3)  Simple and complex searches.
  • List books by category. (2)
  • List a featured book in each category. (1)
  • List books by the same author. (1)
  • Send email to customers. (Needs clarification – 3) Customer preferences, email out, bounced mail.
  • Add new books when the distributor lists them. (Needs clarification – 3) Connect to distributor, send query, get response, add to database.
  • Coupons. (1)
  • Identify related purchases. (2) “If you’re interested in this, you might also be interested in these…”
  • Recommend a book to a friend. (2)
  • Automatic recommendations. (Envelope 1)
    • Track which books were purchased together. (2)
    • Track books ranked high by the same person. (2)
    • Link similar clusters together for customer. (2)
  • Wish list. (2)
  • Smart discounts. (3) If many people browse this book, but few buy, offer a discount.
  • Track user ratings and reviews. (2)
  • Analyze buyer habits. (Envelope 2)
    • Identify most popular and most active books vs. promotion type. (2)
    • Identify “most wished for” books. (1)
    • Determine customer demographics. (1)
    • Correlate activity, promotion, and demographics. (2)
  • User accounts. (2)
  • Show order status. (3) View last/all orders, maintain backorder status, track shipping info.
  • Handle returns. (Envelope 3)
    • Log received return. (1)
    • Re-stock returned item (update availability). (1)
    • Adjust customer record. (1)
    • Apply return credit to credit card. (2)
    • Send return acknowledgement to customer. (1)
  • Accept email from customers (to customer service). (3) Dispatching, agent management.
  • Velocity: 8

Sample 2 – XML Editor:

  • Enter text. (2)
  • Tag text based on schema. (2)
  • Provide a main text editing view. (1)
  • Support XML Schema. (Needs clarification – 3) Schema replaces DTD; defines tags and data types.
  • Provide a tag view. (1)
  • Print preview. (3)
  • Select/cut/copy/paste. (2)
  • Find and replace. (1)
  • Shortcut key for styles. (2)
  • XSL support. (Envelope 1)
    • Style-sheet parsing. (1)
    • Save style settings. (2) This would be useful even without XSL.
    • Make new styles available on menus. (1)
  • Support XML comments. (1)
  • Support links (e.g., <a> tag). (1)
  • Right mouse-click menu support. (2)
  • Undo and redo. (2)
  • Paragraph styles. (2)
  • Character styles (font and style). (2)
  • Page styles. (1)
  • Table support. (Envelope 2)
    • Handle nesting of boxes. (2)
    • Calculate best size for tables and cells. (2)
    • Support table parameters such as line width. (2)
  • Date/time entry. (1)
  • Spell-check. (Envelope 3)
    • Verify each words against dictionary. (1)
    • Allow independent dictionaries. (2)
    • Add/remove entries from dictionary. (2)
    • Suggest alternatives. (1)
  • Print. (3)
  • Multiple streams on a page. (Needs clarification – 3) Multiple columns, multiple sources of text.
  • Headers and footers. (3)
  • Velocity: 6

Source:
(William C. Wake, based on the planning game as described in Extreme Programming Explained.)