Chapter 6. Agile Planning

Agile planning is a commonly misunderstood part of agile project management. Many consider agile planning to be an oxymoron—that agile teams plan very little and iterate with no end in sight.

This chapter introduces what agile planning really is and corrects this misconception. It describes how user stories are prioritized and managed in the product backlog. It introduces the concept of separating the size of user stories from the time it takes to implement them so that teams and stakeholders can easily measure and forecast a project’s progress. It then unites these ideas to describe releases, the longer iterations where major project goals are planned and managed.

Why Agile Planning?

In preparing for battle I have always found that plans are useless, but planning is indispensable.

—Dwight D. Eisenhower

Agile planning does not call for a complete plan up front but spreads the work of planning throughout the entire project. In fact, agile teams spend more time planning than traditional teams; it’s just not concentrated at the start of a project.

Agile planning avoids the typical planning pitfalls—like those seen on Darkwatch—by the following means:

• Deliver potentially shippable features in value-first order: Features are built in the order of the value they add for the consumers who buy the game. Delivering the highest-value playable features ahead of lower-value ones drives the development of the game rather than a preset ordered list of work. This enables the true value of the game to emerge earlier, when we can make better decisions about its direction.

• Plan by feature, which creates cross-discipline behavior: Delivering features every sprint encourages separate disciplines to collaborate to produce results that matter to the stakeholders. Problems that impact one discipline impact the rest and are likely to be solved more quickly, rather than ignored for the sake of a schedule.

• Avoid debt to allow better measurement of progress: Sprints combine the full cycle of feature development. This reduces the debt of debugging, tuning, polishing, and optimization and makes the pace of development easier to forecast.

• Plan continually: Plans created at the start of a project are very good at telling us when the project has failed. Agile planning continually fine-tunes the course of the project to avoid pitfalls and to double down on valuable practices and features. They help teams find success.

• Work with clear objectives: The ongoing communication between the team and the stakeholders enables clear objectives to be created. Establishing a definition of done with the product owner enables the team to understand each sprint goal and accurately estimate the work required to achieve it.

• Prioritize scope to control the budget and delivery date: Many projects that run into trouble first choose to add people or slip the ship date. This is usually done because many key features are developed in parallel and need continuing development to produce any value. Sprints and releases implement features in order of value. This gives the project the option of meeting a ship date by allowing the stakeholders to draw the line and ship with a set of the highest-valued features.

The Product Backlog

The product backlog is a prioritized collection of user stories. Its goals are to do the following:

• Enable stories to be prioritized so that the team is always working on the most important features

• Support continual planning as the game emerges so the plan matches reality

• Improve forecasts so that the stakeholders make the best decisions about the project goals

This section describes these goals.

Prioritizing the Product Backlog

The product owner has the chance to prioritize the product backlog prior to the start of each sprint. It’s done with the input of stakeholders, team members, and domain experts. The following guides help determine the priority of each story in the product backlog:

• Value: 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. By focusing the team’s effort on adding the highest value every sprint, the product owner is generating the best possible ROI. They measure value using their own judgment, feedback from focus testing, and feedback from stakeholders. Value applies to the “nonfunctional requirements” as well. Tool and pipeline stories that improve productivity have a place in the product backlog because improving productivity also improves ROI.

• Cost: Cost is a key factor in the product owner’s ROI calculation. Some highly desirable features might cost too much to implement. An example of this is implementing fully destructible geometry for a shooter. Although this feature may add a great deal of value to the game, the product owner must weigh its value against the cost of developing the technology and producing level assets that leverage it. Two equally valuable features are often prioritized by cost; the lowest-cost feature is given a higher priority.

• Risk: Risk implies uncertainty about value and cost. As a team refines its knowledge in these areas, the product backlog becomes a better tool for the product owner. Stories with higher risk are often prioritized higher to refine a product owner’s understanding of value and cost. If they are not, then potentially valuable stories might be left at the bottom of the product backlog and potentially dropped because of schedule or budgetary limitations.

