Why sprints and how long should they be? - codecentric AG Blog
One of the integral parts of scrum is the iterative development process with fixed time boxes called sprints. In many projects the duration of sprints is a regularly dicussed parameter. First I would likt to analyse the different reasons and boundaries of iterative processes in order to get a better understanding of the advantages and disadvantages of differnt sprint durations.
Iterations in a process modell mean that the same process steps are passed through repeatedly. This can be done time-based (every n weeks) as well as event-based. Both approaches can be mixed or set up in a hierachical manner. Scrum for example uses time-based iterations (Sprints) which include both event-based (every done Backlog-Item) and small time-based (days with daily stand ups) sub iterations. In most cases there also is a production releases cycle, combining several sprints.
The iterative proceeding in agile is described in the 12 principles of the agile manifesto. The following three principles describe this detailed:
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Three main ideas about iterations result from this principles:
- Regulary reflect the development process
- Release Software as soon as possible to production and incrementaly upgrade it
- Regulary present running software to the stakeholders
All three ideas can be independently managed, both in control type (time or event) and in control parameters (1 day / 4 weeks).
The regular reflection on the developement process is used to improve and adapt the process to the current circumstances. There is a danger in most projects to skip this reflection due to pressure of time and to the necessity to reach short term goals. So it makes sense to use fixed time intervalls and to allocate the needed time slots. Scrum has two tiers: a part of the daily stand up is used and after every sprint there is a dedicated retrospective meeting.
The economical reasons for using the developed software as soon as possible are the core ones. The iterative approach allows to create value from the first production release. Furthermore it offers the chance to hit a given “window of opportunity” that is not reachable with a full implementation (see “Business Case for Agile”). The feedback from the production environment should not be underestimated. It is definitely more valuable than the feedback from software running in a sandbox environment (see below). But in most settings a production release causes a lot of organizational and technical efforts. Amongst other things it could be the handover to operations, the instructions for users or the modification of sales and marketing stuff. In addition the included features should have a certain amount and consistency. Therefore the production releases tend to longer cycles.
In order to receive regular and time near feedback about the current state of development, the running software is presented to the stakeholders and released to a sand box environment. This is done more often than production releases and it allows the stakeholders to adjust the project goals based on the achieved results.
The agile principles don’t lead to time based iteration for the last item. A continues delivery is possible too, i.e. every time a feature (or meaningful group of features) is implemented the software is presented and a new feature is taken from the product backlog. This already shows the first difficulty. Presenting the software to stakeholders, who are not involved in the daily project work, is just the point. Getting continues feedback is not cost-effective due to the needed time and effort of this stakeholders. Therefor pooling several features to present them together is the more reasonable way. A fixed temporal rhythm is helpful for scheduling the presentation of the current state.
These are reasons for fixed temporal iterations. Scrum goes even further with his sprints. At the beginning of each iteration the amount of planned work is specified. From my perspective the reasons for this are:
- Experience in project work shows that deadline dates help to focus on completing tasks, especially in the final phase of an iteration.
- The delivery pressure is reduced at the beginning of an iteration, so that there is free space for design and architecture questions.
- Due to the close and strong integration of stakeholders in the project there is a risk that the development work is hindered by a significant amount of change requests and re-prioritizations. By specifying the scope of an iteration, the planned requirements should only be changed under extreme exceptions and the current development work will not be disturbed.
How can this help in the evaluation of different sprint durations in Scrum?
The selected sprint duration have different influences at the different stated reasons for temporal fixed iterations with planned scope:
Shortening the sprints will increase the cost (of stakeholders and team) for the sprint review. A Sprint Review, in which stakeholders should give feedback, could not reasonably be reduced below 90 minutes. The increased costs of stakeholders will be reduced through participating less often and so discussions between the stakeholders will occur less frequently.
At first glance, the sprint duration has no significant influence on the focus of completion which is produced by the deadline. But a shorter sprint duration makes it more difficult to plan the sprint. Usually estimations are vague in scrum, but that will be compensated in the sum of a greater set of estimated requirements (see Law of Large Numbers). The smaller the sprint, the lesser requirements are planned and the greater the expected variance of the sum of estimations. Therefore in shorter sprints the deadline is met less frequently. The same effect results from the fact that problems, e.g. a multi-day illness of a team member, can be lesser compensated in shorter sprints. If the deadline is not regularly met, it quickly looses its focusing power.
Also the perceived lower delivery pressure at the start of a sprint is available from a certain sprint duration. A spare time of 2 to 3 days within a four-week sprint corresponds only to 4 to 6 hours in a one-week sprint. Likewise this lower pressure contributes recovery from stress at the end of sprints to a sustainable pace in all sprints.
In protection against interference, there are two opposing effects. By a shorter sprint duration, changes through stakeholders will be considered earlier. Therefore a possible occurring pressure, to realize these changes in a running sprint, is lower. On the other hand, the team evaluates respectively estimatates changes formulated by the PO in the running sprint. Longer sprints allow the PO to collect and consolidate more changes before the team deals with them.
The selection of suitable sprint duration depends on many different boundary conditions of a project. There are no general rules. However, one should be aware of the disadvantages of a change in length and trade them against the benefits. I know successful projects both with four-week sprints as well with one-week sprints.
What experiences do you have with different sprint durations? Do you have even more reasons for sprints, rather than simply continuous delivery?