Sprint 1- Sprint length

Hello Isha,

The Product Owner is the one to decide the length of the Sprints, with the potential advice from and based on the previous Sprints experience with the Scrum team.
Please check this section from the Scrum guide as the most common reasons are described:
http://scrumguides.org/scrum-guide.html#events-sprint

Kind regards,

Mike Cohn blogged about this topic last week:

http://www.mountaingoatsoftware.com/blog/who-picks-the-sprint-length-on…

This sparked some discussion because although the PO is best positioned to determine the optimal rate for the release of value, sprint length is ultimately a process matter. I therefore agree with him that - when push comes to shove - it's the Scrum Master who must decide.

Hello Ian,

I know it's been quite a while since this post was created, however i would like to have opinion/exp. shared, I feel since the development team estimates their work so they are the right team to decide on the length of the sprint to deliver the desired increment too. However if they choose the sprint length to be greater than 30 days(1 calendar month) then its a responsibility of a Scrum master to pitch in and advise the team that as per Scrum Guidelines the Increments should be delivered within 30 calendar days or less i.e the sprint should not be greater then 1 calendar month.

Coming onto Product Owner. it's always his decision to priorities the requirements in order to get the maximum benefits (ROI) from the product and the development team. The Scrum Master should guide the PO to understand how this can be achieved in an empirical manner as per Scrum Guidelines. So in that way Product Owner would be able to priorities the requirements as per the development teams capacity/ability.

As more is learned the development team can improve on determining what is the optimal sprint length they can adapt to deliver the max value.

Regards,

Rajat

I think that's a good synopsis. The "right" sprint length should balance the Product Owner's appetite for receiving increments of value, with the ability of the Development Team to supply those deliverables. The Scrum Master may have some coaching duties to perform in that regard.

Product Owner and Development Team Defines the length of the Sprint.

Scrum Master Approves it, by analyzing the factors using which length of the sprint is defined.

@Mike Cohn blog very clearly states SM choose the sprint length ( does not define's it ) and in his example, he clearly states that  SM provides the idea to change the sprint length using the appropriate indicators.

Please read more information below : 

A)   How to define the length of the sprint?

As per scrum Guidelines ( developed and sustained by the Scrum creators: Ken Schwaber and Jeff Sutherland).

Role of Scrum master:

·         Keywords: Scrum overview, principles, guidelines, Scrum theory, practices, and process.

Role of Product Owner:

·         Maximizing the value of the product increment

·         Owns in-depth knowledge about the product

·         Release planning

Role of Development team :

·         Delivering a potentially releasable Increment

Following factors needs to be considered to decide right scrum sprint length.

1) Release Planning (Role: Product Owner): How often the product needs to be released to the mainline/ production Environment (Clients platform).  

If a product (smallest done increment) needs to be released :

·         Every week - Sprint Length      = 1 week ( Avoid Overhead)

Ideal for MVP releases, for an example - I have a product which is yet to be manufactured but I need to know about the interest of the customers in my product. I will update the product picture in a retail website and see how much views I get on the product, the more the clicks the more is customers interest. - Amazon yet to adopt this Plan :).

·         once in  2 week - Sprint Length = 2 weeks (Ideal)

·         Once in  3 week - Sprint Lenght = 3 Weeks (Ideal)

·         Once in  4 week - Sprint Length = 4 Weeks (Largest)

·         Anything above 4 weeks is not accepted in the Scrum framework for various reasons ( ref scrum guide/scrum events)

Now Consider I need to deliver a fuel cylinder to NASA jet and the minimum time for production and QA takes around 3 months.

i.e the team can't send the work of 1 month isn't it? Now decompose the 3-month work in the smaller unit and run ideally 3 weeks sprints to enhance the inspection and adaptability, accordingly plan your increment.

Conclusion – The Smaller the release cycle the smaller should be sprint.

2) Inspection and adaptation.

Inspection: How often the product needs feedback.

Adapt: How often the process needs to be fine-tuned.

If a team has very good expertise, but the product which they are building is completely new to team i.e. they don't have experience making a similar product. In this case, the team needs more feedback from PO and other stakeholders. Ideally, its good to have 2 weeks sprint, 1-week sprint will increase the overhead namely planning and review/ retrospective meeting preparations and 3-4 week sprint will fail to provide sufficient feedback.

Conclusion - The faster the product needs feedback the smaller should be the sprint.

3) Team Expertise - If the team does not have enough expertise to deliver the product then learn and implement and probably it's better to adopt 2 or 3-week observation sprint and check with indicators of the team performance based on the PO and stakeholders feedback.