• Knowledge: Sometimes the product owner doesn’t know the value, risk, or cost of a feature. They simply need more information. In this case, they could introduce a timeboxed story for a prototype or experiment to the product backlog. Such a timeboxed story, called a spike, limits how much time the team spends working on it and is intended to produce information alone. An example of this is a two-week prototype to determine whether the physics engine supports destructible geometry. If this spike demonstrates that the cost and risk of implementing the system and tool set is not too great, the product owner is more likely to raise the priority of a story to develop the feature.

Continual Planning

The work done by a Scrum team is determined by the priority of stories on the product backlog and what the team is capable of accomplishing. Every sprint they take stories off the top of the product backlog and break them down into small tasks that they estimate in hours. For this to happen, each story they consider must be small enough to be accomplished in a single sprint and detailed enough to support task creation. Therefore, defining the details of the highest-priority stories is where most of the planning effort needs to take place.

Not every story on the product backlog should be small enough to fit into a sprint. If they were, then the product backlog might contain thousands of user stories, which is too cumbersome to maintain. Instead, the lower-priority stories are not broken down until the higher-priority stories are finished. This is an advantage because the lower-priority stories, which are more distant from implementation, are expected to change as the team and stakeholders learn more about what is possible and what is fun.

A useful metaphor for the product backlog is an iceberg (Cohn 2008), as shown in Figure 6.1. The highest-priority stories are represented by snowballs at the top of the iceberg, which are small enough to be completed in a single sprint. Below them are the lower-priority stories, or larger chunks of ice, called epics.

Figure 6.1. The product-planning iceberg

Everything above the waterline represents the work we want to complete in the current release. Each sprint sweeps off the snowballs (stories) from the top of the iceberg. The stakeholders and team break down the larger chucks of ice (epics) into snowballs for the next sprint.

Forecasting the Future

As we’ll see in the next section, the size of user stories is estimated with units called story points. The rate at which teams implement the stories and remove them from the product backlog is measured in story points per sprint, called the velocity.

This isn’t an abstract practice. It’s the same method we use to calculate velocity in other areas of life. For example, imagine you plan to drive 3,000 miles across the United States in five days. This predicts an average velocity of 600 miles per day. You could use this velocity to forecast, even after the first day, whether you are on track to achieving your goal or not. If, after the first day or two, you discover that your actual velocity is 500 miles a day, you have a number of options available. You can adjust the number of days you plan to drive, alter your destination, or even try to adjust your driving habits (drive longer each day or drive faster). If you’ve placed all your faith in the plan and discover, at the end of the fifth day, that you’re 500 miles short of your destination, your options are far more limited.

Agile planning uses frequent measurements of velocity to forecast the accomplishment of the goals of the project (either knowing what will be accomplished by a given date or when the project will achieve all given goals). This is in contrast to traditional project management practices that place more faith in a plan and are only able to reliably measure location near the end of the project, closer to the testing phase.

By measuring the story points accomplished each sprint, an agile project measures its velocity. The velocity is used to predict how much scope can be implemented by a specific date or to predict a date for a fixed amount of scope to be implemented.

Estimating Story Size

To measure the velocity of anything (a car driving or a ship sailing), you need to measure the size of something changing over the passage of time (such as miles driven per hour or nautical miles per day). Similarly, for measuring velocity on an agile project, we use the size of user stories completed per sprint.

Measuring the size of features has been a product management challenge for decades. Project managers have tried measures such as “lines of code,” which turned out to have very little to do with the actual progress made on the project.¹ This section describes proven methods for estimating user story sizes to be used for measuring velocity.

¹ In fact, it only led to more lines of code.

How Much Effort Should We Spend Estimating?

How much time should we spend estimating stories? We could spend anywhere from a few minutes to a few hours. In a few minutes, we could discuss a broad outline and come up with a guess. In a few hours, we could break a story down into the detailed tasks required to implement it.

We want to spend our planning time wisely. One assumption of planning is that the more time we spend planning, the more accurate our plan becomes. This is, in fact, not true. Figure 6.2 shows that beyond a certain amount of effort, our accuracy decreases (Cohn 2006).

Figure 6.2. Accuracy vs. effort for estimating

Source: Cohn, M. 2006. Agile Estimating and Planning. Upper Saddle River, NJ: Prentice Hall. Reprinted by permission of Pearson Education, Inc.

