A Sprint is not a milestone

April 09, 2011

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 distorded 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, normally because other parties depend on these milestones to synchronize their work. In case of „Sprint milestones“ we produce a chain of many milestones with short periods of time 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 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 help the organization to organize better. It simply produces more reporting and more reporting meetings.

  • Inspect and adapt: Despite the fact that 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 exactly what we 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 is 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 largely 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 deliver 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 different 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 compared to former Sprints.