I recently started learning scrum, I've learned that a sprint has a limited period that can be between 1 to 6 weeks and during which the team build an increment, My question is: If for example, a team works with a sprint of 2 weeks, but during a certain sprint they choose to make it 3 weeks, is that possible or the length must always be fixed?
Scrum Events and Time Boxes Should be Predictable
If for example, a team works with a sprint of 2 weeks, but during a certain sprint they choose to make it 3 weeks, is that possible or the delay must always be fixed?
While the Sprint length can be changed by consensus within the Scrum Team to optimize it as part of the inspect-and-adapt process, the Sprint length should not be variable. This is because the Scrum framework optimizes for predictability, and frequent changes to time boxes and Scrum events would make the overall cadence less predictable.
Important Note: A good cadence is predictable. From a pragmatic agile perspective, this generally means "routine" or "fixed" rather than "immutable."
Look for the X/Y Problem
Sprints are generally fixed at 1-4 week intervals, based on various trade-offs between capacity, flexibility, overhead, and the pace of change. However, the length of the Sprint should be considered fixed for the duration of the project barring exceptional circumstances.
In addition, the desire to frequently readjust the Sprint length often indicates underlying process problems. These may include:
- Poor Sprint Planning or backlog estimation, couple with an expectation that estimates are a fixed guarantee rather than a best-effort forecast based on empirical experience.
- A lack of coherence in Sprint Goals.
- Insufficient decomposition of items on the Product or Sprint Backlogs, none of which should ever exceed a single Sprint.
- Treating Sprint Backlog items as independent tasks rather than steps towards a unified Increment.
- Focusing on doing "all the things" rather than on meeting a singular Sprint Goal.
- Failure to treat the Sprint as an ephemeral time box within which work is either done or not-done, as opposed to a milestone, work unit, or fixed-scope deliverable.
- A company culture where failure—sometimes even explicitly defined as a lack of perfect accuracy, or an unwillingness to accept change or variance in schedule or scope even in the face of change, unforeseen complexity, or *force majeure—leads to blame, and therefore a desire within the Scrum Team to break the iterative nature of the framework by ignoring time boxes to meet fiat targets.
There are certainly other reasons for people misusing Sprint length, but these are the most common ones in my own experience. During your next Sprint Retrospective, and in the course of your conversations with stakeholders and team members, you should try to identify the actual reason that the team wants to ignore or bypass core agile and Scrum principles. Until you do that, it is extremely likely that you are ultimately applying a bandage that simply covers up a more serious organizational dysfunction.
A Sprint cannot be 6 weeks long. In the Scrum framework as defined in the Scrum Guide, the maximum length for a Sprint is 1 month.
Sprint lengths are generally fixed-length. They don't need to remain the same length forever, but the teams do not typically adjust the length of a Sprint on a one-off basis. The Sprint acts as a heartbeat or cadence for the team for a few different things: a planning horizon (Sprint Planning), synchronizing with and receiving feedback from key stakeholders (Sprint Review), and improving the team's way of working (Sprint Retrospective). The Sprint length strikes a balance between how long the team can be expected to go before synchronizing with key stakeholders and adjusting their plans against the context.
Predictability is one reason you don't want to continually change the length of a Sprint. Both the team and the key stakeholders can take advantage of this predictability. The key stakeholders know when the Sprint Review will be and can make sure they are available for the team then, regardless of their availability in the middle of the Sprint. The team has general predictability in how much work they can accomplish because the available time to work remains constant (barring holidays or vacations), which leads to better plans.
When changing the length of the Sprint, the team needs to think about what the change would mean for their ability to craft an achievable Sprint Goal and a plan for achieving that Sprint Goal, achieve that Sprint Goal over the course of the Sprint, get useful feedback from key stakeholders, and respond to that feedback.
Short iterations help to keep delivery risk under control and a regular cycle gives reassurance to customers/stakeholders. Of course it's possible to change the length of a sprint but making exceptions out of just certain sprints is probably not a good sign.
It's a common mistake among inexperienced teams to think that longer sprints will make things easier on themselves, whereas in fact the opposite is usually true. It's much easier to plan and execute shorter sprints than long ones and it's better to make backlog items small enough to fit your iterations. A 5-person team working 2-week sprints does 50 days per sprint, so that's more than two months of work, and if your backlog items are bigger than that then they will probably benefit from being split.
A sprint is a timeboxed period in Scrum that has a set length and can be anywhere from one and four weeks, depending on the team's preferences and the project's complexity. In order to maintain predictability and consistency across the project, the sprint length is decided upon during the Sprint Planning session.
It's vital to remember that too many sprint duration changes might be detrimental to the team's efficiency and morale. Thus, it is generally advised to stick to a constant sprint length and to only make exceptions in extremely unusual circumstances.