Planning provides an initial spike of accuracy with little effort spent. As more effort is spent, the accuracy of estimates actually starts to decline! This is surprising at first glance, but it makes sense. Say we spend an entire day estimating a single story. Given this time, we would eventually create very detailed tasks. These define work creating classes and functions, creating art assets, and tuning variables. As it turns out, this level of detail is too speculative. By the time we start defining functions and variables, chances are we are defining things that won’t be needed or will be changed during implementation.

The purpose of story estimation is meant to be efficient and to occupy the left side of the curve in Figure 6.2. It’s a quick, low-effort estimating practice that provides accuracy valuable enough for forecasting but not enough for a team to commit to the work.

Where Are Story Sizes Estimated?

Chapter 5, “User Stories,” described a story workshop where a hand-to-hand combat system was debated. The debate included not only my technical perspective and experience but also those of the animators and the lead designer. As a result, we had good cross-discipline agreement about the story before we estimated the work.

This is a benefit of story workshops. When teams estimate the size of stories, it drives the discussion of vision, design assumptions, and challenges of implementation. As a colleague once remarked, “It helps remove the fuzziness and hand-waving when you have to come up with a number.”

These cross-discipline discussions refine a team’s understanding of what they are trying to achieve. An estimate for a story needs to reflect this cross-discipline understanding and produce a value that everyone agrees with, regardless of the skills required to implement it. It’s challenging to create a universal scale for all stories. For example, a story about a procedural physics effect and a story about animating a character are difficult to directly compare. However, over time, as a team builds a repository of estimated stories and the experience of implementing them, it becomes easier to find comparable stories.

Estimating user stories should be a quick process that involves the following:

• Expert opinion: Inviting domain experts to story workshops helps inform the group about the issues and effort of implementing something the expert is familiar with. For example, if a story includes an online component, a network programmer would provide value to the discussion about it.

• Analogy: 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. Using triangulation, a story is compared to one larger in complexity or size and one smaller to produce the best results. To provide the best results, a story that requires significant specialization, such as a weapon creation story, is best compared to other weapon creation stories.

• Disaggregation: Large user stories are more difficult to accurately estimate than smaller ones, so often these stories are disaggregated into smaller ones, which are more accurately estimated. However, stories shouldn’t be broken down into a pile of tiny ones because a false sense of detail emerges, as described previously.

Story Points

User stories are typically estimated using story points, which are a relative measure of a feature’s size or complexity. For example, modeling two vehicles is estimated at twice the points of modeling one vehicle and possibly the same as modeling a character. This relative measure of story points allows for a more accurate measure of size, as explained later in this chapter.

A story point estimate is not a commitment to when a story will be completed. There are two reasons for this. First, a story point estimate takes only a few minutes. A team’s commitment to completing a story requires a more precise and time-consuming estimation process. This happens when they break a story down into individual tasks in sprint planning. Second, different teams have different velocities. For example, one team might implement a 10-point story twice as fast as another team based on their membership and experience.

Planning Poker

A favorite technique for estimating user stories is the Planning Poker game (Grenning 2002). Planning Poker combines expert opinion, disaggregation, and analogy in a fun and efficient practice. Planning Poker should be part of release planning meetings and story workshops. It should be used whenever new stories are introduced that need an estimate.

In Planning Poker, attendees discuss stories that have not yet been estimated. After a story is discussed, each person estimates the points they think should be assigned to the story by simultaneously raising 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.

Estimating an entire release plan can take four to eight hours. Often teams won’t tackle all stories for a release in one sitting. They disaggregate and estimate the highest-priority stories and then meet once a sprint to estimate lower-priority or new stories for upcoming sprints.

Story Point Sizes and the Fibonacci Series

Story points provide a quick and relative estimate of size and complexity for a story. Alone they are not perfectly precise, but with a mass of stories, they average out well enough for planning.

Projects need to define a set of numbers that they use for story point estimates. The two rules of thumb for selecting a set of story points are that the entire scale be within two orders of magnitude. For example, a range of 1 to 100 or a range of 1,000 to 100,000 works. Second, the numbers used should be closely spaced out at the small end and widely spaced out at the high end of the scale. The reason is that our ability to judge the difference between stories with sizes of 20 and 21 points, for example, is not the same as our ability to tell the difference between two stories with sizes of 1 and 2 points.

