Chapter 4

Release and Sprint Planning

IN THIS CHAPTER

Developing the roadmap into release plans

Applying the scrum sprint cycle

Planning your sprints for maximum effectiveness

Using the sprint backlog

So far you have a product, a product owner, and a development team. Release and sprint planning is really where the rubber hits the road. As mentioned before, with scrum, you’ll do more planning than ever before, but it’s focused, continuous, value-based, results-oriented, and packaged such that you’ll wonder how you ever managed projects without it.

In this chapter, you find out how to plan the release of project features in a logical and organized way. The purpose of release planning is to mobilize the wider project team around a specific set of functionality that the organization wants to release to the marketplace. This is when such departments or stakeholders as the marketing department, field support, and customer service get mobilized and prepared to support functionality that end customers are going to be using in the real world.

You also go through the scrum event of sprints. Scrum at its core is the sprint cycle. You find out how to use this valuable process and get the best possible results.

A sprint is a fixed timebox iteration within which development is done to produce a working, potentially shippable product. A typical sprint might be one or two weeks in duration but could be as little as a day and as much as a month.

This chapter discusses how prioritizing releases and sprints accelerates time to market and maximizes return on investment (ROI) and explains that by having feedback loops, you create the product that your clients want, with the features they’ll actually use.

Release Plan Basics: Stage 3

The Roadmap to Value begins with the bird’s-eye basics: your vision statement. This allows you to establish your destination and define the end of the project. The second stage, the product roadmap, provides a holistic view of the features that support the vision. As you narrow your focus and generate more detail, you come into release planning, which is Stage 3 in your Roadmap to Value (see Figure 4-1). The release planning concept is scrum. However, the release plan artifact is a common practice that many scrum aficionados use with success.

© John Wiley & Sons, Inc.

FIGURE 4-1: Stage 3 of the Roadmap to Value is the release plan.

A release plan is a high-level timetable for releasing a set of product requirements. So, you’re working down, segmentally, from the big-picture roadmap to the midlevel release plan. (Later in this chapter, you discover the next-smaller size, which is the actual sprint.) The release plan provides a focal point around which the project team can mobilize.

Do the minimum amount possible that still creates a working product. When planning a set of features to release to the market, always ask yourself, “What is the minimum set of features that delivers value to my customer?” This is what is commonly referred to as the minimum viable product (MVP).

You should release product to the market as often as you have something of value to offer your customers — the minimum viable product. Your product releases could also come on a regular schedule (for example, four times a year, at the end of each quarter). But with the advances in technology and the need to be quick to market, releases now may be monthly, weekly, or even multiple times a day in some cases.

Consider the pen-and-pencil rule. You can use a pen to commit to the plan for the first release, but anything beyond this plan is written in pencil. It’s just-in-time planning for each release. (You are learning while delivering value.)

A project may have multiple releases. For each release, you start with the goal, which is supported by the next-highest-priority features and requirements. You’ll see that this is a pattern you follow at each stage of the Roadmap to Value. Each release has a release goal, and you commit to only one release at a time. Figure 4-2 depicts a typical release plan with an optional release sprint.

© John Wiley & Sons, Inc.

FIGURE 4-2: A typical release plan with the release goal and date and an optional release sprint.

The number of sprints within each release can vary depending on the release goal and what’s required to complete the requirements to achieve that goal. An option is to use release trains, in which each release has a set time schedule. Releases are set so that everyone knows when to expect them.

At each scheduled release, the product owner decides which of the completed functionalities will be released on that date. This way, organizations and customers know to expect new features on a set schedule. Scrum teams can predictably organize their release plans to cadence.

Scrum is an empirical approach. Each step of the way, you inspect your results and adapt immediately to the changing needs of your customers. These fundamentals enable you to achieve significant cost and time savings while delivering value and what the client wants. You may have a bird’s-eye view of four releases for your project, but you plan in detail only one release at a time. What you learn in the first release may change what you do in the second release.

Your organization may be afraid to release software incrementally. You may find it difficult to release completed work before the entire backlog is complete. Sometimes that hesitancy derives from a sense that once the product is released you can’t improve it or add to it. Overcome these antipatterns to support more effective and frequent releases.

Prioritize, prioritize, prioritize

