Agile development values working software over documentation and responding to change over strict plans. This allows game development to focus on iteratively finding the fun through prototypes and user feedback. An agile game project consists of short iterations where cross-functional teams implement user stories to build knowledge and steer the project towards more valuable goals. Scrum defines roles like Product Owner to prioritize features and Scrum Master to remove impediments and ensure the team follows agile practices.

1. Agile development basics
Agile development methodology values:
● Individuals and interactions over processes and tools
● Working software over comprehensive documentation
● Responding to change over following a plan
● Customer collaboration over contract negotiation
These values have enabled agile frameworks such as Scrum, Lean, Extreme Programming etc.
Game development challenges
Feature creep ­ a term given to features being added to a project after the original scope is
defined. This happens for two reasons; the first is when the stakeholders see the game in
progress and request new features (so­called emergent requirements); two when a feature
doesn’t live up to its expectation so more work is added to find the fun.
Feature creep and changes are inevitable. This is often the main problem with writing big
designs up front (BDUF): the goal is to answer all the questions about the game. The truth is we
can’t know everything about the game at the start. Knowledge comes only when we get the
controller in hand and start playing the game at a decent frame rate on the target
machine/platform. The only way to recognize the fun is to play it. We may be certain we’re
making a first person shooter, but knowledge of exactly what types of weapons are best is
lacking. We learn more and reduce the uncertainty as we shoot the characters in the game.
Over­optimistic schedules ­ Task estimation is not an exact science. Many things throw off the
estimated time to complete a task:
● The difference in experience and productivity between people working together on a
single task
● How many other tasks a person is working on at the same time
● The stability of the build and tools used to complete the task
● The iterative nature of the task; its uncertain how many iterations will be necessary for
tuning and polishing a feature to “find the fun”
Controlling idea ­ A controlling idea is a bit similar to a business statement, but more directed
at game features. It’s objective is to capture the essence of what the game is and where the fun
factor is. The controlling idea’s essence and strength is in laying boundaries and goals.
Whenever the team is faced with a choice of “should we add this” or “does this fit” they go back
to the controlling idea and typically find the answer.

2. Production cycle:
Pre­production is the exploration of what a game is, so biggest challenge is to find the fun of
the game that will drive the entire production.
Production is a stage where the team fleshes out the story and surroundings to leverage the
mechanics created in pre­production. The challenge of production is to maximize efficiency,
minimize waste and create predictability.
Concept ­ basic description of the game idea and mechanics that could be developed into a full
game
Prototype ­ a working/playable version of the concept that allows for the user to feel the game
mechanics and find the fun in the game, which proves if its worth developing further.
Pre­production ­ preparing the game design documentation based on the prototype and user
feedback; working out what is the fun factor of the game and figuring out the game around it.
Production ­ making all the designs, code, assets, animation and everything necessary for the
releases during the production.
Post­production ­ release, marketing, promotion and post­mortem for the game.

3. According to these stages as the game is developed, the team might find itself in a position of
going through each milestone (in waterfall methodology) and reaching the set goal only to realise
they’d rather be somewhere else with no time left to change much.
By applying the scrum method through iterative game development the goal will reflect the
changes during the production so that the time

4. Why Agile Game Development?
Knowledge is key ­ game development is primarily about learning what to make and how to
make it. It’s about reducing uncertainty over time. Agile development focuses on building
knowledge about value, cost and schedule and adjusting the plan to match reality. Knowledge is
created every day.
Cost/Quality ­ costs can easily run high when developing a game, so it’s no wonder that most
games fail to break even! More cuts made on the resources used to develop a game reduce the
fun quality of the game.
Finding the fun! ­ a benefit of iterative development is to develop a product in small steps and
incrementally add features that add the most value to the game in the fastest and most
economical way. “Finding the fun” is the mantra of any iterative and incremental game
development project. The agile project curve approaches development in a value first approach.
Eliminating waste ­ by finding the fun first, the team is able to find the value early in the project
rather than trying to retrofit it at the end. Simple iteration enables game developers to explore
more ideas. This makes it possible to enact the kill­gate model, where a dozen ideas are
launched and narrowed down until the best remain.
Finding the fun:

