Chapter 3

Planning Releases and Sprints

IN THIS CHAPTER

Decomposing requirements and creating user stories

Creating a product backlog, release plan, and sprint backlog

Getting the product ready to ship and preparing the rest of the organization for the release

Understanding spring backlogs and planning meetings

After you create a product roadmap for your product (see Chapter 2 in Book 4), it’s time to start elaborating on your product details. In this chapter, you discover how to break down your requirements to a more granular level, refine your product backlog, create a release plan, and build a sprint backlog for execution. This chapter also discusses how to prepare the rest of the organization for the release, including operational support and ensuring that the marketplace will be ready for your release.

First, you see how to break down the larger requirements from your product roadmap into smaller, more manageable requirements called user stories.

Refining Requirements and Estimates

You start agile development with very large requirements. As the work progresses and you get closer to developing those requirements, you will break them down into smaller parts — small enough to begin developing. See Chapter 2 in Book 4 for more about this process, which is known as decomposition.

One clear, effective pattern for defining product requirements is the user story. In this section, you find out how to create a user story, prioritize user stories, and estimate user story effort.

What is a user story?

The user story is a simple description of a product value requirement in terms of what that requirement must accomplish for whom. It’s called a story because the simplest way people tell stories is by talking to each other. User stories are most effective when they’re told by speaking to each other face to face. The written pattern described in this section can be used to help with that conversation.

Traditional software requirements usually read something like this: “The system shall [insert technical description].” This requirement addresses only the technical nature of what will be done; the overall business objective is unclear. Because the development team has the context to engage more deeply through the user story pattern, their work becomes more personal and real. They come to know the value of each requirement to the user (or the customer or the business) and deliver what the customer wants faster and with higher quality.

Your user story will have, at a minimum, the following parts:

• Title (recognizable name for the user story)
• As a (type of user)
• I want to (take this action)
• so that (I get this benefit)

The user story tells the “who,” “what,” and “why” for the desired functionality. The user story should also be supported by a list of validation steps (acceptance criteria) to take so you can confirm whether the working requirement for the user story is correct. Acceptance criteria follows this pattern:

When I (take this action), (this happens)

User stories may also include the following:

• A user story ID: A unique identifying number to differentiate this user story from other user stories in the product backlog tracking system.
• The user story value and effort estimate: Value is how beneficial a user story might be to the organization creating that product. Effort is the ease or difficulty in creating that user story. You find out how to score a user story’s business value, risk, and effort in Chapter 2 of Book 4.
• The name of the person who thought of the user story: Anyone can create a user story.

Although agile product development approaches encourage low-tech tools, the scrum team should also find out what works best for themselves in each situation. A lot of electronic user story tools are available, some of which are free. Some are simple and are only for user stories. Others are complex and will integrate with other product documents. We love the simplicity of index cards, but use what works best for your scrum team and your product.

Figure 3-1 shows a typical user story card, front and back. The front has the main description of the user story. The back shows how you will confirm that the requirement works correctly, after the development team has created the functionality.

© John Wiley & Sons, Inc.

FIGURE 3-1: Card-based user story example.

The three Cs formula for user story creation — card, conversation, and confirmation — illustrates how the user story pattern enables agile teams to create customer value. By limiting user stories to fit on a 3x5 index card, you encourage a conversation for achieving a shared understanding of the job to be done for the customer (rather than excessive documentation that implies nothing is left to discuss). If the conversation is supported by the answers to the quiz upfront (acceptance criteria that is a confirmation that the actions the user will take meet the intended needs), you’re probably on the right track.

The product owner gathers the user stories and manages them (that is, determines the priority and initiates the decomposition discussions). It is not the sole responsibility of the product owner to write user stories. The development team and other stakeholders are also involved in creating and decomposing user stories to ensure clarity and shared understanding across the scrum team.

Note that user stories aren’t the only way to describe product requirements. You could simply make a list of requirements without any given structure. However, because user stories include a lot of useful information in a simple, compact format, they’re very effective in conveying exactly what a requirement needs to do for the customer.

The big benefit of the user story pattern is realized when the development team starts to create and test requirements. The development team members know exactly for whom they are creating the requirement, what the requirement should do, and how to double-check that the requirement satisfies its intention. Using the user’s voice is something everyone can understand and relate to — not so much with technical jargon.

Note: This book includes user stories as examples of requirements for software product development. Keep in mind that anything described that you can do with user stories, you can do also with more generically expressed requirements and other product types.

Steps to create a user story

When creating a user story, follow these steps:

1. Identify the stakeholders.
2. Identify who will use the product.
3. Working with the stakeholders, write down, in a user story format, what the product will need to do.

Find out how to follow these three steps in the following sections.

Being agile and adaptive requires iterating. Don’t spend a ton of time trying to identify every single requirement your product might have. You can always add items to your product backlog later. The best changes often come at the end, when you know the most about the product and the end-customers.

Identifying product stakeholders

You probably have a good idea about who your stakeholders are — anyone involved with, affected by, or who can affect the product and its creation. Stakeholders provide valuable feedback about every product increment you deliver each sprint.

You also will work with stakeholders when you create the product vision and product roadmap; see Chapter 2 in Book 4 for more details.

Make sure the stakeholders are available to help you gather and write product backlog items. Stakeholders of a sample mobile banking application might include the following:

• People who interact with customers on a regular basis, such as customer service representatives or bank branch personnel.
• Business experts for the different areas where your product’s customers interact. For example, XYZ Bank might have one manager in charge of checking accounts, another manager in charge of savings accounts, and a third manager in charge of online bill payment services. If you’re creating a mobile banking application, all these people would be stakeholders.
• Users of your product.
• Experts of the type of product you’re creating. For example, a developer who has created mobile applications, a marketing manager who knows how to create mobile campaigns, and a user experience specialist who specializes in mobile interfaces all might be helpful on the sample XYZ Bank mobile banking product.
• Technical stakeholders. These are people who work with the systems that might need to interact with your product.

Identifying users

Agile product development is customer focused. Building on the personas you’ve defined, your understanding of their needs, and the problems to be solved helps the team more clearly understand the product requirements. Knowing who your end users are and how they will interact with your product drives how you define and implement each item on your product roadmap.

With your product roadmap visualized (see Chapter 2 in Book 4), you can identify each type of user. For the mobile banking application, you would have individual and business bankers. The individual category would include youth, young adults, students, and single, married, retired, and wealthy users. Businesses of all sizes might be represented. Employee users would include tellers, branch managers, account managers, and fund managers. Each type of user will interact with your application in different ways and for different reasons. Knowing who these people are enables you to better define the purpose and desired benefits of each of their interactions.

You can define users using personas, or a written description about a type of user represented by a hypothetical person. For instance, “Ellen is a 65-year-old retired engineer who is spending her retirement traveling the world. Her net worth is $1,000,000, and she has residual income from several investment real estate properties.”

Ellen represents 30 percent of XYZ Bank’s customers, and a good portion of the product roadmap includes features that someone like Ellen will use. Instead of repeating all the details about Ellen every time the scrum team discusses these features, they can simply refer to the type of user as Ellen. The product owner might identify several personas, as needed, and will even print the descriptions with a stock photo of what Ellen might look like and post them on the wall in the team’s work area to refer to throughout development.

Know who your users are, so you can develop features they’ll actually use.

Suppose that you’re the product owner for the XYZ Bank’s mobile banking product. You’re responsible for the department that will bring the product to market, preferably in the next six months. You have the following ideas about the application’s users:

• The customers (the end users of the application) probably want quick access to up-to-date information about their balances and recent transactions.
• Maybe the customers are about to buy a large-ticket item, and they want to make sure they can charge it.
• Maybe the customers’ ATM cards were just refused, but they have no idea why, and they want to check recent transactions for possible fraudulent activities.
• Maybe the customers just realized that they forgot to pay their credit card bill and will have penalty charges if they don’t pay the card today.

Who are your personas for this application? Here are a few examples:

• Persona #1: Jason is a young, tech-savvy executive who travels a lot. When he has a spare moment, he wants to handle personal business quickly. He carefully invests his money in high-interest portfolios. He keeps his available cash low.
• Persona #2: Carol is a small-business owner who stages properties when clients are trying to sell their home. She shops at consignment centers and often finds furnishings she wants to buy for her clients.
• Persona #3: Nick is a student who lives on student loans and a part-time job. He knows he can be flaky with money because he’s flaky with everything else. He just lost his checkbook.

Your product stakeholders can help you create personas. Find people who are experts on the day-to-day business for your product. Those stakeholders will know a lot about your potential customers.

Determining product requirements and creating user stories

After you have identified your different users, you can start to determine product requirements and create user stories for the personas. A good way to create user stories is to bring your stakeholders together for a product discovery workshop.

Have the stakeholders write down as many requirements as they can think of, using the user story format. One user story for the product and personas from the previous sections might be as follows:

• Front side of card:
  • Title See bank account balance
  • As Jason,
  • I want to see my checking account balance on my smartphone
  • so that I can decide whether I have enough money in my account to make a transaction
• Back side of card:
  • When I sign into the XYZ Bank mobile application, my checking account balance appears.
  • When I sign into the XYZ Bank mobile application after making a purchase or a deposit, my checking account balance reflects that purchase or deposit.

You can see sample user stories in card format in Figure 3-2.

Be sure to continuously add and prioritize new user stories to your product backlog. Keeping your product backlog up-to-date will help you have the highest-value user stories when it is time to plan your sprint.

You will create new user stories throughout product development. You’ll also take existing large requirements and decompose them until they’re manageable enough to work on during a sprint.

© John Wiley & Sons, Inc.

FIGURE 3-2: Sample user stories.

Breaking down requirements

You refine requirements many times throughout development. For example:

• When you create the product roadmap (see Chapter 2 in Book 4), you create features (capabilities your customers will have after you develop the features), as well as themes (logical groups of features). Although features are intentionally large, features at the product roadmap level should be no larger than 144 story points on the Fibonnaci scale (see the later section “Estimation poker” to find out more about Fibonacci sizing.) Both features and themes are considered very large by a development team.
• When you plan releases, you break down the features into more concise user stories. User stories at the release plan level can be either epics, very large user stories with multiple actions, or individual user stories, which contain a single action. For our clients, user stories at the release plan level should be no larger than 34 story points. You find out more about releases later in this chapter.
• When you plan sprints, you break down requirements even further. User stories are broken down to eight points or fewer. See Figure 3-3 for a helpful requirement decomposition guide.

© John Wiley & Sons, Inc.

FIGURE 3-3: User story decomposition guidelines.

To decompose requirements, you’ll want to think about how to break down the requirement into individual actions. Table 3-1 shows a requirement from the XYZ Bank application introduced in Chapter 2 of Book 4 that is decomposed from the theme level down to the user story level.

TABLE 3-1 Decomposing a Requirement