Conclusion: Lower is the team expertise , longer is the sprint length

B)   Who should define the sprint length in SCRUM team?

The product owner and development team should define the length of the sprint.

C)   What’s the role of SM in defining the Sprint length?

 Scrum master(SM) should cautiously analyze the factors considered to conclude the sprint length. The scrum master should diligently inspect the product and process and if SM observes any variances in scrum goal and the problem with the process; the process should be fine-tuned in earliest and in adherence with the scrum guidelines.

* Note:

1) Scrum Guide does not provide any information on who has to define the Sprint length.

2) Scrum study Sbok says that the PO and Dev team is responsible to define the length of the sprint.

Can you please provide a link to the specific paragraph where "@Mike Cohn blog very clearly states SM choose the sprint length"?

I may be way off here, but hardly do I believe Mr. Cohn makes such a clear statement.

The SM can, of course, make suggestions and help the team get a better understanding of the constraints, benefits, disadvantages, whatever, but the choice (sprint length) is a group choice, based on the specific circumstances (unique, I'd say, to each organisation)

So I'd say the below

Product Owner and Development Team Defines the length of the Sprint.

Scrum Master Approves it, by analyzing the factors using which length of the sprint is defined.

is actually incorrect in my view.

I am total agreement with @Eugene.  I do not see Mr. Cohn saying anything to that effect. I have never seen him say anything close to that and in fact during the CSM training that I attended where he was the instructor he pretty much said the exact opposite. A link to the blog would be nice to have in order to support your statement.

Scrum Master Approves it, by analyzing the factors using which length of the sprint is defined.

Scrum Master does not approve anything.  As a servant-leader and facilitator it is their job to lead the team to agreement on this kind of decision. "Approval" just screams command-control.  There is nothing like this even remotely described in the Scrum Guide. 

I also respectfully disagree with almost all of your conclusions. There really isn't an ideal sprint length or formula for determining one.  It is a trial and error process for the Scrum Teams to undertake in order to determine the correct cadence for delivering the potential releasable increments. 

Ian Mitchell posted a link to a blog post from Mike Cohn, much earlier in this thread.

I find Mike Cohn makes a convincing case, although he goes to great effort to emphasize that this should be an exception.

However, I'd like to throw in some simple considerations, that might help teams arrive at a good Sprint length:

• Who is funding the Sprint? How much time and money are they prepared to spend before they see a releasable increment?
• How long do the Development Team feel they need in order to produce a releasable increment?

The vesting of executive authority in a Scrum Master is always something to be questioned. Given that there ought to be an empowered and self-organizing team, why would authority be placed anywhere other than in that team? What advantage would there be in doing so?

Examples include but are not restricted to a Scrum Master having the final say over Sprint length, or team composition, or the Definition of Done, or as we have recently seen in another thread, a Scrum Master having the say-so on removing a team member. What advantage would such authority give when implementing Scrum?

The following presentation on “Shock Therapy” by Jeff Sutherland imay prove relevant, especially slides 17 - 31:

http://jeffsutherland.org/scrum/SelfOrganizationShockTherapy.pdf

@Simon and @Ian.  Thanks for pointing out that blog post.  I had not seen it.  And in the context he gives, I can agree with what is being said.  But in the tone used by @Manjunatha's I still don't agree with his statement. It seems very much like he is promoting a Scrum Master in a dictatorial role. And as @Ian pointed out in his last comment it does not fit my interpretation of the role or Scrum in general for that matter. 

Again, thanks for pointing out that blog post. I'll add it to my list of reference material because he does make a good case for it.

lol :), My statements are quite clear but yes probably I should have not used the word APPROVAL which is misleading.

Apart @ Daniel, I do agree the best judgment to take a decision is trial and error process for the Scrum Teams that's what even Mike said and that's what even I did while I was working on  LeSS (HUGE) in Nokia Networks. It was SIEMENS earlier:).

FYI: The Concept of agile was introduced long back in the time of world war 2 during the production of missiles. If possible I will try to get you more information on the same. 

Scrum is a framework and not methodology, that does not mean we use no methods to build components. You need to tailor the Agile framework to fit your organization.

Every one of us have to adopt a defined set of methods for critical thinking and Timing which is the most important criteria of any project planning.   

But now @ Daniel & @Simon let me give a simple example and see what your words on it.

It's an emergency defense project for team working on the scrum, its new design and needs to be delivered to the field within 4 weeks that is the Goal? Yes, it's not proven platform.