A useful set of story points that follows these two rules is derived from the Fibonacci numbers. In a sequence of Fibonacci numbers, each number is the sum of the two preceding numbers. An example set of Fibonacci numbers useful for story point estimation follows:

0, 1, 2, 3, 5, 8, 13, 20, 40, 100

The numbers at the high and low ends of the set depart from the Fibonacci sequence. We use zero-point estimates for trivial stories that require very little effort, such as changing a user interface (UI) font color.² Be careful not to accumulate too many zero-point stories...zeros add up with this math! The upper range of these numbers departs from the Fibonacci series rule, but they exist to allow a couple of rounded-out values in the high range.

² Be careful not to accumulate too many zero-point stories...zeros add up with this math!

The team should constrain themselves to use only numbers within the set and not use values between them to create averages or compromises. This creates a false sense of precision with story point estimation and slows down a Planning Poker session!

Ideal Days

The concept of story points is difficult to introduce. Teams accustomed to time estimates often find story points too abstract and instead use ideal days as a benchmark to begin estimating. An ideal day is the measure of work accomplished in a single day with no interruptions (phone calls, questions, broken builds, and so on). Because of this association with something real, the team more readily embraces ideal days.

Ideal days are still measures of size alone. A story estimated to be one ideal day in size doesn’t mean it takes one day of actual work to complete. We want to avoid any translation of ideal days to actual days of effort. Ideal days, like story points, are valuable measures for quick relative forecasts of effort but not precise enough to use for making commitments.

Release Planning

Release planning is different from sprint planning. A release plan has more flexibility as features emerge from the sprints and team velocity is demonstrated.

Releases begin with a planning meeting that establishes major release goals, a release plan, potential sprint goals, and a completion date. A release makes progress through a series of sprints. As each sprint implements user stories, the burndown of story points measures the velocity of work. This is used to inspect progress and adapt the plan.

Release Planning Meetings

A release planning meeting uses the steps shown in Figure 6.3.

Figure 6.3. The flow of a release planning meeting

The product owner, stakeholders, team members, and domain experts attend the meeting. It begins with a review of the progress made in the last release and the product backlog. The group then deliberates on the major goals for the release. These goals, often referred to as big hairy audacious goals (BHAGs),³ represent a challenge for the entire team and establish a vision to aid story prioritization. For example, a BHAG to “fight other players online” might raise the priority of spikes to demonstrate that the animation system works in an online setting.

³ http://en.wikipedia.org/wiki/Big_Hairy_Audacious_Goal

After BHAGs for the release are agreed upon, user stories needed to implement them are identified, prioritized, and estimated using story points. The group uses the estimated story size and priorities to create a release plan, based on the velocity teams have demonstrated in past sprints, to lay out the sprint goals for the release. This is called the release plan.

The release plan identifies potential sprint goals for the release. Figure 6.4 shows a release plan based on a historical velocity of 15 story points per sprint. The goals for sprints 1 through 3 each contain stories that add up to 15 points. The stories for the more distant sprints in the release are lumped together. In this example, the product owner has called for six sprints in the release because the release plan and projected velocity tells them that this is how many sprints are needed (for example, 89 points at 15 points of velocity every sprint tells them they need six sprints).⁴

⁴ We always round up.

Figure 6.4. Splitting the release plan across future sprints

As sprints are finished, the goals and stories for the subsequent sprints are refined. For example, after sprint 1 is completed, the goal for sprint 4 is identified.

It’s important to understand that the sprint goals identified in the meeting are a forecast of work that can potentially be accomplished by the team; they’re not a commitment. They are useful benchmarks for measuring progress.

Rolling Out the Plan

On larger projects, it’s sometimes impractical to have the entire project staff attend the release planning meeting. In this case, only the product owner, domain experts, and discipline leads attend.

After release planning, the product owner presents, or rolls out, the release plan to the entire project staff. The owner describes the BHAGs and release plan and answers any questions raised. The project staff is then given the opportunity to organize themselves into Scrum teams that would best achieve the initial sprint goals in the plan.