Requirement Level	Requirement
Theme	See bank account data on a mobile device.
Features	See account balances. See a list of recent withdrawals or purchases. See a list of recent deposits. See my upcoming automatic bill payments. See my account alerts.
Epic user stories — decomposed from “see account balances”	See checking account balance. See savings account balance. See loan balance. See investment account balance. See retirement account balance.
User stories — decomposed from “see checking account balance”	See a list of my accounts once securely logged in. Select and view my checking account. See account balance changes after withdrawals. See account balance changes after purchases. See day’s end account balance. See available account balance. Change account view.

USER STORIES AND THE INVEST APPROACH

You may be asking, just how decomposed does a user story have to be? Bill Wake, in his blog at XP123.com, describes the INVEST approach to ensure quality in user stories.

Using the INVEST approach, user stories should be

• Independent: To the extent possible, a user story should need no other user stories to implement the feature that the story describes.
• Negotiable: Not overly detailed. The user story has room for discussion and an expansion of details.
• Valuable: The user story demonstrates product value to the customer. It describes features, not technical tasks to implement it. The user story is in the user’s language and is easy to explain. The people using the product or system can understand the user story.
• Estimable: The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary to create the functionality in the user story.
• Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that the development team can complete 6–10 user stories in a sprint.
• Testable: You can easily validate the user story, and the results are definitive.

Estimation poker

As you refine your requirements, you need to refine your estimates of the work required to complete your user stories as well. It’s time to have some fun!

One of the most popular ways of estimating user stories is by playing estimation poker, sometimes called planning poker, a game to determine user story size and to build consensus among the development team members.

The scrum master can help coordinate estimation, and the product owner can provide information about features, but the development team is responsible for estimating the level of effort required for the user stories. After all, the development team has to do the work to create the features that those stories describe.

To play estimation poker, you need a deck of cards like the one in Figure 3-4. You can get a digital version online at www.platinumedge.com/estimationpoker, or you can make your own with index cards and markers. The numbers on the cards are from the Fibonacci sequence, which follows this progression:

1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on

If you start with the numbers 1 and 2, each subsequent number in the Fibonacci sequence is derived by taking the sum of the previous two numbers.

© John Wiley & Sons, Inc.

FIGURE 3-4: A deck of estimation poker cards.

Each user story receives an estimate relative to other user stories. For instance, a user story that is a 5 requires more effort than a 3, a 2, and a 1. It is about 5 times as much effort as a 1, more than double the effort of a 2, and roughly the amount of effort as a 3 and a 2 combined. It is not as much effort as an 8, but is just over half the effort of an 8.

As user stories and epic user stories increase in size, the difference between Fibonacci numbers gets bigger. Acknowledging these increasing gaps in precision for larger requirements is why the Fibonacci sequence works so well for relative estimation.

To play estimation poker, follow these steps:

1. Provide each member of the development team with a deck of estimation poker cards.

2. From the list of user stories presented by the product owner, the team agrees on one user story that would be a 5.

   This user story is the anchor user story for the team. The scrum master helps the development team reach consensus by using a fist of five or thumbs up/thumbs down, with discussion until everyone agrees on a user story that represents an estimate of 5.

   The fist of five looks like rock-paper-scissors. On the count of three, each person holds up a number of fingers, reflecting the degree of comfort with the idea in question. Five means “I love the idea,” four means “I think it’s a good idea,” three means “I can support the idea,” two means “I have reservations, so let’s discuss,” and one means “I am opposed to the idea.” If some people have three, four, or five fingers up, and some have only one or two, discuss the idea. Find out why the people who support the idea think it will work, and what reservations the people who oppose the idea have. You want to get all group members showing at least three fingers — they don’t need to love the idea, but they need to support it.

   You can also quickly get an idea of consensus on a decision by asking for a simple thumb up (support), thumb down (don’t support), or thumb to the side (undecided). It’s quicker than a fist of five, and is great for answering yes-or-no questions.

3. The product owner reads a high-priority user story to the players.

4. Each player selects a card representing his or her estimate of the effort involved in the user story and lays the card facedown on the table.

   You don’t want the players to see each other’s cards until all cards have been played. This limits how much one player can influence others to vote a certain way. The players should compare the user story to other user stories they have estimated. (The first time through, the players compare the user story to only the anchor story.)

5. All players turn over their cards simultaneously.
6. If the players have different story points:

   1. It’s time for discussion.

      Discussion is the value-add of estimation poker, which enables team alignment and consensus. The players with the highest and lowest scores talk about their assumptions and why they think the estimate for the user story should be higher or lower, respectively. The players compare the effort for the user story against the anchor story. The product owner provides more clarification about the story, as necessary.

   2. Once everyone agrees on assumptions and has any necessary clarifications, the players reevaluate their estimates and place their new selected cards on the table.
   3. If the story points are different, the players repeat the process, usually up to three times.
   4. If the players can’t agree on the estimated effort, the scrum master helps the development team determine a score that all the players can support (he or she may use a fist of five or thumbs up/thumbs down) or determine that the user story requires more detail or needs to be further broken down.
7. The players repeat Steps 3 through 6 for each user story.

Consider each part of the definition of done — developed, integrated, tested (including test automation), and documented — when you create estimates.

You can play estimation poker at any point — but definitely play during the product roadmap development and as you progressively break down user stories for inclusion in releases and sprints. With practice, the development team will get into a planning rhythm and become more adept at quickly estimating.

On average, development teams may spend about 10 percent of their time each sprint decomposing and refining product backlog items, including estimating and reestimating. Make your estimation poker games fun! Bring in snacks, take breaks as needed, use humor, and keep the mood light.