You’ve heard this before, and you’ll hear it throughout this book. Identifying the highest-priority (or highest-value) requirements, according to business value and risk, and working with only those requirements are key common practices within the agile community.

Think of each release as the next, incremental MVP of your product. When planning each release, ask these questions to identify the highest-priority features:

• What makes a requirement important for this release?
• What is the minimum number of features providing business value to the customer do we need to bring to market?
• Which requirements present the greatest risk and should be addressed sooner than later?

A famous Standish Group study from 2001 showed on a representational software development project that only 20 percent of the features were used always or often by the customers. Interestingly, 64 percent of features were never or rarely used. With scrum’s emphasis on prioritization, only those most important and useful features are developed first. What if your project runs out of funding and you’re only 80 percent done? Based on what the Standish study found, you might not have needed the remaining 20 percent anyway.

The following four key reasons are why you want as small a set of features per release as possible:

• First-mover advantage of speed to market and increased market share
• Accelerated customer feedback cycle
• Maximized ROI (a dollar today is literally worth more than a dollar will be worth six months from now)
• Reduced internal risk from such factors as organizational change and budget poaching

The product owner fully owns the release plan and is the one who prioritizes the requirements in the product backlog and sets the release goal (as shown in the following section). While the product owner decides what the priorities are and when to release completed shippable functionality, she consults stakeholders and the development team to make her decisions. Figure 4-3 applies the 80/20 rule to the value versus effort idea. It’s isn’t a magic formula, but a helpful way to understand and explain value.

© John Wiley & Sons, Inc.

FIGURE 4-3: Applying the Pareto Principle (80/20 rule) to scrum.

Release goals

Each release plan has an overall business goal called a release goal. This goal is created by the product owner and ties directly to the product end goal, which is the product’s vision statement. The release goal establishes the midterm boundary around specific functionality that will be released to customers to use in the real world.

Having an explicit release goal expedites the prioritization process: If a requirement doesn’t align with the goal, you don’t have to worry about that requirement in this release. Any given requirement should earn the right of your investment. Leave it tucked away in the product backlog until it can support a priority goal. Figure 4-4 shows a matrix to help you determine the priority stories.

© John Wiley & Sons, Inc.

FIGURE 4-4: Backlog priority matrix.

Think of the three layers of goal setting as a prioritization filter system. The vision statement is the highest boundary. If a feature doesn’t fit the overall vision, it doesn’t belong in this project. Don’t even put that requirement on the product backlog. The requester needs to go get funding for that idea separately. Don’t allow features to be stowaways on your project.

Next comes the release goal. This is the midterm boundary. If a requirement doesn’t fit this goal, it stays in the product backlog. Finally, the shortest-term boundary is the sprint goal.

Goals drive the product backlog and the release plan, not the other way around. Every feature and requirement must be thought of in terms of whether it fits the goal. This is purpose-driven development. Goals drive what makes the product backlog. Goals drive what gets included in a release. And goals drive what gets included in each sprint.

Release sprints

Sometimes, releasing product features into the marketplace requires completing certain jobs that can’t fit within a normal developmental sprint. Ideally, all activities required to release a product to the market are done within a normal sprint. But if the way an organization is set up doesn’t allow it, a release sprint may be used to accomplish such purposes as

• Verifying scaling (for example, load or performance testing)
• Broader testing activities (for example, focus groups or validating that developed functionality works with live data)

Although it’s preferable not to have release sprints, simply phrased, a release sprint is for all that other stuff that needs doing to get the product to market.

The release sprint is commonly used at the end of the normal series of sprints within a release. The length of a release sprint may be different from the development sprints in the release. The release sprint length depends on the types of activities and the amount of work required to release the completed product increments from each sprint. The scrum team determines all these factors during release planning.

During a release sprint, no actual development of requirements is done. All development tasks (such as testing, technical documentation, quality assurance, and peer review) are completed during each sprint to satisfy the team’s definition of done, which in turn ensures potentially shippable product at the end of each sprint. But before the product can go out to the market, other things (such as focus groups or load and performance testing) may need to be done.

Because the release sprint length and activities are often different from the development sprints, no concept of velocity exists for a release sprint. Development teams estimate to the best of their knowledge the effort and complexity of the tasks for the release sprint. They should all agree and feel comfortable with the release sprint length after it is decided.

