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

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.

Speeding up Your Scrum Teams

Effective Scrum use is more than Sprint Planning, Daily Scrums, and so on. To see a big difference in your team's Sprints, make these workflow changes.

Keep Your Sprints Short

Scrum teams are responsible for choosing sprint length and are encouraged to experiment with different sprint lengths, but shorter sprints are easier to manage.

Keep Your Eyes on the Sprint Goal

In this article, we'll discuss how a team bares responsibility for the Sprint and what should be done if they can’t get everything done they committed to.