The sprint is the basic unit in Scrum – the period of time in which a team works on an agreed element of a digital product. But how long is a sprint in Scrum, and what factors should be considered when establishing the sprint length? This article takes a look at the key factors that influence sprint length in Scrum, including who has the final decision and how they should reach it.
Table of contents
What is a sprint in Scrum?
Just to be clear before we begin, according to the Scrum Guide, sprints are…
…fixed length events of one month or less to create consistency. A new sprint starts immediately after the conclusion of the previous sprint.
A sprint in Scrum includes the following:
- Sprint planning – agreeing which elements of the product backlog will be tackled during the sprint, setting clear goals.
- Development work and daily scrums – as the team works on the agreed goals, daily meetings (“scrums”) ensure they stay on track.
- Sprint review – when the agreed work is done, the team looks back at the work done on the product, agreeing on any necessary changes.
- Sprint retrospective - another meeting, also looking back, but this time at the development process and how to improve it.
The phrase “one month or less” gives us some latitude, and it’s common to see sprints of two weeks, or even one. Let’s look at the length of a sprint in Scrum and the factors that should be considered when establishing the sprint length.
Why is sprint length in Scrum important?
The duration of a project’s sprint is important because how long the team spends on each iteration can impact various aspects of the project, including:
- team performance,
- speed of delivery,
- flexibility and capacity to pivot,
- relations between the team and the client or product owner.
One point to note is that sprint length in Scrum doesn’t change during the project, however many sprints you need.
Why not? Because sprint length determines the basic structure and routine of the project and development process. Change that, and you risk losing consistent team performance and delivery, not to mention making progress unpredictable for the product owner. The key is to decide on the right sprint length (taking into account all the relevant factors) and then stick to it, enabling the team to focus tightly on the work to be done.
When sprints are too long, the sprint goal(s) may become invalid, or the work may become excessively complex, and project risk can increase. How long is too long? Well, that depends on the circumstances of the project – as we’ll see in the next section.
Key factors that determine sprint length in Scrum
When deciding on how long your Scrum project’s sprints should be, consider the following factors:
- Product type
- Project complexity
- What don’t you know?
- Feedback/release cycle
- The team
- External factors
Product Type
Or to put it another way, where is the product/project in its development cycle? Are you building a prototype or MVP? Or working on the product-market fit, or scaling up for new markets or users? A general rule here is that when working on prototypes and MVPs, the project is subject to more change or unexpected factors emerging, and shorter sprints (one week) enable the team to respond and pivot more rapidly.
Project Complexity
Consider the goals and user stories that will be driving your sprints. The more complex they are, the longer the sprint should be to enable the team to tackle the deeper issues and deliver effectively on stories. That said, with longer sprints comes a greater risk of the requirements or key factors changing mid-sprint. It’s a balancing act.
What don’t you know?
This might sound odd at first, but think about it: every project begins with a lack of data. At Boldare, we begin every collaboration with a product discovery process to uncover as much as possible (product goals, user needs, business priorities, market factors, etc.) before we begin development. But, the early stages also involve a lot of emerging information, new perspectives, increasing clarity, and so on. Given that each sprint is effectively a learning cycle, shorter sprints mean faster learning.
Feedback/release cycle
Product development includes user feedback and testing, and sometimes that means a specific timetable, taking each product iteration (following each sprint) to user groups and getting their input to drive the next stage of development. If there’s a commitment to regular feedback and testing, that will influence sprint length.
The team
Think about the make-up of the development team, the various skills and levels of experience, and whether they have previously worked together. If the team members are learning and bonding while working on the product, that may indicate longer sprints. Likewise, if they lack experience in this specific type of project or are also working on other projects simultaneously. At Boldare, we ensure a mix of experience (combining seniors, mediors and juniors) and always include team members who have worked together before and have achieved a certain level of performance.
External factors
And then there are the non-project issues to consider, including evolving business priorities, changes to the wider organization, additions to the tech stack, etc.
The final question to consider when determining the sprint lenght is: how long can the product owner let the development team work without needing an update? In other words, just what is the comfort level of the product owner and other key stakeholders with letting the team get on with what they do?
Who decides sprint length in Scrum?
So far, we have a lot of interrelated factors that are influencing sprint length. But once everything possible is considered, who actually is responsible for deciding how long your project’s sprints should be?
In Scrum, it’s the Product Owner. The decision rests with them – usually during or immediately after the initial product discovery workshop and before the first sprint planning meeting (the team can’t plan the sprint effectively if they don’t know how long it will be!)
That said, the product owner should be consulting (and listening to!) the development team, users’ input, and other stakeholders, who all have relevant and insightful perspectives. The other essential consultation and input here comes from the scrum master. They are in the ideal position to take an overview of the project and its various factors and offer an expert and informed opinion on sprint length.
When can you change the sprint length in Scrum?
This brings us to the only conceivable exception to the rule about sprint length not changing mid-project. It should be a rare occurrence, but it is conceivable that the sprint length is set too long or too short at the outset (maybe due to one of the above factors being given too much weight, such as a too-early date for product release).
If this does happen, it’s almost certainly obvious from the first sprint or two and will be raised at a sprint retrospective meeting. In these circumstances, it’s a reasonable decision to adjust the sprint length for the rest of the project, getting it back on track.
How to determine sprint length in Scrum?
As you can see, sprint length in Scrum can be a complicated issue, driven by a number of (potentially competing) factors, including project complexity, the needs of various stakeholders, and the development team itself. At Boldare, we may use one-week sprints when there is a strict, early deadline or a need to gather feedback more often (such as for prototypes and MVPs), or four-week sprints for particularly complex projects.
However, around 95% of our sprints are two weeks in length. We find that this is usually ideal for a balance of rapid delivery, high product quality, open and continuous communication with the product owner and client, and the necessary flexibility for operating in a VUCA environment.
Share this article:
