The Lost Alphabet: An Agile Release Planning Game For Teams

18 September

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:



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:

  • It should be possible to construct the phrase: “It’s difficult to put it into words”.


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:

  1. Construction of a minimum of two words with two or more letters.
  2. Construction of a minimum of two words with four or more letters.
  3. Construction of two complete grammatically correct sentences. 
  4. Construction of the sentence which is the object of this mission.

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:

  1. Confirm the goal of the sprint
  2. Determine the expected velocity of the sprint. For the first sprint, the expected velocity is 25 points, and for the others, it will be the actual velocity of the previous sprint. 
  3. Choose the letter to add in the sprint, sorting them in order of priority. Stop adding letters when the total cost of the letters is equal to the expected velocity.

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. 

  1. The first die represents the gains of improving the team performance and the result must be added to the planned velocity.
  2. The second die represents distractions and impediments that reduce the performance and must then be subtracted from the planned velocity. 

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