- 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
Product Ownership
The demand for a Product Owner’s time on game teams can be greater than the demand for Product Owners in other industries. Teams are challenged with knowing if the “fun” they are creating is the “fun” the Product Owner wants. Questions such as how “bouncy” a physics response should be or how “snappy” an animation transition needs to be are subjective and may need daily feedback from the person who owns the vision for the game: the Product Owner.
For large projects with a dozen or more teams, this creates a challenge. The Product Owner’s time becomes spread too thin, and he or she cannot adequately maintain a shared vision for the game across all teams. Without a shared vision, each mechanic will drift from the original vision as it evolves, and the game becomes less consistent and appealing.
A useful practice is for the Product Owner for a large project to delegate ownership of feature areas. One way of doing this is to establish a hierarchy of Product Owners. A lead Product Owner guides the project, and each core mechanic has a Product Owner. Figure 21.8 shows an example of such a Product Owner hierarchy.
)
Figure 21.8 An example Product Owner hierarchy
The Lead Product Owner oversees the two Product Owners who work with one or two Scrum teams. The Lead Product Owner continues to work with teams directly, such as the user interface team, but he or she delegates Sprint responsibilities to the teams that have their own Product Owner.
The Product Owners work with their teams during the Sprint, helping them plan the Sprint and working with them daily to ensure that they achieve the Sprint Goal. For example, as a Product Owner on a team implementing a driving mechanic, my role included educating the team about the shared vision for the mechanic. These often required conversations about the balance between a “sim” versus “arcade” feel for the controls, vehicle physics, and the environment.
The Product Owners need to ensure that a shared vision exists for the entire project. This includes frequent meetings among them all, including the Scrum-of-Scrums meetings (see the later section, “The Scrum of Scrums”), to address any questions about the game’s vision.
Product owners take direction from the Lead Product Owner between Sprints and Release Planning. A difference of opinion often exists on the best path to achieve release goals between the Product Owners. The insight of a team’s Product Owner is invaluable in finding the best way, but the lead Product Owner is responsible for safeguarding a consistent vision for the game across all mechanics and features.
A Product Owner team creates a shared vision on a large project and ensures consistency of vision everywhere.