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.
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?
Rollentrennung und Fähigkeiten
Auslöser für den Blog-Artikel ist eine Diskussion die ich im Rahmen von Lean DUS , einem lokalen Community Event in Düsseldorf, über folgendes Thema geführt habe: Was sollte ein Scrum Master alles können und was sollte er besser nicht können? Dabei ...
12.1.2015 | 7 Minuten Lesezeit
Working with Rules as ScrumMaster
I’ve heard different discussions about ScrumMasters and rules. There a some positions that see the ScrumMaster as the keeper of the rules. His responsibility should be to make sure that everyone is following the rules. Another position says, agile (and...
11.3.2014 | 4 Minuten Lesezeit
Beispiel: Schneiden von User Stories
In der Rolle des Product Owners steht man immer wieder vor der Aufgabe, eine Softwareanforderung (eine große User Story oder ein Epic) in mehrere kleinere zu schneiden. Dabei sollten diese kleineren Funktionspakete, wenn sie einzeln umgesetzt werden,...
6.1.2014 | 6 Minuten Lesezeit
Gibt es intrinsische Motivatoren für Unternehmen?
Einem Softwaredienstleister stellt sich immer wieder die Frage, mit welchem grundsätzlichen Bezahlmodell man seine Dienstleistung an einen Kunden verkauft. Einen interessanten Einstieg in diese Diskussion bietet der Blogartikel „Pricing, And A Little...
3.12.2013 | 3 Minuten Lesezeit
Standup- oder Sofameeting
Ob ein Meeting erfolgreich verläuft, hängt von vielen Faktoren ab, das richtige Format und der richtige Ort spielen dabei eine gewichtige Rolle. Anlass für meine Überlegungen war ein Meeting, das im Kontext von mehreren zusammenarbeitenden Teams (Scrum...
3.4.2013 | 3 Minuten Lesezeit
#OSSWDev at #ALE2012
Open Space Software Development at the ALE2012 unconference in Barcelona I met Jason Ayers (@SimplyTalking ) at the XP2012 in Malmö and he told me about his rough idea of a session where people develop real software with the presetting of Continuous...
10.9.2012 | 8 Minuten Lesezeit
Hot testing of agile methodes and practices
Since a couple of years different ideas, concepts and methods are propagated under the buzzwords “Agility” and “Software Craftmanship”. But how good are they working in an economic everyday project life? Within the framework of my job at codecentric ...
1.8.2012 | 3 Minuten Lesezeit
Akzeptanzkriterien oder -tests als Anforderungsdokumentation?
Wird in einem agilen Softwareprojekt eine Dokumentation der Anforderungen, die in einer Software realisiert werden (Systemanforderungen), benötigt? Und wenn ja, welche Form und welcher Detailierungsgrad ist dabei sinnvoll? Bei der ersten Frage kommen...
24.4.2012 | 4 Minuten Lesezeit
The Scrum Master is not your friend!
During the Unconference ALE2011 in Berlin, an Open Space Session titled „How to get developers’ buy-in when introducing Scrum in a chaotic environment?“ took place. While reviewing the role of the Scrum Master, I have propagated the statement „The ScrumMaster...
18.10.2011 | 3 Minuten Lesezeit
Unconference #ALE2011, a report from a linchpin
From 7th to 9th September the first conference of the Agile Lean European Network happened, the #ALE2011. More than 200 participants from more than 30 countries met at the NH Hotel Berlin-Mitte, to share their experience and knowledge in the area of ...
22.9.2011 | 6 Minuten Lesezeit
XP 2011 – Eindrücke aus den Sessions
Letzte Woche habe ich die XP2011 in Madrid besucht. Im Rahmen der Konferenz habe ich an 15 Sessions teilgenommen und werde hier meine Eindrücke schildern. Der unterschiedliche Detailierungsgrad der Eindrücke stellt keine Wertung der Sessions dar, sondern...
18.5.2011 | 9 Minuten Lesezeit
What makes Scrum to be Scrum?
From time to time project teams ask themselves the question: “Is it Scrum what we do?” These teams usually use terms from Scrum (and other agile methods). There is a “Daily Standup Meeting” and the project uses four-week periods (“Sprint”). At the beginning...
- Agile methods
11.4.2011 | 2 Minuten Lesezeit
Product Owner – a missunderstood scrum role
From time to time I hear sentences like “This isn’t a real scrum project, you as product owner haven’t got any discussions with the scrum master.” This sentences show that conflicts are expected between Scrum Master and Product Owner or between Product...
- Agile methods
2.2.2011 | 2 Minuten Lesezeit
Composition of the scrum team
In the environment of the agile method „Scrum“ I would like to contemplate more closely one important aspect of the project management: The composition of the project team. In the conventional project management this is one of the basic tasks of the ...
- Agile methods
22.7.2010 | 4 Minuten Lesezeit
meet the experts – Agilität: Konzepte vs. Userstories
Auf dem diesjährigen „meet the experts – Agilität“ fand ein Openspace mit dem Titel „Fachkonzept vs. Userstories“ statt. Auslöser dieses Open Space war die in Scrum -Vorträgen vorkommende These, dass Fachkonzepte nicht mehr benötigt werden, diese würden...
23.6.2010 | 2 Minuten Lesezeit
Dein Job bei codecentric?
Agile Developer & Consultant (w/d/m)
An allen Standorten
Gemeinsam bessere Projekte umsetzen.
Wir helfen Deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Do you still have questions? Just send me a message.