The Impact of Scrum on Project Teams

At this point, all of the project teams at Large Animal are using Scrum. Teams continue to experiment with different specific techniques and, as a result, end up doing things slightly differently from one another. However, there are some important common components.

From a high-level product planning perspective, Scrum masters (at Large Animal, producers fill the Scrum master role) use a product backlog board to lay out all of the user stories that haven't been completed and aren't in the current sprint. Each of these stories is written on an index card.

On the product backlog board, a member of the product owner team (usually a senior game designer, with input from a member of the publisher team) will arrange the user stories in priority order. The priority reflects the relative value of the story/feature within the final game. With stories arranged on the board this way, the team can approximate what work future sprints will likely contain and can project a release date for the game.

This exercise is useful for identifying red flags early, such as when the projected release date is two months past the milestone date agreed to in the contract with a publisher, or when a chain of dependencies is laid out that identifies a series of work that should be prioritized higher than it currently is.

(It should be noted that while the product backlog board is an important tool for reducing the long-term risk to a project, it is not used to commit a project team to a predetermined plan. The team only makes a commitment to complete those stories that they pull into a sprint.)

These high-level planning techniques are most effective after pre-production. During pre-production, the product backlog is still incomplete and it is extremely difficult to make schedule predictions that are accurate or useful.

Realizing the benefits of being able to react and plan against something built versus something that only exists as an idea, teams are Large Animal are trying to shorten the pre-production phase of projects and get into the production sprint cycle as soon as possible.

When the team moves a user story from the product backlog into a sprint, they physically move the card that describes the user story from the product backlog board to the sprint board. When this happens, the story is broken down into tasks that need to be completed in order to fully implement, test, and deploy the story into the game.

Teams at Large Animal find it useful to break stories into tasks as a team so that every team member can give their perspective on the work that needs to be completed to wholly realize the story. Each task is represented on its own index card and pinned to the sprint board.

The movement of the task card across the board marks the lifecycle of that task. As the task card moves it stays horizontally aligned with the story card that it belongs to. By arranging the cards on the board this way, team members can easily see their progress by looking at how the tasks of a story are placed across the board.

The sprint board is organized into columns: 'Story', 'To Do', 'In Process', 'Verify', and 'Done'. At the beginning of the sprint, the stories that will be completed during the sprint are laid out vertically in the 'Story' column.

Once tasks are generated for each story, they are pinned to the board in the 'To Do' column, next to the story that they describe. When a team member starts work on a task, they move the task card from the 'To Do' column into the 'In Process' column. Once work on the task is complete, the team member can move the task card into the 'Verify' column.

By moving the task into the 'Verify' column, the team member is indicating that they have completed the task and that they have tested their work. For most tasks for most teams at Large Animal, testing a task at this stage is an informal manual process. For a task to move from the 'Verify' column into the 'Done' column, it needs to be tested by a team member different than the one who originally completed the task.