Originally Published 12/4/2020
The Scrum process is the ideal method for creating a complex product in a complex environment. With its intricacies of software development, game design, art asset creation, sound, story, and more, video game development is a complex product and environment.
Logically, Scrum is the perfect framework for building video games.
This is especially true considering the shift in the industry towards the ‘Game as a Service’ business model as opposed to the antiquated ‘build it, ship it and forget it’ model.
It Starts with an Idea
The game starts with a stakeholder communicating an idea for a new game to a Product Owner. The Product Owner collaborates with the stakeholder to understand the concept and discover the value the idea offers to the market.
The Idea Turns into a Product Goal
Let's assume the idea is to produce a multiplayer Real Time Strategy (RTS) game for Android and iOS. The Product Goal could be: To create a multiplayer F2P RTS which will generate at least $10,000 per month in revenue.
Product Goal Births the Product Backlog
The Product Goal is documented in the Product Backlog, which ensures the goal for the product is transparent to the team and internal stakeholders.
The Product Owner would then begin filling the Product Backlog with new Product Backlog Items (PBIs). In theory, these PBIs represent the work that needs to be completed to accomplish the Product Goal.
A tool used to document PBIs is a User Story. User Stories follow the general template: “As a [stakeholder], I want [some result] so that I [some justification].”
This template allows transparency for technical and non-technical people to understand the PBI and its context.
An early User Story for our RTS game may include: “As the Product Owner, I want two core game loops proposed and documented. As a result, I can A/B test them to gather initial market feedback on the level of interest in each game idea.”
Want to get started with Scrum but don’t know how? Click here to connect with our experts!
Backlog Refinement
The Product Owner will review and refine the PBIs for clarification, documentation, decomposition, and size.
The goal is to create PBIs that developers can complete in one Sprint of work. These refined PBIs have an estimated level of effort and a shared, transparent understanding of what is needed to complete it. This process may involve the Scrum Team, stakeholders, and even consultants.
Going back to our RTS example, let us use the following story: “As a Player, I want to battle another Player so I can have fun.”
This initial story is expansive. During Backlog Refinement, the Product Owner may break up this story into multiple specific stories that developers can realistically complete in a single Sprint.
For example:
- As a Player, I want to see a list of my online friends to ask them to battle with me.
- As a Player, I want to start a Battle to play the game.
- As a Player, I want to select a Unit to command it.
- As a Player, I want to instruct a Unit to attack another unit or building so I can destroy it.
- As a Player, I want to destroy other Player’s units or buildings to progress toward winning the game.
These PBIs would include detailed descriptions, including Acceptance Criteria. Acceptance Criteria are an agreed-upon set of items that developers must complete before an associated PBI can be considered complete.
The goal is to convey as much information as possible about what the PBI requires to ensure the Development Team has a good idea of how to complete the story.
Sprint Planning
The Scrum Team uses a Sprint Planning event to:
- Set the Sprint Goal
- Select and refine PBIs for the Sprint
- Plan how to turn the PBIs into increments of value
Setting the Sprint Goal gives the team a common objective to work toward and communicates to stakeholders the value of the Sprint.
Selecting and Refining PBIs for the Sprint increases the Development Team’s understanding and confidence in completing the chosen work. The selected PBIs for the new Sprint are added to the Sprint Backlog and are considered Sprint Backlog Items (SBIs).
Planning how to turn the SBIs into increments of value allows the Development Team to own the production of the increment. These plans also inform how the SBI will be completed within the Sprint according to the Acceptance Criteria.
During this time, the Development Team may break down SBIs into smaller tasks at their discretion. The team is ultimately accountable for completing the SBIs and achieving the Sprint Goal.
Our RTS example could have a Sprint Goal like this one: "Produce an increment that is playable for two people where one Player can win.”
The above Sprint Goal would give the Development Team an overall goal to work toward while working through the 5 PBIs referenced in the “Backlog Refinement” Section. The Development Team ensures it has a good, well-understood plan before beginning development.
Daily Scrum
The Daily Scrum is intended for the Development Team members to inspect its progress toward SBI & Sprint Goal completion. Based on this inspection, the team may adapt to ensure it completes the Sprint successfully.
Sprint Review
The Sprint Review is a meeting that allows the Scrum Team and Stakeholders to inspect the result of the Sprint.
The Development Team demonstrates the product, verifying each SBI is complete. If it’s determined that an SBI does not meet the Acceptance Criteria, then the SBI is returned to the Product Backlog for consideration in a subsequent Sprint.
This event encourages feedback and often creates new PBIs for future Sprints.
At the Sprint Review, we would have a potentially shippable, complete increment of our RTS game. It may not be pretty and may have some UX issues – but it is playable!
UX and aesthetic improvements would likely be discussed during this event and documented in the Product Backlog.
The main takeaway is that we have produced an increment of the RTS that we can use in the following:
- Focus groups
- Show friends and family
- Demo to investors
- Play ourselves
This provides the opportunity to generate interest, get feedback, adapt the design, and continuously improve without a significant upfront investment.
Sprint Retrospective
The Sprint Retrospective allows the Development Team to inspect and adapt how the work was done. The team plans ways to increase the effectiveness of their work and the quality of the product they produced.
An example of the team's plans for our RTS game may be:
- The addition of unit testing
- An added or new framework or methodology to be utilized
- A new software library to make some aspects of the game easier to implement
Conclusion
The Scrum Framework has a well-deserved seat at a game development table.
Scrum encourages creating value very early in development. This value can then be used to prove hypotheses about what makes a game fun to play.
Using Scrum as an agile framework to create games is a perfect match!
Interested in Scrum? Download the Scrum Guide here.
.svg){kind=small}
.svg){kind=small}
