Sprint

One of the core principles of agile development is to work iteratively, producing frequent deliveries. All agile methods apply this idea, with various prescriptions for the duration of the individual iterations. To denote these iterations, the Scrum term "sprint" has come into wide use.

The purpose of a sprint is to advance the project by a significant increment, working from a task list, known in Scrum as the sprint backlog. In most agile approaches each task on the list is defined as the implementation of a "user story".


Sprint Basics
A Scrum sprint usually lasts one month. Many teams use other durations, and non-Scrum agile authors recommend iterations of varying lengths, although never more than a few weeks in line with the fundamental agile idea of short-cycled iterative development.

This idea of cutting up development into individual iterations lasting a month or so defines the notion of sprint, but a second property, particularly emphasized in Scrum, is just as important. It is the rule that during a sprint, the task list does not grow. The rule has to be absolute: no one, laborer, duke or emperor — or project manager — is permitted to add anything while the sprint is in progress.

This rule is made realistic by the short duration of sprints. Clearly, if iterations lasted six months, it would be impossible to repress the customers' and managers' natural urge to add functionality. With a one-month period, once everyone has signed on to the policy, the project may enforce the strict ban on extensions. No exceptions are allowed, whatever the rank of the supplicant. If there is a really pressing need, it gets parked until the end of the current sprint, and will be examined for possible inclusion in the next sprint. If not having the envisioned feature is a real show -stopper, then the only solution is the extreme one (akin, in the execution of a program, to raising an exception): terminating the sprint early — a decision that, as we have seen, is the privilege of the product owner. It is a pretty drastic decision; unless the product owner feels things are so critical as to justify it, he will just wait, like everyone else, until the next sprint.


The Closed-Window Rule
The rule barring additions of functionality during a sprint follows from one of the principles we saw in an earlier chapter. It does not seem to have received a specific name in the agile literature but it is so important that it deserves one. Let us call it the closed-window rule: the window for changes is closed whenever a sprint is in progress.

The closed-window rule addresses one of the biggest practical obstacles to successful software development: disruptive feature creep, more precisely disruptive customer- or management -induced feature creep. Customers and managers teem with ideas, and keep dreaming up new features. Giving them demos of early versions (in general a good prac-tice, and strongly advocated in agile approaches) can make the phenomenon even worse by bringing to light what functionality is still missing. By itself the feature creep phenomenon is inevitable and in many respects healthy; a successful system will serve the business best if the key stakeholders have had their say. The problem is the disruptive nature of feature requests coming from a person carrying enough authority to change priorities. He or she comes up with a superb idea, so superb indeed that it has to be implemented right this minute at the expense of the currently scheduled tasks. Such interruptions can quickly derail a project: priorities get messed up, important work is delayed, and developers lose morale. But without a clear process such requests can be politically difficult to refuse.

The genius of the closed-window rule is that it neither ignores the risk of feature creep nor fights it head-on, but channels it into the limited framework of sprint planning exercises. A practical consequence is that a kind of natural selection takes place between feature ideas. Many a brilliant suggestion loses its luster when you look at it again after a few days, and when the time does come to select features for the next sprint it may no longer seem so urgent. Disruptions are avoided and noise takes care of itself. The ideas that were truly worthy of consideration are prioritized against all other tasks.


Sprint: An Assessment
Two aspects are interesting to discuss: sprint duration, and the closed-window rule.

The one-month standard duration of sprints appears just right. In this book we often note that strict agile rules are too rigid, and sometimes see that the spirit is more important than the exact details; but in this particular case it appears that following the exact Scrum one-month prescription (including sprint planning and sprint review) works well. More precisely, Scrum specifies "thirty days"; I have found, as noted earlier, that it is more effective to use a calendar month. Simplicity breeds focus.

The closed-window rule is an outstanding idea. While it contradicts the Agile Maniefesto's principle A2, "Welcome changing requirements, even late in development ", by conceding that not all change is welcome at all times, it provides a framework for handling change (or "harnessing" change, as the principle puts it).

Taken from : Agile!: The Good, the Hype and the Ugly