The release sprint is a form of antipattern in organizations that can’t do scaled testing and organizational support tasks within the sprint. If you don’t need it, don’t do it.

Including examples already given, uses for release sprints may include the following:

• Conducting focus groups (keep in mind that this isn’t to identify new features but to validate what you’ve done and identify release issues)
• Scaling tests
• Tweaking performance based on scaling test results
• Integrating the product within enterprise wide systems
• Creating documentation such as user manuals
• Finalizing any regulatory requirements

Release plan in practice

To see how a release plan works in the real world, follow these steps:

1. Develop a release goal.

   This goal is the target for everything else. The product owner ensures that the goal aligns with the product vision and works with the scrum team to make sure that the entire team feels comfortable with the goal.

2. Identify the target release date.

   This date may be influenced by factors outside the control of the scrum team.

3. Identify the highest-priority (highest-value) requirements (MVP) on the product backlog that support the release goal.

   Priority is a function of value and risk. Tackle the highest value/highest risk items first. Refer to Figure 4-4 for a value matrix.

4. Refine the requirements estimates as needed.

   Sometimes, issues and/or synergies are discovered when the development team looks at the smaller package of requirements that go into a release plan. The requirements themselves will also be more detailed and broken down (no larger than 34; see Chapter 3 in Book 5) than when the development team originally estimated at the product roadmap level.

5. Identify the team’s velocity.

   If the team is stable and has been working on the same project, established velocity from previous sprints is a great starting point. If the team hasn’t established velocity, start modestly until you have run a few sprints and velocity can be ascertained.

6. Plan a release sprint (if needed).

   Determine as a scrum team whether you’ll need one and, if so, how long it will be.

7. Finalize the release scope.

   Based on velocity, total estimates of requirements and number of sprints within the release timebox, how much functionality can you include? Which is more flexible — the date or the amount of functionality? What adjustments need to be made to the release date or scope of requirements to release as much as you can within your timebox?

   Suppose that your velocity is 20, the release timebox is 5 sprints, and the total estimated points for the release is 110. This puts you ten points over what’s available in the release. The product owner has a decision to make. Are the requirements that make up the bottom ten points in the release valuable enough to include, or can the release go on without them? Or does the release need to be extended one sprint, and will that be acceptable to the stakeholders and customers?

One option in release planning is to use the release train model. Rather than have releases of varying duration, in this scenario, each release is exactly the same length — six weeks, for example. At the end of each six-week cycle, the completed functionality from each of the sprints is packaged and released. This way, a development rhythm is created, and everyone in the organization can anticipate his workload and schedule moving forward.

Use any of the estimation and consensus-building techniques discussed in Chapter 3 of Book 5 to refine the product backlog items in the release, if requirements still need to be refined and estimated (see the preceding Step 4). If your releases consist of many product backlog items, use affinity estimating (the T-shirt sizing technique discussed in Chapter 3 of Book 5) for release planning.

As with all scrum documentation, the simplest tools possible are preferred. The entire release plan can be mapped out with your trusty whiteboard and sticky notes. This allows for ease in change and immediate access. As well, it just plain saves time.

Sprinting to Your Goals

Finally, the heart of scrum! Sprints, and their built-in inspect and adapt model, are integral scrum features. It is through the sprint process that you can achieve the three agile pillars of improvement — transparency, inspection, and adaptation.

By breaking your project into tangible pieces and then using the empirical model of scrum to assess your progress, you can pivot constantly moving forward. This allows you the nimbleness and ease of adaptation so sorely missing in waterfall.

Each scrum team member has the same purpose in the sprints: maximizing effectiveness in delivering potentially shippable product.

Defining sprints

Sprints are the essence of scrum. They’re a consistent timebox for product development by the development team. Each sprint includes the following:

• Sprint planning, including goal setting
• Daily scrums
• Development time, including regular review by the product owner
• Sprint review
• Sprint retrospective

The consistent timebox of sprints allows the development team to establish a development rhythm. It also enables scrum teams to extrapolate into the future based on empirical data such as velocity. As soon as one sprint is finished, another begins. A flow of consistent iterative feedback loops is created and thereby creates an ideal environment for production and continuous improvement.