5. Agile values in game development:
●
Individuals and interactions over processes and tools:
The main goal is to promote the team(s) to solve many of the production problems on their own.
They manage the smallest details but none of the highest levels. They unburden the leadership
of managing minor details and enable them to focus on the big picture.
●
Working/fun game over detailed documentation
Some form of design documentation is necessary, but detailed documents create work that is
not necessary so much of the work is wasted in the end. If the game follows a detailed plan
up­front it won’t be the best game possible.
●
Responding to change over following a strict plan
The agile approach is to plan what is known and to iterate against what is unknown.
Structure of an agile project
An agile project is composed of a series of iterations of development. Iterations are short
intervals of time, usually 2­4 weeks, during which the game makes progress. Developers
implement individual features that have value for the end customer each iteration. These
features are called (user) stories. Iterations include every element of game development that
takes place in an entire game project:
●
●
●
●
●
●
●
Concept
Design
Coding
Asset creation
Debugging
Optimizing
Tuning and Polishing
Agile project make steps toward a goal. The point is to use the “inspect and adapt” cycle achieve
better results sooner through the ability to steer the plan toward a more desirable goal, rather
than sticking to a strict plan and reaching the goal and then desiring to be somewhere else.
The game is reviewed at the end of every iteration, and the results influence the goal of future
iterations. This is the so­called “inspect and adapt” principle. Every 4 iterations the game is
brought to a release (build), which means the major goals are accomplished and the game is

6. getting near completion.
Agile game development flow
From left to right, studio management (stakeholders) and customers, identify the features and
other requirements (tools and infrastructure needs) for the game. These features are placed on
a list ­ Product backlog, that is prioritized by the Product owner. These product backlog items,
(PBI’s) are expressed as stories that communicate the value of each PBI to the customer and
stakeholders. Scrum teams commit to completing one or more stories from the product backlog
every iteration (this is called a sprint.), and demonstrating them in an improved version of the
game in each subsequent release (build) of the game.
A Scrum master assists each Scrum team, helping them improve impediments to progress and
ensuring that they are following the agreed progress.

7. Scrum roles
Stakeholder(s) ­ define many of the items in the product backlog and work with the product
owner to prioritize the backlog. These are some of the common stakeholder roles:
­ Publisher/producer
­ Marketing people
­ Studio management
Product owner ­ establishes and communicates the vision of the game and prioritizes its

8. features. Also is often considered the “lead customer” as a voice of the end users, even though
he’s part of the team. The product owner is responsible for:
­ Managing the ROI of the game: he’s responsible for ensuring that the investment in the game is
returned with a profit which requires extensive knowledge on what the market wants.
­ Establishing a shared vision of the game: he’s a single voice for the vision that is shared with
the team in order to ignite creativity and ownership with the team and collaborate with them as
the vision evolves with the emerging game.
­ Knowing what to build and in what order: he owns the product backlog and determines the
order of features on the backlog. This order determines the order in which those features are
developed.
­ Creating release plans and establishing delivery dates: he manages release plans based on
changes to the goals or the progress from the team during sprints.
­ Supporting sprint planning and reviews:
● Establishing and updating the features on the backlog and their priorities
● Participating in sprint planning
● Accepting or rejecting the results of the sprint in sprint reviews
­ Representing the end user/player: he makes sure the game has the necessary value for the
end user.
Scrum master ­ His role is to make sure the scrum is a success and he must apply the
principles of scrum and guide the team through the practices.
Scrummaster is responsible for:
­ Ensures impediments are addressed: the scrummaster tracks all impediments discovered in
the development process (bugs, crashes, meetings without results, constant distraction to the
process, progress of each individual on the team on particular tasks...)
­ Monitors overall progress: he makes sure the team knows how well they’re performing against
their current goal on a daily basis. If they’re behind the schedule the team is informed as soon as
possible.
­ Facilitates planning, reviews and retrospectives: prepares all team meetings, agendas and
makes sure the time limit is agreed on for each meeting.
­ Helps the team communicate and improve performance: even with the most productive team
the scrum master seeks new ways of getting more out of them. He might recognize problems
ahead of the team but should never lead with implementation the solution but rather guide/allow