So PO makes his goal clear within 4  weeks the product has to be released, dev team finds it is possible to release the product.  

Timing is a critical factor. Time is money its the value.

Now, who will decide the length of the sprint? 

and @ Daniel@Simon@IAN what's your approach?

1) Trail and Error method :)? 

2) rely on the PO and Dev team who will deliver increment.

3) or a JOINT session based on some experience which is not much related to this product.

SCRUM IS A FRAMEWORK which needs to be TAILORED to the production environment with the implementation of various scientific approach and methods.

With all the due diligence its good see your thoughts but it would have been better with experience.

Scrum Master is a thought leader, he coaches the team and keeps a check on the process in adherence with scrum guidelines.

Read Again 

C)   What’s the role of SM in defining the Sprint length?

 Scrum master(SM) should cautiously analyze the factors considered to conclude the sprint length. The scrum master should diligently inspect the product and process and if SM observes any variances in scrum goal and the problem with the process; the process should be fine-tuned in earliest and in adherence with the scrum guidelines.

@Ian 

Yes, FUNDING is discussed at the business level, what so-called Business unit in a given organization. Once internal funds are allocated for OPEX and CAPEX it is distributed at the business planning cycle and not a point of consideration at lower levels of sprint iteration. By and large, it has nothing; absolutely nothing to do with the length of the sprint.

GOOD LUCK TO ALL SCRUM EVANGELIST !!!

Manjunatha - I think the development team should consider the factors you have mentioned and decide on an appropriate sprint length.

The funding is actually relevant to a sprint length, as a 2-week sprint costs less than a 3-week sprint. Sure, over the course of a 6 or 12 month period it may not matter, but if the organisation is funding at the sprint level (which many organisations don't), then it may be a factor.

Yes Ben you are very true.

Budgeting and Funding is at Business unit - organizational level, of now leave it to me. I will try to get more insight on the same and  see how it might impact the length of the sprint.

Cheers :) 

After fierce discussion, I thought it's better to seek help from a few well known.

I published this question on the linkedin groups and contacted my coach STUART MITCHELL.

what did I publish?

who defines the length of the sprint? Please help me with the right answer as I am getting a varied response from many scrum masters.

a) Scrum Master

b) Scrum Master + Product owner

c) Product Owner + Development Team

d) PO + SM + Dev Team ( scrum team)

total view 105 

important comments 

Jim Pruitt, SMC, SPOC, ITIL  1st degree connection1stSenior Editor/Academic Content Producer at VMEdu, Inc.

Great question, Manju!  As an Agile framework, Scrum is not prescriptive; so any of these answers could be correct depending on the organization and professionals using it. As Corey says, the SBOK™ Guide includes the Scrum Master in making this decision. It also includes the Product Owner and the Scrum Team (development team) and this agrees with Jorge and H. Cem:  "Conduct Release Planning—In this process, the Scrum Core Team reviews the User Stories in the Prioritized Product Backlog to develop a Release Planning Schedule, which is essentially a phased deployment schedule that can be shared with the project stakeholders. Length of Sprint is also determined in this process" (16).  In our review questions we indicate that both the Scrum Master and Product Owner are involved in defining Sprint length. So, if you are preparing for one of our exams,

option D would be the best answer. 

Gene Sorbo  3rd degree connection3rdCertified Scrum Master | Agile Trainer | Certified ICF Team & Leadership Coach | 2019 Community Leadership Institute

In my experience this is typically an organizational decision (management) in light of common desire to align sprint schedules across multiple teams. Influenced by SM, PO, and Team input. If you're spending a lot of time figuring it out just choose a length and go and see how it works.

Sundara Krishnan Y.

Sundara Krishnan Y.  3rd degree connection3rdIT Development Manager

