Sprint Execution

Sprint Execution is performed during each Sprint by the Scrum team to meet the Sprint goal. This tutorial centers around the standards and practices that guide how the Scrum team oversees, plans, performs, and discusses during Sprint execution.

A Quick Overview

Every Sprint, the team implements a project in small chunks and performs all the necessary tasks to deliver a potentially shippable product at the end. The team’s work is based on the Sprint goal and Sprint Backlog.

In Sprint Execution, the majority of the time is spent during each Sprint. Sprint Execution starts after Sprint Planning and ends before Sprint Review. For a two-week Sprint, the duration of Sprint Execution lasts for 8 to 10 days.

During Sprint Execution, the Scrum Master, development team, and Product Owner should be present. The development team members decide the most ideal way to meet the Sprint goal. The Scrum Master mentors, facilitates, and expels obstacles that are blocking the progress of the team. The Product Owner has to be there to solve queries on product requirements, review the work in progress, and give inputs to the team. The Product Owner can also be called sometimes to discuss the adjustments in the Sprint goal and to confirm the acceptance criteria.

How Does Sprint Execution Work?

Sprint goal and Sprint Backlog are the inputs to the Sprint Execution process. These inputs are generated during a Sprint Planning. Sprint Execution process includes task planning, performing, managing the tasks, attending daily stand-ups, and communicating with the Scrum teams. The outcome of Sprint Execution is a potentially shippable product increment, formed from a list of product backlog items by meeting the team members’ definition of done. Below is the image showing workflow of the Sprint Execution.

1. Sprint Execution Planning:

During sprint planning, the team creates a prioritised plan, called Sprint Backlog, for achieving the Sprint goal. While task planning, team members perform ‘just-in-time’ task-level planning to increase the task performance, if needed.

2. Flow Management:

Basically, a team should be able to manage the workflow throughout the Sprint to fulfill a Sprint goal. The workflow management includes the decisions on the amount of work the team can perform parallely, from which task to start, organizing the tasks, which work to perform, and who will be accountable for the tasks. Let’s dive deeper into these.

➢Parallel Work and Swarming
The team must be self-organized to decide how many tasks the members can perform parallely. Because, working on too many tasks at a time can overburden a team and working on just one item at a time is time-consuming. The team should be balanced enough to perform all the tasks, restricting the T-shaped skills from burn-out. This way will result in not only reducing the time but also delivering maximum value during a Sprint.
Swarming is accomplishing one unfinished item at a time with available capacity, instead of switching on to new items. This doesn’t mean sticking to only one item at a time. Finally, teams have to identify the most important items to deliver the maximum value at the end of each Sprint.

➢Picking up the work items
The easiest way to pick up the work items is to choose the highest priority item specified by the Product Owner (PO). Unfortunately, in some cases it doesn’t work. Because dependencies or the team members’ skills might be in a different order. The development team can choose the work items appropriately.

➢Organizing the tasks
The amount of work can be picked up from a value and delivery-focused work items. The developer and tester pair up and work in a highly interleaved manner with rapidly creating test cycles, code, test execution, and test and code refinement. This approach helps in an uninterrupted workflow, supports fast feedback, and enables skilled team members to get the work done by organizing the tasks.

➢What tasks need to be performed
The Scrum teams are self-organized teams. They decide on their tasks to complete the Product backlog items. The Product Owners and Stakeholders define the scope of the feature and create the acceptance criteria. The team and the Product Owner work collaboratively to ensure that the technical decisions are made in an economically sensible way.

➢Who will be accountable for the task?
A team member who can get the task done properly and correctly is the best to handle the task. In case the team member is not available, the team itself should be able to choose the next best person.

3. Daily Scrum:

Daily Scrum is a 15-minute ‘inspect and adapt’ activity, that takes place anywhere in the workplace and once in every 24 hours. The aim of this meeting is to help the teams achieve the Sprint goal faster. Also, Daily Scrum shares the big picture of the current status of the Sprint, how much to work, which work items to start working on, which is the best way to follow, and how to organize the work among the team members. The Daily Scrum is crucial for the flow management.

4. Task Performance- technical practices:

The development team should have technical knowledge of what they perform. For example, if you are implementing Scrum in software development, then the team members must be good at the programming languages, technical practices like continuous integration, automated testing, refactoring, test-driven development, and so on. Teams with weak technical skills generally fail to achieve the long-term benefits of the Scrum methodology.

5. Communication:

Communication is necessary to effectively communicate a progress within a team. Communication can be done in 3 ways:

➢Task Board

The task board eases the communication on the sprint progress within the team members. The task board represents the user stories, a list of tasks. The tasks remain in the ‘To-do’ column till the team starts working on them. Once the team starts working on the tasks, that task is mentioned under the ‘In-progress’ column, and eventually to the ‘done’ column. The team can get the status of work easily just by glancing at the board.

➢Sprint Burn-Down Chart

The sprint burndown chart helps in tracking a progress and predicting when the work will be completed. The chart tracks how many hours of efforts are remaining to accomplish each task per day.

The team updates its ‘in-progress’ tasks with an estimate of how much work is remaining, each day. It adds these task hours to the total number of estimated hours for any tasks that haven't started yet and plots the results on the sprint burndown chart, as given below.

Note: Sprint Burndown charts always use estimated effort remaining. They do not capture actual effort expended.

➢Sprint Burn-Up Chart

The Sprint Burn-up chart is the other way to track a progress through a Sprint. These charts are plotted using user stories. Each day, the sum of completed product backlog items to date, as measured in story points, is charted. Burn up charts allow team members to see how product backlog items are flowing during the sprint.

An ideal burn up chart represents a steady rise in completed work items (see dark blue line in the graph above). If your burn up chart shows almost no progress in terms of completed items from the last few days of the sprint (see light blue line in the graph above), you should consider that as a red flag signal (risk).

Sprint Execution accounts for the majority of time spent during a sprint. Sprint Execution cannot be accomplished by a complete plan that specifies when the work will be done, and who will be the accountable person for this work. Instead, Sprint Execution is performed by knowing the team’s skills, feedback from previous work, and the unpredictable circumstances in the sprint. This doesn’t imply that the Sprint Execution is disorganized. Rather, it provides a proper flow of working.