The Sprint

Basic

difficulty

Stage 2

Agile IQ® Level

The Sprint

GUIDES

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.

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.

search previous next tag category expand menu location phone mail time cart zoom edit close