Scrum defines two types of individuals associated with a project using Scrum; one type is fully committed in a project, the other is merely involved. A commonly referenced joke about the commitment of the pig and the involvement of the chicken in a ham-and-eggs dinner illustrates this and is used to name the roles. The product owner is often referred to as a “chicken” because they aren’t committed to the work to be accomplished by the team every Sprint. They are only involved with the outcome while members of the team are called “pigs” because they truly commit to the work of the Sprint.
The product owner (PO) for a video game project can be compared to the role played by key visionaries such as Shigeru Miyamoto, Will Wright, Tim Schafer and Sid Meier on their projects. A PO represents the ultimate customer during development: the player. The PO has to foresee what the market will want up to three years in advance. They have to know the mind and emotional responses of the player. Pure iteration is not enough for video game development. We typically have one true release to get things right. Most of our games can’t slowly grow their feature sets and market simultaneously like other products. This requires great vision. This is unavoidable.
You might ask “can’t we iterate and focus test our iterations?”. I wish it were so, but over the years I’ve discovered it isn’t enough. Focus testing will tell you how your game compares with the focus tester's current favorite games. Additionally there is a huge discrepancy between the people you focus test and the people you have to impress to get market awareness (e.g. reviewers and hard-core-gamer-mavens). That’s a bigger topic.
Originally the Product Owner role was considered a “chicken” role. That’s to say it was a role that required no commitment to the Sprint goals. This has changed over the past as the product owner role has been identified as a key to success or failure of a project. This is no more true that for game development. As a result, many projects consider their POs as “pigs” (we used the terms “ninjas” and “pirates” for these concepts of commitment because, for some reason, people dislike the labels "pig" and "chicken").
“PO as pig” is needed because we can’t always know what’s fun two weeks from now. Questions about how “bouncy” a physics response should be or how “snappy” an animation transition needs to be, etc, etc are subjective and may need daily feedback from the visionary.
The question this raises is “how can the team commit to Sprint goals if the PO is giving direction every day?”. The answer is that they can’t commit to same level of detail. They have to commit to higher level goals, especially when they are in pre-production. This can be difficult for veteran Scrum teams to accept, but when the PO is a pig, the PO is making a commitment as well. Their “skin is in the game” with the rest of the team. They should commit to goals with the rest of the team. Highly details Sprint goals are meant to improve communication between pigs and chickens, but if your #1 customer is on the team, then the communication problem is reduced.
A PO can’t be a pig on 10 teams however. Some games have a “hierarchy of POs” with the main product owner and a number of POs for major mechanics or functions reporting to them. This is a common solution used in many industries adopting Scrum.
One word of warning. If you are working on a game (agile or not) without a single strong visionary who is clearly calling the shots about the features regularly and transparently, then you may have a problem.