Let me explain a bit before answering this. Scrum team is a self organized team which means each has a role to play. While Product Owner identifies the project timescale (based on stakeholder's priority). Scrum master put heads together with the scrum team and defines the sprint length ranging from 2 to 4 weeks.

So, the answer is (d) - scrum team. Hope this explains!

Stuart Mitchell CST Australia

Snr Agile Coach / DevOps Coach

d is the right answer - confirmed via WhatsApp group

D is the choice of the majority

@Manjunatha  To answer the question you posed me, I would say that a 4 week sprint for that military contract is wrong given it has to be in the field in 4 weeks. If you do a 4 week sprint you are limiting your ability to get feedback on the work until it is too late.  Now, if the military representatives are continuously available and can work as part of the Development Team in order to give continuous feedback, then I would be ok with a 4 week sprint.  If not, I would encourage a 2 week sprint at a maximum so that the feedback loop for which Scrum is famous is able to provide benefit.

As you are fond of doing, let me post an excerpt from the Scrum Guide. 

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

In your example I don't see a complex adaptive problem. I see a complex fixed problem.  I also see little creativity in the delivery, especially given the military nature and fixed short delivery schedule. 

Given my previous statement and based on your military example, I'm not sure that Scrum would be your only choice.  Kanban might be a better Agile choice because it makes the progress apparent and the ordering practice something that is done continuously  It also leads itself to limiting the work in progress in order to finish work as soon as possible. If you are only doing one 4 week sprint then Scrum will be hard pressed to show any benefit.  Another option for that example is to just go with old fashioned waterfall or standard project management practices. You have a defined set of work and a defined end date with no flexibility. 

You state in your response "Read again" but do not state the source of that quote.  Can you provide me a link to that quote as I'd like to read it in its entirety.  

Scrum is a framework, I completely agree.  And the processes used by an organization is entirely up to them to determine.  However, the Scrum Guide clearly states 

Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

It also clearly states in the Guide that (emphasis added by me)

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

As a practicing Scrum Master and Agile Coach I do not believe that a Scrum Master approves anything.  From my years of management experience and the study of management practices I have done, I do not see a servant-leader as being anyone that dictates.  True, in the case where a consensus can not be reached and a decision needs to be made, a servant-leader will make one taking into account all of the information gained to date by discussions. But that is as a service to the team not as a dictatorial decision. 

I am basing my opinions on the Scrum Guide and my knowledge of agile practices.  And again, I emphasis that I am stating my opinion.  Just as you are prone to listening and accepting other's opinions, I give you mine as a point of information. I have provided you source of any of my references and freely post it here, encouraging others to provide their opinions and debate. 

Kanban is good when there are continuous development and deployment of small tasks with no defined release planning; however, I do consider your point.

If scrum, Yes you are very right about the statement 

"

Now, if the military representatives are continuously available and can work as part of the Development Team in order to give continuous feedback, then I would be ok with a 4-week sprint.

"

4th among 12 agile principles

Business people and developers must work together daily throughout the project

So ideally i want the representative to be part of daily scrum as neutral participant 

Thanks  Daniel for constructive feed back, thanks again.

The debate is a kind of brainstorming process and it really encourages me to share my thoughts and LEARN.

Hello :)

In my opinion, the product owner is the one who decides the sprint length, because according to the Scrum Guide, he is the responsible for maximizing the value of the product resulting from work of the Development Team and he may represent the desires of a committee in the Product Backlog, so he is the one who knows when an increment (releasable product) does the business or the committee needs. According to the Scrum Guide also, Only the Development Team can assess what it can accomplish over the upcoming Sprint. So, the development team has already a determined sprint length and according to the length they could choose the number of items selected from the Product Backlog for the Sprint. 

Cheers,

While it is true the PO is the only one with authority to cancel a sprint, the PO surely won't decide the sprint length. Can you think of why the PO is the only one allowed to cancel sprints? 

"Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work"

That's why I argue your interpretation (PO deciding the sprint length) is incorrect

I feel like we've lost our way a little with this conversation, and we're looking for a clear decision from the Scrum Guide, when it does not prescribe a way to set the sprint length.

Scrum doesn't solve your problems, it merely makes them visible. If a team or organization is unable to agree on a sprint length (which could be inspected and adapted after the first sprint), perhaps this is one of the first problems that Scrum will highlight.

8 years later and I believe the subject is still relevant.

Although there are some divergent opinions, I believe someone can make up his mind using the given answers.

But I would like just to share a trend that I noticed with the various development teams I interacted with (as a teammate or an external stakeholder).

If given the choice, development teams tend to prefer longer sprints. The number one reason they usually give is that longer sprints have less overhead due to sprint events (e.g. 1 planning/review/retro meeting every 3 weeks instead of 2). I think this is symptomatic of how sprint events are conducted and perceived by the dev teams.

I've had the exact opposite experience.  I have seen where Developers do not want long sprints or very short ones either.  On almost every Scrum Team I have worked, the Developers ask to settle on a 2 week cadence. It gives them time to get work done and increases the feedback loop that they have available with their stakeholders.  One team specifically said that anything over 2 weeks made it more difficult to deliver consistent value. 

But as with all things, it is up to the Scrum Team to decide what is best and not all Scrum Teams are alike.