Affinity estimating

Estimation poker can be effective, but what if you have many user stories? Playing estimation poker for, say, 500 user stories could take a long time. You need a way to estimate your entire product roadmap, but one that allows you to focus on only the user stories you must discuss to gain consensus.

When you have a large number of user stories, many of them are probably similar and would require a similar amount of effort to complete. One way to determine the right stories for discussion is to use affinity estimating. In affinity estimating, you quickly categorize your user stories and then apply estimates to these categories of stories.

When estimating by affinity, write your user stories on index cards or sticky notes. These types of user story cards work well when quickly categorizing stories.

Affinity estimating can be a fast and furious activity — the development team may choose to have the scrum master help facilitate affinity estimating sessions. To estimate by affinity, follow these steps:

1. Taking no more than 60 seconds for each category, the development team agrees on a single user story in each of the following categories:
   • Extra-small user story
   • Small user story
   • Medium user story
   • Large user story
   • Extra-large user story
   • Epic user story that is too large to come into the sprint
   • Needs clarification before estimating

2. Taking no more than 60 seconds per user story, the development team puts all remaining stories into the categories listed in Step 1.

   If you’re using index cards or sticky notes for your user stories, you can physically place those cards into categories on a table or a whiteboard, respectively. If you divide the user stories among the development team members, having each development team member categorize a group of stories, this step can go quickly!

3. Taking another 30 minutes, maximum, for each 100 user stories, the development team reviews and adjusts the placement of the user stories.

   The entire development team must agree on the placement of the user stories into size categories.

4. The product owner reviews the categorization.

5. When the product owner’s expected estimate and the team’s actual estimate differ by more than one story size, they discuss that user story.

   The development team may or may not decide to adjust the story size.

   Note that after the product owner and the development team discuss clarifications, the development team has the final say on the user story size.

6. The development team plays estimation poker on the user stories in both the epic and the needs clarification categories.

   The number of user stories in these categories should be minimal.

User stories in the same size category will have the same user story score. You can play a round of estimation poker to double-check a few, but you won’t need to spend time in unnecessary discussion for every user story.

Story sizes are like T-shirt sizes and should correspond to Fibonacci scale numbers, as shown in Figure 3-5.

© John Wiley & Sons, Inc.

FIGURE 3-5: Story sizes as T-shirt sizes and their Fibonacci numbers.

You can use the estimating and prioritizing techniques in this chapter for requirements at any level, from themes and features down to single user stories.

That’s it. In a few hours, your entire product backlog was estimated. In addition, your scrum team has a shared understanding of what the requirements mean, having discussed them face to face rather than relying on interpretations of extensive documentation.

Release Planning

A release is a group of usable product features that you deploy to the market. A release does not need to include all the functionality outlined in the product roadmap but should include at least the minimal marketable features, the smallest group of product features that you can effectively deploy and promote in the marketplace. Your early releases will include highest priority (high value, or high risk, or both) items and exclude lower-priority requirements you identified during the product roadmap stage.

When planning a release, you establish the next set of minimal marketable features and identify an imminent product launch date around which the team can mobilize. As when creating the vision statement and the product roadmap, the product owner is responsible for creating the release goal and establishing the release date. However, the development team’s estimates, with the scrum master’s facilitation, contribute to the process.

Release planning is stage 3 in the Roadmap to Value (refer to Chapter 2 in Book 4 to see the roadmap as a whole). Figure 3-6 shows how release planning fits into product development.

© John Wiley & Sons, Inc.

FIGURE 3-6: Release planning as part of the Roadmap to Value.

Release planning involves completing two key activities:

• Revising the product backlog: Chapter 2 in Book 4 tells you that the product backlog is a comprehensive list of all the user stories you currently know for your product, whether or not they belong in the current release. Keep in mind that your list of user stories will usually probably change throughout development.
• Creating the release plan: This activity consists of defining the release goal, release target date, and prioritization of product backlog items that support the release goal. Whereas the product vision provides the long-range goal of the product, the release plan provides a midrange goal that the team can accomplish.

Don’t create a new, separate backlog during release planning. The task is unnecessary and reduces the product owner’s flexibility. Prioritizing the existing product backlog based on the release goal is sufficient and enables the product owner to have the latest information when he or she commits to the scope during sprint planning.

The product backlog and release plan are some of the most important information radiators between the product owner and the development team. (See Chapter 4 in Book 4 for more on information radiators.) In Chapter 2 of Book 4, you find out how to complete a product backlog. How to create a release plan is described next.

The release plan contains a release schedule for a specific set of features. The product owner creates a release plan at the start of each release. To create a release plan, follow these steps:

1. Establish the release goal.

   The release goal is an overall business goal for the product features in your release. The product owner and development team collaborate to create a release goal based on business priorities and the development team’s development speed and capabilities.

2. Identify a target release date.

   Some scrum teams determine release dates based on the completion of functionality; others may have hard dates, such as March 31 or September 1. The first case has a fixed scope and flexible date; the second case has a fixed date and a flexible scope.

   If a fixed date and fixed scope are determined for the release, adjustments may need to be made to the number of teams to accomplish the release goal according to schedule. The development team, not the product owner, estimates the effort required to implement product backlog items. Imposing a fixed scope and timeline without adjusting quality or resources (in this case, talent resources) will not be successful.

