Does the Sprint Guide Say Who Determines Sprint Length?

The Guide does not prescribe a method. How do you think Sprint length should be determined, bearing in mind that there are technical and business concerns which might need to be taken into consideration?

In guide you have something like this:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.

So I would say that the sprint should be long enough (no longer than one month) to ensure that development team can create done potentially releasable increment and in my opinion this statement include lot of variables, like mentioned by Ian technical and business concerns.



Because the team is self-organize, the final decision is up to the team and no one should force fixed sprint duration. Having in mind that Scrum is an adaptive approach to do things, the team can always decide to change length of sprint while they do retrospective meeting. During the sprint, there can not be made any change in duration in my opinion, according to this statement in guide:

Sprints have consistent durations throughout a development effort.

 

My understanding is that it is the scrum team that is responsible for determining the sprint length. To expand on Ian's point, I believe this should be determined empirically. For example, if a team decides it needs regular feedback from the stakeholders, then a shorter sprint would help achieve this or for example to limit the risk etc.

That's my understanding, however, I also found this old post that provides a more holistic view.

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

Thanks for the question. Helped me learn something and contribute (hopefully) :)

If you're introducing Scrum (or have just started and trying to find your pace), it would be worth discussing the topic with the entire Scrum team + stakeholders. Thw whole idea being that a sprint is a mini-project that has a specific (sprint) goal that should bring benefits to the business, people should discuss the cycle length and see what makes most sense.

Bear in mind though that if you release once a sprint, you'd be way better off releasing in shorter cycles (1 week or 2 weeks) vs longer ones (4 week sprints).

Also note that, following trials, you can review the sprint length in retrospectives and decide, as a group, to change the duration.

I am a scrum novice preparing for the certificate, stumbled over the question "who decides sprint length", googled and got ambiguous answers:

a) the Scrum Team owns the sprint and decides

b) the Product Owner has to approve the sprint length because only she/he can assess the business aspect (sprint length should also include market needs like time to market)

Do I have a language issue? To my understanding if "approval" is required the approver has final decision authority and accountability. Consequently she/he "decides" based on what the scrum team has discussed.

On the other hand the PO is part of the Scrum Team. The business aspects would be part of the scrum team's sprint length decision. With respect to the scrum principle of "self organization" I would assume that "the Scrum Team decides and is accountable for the sprint length" would be a better match to the scrum philosophy. Who can help?

Hi Jerry,

the best answer I found is here: https://www.scrum.org/resources/blog/5-powerful-things-about-sprint

Scroll down to #3: There you will find the answer I use for my studies regarding the PSPO I.

KR, Jan 

I believe that your closing interpretations are correct. No where in the Scrum Guide does it state the answer to your question. There are many interpretations floating around the internet and books. So, please remember that what I say is my interpretation. I have also read the reference that @Jan provided and it actually feeds into my interpretation. 

The Scrum Team is self-organizing, self-managed.  The entire Scrum Team should make all decisions based on all of the information available.  The information from @Jan's reference is a key element of information that should be used.  Also the Scrum Guide provides this guidance in determining Sprint length (emphasis added by me). 

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

The Scrum Team should identify a Sprint length that helps to minimize those risks. There is no one role that approves or defines the length. Each role plays a part based on the information and the "function" that they bring to the cross functional team. 

found this on Scrumstar.com:

"If after extensive discussion the Scrum Team cannot agree on the length of the Sprint, who has the authority to make the final decision?"

• The Product Owner
• The Development Team
• The Scrum Master

The correct answer according to them is Scrum Master, which made me raise an eyebrow, google it, and wind up here.

Given timeboxing helps us limit risk to a single sprint, wouldn't the Product Owner be interested in having a sprint length that doesn't allow an unacceptable risk?

Given a Development Team is responsible for producing a "Done" increment, how long would they need to be sure of doing this?

Given a Scrum Team need to set a Sprint Goal, what amount of time allows them to set the most effective Sprint Goals and inspect and adapt their approach to achieving it, as needed?

Given that stakeholders are both needed and ideally interested in inspecting and adapting product increments, what frequency of inspection and adaptation is needed?

If after considering all of these, people are not able to make a collective decision, then there are probably bigger issues than the length of the sprint.

Who is funding the Scrum Team? If funding is reviewed more frequently than once a month, that could be a strong reason for having a shorter sprint length.

Scrumstar.com?

This has been stated repeatedly in this forum.   You would be wise to be cautious regarding the content of any "Scrum" sites other than Scrum.com and perhaps the Mikhail Lapshin practice exams.

found this on Scrumstar.com:

"If after extensive discussion the Scrum Team cannot agree on the length of the Sprint, who has the authority to make the final decision?"

Authority?  None.  Responsibility?  All. @Simon Mayer makes great points across the board.  I will say that the Scrum Master, as part of their responsibility to faciliate Scrum Events as needed and ensuring everyone's understanding of Scrum, has a responsibility to help the team agree on something. I suggest that a good Scrum Master would help the team understand that they can all agree to try a length and then retrospect on it. If it needs to be adjusted, it can be but until you try something you can't know if it is right for your team.

And I'll agree with @Timothy Baffa, I'd be wary of scrumstar.com.  I have nothing specifically against them but since I know that they are part of a company that makes money by selling products and services, I am hesitant to trust them fully. Going through their Agile Glossary I came across a few of their definitions that could be considered questionable.  The Scrum Guide is still the source I recommend when questions arise. 

It would really be easier if the Scrum Guide explicitly said who determines / decides the length of the sprint. But since it's not like that ... it's more fun and exciting trying to find out while we share ours thought and ideas.

As it has already been very well placed here by others, there are many variables (timeboxing, consistent durations throughout a development effort, business and technical needs, available funding, market needs and changes, ...)

Humbly, I think it's a decision made by the Scrum Team as a whole. And if the Scrum Team understands the Scrum Theory (empiricism) and embodies and lives the Scrum Values ​​(commitment, courage, focus, openness and respect), if there is no consense on the length of the Sprint, there will be no problem to agree to try a length and then evaluate the result. And if they deem it necessary, a new Sprint length will be tried out.

Agree with all about, ST decides sprint length taking into account different aspects and can also experiment.

Am I right saying that if the team cannot decide anyway, SM already did his best to facilitate their efford and they still do not agree then the situation become impediment and then SM, to resolve the impediment, can decide the length.

Am I right saying that if the team cannot decide anyway, SM already did his best to facilitate their efford and they still do not agree then the situation become impediment and then SM, to resolve the impediment, can decide the length.

That would not resolve the impediment, it would cover it up. A Scrum Master could reveal what is likely to be the best Sprint length, and why, but resolution of the matter has to lie collectively with the self-managing team.

If the team is unable to self-manage and reach agreement on something, then that would be the impediment the Scrum Master would address.

Thanks Ian, is mine impediment "team cannot take decision despite all the efford and facilitation" not the same as yours "unable to self manage"? (But not called by the name ?)

It's important to distinguish between symptom and cause. The team's failure to agree Sprint length is a symptom of an underlying problem. If any one person was to assume authority and decide on specific matters such as this, as and when they arise, you'd then have reliance on a manager. The underlying impediment constraining the team's ability to self-manage would remain.

A Scrum Master exposes and explains key issues so others are then better able to help themselves, and takes care not to provide mere palliative relief to organizational problems.

Length of the sprint is contained for a reason to one month at max. This minimizes the loss due to unforeseen risks. Scrum employs empirical process control and so the team should be open to course correction. The Scrum team decides and agrees on the sprint length considering the iron triangle of constraints i.e. budget, schedule & scope with control variables for people, process & product.