Chapter 20: Sprint Execution

Sprint execution is the work the Scrum team performs during each sprint to meet the sprint goal. This chapter focuses on the principles and techniques that guide how the Scrum team plans, manages, performs, and communicates during sprint execution.

Overview

Every sprint, the team executes a mini-project unto itself—it performs all of the work necessary to deliver a potentially shippable product implement. The team's work is guided by the sprint goal and sprint backlog.

Timing

The majority of the team's time each sprint should be spent in sprint execution. It begins after sprint planning and continues until the sprint review begins. For a two-week sprint, sprint execution would likely count for 8 to 8.5 of the 10 days.

Participants

During sprint execution, the development team members self-organize to determine the best way possible to meet the sprint goal. The ScrumMaster coaches, facilitates, and removes any impediments that block or slow the team's progress. The product owner is available to answer questions, review intermediate work, and provide feedback to the team. The product owner might also be called upon to discuss adjustments to the sprint goal or to verify acceptance criteria.

Process

Task Planning

During sprint planning the team produces a high-level plan for how to achieve the sprint goal, usually in the form of a sprint backlog. Team members perform just-in-time task-level planning as needed, as opposed to trying to formulate a detailed plan or Gantt chart.

Flow Management

It is the team's responsibility to manage the flow of work throughout the sprint to meet the sprint goal. This includes making decisions about how much work the team should do in parallel, which work to start, how to organize the task-level work, which work to do, and who should do the work. Let's look more closely at these decisions.

Parallel Work and Swarming

The team must determine how many product backlog items to work on in parallel, in other words, at the same time. Working on too many items at once slows the team down. But working on too few items at once is equally wasteful. To find the proper balance, I recommend that teams work on the number of items that leverages but does not overburden the T-shaped skills and available capacity of the team members.

The goal is to reduce the time required to complete individual items while maximizing the total value delivered during the sprint. Another name for this approach is swarming. Swarming is when team members with available capacity work together to complete one unfinished item rather than moving ahead to work on new items. This doesn't mean teams should always work on only one item at a time—the actual number of open items at any one time is highly dependent on context. Teams will have to experiment to find the balance that maximizes the value they deliver each sprint.

Which Items to Start

The simplest way to choose the product backlog item to work on next is to select the highest-priority item as specified by the product owner. Unfortunately, this doesn't always work. In reality, dependencies or skills capacity constraints might dictate a different order. The development team should be enabled to opportunistically select work as appropriate.

How to Organize Task Work

It's tempting for new agile teams to approach task level work in a waterfall fashion: design it, code it, and then test it. It's better, however, to approach the work from a value and delivery-focused mindset. This means minimizing the amount of time work sits idle and reducing the size of handoffs. In practice, this sometimes looks like a developer and tester pairing at the start of a task to work in a highly interleaved fashion, with rapid cycles of test creation, code creation, test execution, and test and code refinement. This approach keeps work flowing, supports very fast feedback, and enables team members with T-shaped skills to swarm on an item to get it done.

What Tasks Needs to Be Done?

The team should decide which task-level work it needs to perform to complete a product backlog item. Product owners and stakeholders influence these choices by defining the scope of a feature and creating acceptance criteria. They also provide business-facing requirements for the team's definition of done. Overall, the team and the product owner must work together to ensure that technical decisions with important business consequences are made in an economically sensible way.

Who Does the Work?

Who should work on each task? An obvious answer is the person best able to quickly and correctly get it done. And if that person is unavailable, the team should decide on the next best person.

Daily Scrum

The daily scrum is a critical daily inspect-and-adapt activity to help the team achieve a faster, more flexible flow toward the solution. It is a 15-minute, timeboxed activity that takes place once every 24 hours. The purpose of the daily scrum is to get the people who are focused on meeting the sprint goal together to share the big picture of what is happening so that they can collectively understand how much to work on which items to start working on, and how best to organize the work among the team members. It is essential for flow management.

Task Performance—Technical Practices

Development team members are expected to be technically good at what they do. For example, if you are using Scrum to develop software, team members need to be skilled in good technical practices for developing software, such as continuous integration, automated testing, refactoring, test-driven development, and so on. Teams that fail to develop strong technical skills generally fall short of achieving the long-term benefits of Scrum.

Communicating

Scrum teams should use highly visible methods to communicate progress. Two of the most popular are a task board and a sprint burndown or sprint burnup chart.

Task Board

The task board is a simple but powerful way to comunicate sprint progress at a glance. The sample task board below lists each PBI and its associated tasks. The tasks remain in the To-Do column until the team starts work on them. Then, as the team begins work on a task, the team moves that task to an in-progress column, and eventually to the completed column. Taskboards can follow whatever format works best for your team, so long as the team and its stakeholders can see how the sprint is going just by glancing at the board.

Sprint Burndown Chart

The sprint burndown chart tracks how many hours of effort remain on each task, by day. Each day, the team updates its in-progress tasks with an estimate of how much work is remaining. It adds these task hours to the total number of hours estimated for any tasks that haven't yet been started and plots the results on the sprint burndown chart, as shown below. The sprint burndown chart is useful for tracking progress and can also be used as a leading indicator to predict when work will be completed. Note that sprint burndown charts always use estimated effort remaining. They do not capture actual effort expended.

Sprint Burnup Chart

A sprint burn-up chart is another way to visualize progress through a sprint. Often, sprint burn-up charts are plotted using story points. Each day, the sum of completed product backlog items to date, as measured in story points, is charted. Burnup charts allow teams to see at a glance how well (or how poorly) product backlog items are flowing through the sprint. An ideal burnup chart shows a steady rise in completed items from early in the sprint to the end of the sprint (see dark blue line in the figure below). If your burnup chart shows almost no progress in terms of completed items until the last few days of the sprint (see light blue line in the figure below), you should consider that a red flag.

Closing

This chapter was focused on sprint execution, the team's work on PBIs during the sprint. The next chapter will discuss the sprint review activity that naturally follows sprint execution.