- The Solutions in This Chapter
- Challenges to Scaling
- Should You Scale Up?
- Scaling the Wrong Process
- The MAGE Framework
- The Product Backlog
- Team Organization
- Product Ownership
- Additional Roles
- Releases
- Sprints
- Managing Dependencies
- Distributed and Dispersed Development
- What Good Looks Like
- Summary
- Additional Reading
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Product Backlog
A game starts with a Product Backlog organized as a hierarchy. This hierarchy will reflect the team and Product Owner organization. This hierarchy will also change over time as the game emerges, and our knowledge grows.
Figure 21.3 shows a starting hierarchical mind map of major epics for a game. Initially, the game staff will be smaller and focus on the camera, character, and hand-to-hand combat epics. They might consist of a single small team or three teams, depending on how many developers are working on the game.
)
Figure 21.3 A basic mind map of the game epics
Later releases might reorganize into single-player and multi-player teams that build upon these core mechanics.
Tools and Mind Maps
Most tools for a Product Backlog support hierarchies, but I prefer the ones that can visualize the Product Backlog as a mind map. A mind map of a Product Backlog should represent the team structures as well as the hierarchy of features. Mind maps have some benefits:
Mind Maps better serve how we think of a set of features.
Mind Maps can be quickly reorganized as teams reorganize, usually on a release-to-release basis.
It’s easier to allow teams to take over a branch of a mind map and will enable the Lead Product Owner to focus on the trunk.
Pooling Functions and Dispersing Components
It might seem logical for every branch to have audio. A feature isn’t “done” until it has audio, right?
The problem is that you might only have two audio composers for a dozen teams that each need only 10 percent of a composer’s time. We don’t want an audio composer spread across six teams, so we’ll pool the composers into an audio support team (see the later “Pool Teams” section).
Conversely, we might have a team of AI programmers create the architecture for basic AI (pathfinding, senses, character and animation control, and so on) before dispersing across teams to better support the needs of AI for all characters in the game (see “Component Teams” below).
The changing needs of the game and team organization should be reflected in the organization of the Product Backlog.
Pillars
Sometimes cross-cutting themes of the game need attention from almost every core feature and mechanic. These are often called pillars. An example of a common pillar is monetization. Many free-to-play games explore ways to monetize features throughout. Significant pillars often have a champion supporting it (see “Pillar Champions” below).