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

• Reporting: The schedule and the achievement of milestones is reported to the organization, generally because other parties depend on these milestones to synchronize their work. In the case of „Sprint milestones“ we produce a chain of many milestones with short periods in between. If the Scrum team has a rough plan for the next three Sprints, but not for the subsequent ones, management tends to ask for further milestones until the end of the project. This forces the Scrum team to make an upfront project plan with Sprint milestones spanning the entire project duration. Of course, milestones need to be tracked because decisions will be made if the desired milestone achievements are not reached. Following that path, step by step the Scrum team will bring itself into a planning and reporting mode that does not help the team to deliver better and that does not support the organization to organize better. It merely produces more reporting and more reporting meetings.
• Inspect and adapt: Even though I don´t think any project has so many milestones, this understanding of software development as a defined process we can cope with by detailed upfront planning is precisely what we do not want to have. The real problem of Sprint milestones is in the denial of self-organizational forces. We want to leverage these forces by using transparency, inspection, and adaption. The possibility and necessity of continuous adjustment are what lets us learn and gain insights from our doing. The upfront Sprint milestone list will make inspect and adapt more difficult and therefore will make learning more expensive, it ignores the delivery velocity of the Scrum team and negates self-organizational forces. And it sometimes leads to the Scrumfall which is also a pattern to avoid.
• Scrumfall: In a Scrumfall the phases of the waterfall model are being organized into several subsequent Sprints. So you could have a first Sprint with requirements engineering, a second with analysis and design, next one implementation followed by a test Sprint and finally delivery. This is an anti-pattern, and we should understand that by following this working model the learning – which is an inherent part of any software development endeavor – is mostly being postponed to the last Sprint when we will see the final software result. Instead in Scrum, we want to go through all of the waterfall phases in each Sprint and deliver software, value, and outcome within each Sprint while learning to achieve better.

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.