This document provides detailed notes about the expectations of an iteration planning meeting.
For our purposes, a “board” may be on Trello, HackNPlan, or GitHub. I have found no digital tool that is robust as an actual whiteboard in a shared physical location, but these tools will have to do.
The board consists of the following columns, as outlined in the methodology:
Backlog: This column contains all of the work items that the team envisions for the project but has not scheduled for completion. In Scrum, this is called the Product Backlog, not to be confused with the Sprint Backlog, the latter being the list of work items to which the team has committed for the current sprint.
Not Yet Started: This column contains all the work items to which the team has committed for the current sprint, but for which no effort has yet been expended in the current sprint.
Only those two columns are needed for iteration planning, but as a reminder, here are the other columns that are needed during the sprint.
In Progress: This column contains all of the work that the team is actively working on. It therefore contains work to which the team committed, for this sprint, that has not yet been completed.
Needs Validation: This column is for work that is completed but requires validation before it is considered done. The nature of this validation is context-dependent. Source code requires peer review, features require playtesting, other creative works require different lenses and perspectives. During a sprint, work that does not pass validation is moved back to In Progress.
Done: This column is for work that is complete and validated.
There are two parts to this meeting: feature articulation and team commitment. During the first part of the meeting, the team figures out what needs to be done. During the second part of the meeting, the team commits to getting it done.
This is the process that generates the work items that are put in the backlog. The key to writing a good feature is that it should be small enough to complete in a few days, and it should obviously and immediately add value to the player’s experience.
Each feature is expressed as a user story. This technique comes from agile software development as a way of keeping the focus on adding value to the user–in our case, the player. There are several different philosophies about how to articulate the stories. A popular one that I have used is Mike Cohn’s format. His format names stories in the format:
As a role, I want goal [so that reason].
An example that might come up in a platform or open-world game is: As an explorer, I want to jump so that I can reach new areas. Note that here, I’m drawing casually from Bartle’s player typology to contextualize what kind of player might do this, although I could also make use of other techniques such as personas.
Others suggest that user stories should be more narrative, more like the colloquial use of the word “stories.” For example, one might write a user story like this:
The player presses right on the controller, and Mario runs that direction on the screen. He runs under a box emblazoned with a question mark. The player presses ‘A’, causing Mario to jump straight up with a sproing sound. Mario hits his head on the box, which shakes and produces a chime and a coin.
Regardless of the format used to articulate the story, the team will probably want to come up with a short name to quickly reference the story (such as “Jumping”). The full name of the story then can be given in the description of the card.
In either case, a crucial part of describing a feature is to include its conditions of satisfaction. These are the specific, measurable, assignable, relevant, and timely criteria by which anyone on the team can determine that the feature is done. These should be listed as checklist items on the card.
During or after feature articulation, the team should prioritize the stories in order of decreasing value to the user. That is, the stories that add the most value to the user should be highest priority. Keep in mind that there is an implicit dependency management process here as well: while it’s true that your players may really enjoy your dynamic quest generation system, your RPG will have no value at all if players cannot move their heroes around the screen. “Value” is about playability and not marketing or ungrounded concepts.
During this phase, the team moves features from the backlog to the Not Yet Started column. Here is an algorithm to describe the process. Note that the estimates are done in clock hours, not person-hours.
The team looks at the top priority item from the backlog and estimates how long it will take to complete, noting this on the card. (For example, in Trello, I put this number in parentheses before the name of the card.)
If the number of hours available to the team allows them to pick up the top-priority story, move it to Not Yet Started and go back to step 1.
If the number of hours available is not sufficient to complete the feature, then browse the items of slightly-lower priority that are significantly smaller to determine if there are any items that should be completed out of priority order. (Usually, the answer is “no” because value to the user is of utmost importance. However, sometimes features are of essentially equivalent priority but must be sequenced due to the restrictions of the tool.)
Repeat until the team’s plate is full.
In Scrum, it’s not the team who documents and prioritizes the user stories but the Product Owner. We are taking collective ownership of these projects, which has the benefit that everyone is involved but it also has the drawback that responsibility and authority for this process become distributed. If this leads to problems, teams can work with the project mentor to establish an appointed decision-maker.