In Scrum, iterations are called sprints and they are the most important rhythm in the project. They start with a sprint planning session and end with a sprint review and a sprint retrospective. Here are some further attributes of a sprint:
- fixed in length – a sprint must have a defined start and end date … release dates might slip, but a sprint end date shouldn’t
- fixed in scope – the work to be done in a sprint must be clear and well-understood before the sprint starts
These two points play nicely into the concept of the Iron Triangle of software. Simply put, the Iron Triangle asserts that you can control two factors in the diagram below, but attempting to control all three will typically lead to failure.
What we can see is that we are fixing time and cost and as a result, it is scope which is variable. This is an important point and one that is not often appreciated. If your project has a scope which is fixed and cannot be changed, then Scrum may not be the best choice. Agile processes are good at adapting to changing and emerging requirements, not at hitting a fixed set of deliverables over a long time period.
And now to some more detailed points relating to sprints:
Sprints must be regular
As I said at the start of this post, sprints form the basic rhythm of the project. As a result, they need to be regular and all the same length.
This is not to say that a project cannot change it’s mind about sprint lengths. I’ve been on projects where the team has decided to vary the sprint length, with a view to improving it's velocity, and this was fine. However, irregular sprint lengths should not be something that the team has to endure.
Sprints must be short
A sprint should represent the maximum length of time for which requirements can be fixed. If business users cannot commit to 4 weeks of stability, then sprints should be 2 weeks. If business users cannot commit to 2 weeks of stability, then sprints should be one week. If business users cannot commit to 1 week of stability, then you have some big issues and applying Scrum to your software development is unlikely to address them!
I’ve never heard a good reason to have sprints longer than 4 weeks. And my personal preference is to have sprints of 2 weeks. In my experience, this has a number of benefits:
- the team remains focussed since the end of the sprint is always typically close … 4 week sprints can result in a dangerous lull of activity during the first week or two
- requirements can usually be fixed for a 2 week period
Sprints should finish on a Friday
The team will typically focus a lot of energy towards the end of the sprint and having a few days off after the end of a sprint is very refreshing. The alternate situation is that the team finishes a sprint, possibly making a bit of a push to get over the line, and then has to start sprint planning the next day. I always find sprint planning to be the most demanding activity in Scrum, so starting it immediately after the end of a sprint feels a lot like unnecessary hard work!
The output a sprint is essentially unknown
This follows from my earlier point that scope is allowed to vary. The project team will, during sprint planning, use various techniques to work out how much work can be achieved during the sprint. This set of work becomes the goal for the sprint. However, the team may or may not actually get all of the work done. After all, as a famous physicist once said “Prediction is difficult … especially about the future”.
Success means meeting sprint goals
A successful sprint is one in which the team delivers its sprint goals – this is the definition of success for a sprint. A successful team is one which regularly has successful sprints. Conversely, a team which regularly misses its sprints goals is unsuccessful and has issues that need to be sorted out. These issues can sometimes be identified and resolved during project retrospectives, but sometimes teams are either stubborn (refusing to change) or myopic (they fail to see the issues) or dumb (they fail to see the problem). In these cases, external scrum coaches can often help the team through their issues.
Sprints can be terminated abnormally
The situation can sometimes arise where business priorities shift dramatically during a sprint. In these cases it may be futile or even harmful for the team to continue with the sprint. If this is the case, then a sprint can be terminated. Any work in progress should be destroyed and not committed – we do not want half-finished work in the project and it is not clear when the team would complete this work (if ever).