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?
-
1What "delay" are you talking about? I think there's a second question implied here, and recommend that you open a separate but related question to address that specific part of your team's issue with adequate details and context.– Todd A. Jacobs ♦Feb 25 at 22:37
-
By delay, I mean the sprint length– amelFeb 27 at 7:40
-
So by "delay" you mean the delay in the feedback loops provided by Backlog Refinement and the Sprint Review, or possibly the "delay" in releasing a potentially-shippable Increment. You should probably splice that into your question since it wouldn't fundamentally change the question, but would certainly help clarify it for readers and people trying to answer your question. On PMSE, we try to make questions and answers helpful for future readers, and not just the person currently asking the question. This sort of definitional stuff is very helpful for those future visitors!– Todd A. Jacobs ♦Feb 27 at 15:47
Add a comment
|
4 Answers
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.
answered Feb 25 at 22:17
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.
-
I am giving this a +1 for the cadence and predictability focus, but genuinely think there's an underlying X/Y the OP hasn't surfaced yet (although see the recent comments here and here), which I try to address in my own answer.– Todd A. Jacobs ♦Feb 25 at 22:31
-
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.
-
1I agree with most of this, but want to point out that longer Sprints have lower framework overhead but slower feedback loops . Longer loops in turn may lead to a reduced capacity for rapid change. Sprint length represents a number of trade-offs, and estimation accuracy (while definitely a valid one) is only one of many dimensions involved in length optimization.– Todd A. Jacobs ♦Feb 25 at 22:27
-
On a side note, teams that have trouble with decomposition don't always benefit from longer Sprints, but will most likely fail miserably with one-week Sprints since all planned backlog items must fit within a single Sprint.– Todd A. Jacobs ♦Feb 25 at 22:34
-
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.
