What is Scrum?
“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems” (Scrum Guide 2020 Version).
Scrum consists of Events and Artifacts which provide opportunities to embrace empiricism to drive decisions and ultimately, produce value for stakeholders.
- Sprint: Time-Boxed to 1 month or less, this is a period where the other Scrum Events occur and where the Value is produced in the form of at least one Increment
- Sprint Planning: Time-Boxed to 8 hours for a 1-month sprint, this is where a Sprint Goal, what can be done in this sprint, and how will the chosen work get done are defined by the team
- Daily Scrum: Time-Boxed to 15 minutes, this is where the development team inspects and adapts their plan of work to ensure they are on track to achieving the Sprint Goal
- Sprint Review: Time-Boxed to 4 hours for a 1-month sprint, this is where the outcome of the sprint is presented to stakeholders to inspect, and discussion occurs on how to adapt the product in the next Sprint
- Sprint Retrospective: Time-Boxed to 3 hours for a 1-month sprint, this event provides the team the opportunity to inspect and adapt how the work gets done.
- Product Backlog: According to the Scrum Guide: “The Product Backlog is an emergent, ordered list of what is needed to improve the product.”
- Sprint Backlog: “The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).”
- Increment: “An Increment is a concrete stepping stone toward the Product Goal.”
Scrum & Empiricism
Scrum has its roots in empiricism which encompasses ideas around knowledge being obtained from experience and observation and that decisions should be made based on such observation. Transparency, Inspection and Adaptation are known as empirical Scrum Pillars and are the foundation for the value which Scrum can bring to complex projects like Game Development.
Empirical Scrum Pillar: Transparency
According to the Scrum Guide, “Transparency enables inspection. Inspection without transparency is misleading and wasteful.” This pillar is driven by the Scrum Artifacts mentioned above as a vehicle to produce the opportunity to be transparent within a project. This is only an opportunity however, because real transparency requires trust. Development team members must trust that there will be no serious repercussions from their being transparent about the current state of a Sprint for instance. This trust is fostered through company culture and the team learning to embrace Scrum’s Values.
Empirical Scrum Pillar: Inspection
The Scrum Guide states “Inspection enables adaptation. Inspection without adaptation is considered pointless.” Inspection allows the mitigation of risk. This risk includes things such as not achieving the sprint goal, producing a product that is not valuable or does not meet the expectations of the stakeholders, and the risk of process-improvement stagnation.
Empirical Scrum Pillar: Adaptation
As per the Scrum Guide, “If any aspects of a process deviate outside acceptable limits or if the resulting product is unacceptable, the process being applied or the materials being produced must be adjusted. The adjustment must be made as soon as possible to minimize further deviation.”
Scrum Values help guide the organization and its people in their actions, decisions and behavior. Fully embracing these values are essential to successful Scrum implementation and breathe life into the three Empirical Scrum Pillars. There are 5 Scrum Values as follows:
- Commitment: Achieving Sprint and Product goals require commitment. Team members commit to supporting each other in the pursuit of these goals.
- Focus: Achieving Sprint and Product goals also require focus – the team all must focus on the work in the sprint.
- Openness: This is required to ensure Transparency is realized, the team and stakeholders all must remain open about the work, complexities of the work and issues faced.
- Respect: A two-way street, the team members must respect each other. The rest of the organization and stakeholders must respect the team. This respect implies a mutual understanding that people are capable and independent.
- Courage: Embodies the team’s willingness to do the right thing and work on tough problems. It also takes courage to be open.
The Scrum Framework recognizes just 3 titles:
- Product Owner: Is the sole person accountable for maintaining and updating the Product Backlog.
- Development Team: Includes everyone needed to successfully achieve the Sprint Goal. They are responsible for the Sprint Backlog (planning how the work will get done) and holding each other accountable for achieving the Sprint Goal.
- Scrum Master: Coaches and serves the Product Owner, Development team and the entire Organization.
There are many additional facets to Scrum which were not covered here. What we have covered should be enough of an overview to discuss how Scrum can fit into a Game Development project. If you would like to learn more about the Scrum Framework, check out Scrum.Org – this site is a wonderful, free resource for all things Scrum.
Scrum & Game Development
Scrum is ideal for producing a complex product in a complex environment. Video game development is certainly a complex product, and software development in general is certainly a complex environment. Scrum seems to be a perfect framework to use to build video games. This rings especially true considering the shift in the industry which is driving a ‘Game as a Service’ business model as opposed to the antiquated ‘Build it, ship it and forget it’ model.
It Starts with an Idea
It would all start by a stakeholder communicating an idea for a new game to our Product Owner. Our Product Owner would collaborate with the stakeholder to understand the idea and the value proposition the idea offers to the market.
The Idea Turns into a Product Goal
For this thought exercise, lets assume the idea is to produce a multiplayer Real Time Strategy (RTS) game for Android and iOS. The Product Goal would be: To produce 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. Our Product Owner would then begin populating the Product Backlog with new Product Backlog Items (PBI’s). These Product Backlog Items represent work which in theory, once completed, will facilitate the achievement of the Product Goal.
Product Backlog Items (PBIs)
A non-Scrum tool used to document PBIs is the User Story which follows the general template: ‘As a [stakeholder], I want [some result] so that I [some justification]’. Using this template allows transparency for technical and non-technical people to understand the PBI and the context surrounding it. An early User Story for our RTS game may include something like: ‘As the Product Owner, I want two core game loops proposed and documented so that I can use them in A/B testing to gather initial market feedback on the level of interest in two game ideas.
The Product Owner will engage in Backlog Refining activities which serve to clarify, document, decompose, prioritize and size PBIs. This results in PBIs which can be completed in one Sprint, have an estimated level of effort, and have a shared, transparent understanding of what is needed to complete the PBI. This process may involve the Scrum Team, stakeholders and even consultants.
Going back to our RTS thought exercise let us use the following example story: As a Player, I want to control battle another Player so I can have fun. This initial story is very broad. During Backlog Refinement activities, the Product Owner may decompose this story into multiple stories which are more specific and more realistically completed in a single Sprint. For example:
- As a Player, I want to see a list of my friends who are online so I can ask them to battle with me.
- As a Player, I want to start a Battle so I can play the game.
- As a Player, I want to select a Unit so I can 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 so I can progress toward winning the game.
Further refinement of these PBIs would include detailed descriptions on each. The goal is to convey as much information about what the PBI requires as reasonable to ensure the Development Team has a good idea how to complete the story.
The Scrum Team uses this event to accomplish 3 major objectives: Set the Sprint Goal, Select and refine PBIs for the Sprint, and finally plan how to turn the PBIs into increments of value.
Setting the goal of the Sprint 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 serves the purpose of increasing the development team’s understanding and confidence in their ability to complete the selected 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 and how it is to be completed within the Definition of Done during the Sprint. During this time, the Development Team may decompose the SBIs down into smaller tasks at their discretion. The team is ultimately accountable for completing the SBIs and achieving the Sprint Goal.
Our RTS example would result in a Sprint Goal like “Produce an increment that is Playable with two people and one Player to win.” This would give the development team the overall goal to work toward while thinking through and completing the 5 PBIs above (in the Backlog Refining Section). The Development team would ensure it had a good, well understood plan in place before kicking off the development effort.
The Daily Scrum is intended solely for the Development Team to inspect its progress toward SBI & Sprint Goal completion. Based on this inspection, the team may adapt to ensure it completes the Sprint Successfully.
This allows the Scrum Team and Stakeholders to inspect the result of the Sprint, the Product Increment. The Development Team demonstrates the product during this meeting, each SBI is verified as complete. If it is determined that a SBI does not meet the definition of done, then the SBI is returned to the Product Backlog for consideration in a subsequent Sprint. This event also fosters feedback and often results in new PBI being created for consideration in future sprints as well.
At this point, we would have a potentially shippable, complete increment of our RTS game. It may not be pretty; it may have some UX issues – but it is playable! The UX and aesthetic improvements likely be discussed during this event and documented in the Product Backlog. The main takeaway from this is that we have produced an increment of the RTS that we can then use in focus groups, show friends, demo to family, have investors take a look, and play ourselves. This provides ample opportunity to generate interest, get feedback, and adapt the design or direction without a large investment up front.
The Sprint Retrospective event allows the development team to inspect and adapt the way the work gets done. The team plans ways to increase effectiveness of the work they do, and the quality of product they produce.
For our RTS game, examples of the plans the team comes up with may be the addition of Unit Testing, the adoption of a framework or methodology, or a new software library to make some networking aspect of the game easier to implement.
The Scrum Framework certainly has a well-deserved seat at a game development project’s table. Scrum encourages value creation very early in the development effort which can then be used to prove hypotheses about what make a game fun to play. The utilization of Scrum as a framework to produce game software is a very good match indeed.