Choosing a Sprint Length | David Tzemach
In almost any Agile project, a frequently asked question is: what should be the length of our development sprints? One week, two weeks… and what is the benefit of selecting any particular length?
So, to provide a formal answer, I will start with the standard definition of a Scrum sprint. There are two options: either “A sprint is a fixed period, from one to four weeks, with a preference toward shorter intervals” (Scrum Alliance) or “The heart of Scrum is a Sprint, a time-box of one month or less during which a ’Done, ‘usable, and potentially releasable product increment is created."
As you can see, these formal answers do not provide any reasonable response to the question of length, but it is still essential to understand their spirit. If you are familiar with the Agile manifesto, you already know that Agile teams are vital stakeholders in Agile, so it is left to the Agile team to decide the sprint length that works best for them.
In the real working environment, it can take Agile teams 4-6 sprints until they find the rhythm that works best for them. As I learned through the years, the team can share their inputs, but the business, especially senior management, has the final say. (To avoid team frustration, it is always a good idea to involve them in the decision).
I usually let the team experiment for a few sprints to decide which length allows them to provide the best ROI. Once they have a number, I set up a meeting with senior management to get the final verdict, based on the team’s input but also on the information gathered by answering a few basic questions that allow all participants to understand the project’s bigger picture:
What is the complexity of the project?
What is the number of available teams?
What is the expected duration of the project?
What are the deadlines determined by the customer?
What is the team’s experience in Scrum?
Do we have supporting infrastructure (Automated frameworks, build system, etc.)?
During the years, I have worked on projects based both on short sprints (1-2 weeks) and long sprints (3-4 weeks). As part of these projects, I always tried to understand how each selection I made would affect the team, customer and the business. As part of my research, I have come to these conclusions:
To work in short sprints, the team must have supporting infrastructures (Test tools, CI/CD systems. Etc.) That is not always available at the beginning of the project.
The longer the sprint length is, the greater the opportunities for external and unexpected interruptions to prevent the team from delivering.
Shorter sprints allow the team to conduct faster and more effective Scrum meetings such as refactoring, pre-planning, and planning.
Shorter sprints make it harder for the team to deliver a high-quality product (although experienced teams can easily overcome this issue).
When moving from traditional methodologies to Agile, it is easier to start with longer sprints that help the team adapt to the concept of sprints.
For inexperienced teams, shorter sprints can make team members stressed due to the short delivery dates.
The use of short sprints will increase business ROI by reducing the delivery time of each release. However, longer sprints mean more functionality to deliver at the end of the development cycle.
The shorter the sprint length is, the greater the chance for the team to keep their focus throughout the development effort.
Shorter sprints increase the number of review meetings, allowing the customer to increase the frequency of feedback cycles that guide the team through the project.
Shorter sprints increase the number of retrospectives that help teams improve their process and remove impediments that hold them back.
Allowing for your team’s maturity, longer sprint length means better chances that the team can deliver actual shippable functionality without increasing the technical debt.
The longer the sprint length is, the greater the probability of creating “Mini” waterfalls.