3. Review the product backlog and the product roadmap to determine the highest-priority user stories that support your release goal (the minimum marketable features).

   These user stories will make up your first release.

   Try to achieve a release goal with about 80 percent of the user stories, using the final 20 percent to add robust features that will meet the release goal while adding to the product’s “wow” factor. This approach provides appropriate flexibility and slack for the scrum team to deliver value without having to complete every single task.

4. Refine the user stories in your release goal.

   During release planning, dependencies, gaps, or new details are often identified that affect estimates and prioritization. This is the time to make sure the portion of the product backlog supporting your release goal is sized. (Refer to Figure 3-3.) Make sure that items supporting the current release goal have been decomposed and are sized appropriately for the release. The development team helps the product owner by updating estimates for any added or revised user stories, and commits to the release goal with the product owner.

   Release planning is the initial opportunity to identify and break down dependencies before they become impediments. Dependencies are anti-patterns to becoming agile. Teams should work to become highly aligned and highly autonomous. Dependencies are an indication that your team does not have the capability to do whatever they are dependent on.

5. Estimate the number of sprints needed, based on the scrum team’s velocity.

   Scrum teams use velocity as an input to plan how much work they can take on in a release and sprint. Velocity is the sum of all user story points completed within a sprint. So, if a scrum team completed six user stories during its first sprint with sizes 8, 5, 5, 3, 2, and 1, their velocity for the first sprint is 24. The scrum team would plan its second sprint keeping in mind that it completed 24 story points during the first sprint.

   After multiple sprints, scrum teams can use their running average velocity as an input to determine how much work they can take on in a sprint, as well as to extrapolate their release schedule by dividing the total number of story points in the release by their average velocity. Find out more about scrum in Book 5.

Be aware that some teams add a release sprint to a release to conduct activities unrelated to product development but necessary to release the product to customers. If you need a release sprint, be sure to factor that into the date you choose.

Delaying crucial development tasks such as testing until the end of development rearloads risk. Agile techniques frontload risk to avoid the surprises and defects that result from delayed testing. If a scrum team requires a release sprint, it probably means the broader organization can’t support being truly shippable with each sprint, which is an impediment to becoming agile. The goal for agile teams is to have every type of work or activity required to release functionality to the market as part of the sprint-level definition of done. Scrum masters should work together to remove organizational impediments preventing teams from being able to release at scale according to their sprint-level definition of done.

In some traditional or project-focused organizations, some tasks, such as security testing or load testing a software product, can’t be completed within a sprint because the task’s environment takes time to set up and request. Although release sprints allow scrum teams to plan for these types of activities, doing so is an anti-pattern, or the opposite of being agile. In these examples, the scrum master would work with the organizational leaders who manage the security or load testing environments to find ways to enable scrum teams to accomplish security or lead testing during the sprint.

Each planned release shifts from what was a tentative plan (high-level product roadmap items) to a more concrete goal ready to execute in the sprint(s) of the release. Figure 3-7 represents a typical release plan.

© John Wiley & Sons, Inc.

FIGURE 3-7: Sample release plan.

Bear in mind the pen-pencil rule: You can commit to (write in pen) the plan for the first release, but anything beyond the first release is tentative (written in pencil). In other words, use just-in-time planning for each release. After all, things change, so why bother getting microscopic too early?

Preparing for Release

In release planning, you also need to prepare your organization for the product release. This section discusses how to prepare for supporting the new functionality in the marketplace and how to get stakeholders in your company or organization ready for product deployment.

Preparing the product for deployment

In each sprint, a valuable working product increment is created in support of the release goal. With a definition of done that means your increment each sprint is shippable, there’s not much more you need to do to prepare the product for technical deployment. Every sprint, you’re ready to release if there is enough value accumulated for the customer.

With software product development, releasing to production is done through continuous integration (CI) and continuous deployment (CD), which are extreme programming (XP) practices used with software product development. The product code is checked in and moved to quality assurance (QA) and then to the production (live) environments as quickly and seamlessly as possible. Advancements in technology enable teams to automate a pipeline for building, integrating, testing, and fixing without delay. Combining a CI/CD pipeline with a robust automated testing harness raises the bar of your product development agility. Teams developing non-software products should use techniques that automate testing and integration of new functionality to the existing product as much as possible.

In information technology (IT), usually involving software development, development operations (DevOps) is the integration of software development and IT operations (which includes functions such as systems administration and server maintenance). Taking a DevOps approach enables everyone involved (user experience, testing, infrastructure, database, coding, design) to work together, to eliminate handoffs, and to streamline collaboration for reduced deployment cycle times. Multiple teams working on the same product will not be successful without a reliable CI/CD pipeline.

Not all agile product development efforts use release planning. Some scrum teams release functionality for customer use with every sprint or even every day. The development team, product, organization, customers, stakeholders, and product’s technological complexity can all help determine your approach to product releases. Helpful for this discussion are Principles 1 and 3, respectively: “satisfy the customer through early and continuous delivery” and “deliver…frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” (For details, see Chapter 1 in Book 4.)

Prepare for operational support

After your product is released to the customer, someone will have to support it, a responsibility that involves responding to customer inquiries, maintaining the system in a production environment, and enhancing existing functionality to fill minor gaps. Although new development work and operational support work are both important, they involve different approaches and cadences.

Separating new development and support work ensures that new development teams can focus on continuing to bring innovative solutions to customers at a faster rate than if the team frequently switches between the two types of work.

Consider a model that separates new development and maintenance work, as illustrated in Figure 3-8.

© John Wiley & Sons, Inc.

FIGURE 3-8: Operational support scrum team model.

