The Sprint

Basic

difficulty

Stage 1

Agile IQ® Level

Planning

Practices

Scrum

Framework

Introduction

Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

How long should the sprint be?

Sprints are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

The team’s length of Sprint depends on how fast they seek feedback from stakeholders and how quickly they want to adapt to their environment. Two weeks is the industry standard for a Sprint.

Marketing Teams: One-week Sprint length. This increases the speed of the team’s ability to pivot and react to changes in social media and stakeholder engagement needs.
HR Teams: Two week Sprint length. 2-weeks is sufficient time to deliver iterations of the staff experience, obtain feedback, and then plan the next Sprint.
Software Teams: Two week Sprint length. This is the industry standard. Sometimes, the tendency is to make a software team’s Sprint length 4 weeks because the team has trouble fitting in all the testing needed. This is an anti-pattern. DOn’t increase the length of the Sprint to fit more work in. Instead, learn how to fit work into the fixed timeframe of the Sprint. Sometimes, this might take a few months.
Finance Teams: Two week Sprint length. This size of Sprint helps limit the large batch processing that can occur when invoices build up toward the end of the month.

Anti-patterns: Don't change the Sprint length to accommodate the work

The length of many teams' Sprints is determined by approvals, waiting time, and the size of work. The length of the Sprint should be determined by how fast you want or need to adapt to change. Keep the Sprint length the same in order to improve predictability about how much work can fit into a Sprint and still get to Done. If you're not getting the work to Done, don't make the Sprint longer, instead take on less work into the Sprint so everything has a chance to get to Done.

Sprints decrease variability

Sprints and their events are designed to optimise out variability by making them the same length, and at regular intervals inspecting progress and adapting plans.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame.

During the Sprint

No changes are made that would endanger the Sprint Goal
Quality does not decrease
The Product Backlog is refined as needed
Scope may be clarified and renegotiated with the Product Owner as more is learned.

Reporting

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

Cancelling a Sprint

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Actions

In a Retrospective, discuss how long is your Sprint length and why? Some useful questions and issues to investigate:

Is your Sprint length determined by how much work you can get to Done?
Is your Sprint length because too many meetings mean you don’t have time to deliver?
Is your Sprint so long that by week 4 you’ve forgotten the plan?
Is your Sprint length longer because you have to wait on approvals?
Is your Sprint length longer because you have to move code between environments?
When change occurs, how many Sprints does it take to adapt to that change? What is the overall lead time?

All fields are required.