Imagine that you’re a runner. You’re consistently training for the 100-yard dash and have become incredibly proficient at it, but suddenly your coach asks you to run a marathon. If you attempt the marathon at your 100-yard-dash pace, you won’t finish the marathon. You need to modify your training to adjust for a marathon pace, which will require coaching, schedule, and diet changes over time. All the muscle memory and the type of endurance that your body has developed will need to be relearned to run a different length of race.

Planning sprint length

Because sprint goals don’t change during a sprint, the answer to the question “How long should a sprint be?” depends on your project and how long your organization can go without making changes. That is the outer edge. You have no reason to discuss going beyond that in duration. For example, if your organization struggles to go a week without needing changes, don’t even entertain the idea of a two-week sprint. You won’t be able to maintain the integrity of the stability of the sprint, and stability is a huge driver of performance in scrum. Instead, discuss how much shorter you can make the sprint.

Also, sprint lengths don’t change after they begin and ideally don’t change throughout a project unless they’re being made shorter. If a scrum team changes sprint length during a project, it comes at a significant cost: Their earlier velocity is no longer relevant. Performance is not a straight mathematical line that can be sliced, diced, and reassembled. Just because a scrum team doubles their sprint from one to two weeks doesn’t mean that they will automatically accomplish double their historical two-week velocity.

Shorter sprints decrease the amount of time between feedback received from stakeholders, enabling scrum teams to inspect and adapt earlier and more often. Longer sprints have a diminishing return because less of a sense of urgency exists due to the multiple days still available to the team. Weekends and longer sprint meetings can also have a negative effect on efficiency.

The capacity of a development team during a one-week sprint may be higher or lower than half the historical two-week velocity. You don’t have any idea until you run a few sprints, and you don’t know for sure until you run a lot of sprints.

Whereas the cost of changing sprint lengths throughout a project is significant, the cost of changing a sprint goal during a sprint is probably worse. If a sprint goal becomes irrelevant (for example, because of changes of company direction or changes in the market) before the end of a sprint, a product owner may decide to cancel the sprint. But be aware that canceling wastes valuable development resources and is quite traumatic to the scrum team and the organization. Also, the shorter the feedback loop (that is, length of sprint), the less likely a product owner would be to cancel a sprint.

One things we know from science is that you can’t turn off your mind. It’s always working. If you can give your development team a small number of problems to solve, and tell them that they’ll face those problems tomorrow, they’ll think about them consciously at work. Whether they want to or not, they’ll also think about them unconsciously when they’re away from work. This is the reason why the stability of sprints is so important. After a sprint starts, the developers must have confidence that the scope is stable so that their minds can be fully focused on what needs to be done for this sprint, whether they’re at work or away from it. Have you ever had an epiphany while brushing your teeth? That’s the dynamic discussed here. But you need two elements: a limited number of problems and confidence that you’ll face those problems tomorrow. If every day a developer could be working on Project A, Project C, or Project who-knows-what, this won’t happen. A developer will mentally engage only when he gets to the office and discovers what’s ahead of him in reality. One reason why agile projects are so innovative is that they have this stability and, thus, more of the developer’s mind share.

The one-week sprint length is a nice rhythm. It gives the development team clear time off, avoids weekend cheating to get more work done than is within the team’s capacity, yet is long enough for real progress to be made every week. This shorter feedback cycle also allows scrum teams to inspect and adapt more frequently. For these reasons, scrum teams should always be looking for ways to responsibly shorten their sprint length.

The key is to run sprints that enable your development team to realistically create tangible, tested, and approved product every single sprint. After each sprint, you will have something real to show to stakeholders.

Following the sprint life cycle

Each sprint has the same process: sprint planning, daily scrums, a sprint review, and a sprint retrospective. Sprints are developmental cycles that repeat until your project is complete. Requirements (often in the form of user stories) are developed, tested, integrated, and approved within each sprint. The process continues sprint after sprint. Figure 4-5 depicts a one-week sprint life cycle.

© John Wiley & Sons, Inc.

FIGURE 4-5: The one-week sprint life cycle.