9. the team to see and own the solution to the issue.
The big picture
A game made with Scrum makes progress in 2­4 week iterations, or sprints, using
cross­disciplined teams of 6­10 people depending on the need to complete a sprint. at the start
of a sprint, during the sprint planning meeting, the team selects a number of features from the
product backlog. The team then estimates the tasks required to implement each PBI into a
sprint. The team only commits to features in a sprint they judge to be achievable.
Sprint meetings (daily scrum) can be held daily or 2­3 times a week, but are always limited to 15
minutes (timebox) where the team shares their progress or any impediments in their work.
Timebox is a fixed amount of time given to a meeting or a task. The 15 minute timeboxed
meeting will end at the 15­minute mark regardless of whether all the agenda items are
addressed, which pushes the team to be as short and to the point in a meeting as possible.
The principles of Scrum
As a framework Scrum is meant to have practices added and changed as teams and products
evolve.
­ Empiricism: scrum uses an “inspect and adapt” cycle that enables the team and stakeholders
to respond to emerging knowledge and changing conditions in real time using actual data gained

10. in the development process. scrum meeting enable teams to respond quickly to daily issues.
­ Emergence: As the game is developed we learn more about the game and what makes it fun,
what is possible and how best to create it. Scrum practices don’t ban designs from being
developed upfront. They acknowledge that we can’t know everything about a game from the
start.
­ Timeboxing: Scrum is iterative. it delivers value on a regular basis and enables stakeholders
and developers to synchronize and micro­steer the project as value emerges. Sprints are an
expression of this timeboxed practice.
­ Prioritization: Some features are more important to stakeholders and customers than others.
Rather than approaching the development of a game by “implementing everything in the design
document”, Scrum projects develop features for a game based on their value to the player who
will buy the game. This is what the product backlog is for.
­ Self­organization: Small, cross­discipline teams are empowered to organize their
membership, manage their process, and create the best possible product within the timeboxes.
They use the “inspect and adapt” cycle to continually improve the work.
Scrum parts
Product backlog ­ a prioritized list of the requirements or features for a game or the pipeline for
making a game. Example:
● Add a new character/enemy on the second level
● Add a particle effect to the game
● Add online gameplay
The product backlog is allowed to change after a sprint. PBI’s that weren’t anticipated are then
added, those that aren’t necessary are removed and the priorities changed if necessary. The
value of every feature is measured in terms of how valuable it will be to the player. This
minimizes work based on assumption.
The most valuable items in the backlog are broken down into smaller features to fit into a sprint
that the team can handle.
Sprints ­ a scrum project makes progress in sprints, which are in effect the heartbeat of the
entire project. sprints have a fixed duration 2­4 weeks (can be shorter if necessary) and the team
commits to the PBI’s they can complete in a single sprint. Sprints produce vertical slices of
functionality, sort of like mini­projects on their own that contain everything necessary to get the
game to a shippable state (coding, design, asset creation, debugging etc.)At the end of a sprint
the team has a new build of the game that demonstrates that the sprint goal was reached.

11. Releases ­ are a set of sprints meant to bring the game with major new features to a
near­shippable state. A typical release lasts between 1­2 months, sometimes more.
Sprints
Planning ­ the stakeholder, scrummaster and product owner meet with the team to groom the
backlog and identify the sprint goal. The sprint planning meeting creates the sprint backlog that
defines the work that the team commits to completing buy the next sprint review.

12. Prioritization ­ this is where the team meets to set the sprint goals for the high priority items on
the backlog with the product owner describing the features on the backlog that the team needs to
understand in order to evaluate. This is where the team raises questions, concerns about details
and requirements for each item. If the items are too large for a single sprint they are broken
down into several PBI’s that can fit into sprints.