For a scrum team of nine developers, for instance, you would divide the development team into two teams, one with six developers, and the other with three. (These numbers are flexible.) The team of six does new development work from the product backlog in one-week to two-week sprints, as described in Book 4. The work that the team commits to during the sprint planning meeting will be the only work they do.

The team of three are your firefighters and do maintenance and support work in one-day sprints or by using kanban. (You learn about one-day sprints in Chapter 4 of Book 4.) Single-day sprints allow the scrum team to triage all incoming requests from the previous day, plan the highest-priority items, implement those items as a team, and review the results at the end of the day (or even earlier) for go or no-go approval before pushing the changes to production. For continuity, the product owner and scrum master are the same for each team.

Although the newly modified product development team is smaller than before, there are still enough developers to keep new development efforts moving forward, uninterrupted by maintenance work. By the time you begin releasing functionality to the market, your scrum team will be working well together and the developers will have increased their versatility by being able to complete more types of tasks than when the project first started.

Teams should rotate team members between the two activities at sprint boundaries (every three to five sprints, for example) to give everyone an opportunity to learn from both types of work. If support is excessive, the product owner may want to reevaluate the product backlog to see if there are ways to reduce the weight of support and its distraction. Support distractions cause the team to focus on tactical resolutions rather than strategic value creation. Team stability and acceleration will improve.

When preparing for release, establishing expectations upfront regarding how the functionality will be supported in production allows the scrum team to develop the product in a way that enables the team to effectively support the product after it’s deployed. Establishing expectations also increases ownership across the scrum team and heightens the team’s awareness and dedication to long-term success.

Product owners who maintain a strong working relationship with help desks or those providing customer support benefit greatly by understanding how their products are used by real users. Help desk reporting can be valuable for evaluating product backlog candidates or upcoming priorities. Help desks benefit by knowing that the scrum team is working to address any escalated incidents. The product owner involves these groups in release planning to ensure that all are prepared for operational support well in advance of release.

Preparing the organization

A product release often affects a number of departments in a company or an organization. To get the organization ready for the new functionality to be released next, the product owner coordinates with the rest of the organization regarding what to expect and what will be needed from them during release planning. When product owners do this effectively, there shouldn’t be surprises at release time.

Release planning addresses not only the activities for the development team to release but also the activities to be performed by the rest of the organization. These might include the following:

• Marketing: Do marketing campaigns related to the new product need to launch at the same time as the product?
• Sales: Do specific customers need to know about the product? Will the new product cause an increase in sales?
• Logistics: Is the product a physical item that includes packaging or shipping?
• Product support: Does the customer service group have the information it needs to answer questions about the new product? Will this group have enough people on hand in case customer questions increase when the product launches?
• Legal: Does the product meet legal standards, including pricing, licensing, and correct verbiage, for release to the public?

The departments that need to be ready for the release and the specific tasks these groups need to complete will vary from organization to organization. A key to release success, however, is that the product owner and scrum master involve the right people and ensure that those people clearly understand what they need to do to be ready for the functionality release.

During release planning, you also need to include one more group: the customer. The next section discusses getting the marketplace ready for your product.

Preparing the marketplace

The product owner is responsible for working with other departments to ensure that the marketplace — existing customers and potential customers — is ready for what’s coming. The marketing or sales teams may lead this effort; team members look to the product owner to keep them informed as to the release date and the features that will be part of the release.

Some software products are for only internal employee use. Certain things you’re reading in this section might seem like overkill for an internal application — that is, an application released only within your company. However, many of these steps are still good guidelines for promoting internal applications. Preparing customers, whether internal or external, for new products is a key part of product success.

To help prepare customers for the product release, the product owner may want to work with different teams to ensure the following:

• Marketing support: Whether you’re dealing with a new product or new features for an existing product, the marketing department should leverage the excitement of the new product functionality to help promote the product and the organization.
• Customer testing: If possible, work with your customers to get real-world feedback about the product from a subset of end users. (Some people use focus groups.) Your marketing team can also use this feedback to translate into testimonials for promoting the product right away.
• Marketing materials: An organization’s marketing group also prepares the promotional and advertising plans, as well as packaging for physical media. Media materials, such as press releases and information for analysts, need to be ready, as do marketing and sales materials.
• Support channels: Ensure that customers understand the available support channels in case they have questions about the product.

Review the items on your release backlog from the customer’s standpoint. Think of the personas you used when creating your user stories. Do those personas need to know something about the product? Update your launch checklist with items that would be valuable to customers represented by your personas.

Finally, you’re there — release day. Whatever role you played along the way, this is the day you worked hard to achieve. It’s time to celebrate!

Sprint Planning

With agile product development, a sprint is a consistent iteration of time in which the development team creates a specific group of product capabilities from start to finish. At the end of each sprint, the functionality that the development team has created should be working, ready to demonstrate, and potentially shippable to the customer.

Sprints should be the same length. Keeping the sprint lengths consistent helps the development team measure its performance and plan better at each new sprint.

Sprints generally last one to four weeks. One month is the longest amount of time any sprint should last; longer iterations make changes riskier, defeating the purpose of being agile. It’s rare to see sprints lasting longer than two weeks, and more often you see sprints lasting a week. One-week sprints are a natural cycle with the Monday-to-Friday business week, which structurally prevents weekend work. When priorities change on a daily basis, some scrum teams work in one-day sprints, as discussed in Chapter 4 of Book 4.

Market and customer needs are changing more and more quickly, and the amount of time you can afford between opportunities to gather customer feedback only gets shorter. Your sprint shouldn’t be longer than your stakeholders can consistently go without changes in priority regarding what the scrum team should be working on in the sprint. Sprint duration is a function of the business’s need for change.

