There’s a reason we have something called a Sprint in Scrum: empiricism. While Agile Development calls for short iterations and working software, Scrum perhaps solidifies what the agile principles are saying: build products in small increments, always make sure it’s working, and make sure you get feedback from your customers on a regular and frequent basis.

This is part of the core beliefs of Agile Development and at the heart of Scrum: build a little, make sure it works, validate with the customer, decide what to do next. We call this “empiricism.”

To be empirical means to do something based on observation and experience, without using a scientific method or theory. It is very difficult to build software or, in fact, to do anything artistic, creative or unique by following a theory. Medicine, for example, is frequently empirical, attempting various treatments until a positive result is achieved.

In Scrum, a “sprint” provides the period of experimentation that ends at a fixed point in time, upon which the team stops, evaluates what was accomplished, learns as much as possible from what happened during the Sprint, and then decides what to do next.

Teams and organizations frequently look at the end of the Sprint as a point in time when all work in the Sprint must be complete. They then either rush to get it all done (compromising quality) or attempt to extend the Sprint by a day or two to “get everything finished.” When we do this, we make three really critical mistakes:

  1. By extending the Sprint, we’re doing more without getting feedback that what we’ve already completed is what the customer wanted.
  2. By extending the Sprint, we’re making “getting stuff done” more important than doing the right thing.
  3. AND MOST IMPORTANTLY, by extending the Sprint, we’re demonstrating a true lack of understanding of what Scrum is and what it means.

Based on the definition of Scrum (and simply because it’s just a good idea), when the Sprint ends, take all unfinished work (don’t bother with a demo) and return it to the Product Backlog where it can be staged for inclusion in another Sprint (probably the next one, but maybe not).

Never, ever extend a Sprint. Even if you think you need to, trust us, you don’t.

FEATURED RESOURCE:

FEATURED RESOURCE:

Sprint Goals Reference Guide

Download Now!

Swipe this FREE DOWNLOAD for a breakdown of sprint goals.

Normally available ONLY to Artisan students, we’re offering this handy guide to you for a limited time!

More About #Sprints

Sprint Goals: The Key to a Well-Executed Sprint

Sprint goals are key to a successful Sprint. They help keep the Scrum team on track and moving together in one direction. Without Sprint goals, the Scrum team can easily lose focus and get sidetracked. In this blog post, we'll discuss what sprint goals are and how they can help your Scrum team stay focused

What is Scrum?

The most popular Agile Development framework, Scrum, can be explained in many ways. If you're just trying to understand what Scrum is, this post is for you.

Gearing a Team for Maximum Outcomes

Creating a maximum outcome team is every ScrumMaster’s goal, but you must first understand how great teams form and what YOU need to do to create a great team.