When scrum teams are distributed offshore with team members in faraway time zones (such as the United States and India), arrangements need to be made for all team members to attend each of the sprint meetings. To account for time-zone differences, the domestic team members might join the meeting Sunday night while it’s Monday morning for the offshore team members. At the end of the sprint, the domestic team members finish the sprint Friday morning and take the rest of the day off while the offshore team is joining the sprint review and retrospective Friday night. Rotating each sprint might be appreciated on each end so that each team member doesn’t always have to work on Sunday nights or Friday nights.

The key is that after each sprint, the scrum team learns new things. Change happens; it’s inevitable. Responding and adapting to it should be considered progress, not failure.

Change is easy in scrum because at the end of every cycle, what was created was done to completion. When you go into your next sprint and work on items from the product backlog, it doesn’t matter whether those items have been on the product backlog for four months, four weeks, or four minutes. Old or new, each product backlog item gets prioritized not by the order in which it was received, but by the order in which it will deliver the highest value to the customer.

The Monday-to-Friday work week is a natural, biorhythmic time frame. Teams need a weekend break, which fits naturally with life patterns. So, avoid off-kilter sprint patterns of Wednesday to Tuesday or the like.

Planning Your Sprints: Stage 4

The planning of sprints is Stage 4 in the Roadmap to Value. All the work to be accomplished during that specific sprint is planned here. Each sprint planning session is timeboxed to no more than two hours for each week of the sprint. If you have a one-week sprint timebox, you have a maximum of two hours to plan your sprint, for example.

Sprint goals

A goal is created for each sprint. The product owner initiates the goal discussion, identifying the business value objective that needs to be met. After the team is clear on the goal, the product owner chooses the requirements from the product backlog that best support the goal. As with the release goal, the sprint goal drives the requirements developed, not the other way around.

The sprint goal itself must support the release goal, which supports the vision statement. This goal decomposition and alignment are essential for ensuring that you’re doing purpose-driven development.

The development team is critical in creating the sprint goal. Because they’re the ones doing the actual work, while the product owner establishes the direction, or the what, the development team establishes the how and how much.

If your development team has an established average velocity, it may be used as input in determining the amount of work they will take on during the sprint.

The development team can also use velocity for stretching, testing its limits, or backing off if they’re struggling to achieve the goals set. If they’ve been achieving 34 story points comfortably, they might push it to 38 or 40. If they’ve been struggling to achieve 25, they might lower it to 23 while the scrum team figures out organizational drag that can be removed.

Both phases of sprint planning occur in the single sprint planning meeting at the beginning of the sprint. Phase I is where the product owner, with input from the development team and facilitated by the scrum master, determines what needs to be accomplished (the goal). In Phase II, the development team determines how to achieve the sprint goal and develops the actual sprint backlog of supporting tasks.

The sprint planning meeting may not always go smoothly, especially at first. You may slip down rabbit holes, discover tangents, and unearth different estimations of what’s possible. This is where a strong and deft facilitator is needed in the form of the scrum master. It’s their job to make sure that the session stays on track and the heat stays on low.

Phase I

At the start of Phase I, the sprint goal is created, and the development team must fully understand it, because it will provide the boundaries and direction for the work they will do throughout the sprint. The product owner then selects a portion of the product backlog that supports the goal. This won’t necessarily be the final sprint backlog, but is the forecasted functionality that if finished in the sprint, would satisfy the sprint goal. It’s what the development team will work from to achieve the sprint goal and determine the actual sprint backlog.

Phase I gives the development team and product owner another opportunity to clarify any existing requirements or identify new ones that are needed to achieve the sprint goal. This would also be the time to give the final size estimation on any clarified requirements and size any new requirements for the sprint. Remember the yardstick: If any requirements are sized higher than an 8, they’re too big for a sprint (see Chapter 3 in Book 5).

Consider bringing six to ten product backlog items into each sprint. This is usually the right balance of being able to deliver a product increment with substantial functionality as well as litmus that each individual item is sufficiently broken down.

The only requirements discussed in sprint planning should be those estimated between 1 and 8 on the Fibonacci scale. This isn’t a scrum rule, but it aligns with the affinity estimating model (see Chapter 3 in Book 5) and has been an effective way for many teams to keep focused on properly refined requirements that can be completed within a sprint. For more on Fibonacci numbers, see Chapter 3 in Book 5.

Phase II