Each sprint includes the following:

• Sprint planning at the beginning of the sprint
• Daily scrum meetings
• Development work — the bulk of the sprint
• A sprint review and a sprint retrospective at the end of the sprint

Discover more about daily scrums, development work, sprint reviews, and sprint retrospectives in Chapters 4 and 5 of Book 4.

Sprint planning is stage 4 in the Roadmap to Value, as you can see in Figure 3-9. The entire scrum team — the product owner, scrum master, and development team — works together to plan sprints.

© John Wiley & Sons, Inc.

FIGURE 3-9: Sprint planning as part of the Roadmap to Value.

The sprint backlog

The sprint backlog is a list of user stories associated with the current sprint and related tasks. When planning your sprint, you do the following:

• Establish the goal for your sprint.
• Choose the product backlog items (user stories) that support your goal.
• Break user stories into specific development tasks.
• Create a sprint backlog. The sprint backlog consists of the following:
  • The list of user stories in the sprint in order of priority (value).
  • The relative effort estimate for each user story.
  • The tasks necessary to develop each user story.

  • The effort, in hours, to complete each task (if needed). At the task level, if you estimate the number of hours each task will take to complete, use hours instead of using story points. Because your sprint has a specific short length, and thus a known number of available working hours, you can use the time each task takes to determine whether the tasks will fit into the team’s capacity of the sprint. Each task should take one day or less for the development team to complete.

    Some mature development teams may not need to estimate their tasks as they get more consistent at breaking down their user stories into executable tasks. Estimating tasks is helpful for newer development teams to ensure that they understand their capacity and plan each sprint appropriately.

  • A burndown chart, which shows the status of the work in progress for the sprint.

Tasks should take a day or less to complete for two reasons:

• The first reason involves basic psychology: People are motivated to get to the finish line. If you have a task that you know you can complete quickly, you’re more likely to finish it on time, just to check it off your to-do list.

• The second reason is that one-day tasks provide good red flags that development targets might be veering off course. If a development team member reports that he or she is working on the same task for more than one or two days, that team member probably has a roadblock and the scrum master should investigate what might be keeping the team member from finishing work. (For more on managing roadblocks, see Chapter 4 in Book 4.)

The development team collaborates to create and maintain the sprint backlog, but only the development team can modify the sprint backlog. The sprint backlog should reflect an up-to-the-day snapshot of the sprint’s progress. Figure 3-10 shows a sample sprint backlog at the end of the sprint planning meeting. You can use this example, find other samples, or even use a whiteboard.

The sprint planning meeting

On the first day of each sprint, often a Monday morning, the scrum team holds the sprint planning meeting.

© John Wiley & Sons, Inc.

FIGURE 3-10: Sprint backlog example.

For a successful sprint planning meeting, make sure everyone involved in the session (the product owner, the development team, the scrum master, and anyone else the scrum team requests) is dedicated to the effort for the entire meeting.

Base the length of your sprint planning meeting on the length of your sprints. Sprint planning should take no longer than two hours per week of the sprint, or no longer than a full day for a one-month sprint. This timebox helps ensure that the meeting stays focused and on track. Figure 3-11 is a good quick reference for your sprint planning meeting lengths.

© John Wiley & Sons, Inc.

FIGURE 3-11: Ratio of sprint planning meeting to sprint length.

With agile product development, the practice of limiting the time of your meetings is sometimes called timeboxing. Keeping your meetings timeboxed provides focus and ensures that the development team has the time it needs to create the product.

You’ll split your sprint planning meetings into two parts: one to set a sprint goal (the “why”) and choose user stories for the sprint (the “what”), and another to break down your user stories into individual tasks (the “how” and “how much”). The details on each part are discussed next.

Part 1: Setting goals and choosing user stories

In the first part of your sprint planning meeting, the product owner and development team, with support from the scrum master, decide what to do during the sprint by doing the following:

1. Discuss and set a sprint goal.
2. Select the user stories from the product backlog that support the sprint goal, further refine them for understanding, and revisit their relative estimates.
3. If needed, create user stories to fill gaps to achieve the sprint goal.
4. Determine what the team can commit to in the current sprint.

Consistently refining the product backlog ensures that the scrum team plans items into each sprint with which they’re already familiar. This refinement is also critical for ensuring that sprint planning stays within the timebox and results in a clear plan to deliver potentially shippable functionality at the end of each sprint. Scrum teams, on average, spend about 10 percent of their sprint in product backlog refinement for future sprints.

At the beginning of your sprint planning meeting, the product owner should propose a sprint goal that identifies a problem to solve for the customer and then together with the development team discuss and agree on the sprint goal. The sprint goal should be an overall description of the working customer functionality that the team will demonstrate and possibly release at the end of the sprint. The goal is supported by the highest-priority user stories in the product backlog. A sample sprint goal for the mobile banking application (refer to Chapter 2 in Book 4) might be as follows:

Demonstrate the ability of a mobile banking customer to log in and view account balances and pending and prior transactions.

Using the sprint goal, you determine the user stories that belong in the sprint and refine the estimates for those user stories, as needed. For the mobile banking application sprint goal example, the group of user stories for the sprint might include the following:

• Log in and access my accounts.
• View account balances.
• View pending transactions.
• View prior transactions.

All these would be high-priority user stories in the product backlog that support the sprint goal.

Don’t forget to bring at least one improvement item agreed to during a previous sprint retrospective.

