Agile game dev (2/5) - Keith 2010

Agile game development with Scrum, Clinton Keith, 2010

Part II - Scrum and agile planning

Read the series: 1/5, 2/5, 3/5, 4/5, and 5/5.

This part should be dealing with Scrum and agile in general, but in the book, a lot of the examples are actually drawn from game development.

Actors

The team is often collocated, and members organize themselves as they want. Scrum teams are made of 6-10 people. There should be designers, programmers, and artists in the team.

The scrum master is not a manager, but rather a sheep dog. She makes the bridge between the stakeholders, who talk about ROI or budgets, and the developers, who talk about gameplay, art, or engineering. She educates the team to scrum by reminding them that they own the product, and that debugging/polishing must happen throughout the sprint. She also facilitates planning by preparing meetings and monitoring progress. And she also puts problems to the front stage so that anyone in the team can help in solving them: bugs, dev pipeline stuck, buying a tool, or administrative issues. The scrum master is usually not a developer, and handles 2-4 teams at a time. In the game industry, the role of scrum master is often taken by producers or senior/lead developers.

The stakeholders are the customers. In the game industry, they are the publisher(s), marketing, sales, IP owners, the studio management, but also the players.

The product owner is the voice of the customers to the team. He knows the market, so his vision for the game is trusted, and he has the final word on the priority of the features to be developed. Increasing the priority of features with most value and low cost is how he maximizes the ROI for the customers. He plans releases (date and features in them) and contributes to sprint planning and sprint reviews. He regularly asks the top execs for advice (e.g. the CTO for technical feasibility). Examples of illustrious product owners include Miyamoto and Sid Meier.

User stories

A design document does not indicate which features are of highest priority. Moreover, updating it quickly is difficult. And finally, it does not communicate value to everyone. Instead, agile uses a product backlog, which is basically a list of features (called PBIs) prioritized by the product owner, with input from the team, domain experts, and stakeholders, before each sprint. The product backlog of a console game contains 300-500 stories, while an iPhone game 100-200.

PBIs are also called user stories. They take this form: "As a [role] I want [goal] so that [benefit]". Role can be "player", but can also be an artist using a tool, or a programmer using a continuous integration server. The more detailed the role, the better: "FPS expert player", "Healer", or "proficient 3DSmax designer". Everyone should be able to understand the story and see its value. For instance, "As an audio programmer, I want a checkbox to control the boolean bLooping" should instead be "As an audio programmer, I want to control the looping background sound effects." Stories are collected and estimated during a workshop attended by the team and moderated by the owner. They can also come from marketing and/or focus groups at the start of the project. Good stories show the qualities listed in INVEST:

Quality	Example
Independent	"As a player, shooting a door makes it explode with wooden particles" and "As a player, shooting a window makes it explode with glass particles" are dependent because they require the same tech. Combine them: "As a player, shooting props makes them explode with shards".
Negotiable	"As a driver, I want to see water spray when driving over water" does not harness the team's creativity. Who knows, maybe mud effects could be more appropriate. Replacement: "As a driver, I want to see effects when driving over various surfaces", and eventually add the CoS "Over water, there should be a water spray."
Valuable	"As a designer, I want all the rigid bodies that are near each other to be grouped into the same cluster" does not show value. Add "so that the game can run at 30 FPS" and everyone gets it.
Estimable	The owner should be able to estimate risk and whether the value of a story is worth its cost. When he does not know, he asks for a particular sprint called a spike to gain knowledge. Example of story in a spike: "As an owner, I want to see a video of the fighting mechanics on iPhone".
Small	Break down large tasks into small ones. Eventually group tasks worth less than an hour into a single one.
Testable	Use CoS, or a lead developer can approve stories by saying "OK, level 1 is fun", but that's subjective. A definition of completeness also helps: "the character model has been mocapped, rigged, textured, and tested in game".

Epics are large stories that require more than a dozen hours to implement. They are broken down in smaller stories as their priority increases and they are moved up the product backlog. Using "hours of work" to estimate a story size is not appropriate: teams work at different speeds, so "10 hours of work" for an experienced team may actually mean 30 hours for a team of beginners. Moreover, a story has to be broken down into developer tasks. In the end, tasks are the ones being estimated using points. The number of points completed per sprint by the team is called velocity, and it is tracked by the scrum master. Velocity is useful to gauge if a project is on time, and if changes to practices are effective.

Velocity and points are used to track progress on a burndown chart, where a flat line shows stagnation and a steep decline shows progress. The team can see their efficiency at processing tasks over the sprint, and determine if they are going to make it by the end of the sprint.

The burndown chart is usually hung in the war room, a room where the team holds its daily scrum meeting. It does not have chairs, otherwise people would be tempted to sit on them and not talk - hence the name stand-up meeting. In the war room, there is also a task board on which 3-by-5 cards are hung to show tasks and their progress. Cards are good because they can be customized, color-coded, hung on a side-wall, etc.

The release plan is a subset of the product backlog, detailing the release date and the release goals (in terms of stories). Like in the product backlog, the stories at the bottom of the release plan have low priority and have not been broken down. Stories are grouped together in goals and themes that can be tackled by the team in a single sprint.

