This basic game is designed to help players understand the concepts involved in release and iteration planning. It covers how to plan for new features, minimise defects, monitor velocity, re-plan and the impact of technical debt.
You will need:
Overview
The problem:
The process of language simplification that was accelerated by the advent of the internet has reached its climax. In this scenario, the people of a certain city have completely forgotten the meaning of the letters of the alphabet and therefore can’t communicate through written or spoken language.
The objective of the project:
In order to recover the ability to communicate in this community, you were designated a team whose mission is to rebuild the maximum number of letters of the alphabet as possible. This will allow the gradual return of the lost communication. By the end, the mission should reach the following criteria:
The goal of the sprints:
Due to the urgent need to communicate for the survival of the residents, the chosen strategy was a rapid and graduated construction of the letters that will be delivered in rapid sprints. Each sprint must have the following goals:
You can't use a word more than once in the game, but you can freely repeat the letters you have constructed, using the same letter in as many words as you want.
Instructions for teams
1. Initial project planning
The first thing your team needs to do is the initial project planning. This is when all the stories of the project must be identified and prioritised.
2. Sprint planning
The project will be performed in 4 sprints that must be planned, executed and evaluated sequentially.
In order to do that, steps 2 to 5 must first be performed for the first sprint and afterwards repeated for the following sprint until the end of the project. To plan a sprint you should:
The assignment of stories to the current sprint is a must. The team can also decide to assign stories to the following sprints, but that is optional.
3. Sprint execution
You know the expected velocity for the sprint and now it's time to find the actual velocity.
Roll the dice twice.
Actual velocity = Expected Velocity + die (first) – die (second)
If the actual velocity is greater than planned, the team can insert new items into the sprint (new stories, correction of defects or reduction of the technical debt) until the total is complete.
But, if the actual velocity is less than planned, the team should remove as many items as necessary. The items to be removed are those of less priority and should be postponed until the following sprint.
This actual velocity will also be the expected velocity for the next sprint.
Expected velocity (sprint x+1) = actual velocity (sprint x)
4. Sprint evaluation
Were the sprint goals met? Write the response on the sprint board.
Optional instructions
5. Update the status reporting sheet
Update the status report to reflect what has occurred during the sprint. If you are at sprint 1, 2 or 3 then go back to step 2 to plan the next sprint.
Check with the instructor at the end of each sprint to confirm your success and check for any additional instructions. If you don't update the facilitator means that the sprint is invalid.
6. Ending the project
After the sprint 4, the team should do a lessons learned session, also recording any doubts and questions.
Copyright © James King
Game adapted by Eduardo Meira Peres
Your details have been submitted and we will be in touch.