Sprints
Sprints are protected time-boxes of under 1 month in duration that enable a Scrum Team to focus on a small amount of work at a time and complete it to a potentially releasable state or “Increment”.
Sprints have events such as Sprint Planning, Daily Scrums, Sprint Reviews and Sprint Retrospectives that allow the Scrum Team to inspect progress towards the Sprint Goal, inspect the resulting Increment, inspect the processes used, and adapt accordingly.
Duration
The guidance from the Scrum Guide is that a Sprint should be “…one month or less…” and have “…consistent durations…”[1]
Practical Tips
| Duration | The choice of Sprint length is best decided upon by the Scrum Team with respect to two main qualities:
A very common duration for many Development Teams is 2 weeks, which seems to be just long enough to produce something meaningful for the product Increment, and short enough to enable a project to adapt often. Development Teams that have a quick cycle to provide something meaningful in short timeframes may opt for a shorter duration such as 1 week Sprints for example, whereas Development Teams that need more time to cater for external processes or events beyond their control, may opt for a longer duration such as 3 weeks for example. |
| Rhythm | Using consistent durations of Sprints will enable habits and rhythms to develop in the Scrum Team over time as their biological clocks begin to understand how long a Sprint is, when to expect Sprint Planning and the other events, and when a Sprint is drawing to a close.
Over time these rhythms can develop into “muscle memory” for the Scrum Team and allow them to intuitively understand how much work can be done within a Sprint, which aids Sprint Planning and forecasting. |
| Metrics | Constant Sprint durations will also help consistent metrics to be captured and form time series data of time-boxes.
Using variable Sprint durations by comparison can be disruptive and present incoherent metrics. |
| Consistent Duration | Occasionally it can be tempting to change the duration of a Sprint, which might be as a result of being unable to break work down sufficiently to fit within a Sprint, or wanting to squeeze just a few more features into a release for example.
Here, we would be changing the Sprints to fit the work, rather than changing the work to fit the Sprint. As a result, we would also be changing the pattern of when we could inspect the Increment and adapt accordingly, and also compromise the team’s ability to understand its capacity within a Sprint. Hence, we tend to think of the Sprint as a protected time-box to provide a consistent rhythm of inspection and adaptation, where the work is broken down to fit within the rhythm. |
| Avoid The Mini-Waterfall | Mini waterfalls in a Sprint look like the first few days doing analysis work for all of the items, followed by a few days design, followed by a few days building and then running out of time for testing. These are often done by individuals in the team working in silos with respect to their skill set, e.g. testers only take on testing work, coders only take on building work etc.
Mini Waterfalls suffer from the same issues as large waterfalls in that, there is an assumption that everything can be done within the Sprint and that there is little collaboration in the team or adaptation in the product to match reality. Hence, a more fluid approach that considers items as team objectives, which are then swarmed upon by the team with rapid feedback loops and constant refinement tend to work much better. Working through a few higher ordered items at a time to completion before starting work on the next item tends to work much better. |