Reference: Clinton Keith, Agile Game Development with Scrum, Chapter 6.

Civilization V video review.

Objectives of agile planning:

• Deliver potentially shippable features in value-first order;
• Plan by feature, which creates cross-discipline behavior;
• Avoid debt to allow better measurement of progress;
• Plan continually;
• Work with clear objectives;
• Prioritize scope to control the budget and delivery date.

The product backlog enables user stories to be prioritized so that the team is always working on the most important features. The product owner gathers input from the stakeholders, team members, and domain experts and uses the following guides help determine the priority of each story in the product backlog:

• The value that a story adds for the player who buys the game is the main criteria in determining the priority of that story on the product backlog, which generates the best possible ROI. Value applies to the "nonfunctional requirements" as well.
• Cost is a key factor in the product owner's ROI calculation. The product owner must weigh the value of the user story against the cost of developing the technology and producing assets that leverage the story.
• Risk implies uncertainty about value and cost. Stories with higher risk are often prioritized higher to refine a product owner's understanding of value and cost.
• Sometimes the product owner does not have the knowledge of the value, risk, or cost of a feature. In that case, a spike, a timeboxed story for a prototype or experiment to the product backlog, is used to produce more knowledge about the product.

The product backlog supports continual planning as the game emerges so the plan matches reality. Not every story on the product backlog should be small enough to fit into a sprint. Lower-priority stories are not broken down until the higher-priority stories are finished. Lower-priority stories are more distant from implementation and are expected to change as the team and stakeholders learn more about what is possible and what is fun. The iceberg analogy places highest-priority user stories at the top (small snowballs), while lower-priority epics are at the bottom (large chunks of ice, which are broken down as the developers work their way from top to bottom of the iceberg).

The product backlog helps improve the forecast so that the stakeholders make the best decisions about the project goals. The size of user stories is estimated with story points. The rate at which teams implement the stories and remove them from the product backlog is measured in velocity, number of story points per sprint.

Planning provides an initial spike of accuracy with little effort spent. As more effort is spent, the accuracy of estimates actually starts to decline. Estimating user stories should be a quick process that involves the following:

• Domain expert opinion helps inform the group about the issues and effort of implementing something the expert is familiar with.
• Analogy is used to estimate story size. When stories are compared to each other, a far more accurate estimate can be achieved than estimating stories on their own.
• Disaggregation breaks down large user stories that are more difficult to accurately estimate into a smaller ones (not too many!), which can be more accurately estimated.

User stories are typically estimated using story points, which are a relative measure of a feature's size or complexity (but not time).

In Planning Poker, team members discuss user stories that have not yet been estimated. Each person simultaneously raises a card with their estimate on it for all to see. The first vote often reveals a wide disparity of estimates. The group discusses the range, first by asking the outlying voters to describe the reasoning behind their estimate. This exposes the uncertainties and assumptions of the story. As a result, the vision, design, and implementation details are discussed and refined. These discussions often lead to adding conditions of satisfaction for a story or defining new stories that were not previously considered. This practice is repeated until everyone produces the same estimate. If a couple of people have different but close estimates, they may concede to the group's estimated points and allow the meeting to move to the next story.

Story points provide a quick and relative estimate of size and complexity for a story with two rules of thumb:

1. The entire scale be within two orders of magnitude, and
2. The numbers used should be closely spaced out at the small end and widely spaced out at the high end of the scale.

Fibonacci numbers are very useful as story points. Some very small stories can be assigned a size of zero (but these may add up!).

Release planning is different from sprint planning. A release plan has more flexibility as features emerge from the sprints and team velocity is demonstrated. A release planning meeting is attended by the product owner, stakeholders, team members, and domain experts. The group deliberates on the major goals for the release (often referred to as big hairy audacious goals, or BHAGs) which represent a challenge for the entire team and establish a vision to aid story prioritization.

A release plan is created by assigning user stories to a set number of sprints with the same velocity. More distant sprints in the release can be lumped together. The sprint goals identified in the release plan are a forecast of work that can potentially be accomplished by the team; they are not a commitment, but a useful benchmarks for measuring progress.

The release plan is reexamined following each sprint review. New stories to be added or removed if necessary.

In the context of game development, an MVP/MVG is a playable game with the minimal set of features that can be developed with the least effort allowing the team to generate the maximum amount of knowledge about where the fun is. An MVP can be developed within the first one or two sprints.

Making Your First Game: Minimum Viable Product - Scope Small, Start Right