Agile games
•Download as PPTX, PDF•
0 likes•487 views
This document outlines a simulation game where participants are divided into teams that plan and build a Lego city over multiple rounds or sprints. The objective is to blow things up in the city. Teams self-organize and work on a shared backlog of tasks, estimating work. Sprints involve planning, building, and reviewing progress, with the goal of continuous improvement.
More Related Content
Viewers also liked
Viewers also liked (20)
Recently uploaded
Recently uploaded (20)
Agile games
- 2. Round 1 - Upfront Planning Objective: Blow Stuff Up
- 3. Round 2 - Iterative Planning Swap Players Objective: Blow Stuff Up
- 4. Debrief
- 5. Lego City A SCRUM Simulation
- 6. Self Organization 5 Teams of 4-6 Peop
- 7. Project Chartering Single Product – Not Competing Product is the Lego City This is MY City
- 8. Building the Backlog Pre-Prepared Feel free to get creative
- 10. Sprint Planning
- 11. SPRIN T!
- 12. Review What Can I Do Better?
- 13. Sprint 1 Planning – 3m Sprinting – 7m Review – 5M Sprint 2 Sprint 3 Planning – 3m Sprinting – 7m Review – 5M Planning – 3m Sprinting – 7m Review – 5M
- 14. Debrief
Editor's Notes
- Separate into Teams of 2Player 1 Places Battleships Player 2 Has $25k to spend (each bomb costs $1k), plan moves at the same time as player 1 places ships
- Separate into Teams of 2Player 2 Places Battleships Player 1 Has $25k to spend (each bomb costs $1k), but reacts to Player 1’s communication.
- Predictive planning is unreliable and is akin to reading crystal balls, reading tea leaves or any other clairvoyant technique you care to mention. Ultimately you’re predicting the future based on an infinite number of possible outcomes, effects and variables. The iterative approach is empirical, each time Player B hits his opponents ships, he can instantly change plans and target nearby locations to sink it.There are a few other parallels you can draw from it.. Player A will often score hits but not sink, this is akin to features that were developed but not tested before time or money ran out. Player B however may not hit all the ships but is much more likely to sink the ones he does hit, making it a metaphor for “potentially shippable product increments” (no pun intended).Occasionally Player A wins, this is a bit like the fortune teller coincidentally getting something right, it’s often more luck than judgment.
- 5 Minutes
- 5 Minutes
- 5 Minutes
- 15 Minutes
- 3 Minutes
- Sprint – 7 MinutesReview – 5 Minutes
- 15 Minutes
- What did students observe?How did it feel being on a Scrum team?How did the short iterations go?How accurate were the estimations (provided the Release Burndown is there)What would we have done differently from the beginning, if we had another chance to play the game?What was the job of the Product Owner?How did it feel after the first sprint when almost all items required re-work?What did the Scrum Masters do?How will your strategy change, if you know the Product Owner is unavailable during sprints?How did inter-team communication go? Were there any dependencies? How were they resolved?What did students learn?