Scrum is a project development framework frequently used in software development and specifically game development. It is an agile development method with a strong focus on visibility, accountability, team dynamics, quick pivots and finishing demoable product. It has been an essential tool at BioWare San Francisco for managing the breakneck pace of live game development, and has been transformative in my own time serving as a game producer.
There are numerous resources throughout the web that can educate you on the Scrum process. I found this brief video from Jeff Sutherland that explains the foundation of and basic tenants of Scrum. This posting explains the various Scrum concepts I reference heavily in the posts related to the Scrumification of Music, as I interpret them.
BACKLOG
The backlog is the master document owned by the Product Owner. It is a single list of all of the user stories that make up the project, ranked by priority or business value. When the team goes into sprint planning, they should simply be committing to completing as many user stories as is feasible from the top of the backlog.
BLOCKER
A blocker is anything that is preventing a team member from completing his sprint commitments. It is a team member’s responsibility to call out any blockers each morning as part of the standup, or earlier if possible. When a team member is blocked, they frequently need another member of the team to complete a task or fix part of their work, or they may require the scrum master to resolve an external dependency.
BURNDOWN CHART
A burndown chart tracks the team’s progress against completing their sprint commitments. It shows the number of total hours committed to, an ideal burn down by day, the number of hours the team has burned down each day, and estimates how many hours the team will complete by the end of the sprint. Burndown refers to completing hours of work that were identified in the sprint planning meeting.
BUSINESS VALUE
One of the primary purposes of Scrum is to ensure that the team is doing the things that are most valuable to the business. It is a frequent occurrence with a creative team that the tasks people want to work on and the tasks that are most important to work on are not the same thing. It is the product owners job to identify the business value of tasks, ensuring the product backlog is an up to date ranking of tasks based on the most recent business conditions. Tasks can easily shift in priority sprint to sprint as things change within and without the team; a well ordered backlog is the product owner’s method for ensuring the team is always working on what is important.
COMMITMENT
A key concept of Scrum is commitment. Scrum helps builds empowered teams where each player is accountable to the team for the commitments they make, and team members are able to solve problems in an environment free of micromanagement so long as they meet the identified goals. Scrum is built on commitments. During sprint planning, the team commits to completing a certain number of tasks as identified by the product owner. In return, the product owner commits to the team that he will not change course during the sprint. The structure of the sprint team focuses on team members working together to stay accountable to the commitments they have made each sprint.
DEFINITION OF DONE
Part of a user story, the definition of done is the product owner’s way of setting clear goals for each story. Definitions of done should be thorough and modular and avoid prescriptive goals. A product owner empowers his team by focusing on what the end result looks like, not how a team member should complete that task.
DEPENDENCY
Dependencies are tasks related to the completion of a task, which must be completed before work can be started. Dependencies can be internal to the team, like when a programmer must wait for an explosion animation to be completed before she can program the fireworks effect. Dependencies can be external to the team, like when a programmer cannot finish her task of integrating filters into the game’s store until the marketing team identifies the ways they would the filters to work. Dependencies should be identified and resolved as early as possible to ensure the team meets its commitments.
PRODUCT OWNER
The product owner is the person responsible for setting the team’s goals, writing users stories and thorough definitions of done, identifying business value and verifying whether or not the team has completed user stories. Frequently the product owner is responsible for working with other teams or stakeholders within the company to ensure that the team is truly unlocking business value. It is the product owner’s responsibility to empower the team to complete their goals but also to identify when the team is headed for disaster and guide it away from catastrophe. For a thorough look at how a product owner should work to build an empowered team, I recommend reading this fantastic interview with Riot Games’ Sr. Producer, Travis George.
SCRUM MASTER
The scrum master is one of two key roles specified in the scrum framework. The scrum master works on behalf of the team to help them complete their tasks. A scrum master runs sprint planning, daily stand ups, shows of value and sprint retrospectives. She is responsible for providing visibility, data and burndown charts, identifying blockers and dependencies, and resolving any issues that are preventing the team from completing their goals. The scrum master also works on long term planning and milestones, and typically works with internal and external groups that provide services to the team, such as quality assurance and localization teams.
SHOW OF VALUE
In order for a sprint to be successful, the team must complete work that can be demoed for the product owner. This focus on regularly proving the value of tasks completed gives the product owner the chance to measure if his goals have been met, if the team is truly “done” with a piece of work, and overall helps keep a project on track. Although this may introduce seemingly wasteful tasks – like a database programmer being required to make sample input and output files with fake data to prove a new operation works – in the long run these tasks keep team members focused on creating value that can be proved. The show of value is usually a meeting where team members demo their completed tasks for the product owner, who assesses the work against his definitions of done, and determines if the task has met his goals and can be marked complete.
SPRINT
A sprint is a period of time in which the team commits to completing an amount of user stories. Sprints may be between one and four weeks long, depending upon the team. At the beginning of the sprint, the team commits to completing an amount of work, and at the end of the sprint they demo that work for the product owner. In order for a sprint to be successful, the team must exit it with work whose value can be demoed to internal or external stakeholders.
SPRINT BOARD
A sprint board is a physical board set up in a central location that shows the team’s progress against their sprint commitments. The sprint board is usually a wall for of sticky notes, where each note is a task to be completed and is in one of the following columns: to do, in progress, needs verify, done. The sprint board also shows each user story and its definition of done, and a printed copy of the latest burndown chart. Anyone should be able to glance at a sprint board and understand how the team is progressing that sprint. Sprint boards can also be purely virtual, but when the team is co-located, having a public, visible sprint board can be a powerful motivating force.
SPRINT DOC
A sprint doc as we use it is a shared spreadsheet document that contains all the necessary information about that sprint, including user stories, definitions of done, tasks, estimates, stretch goals, burndown data charts and other information or breakdowns as deemed necessary by the scrum master. Each member of the team is responsible for updating their hours each morning before the daily stand up. The scrum master is responsible for the sprint doc, sprint board, and burndown charts.
SPRINT PLANNING
Sprint planning is the meeting that kicks off each sprint. During sprint planning, the team takes user stories from the backlog, breaks them down into tasks, estimates effort to complete those tasks and commits to a body of work. They may or may not assign each task to individual contributors depending on the flavor of the team. In order to insure that this required, full team meeting does not become a time suck, it is common for product owner, scrum master and discipline leads to meet ahead of sprint planning to pre-plan the sprint.
SPRINT RETROSPECTIVE
At the conclusion of each sprint, the team meets to do a postmortem on the sprint without the product owner. Sprint retrospectives are most useful, in my opinion, when they are an open and honest look at what went right and what went wrong during the sprint. It is always better to air grievances openly then to let issues that prevent the team from meeting its goals fester beneath the surface for the sake of superficial harmony. This does not mean that sprint retrospectives should be a venomous airing of grievances straight from Festivus, but the best way to clear an elephant out of a room is to acknowledge his presence and just how he got there in the first place. More important than listing what went right and what went wrong is identifying actions the team will take to prevent problems from repeating in the future.
STAND UP
Each morning, the team meets for the daily stand up. This brief, 15 minute meeting is one of the few required from all members of the team. During the stand up, each team members takes a turn updating the team on what she did yesterday, what she plans to do that day, and any dependencies or blockers that will prevent her from meeting her sprint commitments.
TASKS
During sprint planning, each user story is broken down into tasks that an individual can complete. Tasks should be granular and it is the scrum master’s job to ensure that an individual task is small and well defined. For instance, if a task is estimated at longer than 15 hours, it should probably be broken down into smaller tasks to prevent the team member from getting lost in the weeds. A tasks needs to be descriptive enough that the team member responsible for completing it should have all the details required to complete the task without going to the product owner for more information.
TIME ESTIMATES
During sprint planning, the team puts hour estimate against each task. Accurate time estimates are the cornerstone of data that provides the sprint to sprint predictability that is a goal of the framework. It generally takes any new team, even those comprised entirely of people who have worked together before, several sprints before they are able to make accurate time estimates.
USER STORIES
A user story is a description of a task or group of tasks that describes what end result will look like from the client’s perspective. For example, a user story may read “A player will be able to make her avatar jump by pressing a button on her controller.” The client of a user story can also be a member of the team, like “A game designer will be able to access a telemetry log of player performance on his latest level by visiting a page on the internal wiki.” Well written user stories written by the product owner are key to running successful sprints.
VELOCITY
Velocity is the measurement of how many hours the team can burn down each sprint. When a team can accurately track its velocity, it can make informed decisions about how much work to take on each sprint. Velocity figures help the scrum master make long term predictions and identify if the project will be completed in time, and when the team is behind schedule and needs to realign its priorities or change its dates.
WORK BRIEF
A work brief is a non-required document that I like to use as part of the scrum process. The work brief can set up an epic story or large body of work by identifying clear goals and requirements of a task, and provide any reference or background information key to completing the task. A work brief can help focus a team by communicating the spirit of what they are expected to do.
X STATEMENT
An X statement is a term widely used at EA. It is a short, simple sentence that effectively communicates the guiding idea behind a game or piece of work. For example, the X statement behind the movie Toy Story would be “Inside the secret world of toys.” A good X statement should be catchy, require little background information and quickly explain the central idea of a game to the team, executives and external stakeholders.