Sprint Length

What are your thoughts on how an optimal sprint length ought to be determined in the first place?

>> 1. Who decides the sprint length in the beginning?

The Scrum Team decides the Sprint length.  The time box for a Sprint should be 30 days or less. These are some variables to consider about Sprint length. The Scrum Team should consider how often market conditions change. They should consider how long they can wait for stakeholders to give feedback at the Sprint Review to inspect the Increment and adapt the Product Backlog, the risks to technology uncertainty, dependencies external teams may have, and the length of time they can stay focused. Shorter Sprints such as 1 week Sprints tend to be more costly because of the additional overhead of the Scrum events. The consistency of the time box provides focus, and gives the Development Team a way to learn and improve on what is possible within a steady length of time. Varying Sprint lengths usually result in a loss of productivity as well.

>> 2.  If in between the sprint, the development team wants to extend the sprint length then can they do so?

There is no in between time for Sprints - when the time-box expires then the Sprint is over..  As soon as one Sprint ends, the next Sprint begins right away.  The Scrum Team put thought into the length of Sprint for a reason, and may have set the length to get timely stakeholder feedback, and may be missing out on critical feedback.

The Development Team needs to learn how to deliver a "Done" Increment within the time-box, and to establish a consistent, predictable rhythm, or heartbeat of delivery. The fixed time-box helps with focus as well. There would be more longer term harm done. Most likely you would just end up extending the Sprint more than a few days, and the Development Team won't take time boxes seriously in the future. Soon time boxes for other Sprints and events won't matter either if you break the rules. The Scrum Team will have the opportunity to inspect what happened, and adapt next Sprint.

>> 3. Who has the power to approve the extension of sprint length if the development team demands?

As Scrum Master, he or she should advise the Development Team that the time-box needs to be respected, and that the Sprint will not be extended per Scrum rules.  More importantly the Scrum Master should be teaching and coaching Scrum values of respect (the rules of Scrum), focus (the gift of the Sprint time-box, commitment (to do the right thing), courage, and openness. 

Sprint length can be inspected and adapted in the Sprint Retrospective, however, the Sprint is the heart beat of Scrum, so be careful not to throw it off very often.

Why would the Development Team want the Sprint to be lengthened?

Could this be a sign that the Development Team are unable to be open about missed goals, or inaccurate forecasts?

Is it safe for the Development Team to be transparent about the actual state of their progress and achievements?

Do the Development Team respect the importance of being able to limit risk, and change direction, based on lessons learned over the course of a Sprint? 

Thank you for your quick replies. I have recently started to prepare for psm1 and I am new to agile, due to which understanding of few concepts is a challenge initially. But you all helped me to understand the important concept.

Ian Mitchell - As mentioned in the guide, the optimal length needs to be not more than a month (4 weeks).

Chris Belknap - Thank you for Chris for a detailed explanation, it helped me a lot.

Simon Mayer - I was considering a hypothetical situation just for the sake of understanding the concept more deeply as I am new to this. Your reply actually helped me to clarify the concept.

Sprint length can be inspected and adapted in the Sprint Retrospective, however, the Sprint is the heart beat of Scrum, so be careful not to throw it off very often.

100% agree!

@Amit

If this is a newly formed Scrum team, or even a company that just embraced scrum, the risk is not just the uncertainty of the business side of the market.

There’s social risk: Can these people work together to accomplish the tasks?

There’s technical risk: Does the development team have enough technology? Will it work on the platform that we want to run it on? Will it scale?

And there’s cost and schedule risk: Can we finish the product in a reasonable amount of time, for a reasonable amount of money?

And so on...

So when the uncertainty is higher, you need a faster feedback loop. In this way, the response and adaptation can be made as soon as possible, thereby reducing the risk and loss.

I would usually suggest a new team with a week as the length of the Sprint. Even though the finished user story is small, business value is small, but it can accumulate knowledge value. Knowledge is the opposite of risk.

Considering a hypothetical situation:

If the Sprint 1 was of 1 week long, but in Sprint Retrospective the development team wants to convert the sprint length into 2 weeks. Can this extension be possible? Who has to approve to this request?

Hi Amit,

Scrum Team can collectively discuss the pros and cons of the extending the Sprint length and decide. Though there are lot of factors to be considered while changing the sprint length. It is recommended not to alter the sprint lenght unless really required. 

Can this extension be possible? Who has to approve to this request?

Scrum is based on empiricism. You can certainly discuss the length of the Sprint in the Retrospective meeting, if the team feels it is necessary.

Scrum Team is self-organized. No one would approve the request, but the Scrum Team itself.

I suggest you take some time to refer to Chris ' suggestion.

If there are multiple Scrum Teams working on the same product, it is often desirable to align the Sprints, to either have them all of the same start and end, or at the very least so that there is a regular cadence where both team's Sprints end together.

For instance, if both teams are running 3 week Sprints, it might be acceptable for one team to choose to have 1 week Sprints, because there would still be alignment every 3 weeks, but if the team instead opted for 2 week Sprints, that alignment would only happen every 6 weeks, which might be problematic.

Essentially, I would say that while it is the decision of the Scrum Team, it is best to collaborate with the organization (including other Scrum Teams) to find a convenient solution. 

There have been multiple mentions in this thread about discussing the Sprint length in the Sprint Retrospective. I agree with this, but it could also be a relevant topic to discuss in the Sprint Review, as it has the potential to affect releases and delivery dates.

Ian Mitchell - As mentioned in the guide, the optimal length needs to be not more than a month (4 weeks).

What other things do you think ought to be taken into consideration? Why might the optimal Sprint length be less than a month?

If the Sprint 1 was of 1 week long, but in Sprint Retrospective the development team wants to convert the sprint length into 2 weeks. Can this extension be possible? Who has to approve to this request?

There is a HUGE difference between extending the sprint length versus changing the sprint length. Extending the sprint length is adding a day or 2 because the team didn't finish what they needed to. It's a 1 time ordeal. The scenario you mentioned involves the team deciding that the 1 week sprint is too short so they want to change it to 2 weeks. For the foreseeable future, the sprint length is 2 weeks unless there is a need to change that in the future.

As for approving this request, the team is self-organizing. They don't answer to anyone about HOW they do their jobs. Therefore, the team approves this sort of change.

Thank you, everyone, for swift responses. I am actually preparing for PSM1 and therefore want to clear few confusions. I respect and thank everyone for the support and making efforts to clear my confusions.

Ian Mitchell - The answer to your question is the answer provided by you to some other person on this forum. I am quoting your response which is actually a good insight :

"1) When the organization is known to have a release cadence of one month, and half of the two-week sprints would therefore not be potentially releasable 

2) When the Product Owner cannot articulate Sprint Goals and the corresponding release of Incremental value in timeboxes of less than one month 