When the goal and the supporting requirements have been determined by the scrum team, the development team breaks down those requirements into individual tasks — how they will turn product backlog items into the product increment. The tasks for each requirement should explicitly satisfy the team’s definition of done. For instance, if the definition of done includes integration with system A, at least one task for the requirement should be “integration test with system A.”

Ideally, each task should be able to be completed in one day. This gives the development team a tangible, realistic time target as they break requirements down into tasks. It also sets a benchmark from which the team can be alerted to any development problems. If a task is taking multiple days to develop, an issue might need to be addressed with the task or the developer.

Development teams may choose to estimate the tasks for each requirement in hours if the organization wants that level of visibility. But many teams simply use velocity and complete/not complete of product backlog items to adequately visualize sprint risk.

The development team is forced to be the most detailed here, which helps to sharpen the mind. They can really dig down and look at what needs to be done.

By the end of sprint planning, the development team should be clear on how the chosen sprint backlog items support the sprint goal and how the work to complete those backlog items will be done. This does not mean that all (or any) of the tasks on the sprint backlog get assigned at this time. Rather, each day the development team self-organizes by having each developer pull a task and work on it to completion. (You find more on pull versus push in “Working the sprint backlog” later in this chapter.)

Your Sprint Backlog

The sprint backlog is created in the sprint planning session and is the ordered list of requirements and tasks necessary to achieve the sprint goal.

A sprint backlog might contain the following information:

• The sprint goal and dates
• A prioritized list of the requirements (for example, user stories) to be developed in the sprint
• The estimated effort (that is, story points) required to develop each requirement
• The tasks required to develop each requirement
• The hours estimated to complete each task (if needed)
• A burndown chart to show the status of the work developed in the sprint

The burndown chart benefit

Burndown charts are ways to visually represent progress achieved within the sprint. They depict the amount of work accomplished versus the amount left to go. Figure 4-6 shows an example:

• The vertical axis represents the work left to be done.
• The horizontal axis depicts the time still available in the sprint.

Your sprints will show a diagonal line from the top-left corner to the bottom-right corner, which represents what an even and consistent burn would look like, though really you won’t have a perfectly even burndown.

© John Wiley & Sons, Inc.

FIGURE 4-6: Sprint burndown chart.

Some burndown charts also have a line showing the outstanding story points. This allows you to quickly and easily see the status of your sprint from both time and relative estimation perspectives.

You can create your own burndown chart with Microsoft Excel or download the one that’s included within the sprint backlog template, which you can download from this page: https://platinumedge.com/blog/anatomy-sprint-backlog.

The burndown chart is generated from the sprint backlog. The sprint backlog should be updated every day, and only the development team can do this. At the end of each day, each developer updates their task (whether on a 3x5 card, on a spreadsheet, or in an electronic tool) by entering the number of remaining hours (not the number of completed hours) that are left to complete the task. That’s it. One number. It takes seconds and the results are invaluable. See Figure 4-7 for a sample sprint backlog.

The sprint burndown chart is an information radiator that shows anyone who wants to know the status of the sprint. Burndown charts get generated automatically as development team members update the amount of time left on their one active task at the end of each day.

The burndown chart shows the amount of time remaining for the sum of all the requirements on the sprint backlog. Compared with the trend line, it provides a daily level of status detail for a scrum team that you can’t get with traditional project management techniques.

© John Wiley & Sons, Inc.

FIGURE 4-7: A sprint backlog is a key scrum artifact.

Setting backlog capacity

How much capacity is in a day? If you’re looking at the number of hours per day that a development team member is able to devote to her main job — developing! — allow for less than eight. Every organization has a certain amount of overhead. For most organizations, somewhere between five and seven hours is a normal effective workday.

How much capacity is really in a sprint? In a one-week sprint, scrum teams will spend up to two hours in sprint planning, up to one hour in sprint review, and up to 45 minutes in a sprint retrospective. That’s about four hours in sprint meetings. (Do you have to use all four hours? No. Can you go over the limit for any given meeting? No.)

That accounts for four of the five scrum events (assume that a maximum 15-minute daily scrum won’t affect development time), but don’t forget product backlog refinement. Development teams will on average spend 10 percent of their time each sprint in product backlog refinement activities. This translates to about three to four hours in a one-week sprint.

So, for a one-week sprint, each developer spends between seven and eight hours in sprint events, which takes care of one full workday for an efficient organization and about a day and a half for a less efficient organization.

