Reading notes - Agile Game Development with Scrum, Clinton Keith
Clinton Keith was part of Sammy Studios, developing Darkwatch (at the time meant to rival Halo). They had all the reseources any game devs could want – within a year it was 6 months behind schedule. From here Agile met game devleopment.
Scrum, Lean and Extreme Programming are methodologies of Agile game development.
“What has led us to bloated budgets, schedules that are never met, and
project overtime death marches?” Preface xxi
"An industry that sold its good in Ziploc bags now rakes in more cash than the Hollywood box office". Pg3
Home computer and console market driven by Moore's Law. "Every several years a new generation of processors rolls off the fabrication lines, the performance of which dwarfs that of the previous generation. Consumers have an insatiabke thirst for the features this power provides, while developers rush to quench those thirsts with power-hungry applications." pg5
The mid-80s saw the decline in the video game market. Falling hardware costs allowed almost anyone to create a game; which they did and which flooded the market. Consumers decided to spend money on other things.
Illustration 1: Waterfall game development
When games got more expensive to make due to techological developments allowing greater results and of course meaning more people were required to produce tese results; different methods were adopted for game development. One was a Waterfall style methodology. Each stage was more expensive than the last. The flip side here is, most of the design is performed early on – most of the testing is made late on.
"By the ninteies, small teams of severl people were required to create games, and they often took longer than several months to finish. This raised the cost of creating games proportionally, and they've continued to rise..." pg8 But the hits dont pay for as many misses as they did like 30 years ago - it's getting to the stage now where every game a publishers releases will have to be a hit just to break even
The hit-or-miss model. One hit pays for many failures.
"Most recent games go over budget and fail to stay on schedule" pg10. The decline fo the hit-or-miss model has resulted in three things for studios; Less innovation, less game value (poor game), deteriorating work environment for devs and makers.
Typically, games dont last as long now as they used to, so consumers are less willing to shell out £60 for a game. As a result, rentals and second-hand / trading has blossomed
The agile manifesto;
In development, a lot is planned but a lot changes also. For example; when testing a first person shooter, the type of guns desired / required may change depending on what feels right.
Illustration 2: Reducing uncertainty
"Production should begin when the uncertainty about the gaame mechanics and the uncertainty of the technology and tools to make the game have been reduced." pg19
Illustration 3: Uncertainty
Clint Keith warns us to be wary of entering into production too soon, without the proper knowledge of what to build. A team could spend a lot of time in production building things which are based on assumption.
"Game development is primarliy about learning what to make and how to make it". Pg21
“Agile development focuses on building knowledge about value, cost, and schedule and adjusting the plan to match reality.” pg21
"Find the fun" is the mantra of any iterative and incremental game development project. Pg23. The fun must be found at every step, or iteration. A game that isn't fun must be questioned at each stage. Try to find the fun first off. It also works from the techie side; fixing a bug minutes or days after it was created is way better than trying to delve in and sort it out months down the line.
Delivering working / playable software in interation will help to ID problems as allow you to assess ideas.
Part of Agile methodology is to have smaller teams of multi-disciplines who are in charge of more decisions, decisions on small scale; giving them more ownership and freeing up higher management.
Fixed milestone deliverables in a contract – good or bad?
The agile method means; Plan for what is known, iterate against what is not known. An agile project is composed of a series of iterations of development. Iterations are short intervals of time, usually 2 or 4 weeks, during which the game makes progress. Developers implement individual features that have value to customers / players at every iteration. These features are called user stories.
Iterations include every aspect of development, eg; concept, coding, asset creation, debugging optimising, etc. The game is reviewed at the end of every iteration and the results influence the goals of future iterations. Inspect and adapt. "The first iterations of a project will often focus on building the minimum necessary infrastructure, if one does not exist, before any valuable gameplay is seen.” pg29
Illustration 4: Agile development not constrained to original goals
PART II: SCRUM & AGILE PLANNING
How can I apply Scrum methodology to myself? It seems designed for teams of people in an organisation...Think of Keith's Industrial Revolution analogy...perhaps think of Scrum as a production line where one product is assembled at various stages. Each stage is QC'd before it progresses onto the next stage. Every 2 to 4 weeks the stages are assesed to see if they can be improved towards making both the end product AND the experience of making it, better.
Each Product Baclog Item (PBI) has a list of tasks developed which are required in order to make the particular PBI happen. Say I want to make a player able to make a character jump in-game...
This course of this task or Sprint is between2 to 4 weeks and each day, they team has a daily scrum to share progress and impediments of their work. The objective of the sprint is the sprint goal. Releases are a set of sprints desinged to bring about major new features in a game. They usually last about 2 to 4 months. Releases start with a planning session that establishes the major goals for te game.
"The value of each feature to the player is used to prioritise the backlog." pg42
The most important PBIs are at the top of the list (the Product Backlog). PBIs at the bottom of the list as they only rise to the top when I'm closer to implementing them. Breaking down each PBI from the Product Backlog must be done in order to understand the tasks required to undertake during the sprint.
Illustration 5: Sprint method for a more complex issue
One of the roles I have is that of Product Owner. I'm responsible for communicating the vision of the game and maximising return on investment. I need to understand the market and business aspects of the project. I am the scrum team and I am the developer, self-organsing and self-managing. I determine how much work I can commit to at the start of a sprint and take responsibility to deliver it. I must reduce impediments!
It's important that I conduct sprint reviews at the end of each iteration.
Tracking Progress:
Task Cards (different colour cards which prioritise work)
Burndown charts (a line graph, hours ndded to complete tasks v days left). Look these up.
Task board (below is a Task Board example; a list of PBIs which with related tasks which are moved depending on what state the PBI task is in. The second column is the tasks relating to completing each PBI).
User Stories
Stakeholder's language is business. Artist's language is that of polygons and tecure and lighting. Programmer's language is that of math and code. A universal language must be spoken, that of the consumer or player.
A User Story is a short description of a game, tool or pipeline feature that has a clear value to the user. If the feature is a tool or pipeline change, the user can be a developer who uses the tool or pipeline to make the game. Who are you? What do you want? Why do you want it?
Teams complete one or more user stories per sprint. We dont want to break down every large feature into sprint sized stories at the start of a project. That creates too many stories to be practically managed by the product owner; me. Instead, priority determines when features are broken down. User stories that are too large to be accomplished in a single sprint are called epics (like a player wanting an online gaming feature; which leads to different types of online gaming desires and the ability to decide which game to join in a lobby). Sometimes a number of related user stories are gathered together in a theme.
The following INVEST attributes are suggested for the makings of a good story;
INDEPENDENT - Stories should be independent of other stories in the order they are implimented. Dependecies create problems which make things hard to prioritise.
NEGOTIABLE – Stories are not locked in contracts. They're placeholders for conversation where things can change which will add value and allows better ideas to rise up.
VALUABLE – Stories need to communicate value to the player and the team developing the game.
ESTIMATABLE - A spike is a story introduced to add knowledge about the cost of implementing the feature - a story which at this point may be simple OR complicated to implement. The story such as this will be timeboxed so a great deal of time and effort wont be spent on it. This helps the story be estimatable.
SIZED APPROPRIATELY – Stories need to be made small enough to fit into a sprint. A group of stories can be gathered together to form one story theme; for example bug fixes. Each bug doesn't require its own story but they can be lumped together to make a theme.
TESTABLE – A story must be verified before the end of a sprint. An agreement on what done means has to occur before each story is broken down into tasks. This is where Conditions of satisfaction come in; agreements of what is included in a completed User Story to consider it done. For example; As a designer, I want to have my chatacter jump across a gap to determine whether the mechanic is fun. CoS: Poses will be used in place of any animation
Collecting stories
Collecting stories in the product backlog is an ongoing process that occurs
throughout development.At the start of an agile project, the team and stakeholders collect enough stories to encompass all the major requirements (epics) known and enough detailed stories to enable the team to start iterating. A useful exercise is the story-gathering workshop brings stakeholders and teams together to brainstorm user stories for the game. At the first workshop, the major epics are identified. An example of an initial summary of epics for a first-person shooter might resemble the below;
If the teams confirm that they have the necessary specialists to accomplish work in these areas, then the workshop focuses on breaking out stories sized appropriately. When epics are broken down, smaller epics are revealed. A smaller epic for player control is below;
Some benefits of agile planning
Features are built in the order of the value they add for the consumers who buy the game. Delivering the highest-value playable features ahead of lower-value ones drives the development of the game rather than a preset ordered list of work.
Plan continually: Plans created at the start of a project are very good at telling us when the project has failed. Agile planning continually fine-tunes the course of the project to avoid pitfalls and to double down on valuable practices and features. They help teams find success.
The Product Backlog
The product backlog is a prioritized collection of user stories. Its goals are to do the following:
Enable stories to be prioritized so that the team is always working on the most important features
Support continual planning as the game emerges so the plan matches reality
Improve forecasts so that the stakeholders make the best decisions about the project goals
Every sprint they take stories off the top of the product backlog and break them down into small tasks that they estimate in hours. Defining the details of the highest priority stories is where most of the planning effort needs to take place.
Prioritizing the Product Backlog
Value: The value that a story adds for the player who buys the game
is the main criteria in determining the priority of that story on the
product backlog. The sprint team measure value using their own judgment, feedback from
focus testing, and feedback from stakeholders.
Cost: Cost is a key factor in the product owner’s ROI calculation.
Some highly desirable features might cost too much to implement.
Risk: Risk implies uncertainty about value and cost. Stories with higher risk are often
prioritized higher to refine a product owner’s understanding of value
and cost.
Knowledge: Sometimes the product owner doesn’t know the value,
risk, or cost of a feature. They simply need more information. In this
case, they could introduce a timeboxed story for a prototype or experiment
to the product backlog. This is the spike and it limits how much time the team spends working on it and is intended
to produce information alone.
Story points can also help the estimation process. Velocity is measured as the number of story
points accomplished every sprint. For example in modelling; one story point might be assigned to modelling a car - so therefore modelling two cars equals two story points. Modelling a character might be the equivalent amount of work; two story points. Projects need to define a set of numbers that they use for story point estimates. The two rules of thumb for selecting a set of story points are that the entire scale be within two orders of magnitude. For example, a range of 1 to
100 or a range of 1,000 to 100,000 works. This might work well for me (expecially at the start) as I'm not sure how long things will take but I'll have an idea of the effort required.
Release planning
This is where I'm at, so this diagram is relevant to me right now;
For many games developed using agile, there is still a need to separate some of the development activities.Most game development projects have stages regardless of whether they are agile or not. These stages change how teams develop the game:
Stages of Game Dvelopment
The framework used is still Scrum, but teams adjust the practices for the current stage.
Concept: This stage occurs before pre-production. Concept development is almost purely iterative. Ideas are generated, possibly prototyped, and thrown away on a regular basis. This stage is usually
timeboxed
Concept with Scrum: Sprints are shorter, and most of the stories in the very small backlog are spikes. The main goal of the conceptual stage is to create knowledge for the team and stakeholders, not value for the consumers. Release goals are concept treatments and perhaps a prototype
to demonstrate to stakeholders.
Pre-production: Teams explore what is fun and how they are going to build assets to support it during production. They also create levels and other assets that represent production quality. This stage is fully iterative and incremental.
Pre-production with Scrum: Scrum is used to discover the fun of the game and
incrementally and iteratively build value and knowledge about production
costs. Development is paced by sprints and releases. Release
goals are major features.
Production: The team focuses on creating an experience using the core mechanics and processes discovered during pre-production. Teams iterate less on core mechanics discovered during pre-production because they are building a great deal of assets based on them. It’s critical to discover and lock down such metrics during pre-production.
Production with Scrum: Teams produce assets that were identified in preproduction
and incrementally improve the asset pipelines. Although
sprints and releases are still used, the pace of asset production
becomes the metric for measuring velocity.
Post-production: With the content brought to shippable quality, the team focuses on polishing the whole game experience. This stage improves the game incrementally. Following this, the game is submitted to hardware testing.
Post-production with Scrum: Teams focus on tuning, polishing, and bug fixing
tasks they identify daily. The goals are driven more by the daily backlog (which includes bug
fixes and polishing tasks) and upcoming key dates such as submission.
Post-production starts on the alpha date and includes the beta and
shipping dates.
Some stages will overlap. For example, rather than an official “production start date,” teams see a
gradual buildup of production activities and a drop-off of pre-production work in the middle of the project.
Series of sprints = a release. A series of releases = a consumer ready game
a player driving past
a 10,000-polygon fire hydrant does not experience 50 times the value of a
200-polygon fire hydrant.
Glossary
BDUF = Big Design Up Front
Conditions of Satisfaction = which clarify the goal of a User Story it it's too ambiguous
Crunch = projects with loads of overtime
Emergent requirements = when stakeholders want more stuff added to the game during development
Feature Creep = Features being added to a project after the original scope is defined.
Iterative = repetition of a mathematical or computational procedure applied to the result of a previous application, typically as a means of obtaining successively closer approximations to the solution of a problem.
Kill-gate = a method of development where a number of prototypes are made but only one “top” one makes it through. The best wins and the others are stopped at the “gate” and “killed”.
Pre-production = to find the fun of the game that drives the production
Production = the stage where the team builds a few hours of content (characters / levels). Production fleshes out the story and surroundings to leverage the mechanics created in pre-production.
Timebox = fixed amount of time for a meeting or task