3) When the Development Team cannot commit to two-weekly Sprints but can commit to monthly ones."

Curtis Slough - By mentioning "Team", do you mean Scrum Team or Development Team? Because it is the Development team which is self-organizing.

https://www.scrum.org/forum/scrum-forum/6176/sprint-1-sprint-length

There are many reasons to increase Sprint length:

1. Reducing requirements variability is an advanced skill and can take some time to get right. Getting PBIs to fit in Sprints while still delivery value is not always easy. It's better to increase Sprint length than to take short cuts on a definition of done. Teams tend to cut things like unit testing and collaboration when this happens. 

2. Teams must develop the skills to work through bottlenecks within the Sprint and achieve a definition of done that includes quality checks. Scrum doesn't account for wait times or the theory of constraints so teams will underestimate the time it takes to get a story to done until they develop the right skills and team work.

3. Overhead. For some teams compliance and/or regulatory requirements provide too much overhead to iterate that quickly. Sometimes it's a technological hurdle.

My recommendation is that a team that's never done Scrum before start with 4 weeks with an create an objective to lower it to 3 weeks in the future. Teams should conduct process miniatures prior to any Sprint launch. Start slow and increase velocity over time.

I have a completely opposite view (which is similar, if not identical, to Ching-Pei's). 

"Why?" one may ask. Well, because, to me, it's all about common sense. Sprints (mini projects) consume resources (time, motivation, money, dedication, you name it - and let's not forget about missed opportunities had you known sooner what you usually find out later). 

Given the huge investments teams (and their organizations) make in sprints, it's usually wise to get as much feedback in the shortest possible timeframe. I say "usually", cause I appreciate (and have seen myself on many occasions) there are instances where 4-week sprints are the best way to proceed given the individual circumstances

I mentioned "common sense" above. Why? Because to me it makes sense to discover as I travel rather than discover right at the end. If I decide my next Netflix (TV Show) is going to be [Insert title here], and after S01E01, S01E02, S01E03 I decide I don't really like it, I won't spend time getting to the end of S01, and definitely not going to watch S02 and the following ones.

Brilliant discussion, I have really enjoyed reading it.

Just a few thoughts to add:

1. If we are doing a form of Scaled Agile (such as Nexus or Scrum@Scale), the assumption is that sprints across the different teams will be aligned so that a single Sprint Review can be held. In which case the decision on Sprint durations would most likely be taken at the Nexus of Scrum of Scrum level. Changing it mid-project would require alignment with all the Agile teams.
2. In many organizations, who are reasonably mature in their Agile journeys, the Sprint timetable is defined at the department or organization level and individual Agile teams are expected to align. So in this case the decision would most likely be taken with Senior Executives and Agile Leads.

In my personal experience, as a Scrum Master, changing the duration of Sprints has never been a decision that the Scrum team is able to make.