13. Sprint meeting:
●
●
●
What have I done since the last meeting?
What am I going to accomplish for the next meeting?
What are the problems slowing me down?
Sprint review:
● What things should we stop doing? ­ Practices that have brought problems in the dev
process
● What should we start doing? ­ Practices that help the dev process
● What is working well for us? ­ Practices that we should continue in the process
Sprint resets
When the sprint that the team started working on doesn’t seem achievable for a variety of
reasons (sprint goal needs to change, running out of time, wrong estimate etc.) the team has 3
choices:
1. Work overtime to make up for the difference
2. Negotiate with the product owner to remove one or more of the lower priority PBI’s or
remove part of the PBI
3. Request a sprint reset. Set a new sprint with a more achievable goal.
Everyone on the team needs to be aware of the cost of each of these options for the production
cycle, both money and time­wise so that the best option can be chosen. If the sprint is reset all
the unfinished PBI’s are returned to the backlog and the team returns to sprint planning.
Stories
Stories are a template for expressing the value of a feature/item to the end user. Team

14. completes one or sometimes more stories per sprint. Usually the stories are formulated in this
manner:
As a <user role>, I want <goal> [so that <reason>].
●
●
●
User role ­ a player of the game or a user of the pipeline who benefits from this story
Goal ­ the clear goal of the story. This is a feature or function in the game or pipeline.
Reason ­ benefit to the player when this feature is used in the game.
Spikes
Spikes are important for video game development. They are timeboxed stories that address
areas of great uncertainty and their goal is to create knowledge that help the product owner

15. evaluate the cost of other stories. Example:
“As a product owner I want to see a mock­up video/animation of how our fighting mechanic
would look on an iPhone”
Stories are sized appropriately to fit into a sprint, if they are too big they’re disaggregated into
smaller ones, or if too small can be combined into a larger story to manage more easily by the
team in a sprint. From these sprints a list of tasks can be created so the production can be
clearly tracked over time.
Task list (Boards in Trello)
What happens to the design document?
Stories collected on a product backlog are intended to replace much of the design
documentation. Best practice is to still maintain a technical design document that lists technical
risks and strategies for overcoming those risks, but use it to help prioritize the backlog, which is
where all work done by the team originates.
Product backlog
Prioritizing

16. ●
Value ­ the value that the story has for the player is the primary criteria in determining the
priority of that story on the product backlog. By focusing the team’s effort on adding
highest value every sprint, the product owner is generating the best possible ROI.
● Cost ­ is the key factor is product owner’s ROI calculation. Some highly desirable
features might cost too much to implement. Two equally valuable features are often
prioritized by cost, so the lower­cost feature is given a higher priority.
● Risk ­ implies uncertainty about value and cost. stories with higher risk are placed higher
on the product backlog to refine a product owner’s understanding of value and cost of a
feature.
● Knowledge ­ sometimes the product owner doesn’t know the value, risk or cost of a
feature. So they might introduce a timeboxed story (spike) for a prototype limiting how
much time team spends working on it to gain more knowledge on the item.
Scrum team(s)
Scrum creates conditions that enable teams to achieve greatness through its practices and
principles.
● Cross­discipline teams ­ enables teams to deliver features and mechanics that
represent clear value for the user
● Self­management ­ enables teams to select the amount of work they can commit to

17. every sprint and complete it through whatever means necessary
● Self­organization ­ enables team to have a degree of authority and responsibility to
select their membership role
● True leadership ­ provide leadership focused on mentoring and facilitation to free the
best performance possible from the team by finding the approach between
micro­managing teams and throwing them in over their head. Both of these extremes will
lead to failure.
Cost of change
Changes made late in the project can result in costs that are a magnitude or more greater than if
those changes were made early in the project.
Too much architecture upfront
● It slows the introduction of new features upfront
● Architectures designed upfront often need to be changed later
● Changing bigger systems is more costly than changing smaller ones
Role of documentation
A goal of a design document is to share the vision about the game with the team. Relying solely
on a document to share a vision is full of weaknesses:
●
Documents aren’t the best form of communication ­ much of the information between an
author and reader is lost.

18. ●
Vision changes over time ­ documents are poor databases of change. Don’t expect team
members to revisit the design documentation to find modifications. Daily conversation,
meaningful sprint and release planning and reviews are all places to share vision.