The conditions of satisfaction specify the tests that a story should pass, ie the definition of "done" for that sprint. For instance, "As a player, I want to see enemies react when shot" can have CoS written at the back of the story's 3-by-5 card like "when shot in the head, knock-back; when shot from the right, shift left". The definition of "done" can take multiple predefined levels, such as "Runs on dev machine", "Runs on all platforms", or "No memory leak". The magazine demo usually has a demanding "done": fun and challenging, no large memory leak, no missing asset, and a clean UI. It may require a sprint dedicated only to polishing, called a "hardening sprint". The debt induced by a sprint is the amount of work remaining to reach the shippable definition of "done" after the sprint is over. When definitions of "done" are stricter, ie closer to the shippable "done", there is less risk of debt. Hardening sprints reduce debt at the expense of time.

Meetings

Meeting	When	How long	Who	Why	Details
Sprint prioritization meeting	Beginning of each sprint	Until the sprint is filled	Team, owner, scrum master, and eventually a domain expert (e.g. network programmer or mo-cap technician)	Prepare the product backlog and identify sprint goals. Establish 2 themed sprints worth of PBI. It is the opportunity for the team to ask questions to the owner and understand PBIs and the vision.	Sprint planning: The PBI "player can jump" can be broken down into the sprint backlog tasks "make jump animations: 10h", "program jumping controls: 5h", "program jump physics: 15h", and "make the sounds for jumping: 2h". PBIs at the top of the product backlog should require less than a dozen hours, and fit in a single sprint. If not, they should be broken down into smaller ones. All the tasks coming from a PBI should fit in one sprint. If not, break that PBI in smaller PBIs. PBIs at the end of the product backlog are vague and need to be broken down and detailed when their time comes. For instance, "online play" may be broken down into "lobby", "capture the flag gameplay", and "multiplayer analytics". If the team overestimated the work to be done, and has finished a few days before the end, call a mini sprint planning meeting and add a couple small PBIs to work on until the end of the sprint.
Sprint planning meeting				Add tasks to the sprint backlog from the product backlog. The scrum master first identifies constraints against the goal such as holidays or engine updates. The team and the owner then discuss the design and implementation of the highest-priority PBIs, break them in tasks, estimate the amount of work for each task, and add those tasks to the sprint backlog until there is work for the whole sprint. The owner has the last word on which PBIs the team should work on for the sprint.
Daily scrum	Daily	15 min, timebox	Team, scrum master	Share progress and impediments. Each team member explains what they've done, what they're going to do, and what is slowing them down.	"I spent 6 hours on that bug and still have not figured it out" calls for more people to look at it.
Sprint review	End of the sprint	~ 1 day	Team, owner, scrum master, stakeholders	Review of the sprint by the owner, who plays the game or watches a demo, and updates the product backlog accordingly. If not satisfied, he decides which features go back to the product backlog (to be worked on again) or are deleted. Not all stakeholders need to attend, but the publisher should be present.	Large projects with many teams should have a single big meeting with everyone. Pros: It saves time for the owner and gives a unifying vision to everyone. Con: the owner may take it as a ceremony since it's rare and there are lots of people. Alternative: the owner can review each team separately. Pros: more casual, detailed, and direct. Cons: more time consuming. When the sprint review is over, productivity won't be 100%, so the team can spend the rest of the day celebrating or playing games.
Retrospective meeting	Just after the sprint review	30min to 3h, timebox	Team, scrum master	Talk about which practices work, should stop, or be tried. The scrum master keeps track of answers and whether things are fixed or not.	"The build server should send an email when the build is broken" gives an action item for the sysadmin/build team. If no sysadmin is in the team, the scrum master should go ask the sysadmin.
Release plan meeting	End of the sprint	4-8h	Team, owner, experts, stakeholders	Discuss epics, story themes, and release goals. Prioritize and estimate stories, set the release date, and select the length and goals of the next 2 sprints.	For each story, everyone raises a card showing their point estimation. Estimations can only take values in {0 (trivial), 1, 2, 3, 5, 8, 13, 20, 40, 100}. People debate and re-vote until everyone shows the same points. Different estimates should not be averaged: this would hide matters that need to be discussed.
Planning poker				Team, owner, and experts determine the workload of a story based on similar stories already completed. Points are used, not hours, because teams have different velocities. Spend a couple minutes per user story.

Miscellanea

The sprint goals/PBIs should not change throughout the sprint. In a way, the team is "locked" on those PBIs for the duration of the sprint, unless the owner asks for a sprint reset. In a sprint reset, the team stops the tasks it was currently working on and calls a new planning meeting. A reset can happen when big goals change, such as when the CEO wants a new feature in 2 weeks to demo the game and raise funds. The team and owner should assess if it's doable, then reset. Resets can also happen when the sprint is running out of time, working overtime is not possible, and the owner does not want to remove lower-priority features from the sprint.

Sprint length: 2-4 weeks, but the owner has the last word. The length should not change too often, otherwise teams can't get used to it. Shorter sprints are appropriate in uncertain contexts such as pre-prod (when customer feedback is frequently required) or for teams new to agile or to working together. In general, 10-20% of sprints should run out of time before they end. If less, it looks like the team is fearing commitments. If more, it means they keep miscalculating, and may not take their commitments or estimations seriously.

Read more:

• Cohn 2006, Agile estimating and planning
• Cohn 2004, User stories applied