Copyright © 2016, Artisan Software Consulting LLC
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:
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.