Teams are usually organized around the BHAGS. For example, in a release that has single-player and online gameplay BHAGS, teams are organized around each. After the teams form, they can each hold a release planning meeting to further refine their area of the release plan.

Updating the Release Plan

Following each sprint review, the release plan is reexamined. Sometimes the sprint has identified new stories to be added. These are stories that were either overlooked or not anticipated in release planning. Other times, stories are removed. These stories are considered unnecessary, or their priority was reduced enough to push them into a future release. As with the product backlog, the product owner makes the final decision on the addition, deletion, or reprioritization of any story in the release plan.

The release plan may also need refinement based on the team’s actual velocity. Figure 6.5 shows an example of an original release plan on the left, which forecasted 16 user story points of velocity per sprint. However, the first sprint accomplished only 13. As a result, the product owner updated the new release plan—shown on the right—which dropped the last two (lowest-priority) stories.

Figure 6.5. Updating the release plan based on velocity

The product owner also had the option of adding another sprint to the release if they didn’t want to drop those stories.

Magazine Demos and Hardening Sprints

Scrum describes sprints as delivering a potentially shippable version of a product at the end of every sprint. This allows the product owner to decide to ship the product on short notice. This is a challenging goal for many large-scale game projects for three reasons:

• There is only one true release at the end of two or more years of development.

• Many features and assets require a number of sprints to implement (for example, production levels).

• To be shippable, games must often pass rigorous tests for hardware and first-party compliance. These tests can take weeks to conduct and cannot be done every sprint.

Nevertheless, sprints should achieve a minimum definition of done as defined by the product owner.

A release build should approach the potentially shippable goal more closely. Its definition of done should be higher than a sprint’s. Still, a release build cannot always be expected to pass all shipping criteria unless it is the final release of the game. For all previous releases, a good example of a definition of done is the magazine demo.

A magazine demo has certain expectations:

• It has no major memory leaks preventing it from being played for an hour or two.

• There are no major missing assets. All stand-in assets are clearly identified as such.

• The game has a clean and usable user interface.

• The player has a clear objective and experiences the fun of the game.

These are typical requirements for a demo version of a game in any publication, so they are easy to communicate.

As a result of the different completion bars for releases and sprints, release builds require additional testing beyond what is tested for every sprint. If this testing identifies issues with the game that aren’t found in sprint testing, the additional work created to address them creates the need for a special sprint at the end of the release called a hardening sprint.

Work for the hardening sprint is derived from the difference between the definition of done for sprint builds and release builds. If the definition of done is the same for both, there should be no reason for a hardening sprint.

Hardening sprints are often run using a list of bugs and polishing tasks that need to be worked on. They are not used to complete stories from the product backlog (see the sidebar “How to Run a Hardening Sprint”).

Summary

Agile planning is not an oxymoron. Agile teams plan in ways that allow iteration, transparency, and change. They adjust planning to match reality rather than trying to make reality match a plan.

Agile planning requires a product backlog that prioritizes the user stories that the stakeholders want in the game. The product backlog prioritization and team membership determine which stories might be completed every sprint. These stories, measured in size by story points, allow the measurement of work accomplished per sprint, which is the velocity. Velocity is used to examine the rate of development and predict future progress. Measuring velocity early and frequently allows the project to be steered when many options are available to it.

Release cycles allow major goals to be achieved over a longer time frame. Because of the longer time frame, releases have flexibility in planning that does not exist with sprints. Release plans can be altered in duration or in scope. Releases also demand a more refined definition of done (see Chapter 5) to bring an almost shippable level of polish, stability, and tuning to the game, rather than postponing it to near the end of the project.

For many projects, this is enough. The release cycle is sufficient to release versions of the product to consumers on a regular basis. Most video game projects don’t have this luxury. They have pre-production and production phases that have a different focus and challenges. The next chapter describes these phases and how Scrum, agile planning, and lean practices can be combined for planning over the entire development life cycle.

Additional Reading

Cohn, Mike. 2006. Agile Estimating and Planning. Upper Saddle River, NJ: Prentice Hall.