Basic Agile: the Game


Published on

This is the set of instructions for a game that simulates basic iterative development. It accompanies the presentation on how boardgame mechanics can be used to explain software development in easy-to-understand terms.

Published in: Software
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Facilitator Notes:
    The loss of a point is the context switching the person is doing; this occurs each time a person moves from one task to another.
    Remember: the average # of points that is calculated for a person to work per day is 5.4; this means that there are 28 (29 if the deck has the recommended 3 Jokers) below that (impediments mean no points work), while there are 26 above this value.
    After several iterations have occurred, it may be worth noting whether they are pairing on stories (more likely to complete them) and/or whether the story size is too large. If these are being noted… Ask the following questions:

    What could you do to help get work to done
  • Basic Agile: the Game

    1. 1. Agile: the Game
    2. 2. Learning Agile Through Elaborative Plotting Let’s look at A Quick Partial Hands-On Tutorial
    3. 3. Materials You’ll Need • A Pair of Standard 6-sided Dice per team (called d6 or 2d6 for the pair, 1d6 for a single die) • Index Cards to write down ‘Stories’ • Painter’s Tape or a Flipchart & Markers to Create Your Story/Task Board; Also a Flipchart & Stickies for your Story Map • Set of Rory’s Story Dice, or other story/visualization game (e.g. Dixit, Pictionary Cards) • A copy of Boggle • A Set of game pawns in various colors, or 8 Chess
    4. 4. Building The Product Team • Gather into groups of 5-9 • Decide who will be the product owner and facilitator; when I refer to the delivery team size, then I mean everyone but the product owner • Decide when the product owner will review and accept stories; think when your last responsible moment is. • Create Story Task board: Release Backlog | Story Backlog | In Process | Done • Place the pawns representing your team with the King or Queen representing the product owner at the top left of the board
    5. 5. Product Planning • Roll 2-3 story dice; use the images to write a 5 paragraph or story line (could also shuffle and draw 2-3 Dixit cards or 8-10 Pictionary cards and create a picture); the goal here is to have a simple vision that because of the short ‘story’ has elements that can be broken down • Want to do this for the real world? Create an Elevator Pitch for your product: FOR <target customers> WHO <statement of need> THE <product name> IS A <product category> THAT <key benefit, reason to buy> UNLIKE <competition, alternative> OUR PRODUCT <differentiating statement>
    6. 6. Product Planning, Continued • Use sentences/elevator pitch to determine important Epics/Features that are needed (either for the story or real world product) – Form of <Role/Persona> <Verb> for <Result/Info> (e.g. “We Cry for Jenny” or a possible real one: “Applicant Creates Profile”); remember you are refining details on the short paragraph – Use the Vision/Pitch to help define a sequence these should follow (a Usage Sequence for your Story Map)
    7. 7. Release Planning • Roll 2d6 per Epic; this is the # of ‘user’ stories you need to create for each one (if doing this for real, begin using story splitting techniques – the number needed will outflow from that) – For the game, write the user stories as follows: – These details will usually be something that has relative importance as related to the Epic; this prioritization is used to create your Release Backlog Game Play For Real As <character>, I will do <some action>, So that I <further the plotline> As <role/persona>, I want to <some business function>, So that I can <obtain business value>
    8. 8. Release Planning (Cont’d) • Roll 2d6 for each story and consult the table below: • These become the points for each story to be worked; record these on your index cards • Sum these points & record on a burn down chart • The # of available work days for your project is calculated by the following formula: # work days = [Σ(story points) ÷ (team size x 3.7)] + 2d6 - 1 for a mgmt reserve 3.7 is an expectation of the average of points each person can work per day based on the Boggle story point scoring Die Roll 2 3 4 5 6 7 8 9 10 11 12 Release Story Pt Value 3 5 5 8 8 13 13 13 21 21 34 delivery
    9. 9. Release Planning (cont’d) • Decide on the number of days in your iteration (2 weeks = 10 days, we don’t work weekends); the number of work days for each iteration is your selected number - 1. • # of iterations = work days/# days in iteration • Plot a straight line from start to end of your last iteration
    10. 10. Iteration Planning • Pull stories and prioritize these as desired by the product owner • For the story line, he product owner can look at the user stories and give any details that may help him select acceptable words in terms of quantity, adjectives, etc. • Continuing with the Iteration (Sprint) Planning Phase: – If you split a story, determine the new story points for each story using the following table: – You may further split a story that has already been split; subtract one from the size die roll if you do so – As a team, decide when to stop pulling stories and make a commitment for the Iteration (Sprint). Die Roll 1 2 3 4 5 6 7 8 9 10 11 12 Split Story Pt Value 1 2 3 3 3 5 5 5 8 8 8 13
    11. 11. • Daily Round Phase: – Daily Stand-Up: the players now collectively review what user stories they were able to accomplish the day prior and what they want to work on the next day (and place their pawns). – Once the stand-up is completed, it’s time to do work! Since we’re using a story-telling theme, we’re going to work stories off using words in 3 minute days. Shake Boggle and get the letter cubes seated, then start the 3 min timer. – Find words; select words with 3 or more letters you think will be acceptable to fleshing out the user story and the details the product owner added. – Record the word on a sticky that goes onto the story.
    12. 12. Product Owner Review • Record the points (in black) each word is worth using the following table: • Whenever you had agreed your product owner would review your stories, have them review your words, check off the words that were acceptable to the product owner and add up the total. • If this is equal to or exceeds the # of points required to work the story, then the story is complete. • If you are still in the iteration, you can pull another story in to work. Word Size 2 3 4 5 6 7 8+ Amount of Story Points Worked 1 2 3 5 5 8 13
    13. 13. Iteration Review • Record the story points off of the completed cards. • Update your burn down chart based on this number. Retrospective • Discuss with your team mates if you need to rethink how you pull stories for commitment, whether you need to size them differently, or how you assign workers. • Your facilitator may make some observations or introduce new rules at this point.
    15. 15. The GameDebrief