The second part of reviewing user stories is confirming that the effort estimates for each user story have been reviewed and adjusted, if needed, and reflect the development team’s current knowledge of the user story. Adjust the estimate if necessary. With the product owner in the meeting, resolve any outstanding questions. At the beginning of the sprint, the scrum team has the most up-to-date knowledge about the system and the customer’s needs, so make sure the development team and product owner have one more chance to clarify and size the user stories going into the sprint.

Finally, after you know which user stories support the sprint goal, the development team should agree and confirm that it can complete the goal planned for the sprint. If any of the user stories you discussed earlier don’t fit in the current sprint, remove them from the sprint and add them back into the product backlog.

Always plan and work on one sprint at a time. An easy trap to fall into is to place user stories into specific future sprints. For example, when you’re still planning sprint 1, don’t decide that user story X should go into sprint 2 or 3. Instead, keep the ordered list of user stories up to date in the product backlog and focus on always developing the next highest-priority stories. Commit to planning only for the current sprint. What you learn in sprint 1 may fundamentally change how you go about sprint 2 or 10 or 100.

After you have a sprint goal, user stories for the sprint, and a commitment to the goal, move on to the second part of sprint planning.

Because a sprint planning meeting for sprints longer than one week might last a few hours, you might want to take a break between the two parts of the meeting.

Part 2: Breaking down user stories into tasks for the sprint backlog

In the second part of the sprint planning meeting, the scrum team does the following:

1. The development team creates the sprint backlog tasks associated with each user story. Make sure that tasks encompass each part of the definition of done: developed, integrated, tested (including test automation), and documented.
2. The development team double-checks that it can complete the tasks in the time available in the sprint.
3. Each development team member should choose his or her first task to accomplish before leaving the meeting.

Development team members should each work on only one task on one user story at a time to enable swarming — the practice of the entire development team working on one user story until completion. Swarming can be an efficient way to complete work in a short amount of time. In this way, scrum teams avoid getting to the end of the sprint with all user stories started but few finished.

At the beginning of part two of the meeting, break the user stories into individual tasks and allocate a number of hours to each task. The development team’s target should be completing a task in a day or less. For example, a user story for the XYZ Bank mobile application might be as follows:

Log in and access my accounts.

The team decomposes this user story into tasks, such as the following:

• Write the unit test.
• Write the user acceptance test.
• Create an authentication screen for a username and password, with a Submit button.
• Create an error screen for the user to reenter credentials.
• Create a screen (once logged in) displaying a list of accounts.
• Using authentication code from the online banking application, rewrite code for an iPhone/iPad/Android application. (This task could potentially be three different tasks.)
• Create calls to the database to verify the username and password.
• Re-factor code for mobile devices.
• Write the integration test.
• Promote the product increment to QA.
• Update the regression test automation suite.
• Run the security test.
• Update the wiki documentation.

After you know the number of hours that each task will take, do a final check to make sure that the number of hours available to the development team reasonably matches the total of the tasks’ estimates. If the tasks exceed the hours available, one or more user stories will have to come out of the sprint. Discuss with the product owner what tasks or user stories are the best to remove.

If extra time is available within the sprint, the development team might be able to include another user story. Just be careful about over-committing at the beginning of a sprint, especially during the first few sprints.

After you know which tasks will be part of the sprint, choose what you will work on first. Each development team member should select his or her initial task to accomplish for the sprint. Team members should focus on one task at a time.

As the development team members think about what they can complete in a sprint, use the following guidelines to ensure that they don’t take on more work than they can handle while they’re figuring out new roles and techniques:

• Sprint 1: 25 percent of what the development team thinks it can accomplish. Include overhead for learning the new process and starting product development.
• Sprint 2: Assuming the scrum team was able to complete sprint 1 successfully, 50 percent of what the development team thinks it can accomplish.
• Sprint 3: Assuming success in sprint 2, 75 percent of what the development team thinks it can accomplish.

• Sprint 4 and forward: Assuming success in sprint 3, 90 percent. The development team will have developed a rhythm and velocity, gained insight into agile principles and the product, and will be working at close to full pace.

  Avoid planning 100 percent of capacity for a sprint. Scrum teams should build in slack in their sprint to account for unknowns that inevitably come up. Instead of padding estimates, simply be wise and don’t commit every available hour, assuming everything will go as planned. Teams that finish early accelerate faster.

The scrum team should constantly evaluate the sprint backlog against the development team’s progress on the tasks. At the end of the sprint, the scrum team can also assess estimation skills and capacity for work during the sprint retrospective (see Chapter 5 in Book 4). This evaluation is especially important for the first sprint.

For the sprint, how many total working hours are available? In a one-week sprint or a 40-hour week, you could wisely assume that 4.5 working days are available to develop user stories. Why 4.5 days? About one-fourth of day one is taken up with sprint planning, and about one-fourth of day five is taken up with the sprint review (when the stakeholders review the completed work) and the sprint retrospective (when the scrum team identifies team improvements for future sprints). That leaves 4.5 days of development. If you assume each full-time team member has 30 hours per week (6 productive hours per day) to focus on the sprint goal, the number of working hours available is

Number of team members × 6 hours × 4.5 days

After sprint planning is finished, the development team can immediately start working on the tasks to create the product!

The scrum master should make sure the product vision and roadmap, product backlog, definition of done, and sprint backlog are in a prominent place and accessible to everyone during sprint planning as well as in the area in which they work. In this way, stakeholders can view the product information and progress on demand without interrupting the development team. For details, see Chapter 4 in Book 4.