Is there any buffer in scrum? Sure. Consider that a development team has 165 hours available to them for a sprint. They shouldn’t take on 164 hours under the false assumption that everything is going to go exactly according to plan. The buffer varies from team to team, but you should make it transparent.

So capacity for one developer for a one-week sprint would be 18 to 27 hours, depending on the organization’s established effective workday. Take this into consideration when identifying a development team’s capacity during sprint planning. This is assuming that no paid holidays, vacations, or other time off is planned that will keep developers from developing.

Who said scrum is rudderless? You can’t get much more disciplined than this.

What an incredible impact having a dedicated and effective scrum master means to a development team’s capacity. By removing the organizational drag (impediments) that keep effective workdays from increasing from five to seven hours, the impact can add up to an additional nine work hours in a one-week sprint per developer. For a development team of seven, that’s a potential 63-hour efficiency increase. Scrum masters add value.

What happens if at the end of sprint planning, the development team finds that the number of estimated hours for their tasks from the sprint backlog is more than their capacity? Do they hunker down and work overtime? No, the product owner has a decision to make: which sprint backlog items will be moved back to the product backlog to get the number of hours below the development team’s capacity. Sustained overtime leads to poor team morale, poorer quality, and long-term productivity loses.

The value of the iterative planning process is easily visible within sprint planning. By the time the work to be done is outlined and broken down to the task level, you will have done so in a way that minimizes time waste and maximizes business value and ROI. This is because the Roadmap to Value, from the vision statement all the way down to the sprint level, has enabled continuous prioritization and progressive elaboration of only the most important product backlog items.

Working the sprint backlog

Development teams can get distracted and go off target by making some common mistakes. Follow these practices to counter those mistakes when working with the sprint backlog:

• Make sure that requirements are broken down into tasks that accurately and completely reflect your definition of done (see Chapter 3 in Book 5).

  The product owner should not accept a requirement until it completely satisfies the sprint definition of done.

• The entire development team ideally works on only one requirement at a time and completes that requirement before starting another. This is called swarming.

  Swarming can be accomplished by such activities as

  • Each team member working on individual tasks related to the same requirement
  • Pairing two people on one task to ensure quality
  • Team members shadowing each other to increase cross-functionality

  As development teams swarm around one requirement at a time, this ensures cross-functionality and ensures that every sprint will have something tangible accomplished at its end.

• Each requirement must be fully developed, tested, integrated, and accepted by the product owner before the team moves on to the next requirement.

• Don’t assign multiple tasks to individual development team members.

  Each day, the development team coordinates priorities and decides who will do what. A developer should be working on only one task at a time until that task is completely done. This is called a pull mechanism.

  Don’t fall back into the traditional method of a manager assigning tasks out to team members. Traditional project management follows the push model of assigning tasks to individuals when they’re identified. Each individual manages and focuses solely on the tasks in his personal queue. This queue builds up over time, and attempts are made to redistribute task load across team members to avoid over- or underloading. The trouble with push systems is that it’s difficult to know the status of things unless everything is either unstarted or all the way complete. This also tends to contribute to team members operating as silos rather than cross-functional teams.

Swarming on requirements stems from the lean concept of work in progress (WIP) limits. When a development team has a lot of work in progress, it delays taking the actions necessary to finalize that work and rear-loads issue correction. Your WIP limit should ideally be only one requirement at a time for the development team and only one task at a time per developer. The development team usually finds that their tasks get completed sooner than if they had started them all at the same time. Having only one requirement open at a time is also an effective way of exposing process bottlenecks, which can then be addressed and fixed for faster throughput.

Prioritizing sprints

Each sprint has its own life cycle, as shown in Figure 4-5 earlier in this chapter. Within each sprint, each requirement has its own prioritization and life cycle, too. Each requirement and task are developed, tested, integrated, and approved before the team moves on to the next-highest-priority item. See Figure 4-8 for a representation.

The sprint backlog items are prioritized from highest to lowest and developed in that order. The development team works on only one requirement at a time. When that requirement is finished, the team moves on to the next-highest-priority one rather than picking one lower on the list that might be easier or more interesting.

© John Wiley & Sons, Inc.

FIGURE 4-8: Prioritization within a sprint.