A Sprint is not a milestone

By using Scrum, we deliver “things” in a rhythm that is given by so-called Sprints. Sprints should be of the same duration (for example two weeks) and at each Sprint ending there should be testable results. In the case of software development preferably working program code.

Usually, a development team has not only a concept for the things to deliver in the current Sprint. A rough idea for the delivery order of the next couple of Sprints can often be seen.

In organizations that are new to the concept of Sprints, this foresighted order can lead to the misunderstanding that Sprints need to be handled like milestones which define anticipated results of the project. This is a distorted understanding, and it makes the handling of Sprints for both – the Scrum team and the surrounding organization – difficult because it points into the wrong direction.

These are the problems #

A Sprint is a sensor, not a milestone.

The Sprint allows us to produce small, understandable and controllable results. And it enables us to inspect in relatively short feedback cycles how good we are doing. We can learn something from each finished Sprint and a Sprint without the achievement of desired software results may be a success, because we learned an important thing to do differently in the next Sprint.

And in the same sense a Sprint should be reported to the organization: As a sensor that tells us what is. A sensor that allows us to see, what has been done, what impediments are in our way and how we did better in comparison to previous Sprints.