Can we change Sprint Duration after a few initial sprints?

Hi Krutivas,

it is totally OK if the team decides to change the sprint lenght based on "lessions learned", and as a self-organized team they have the final say on it. BUT the maximal duration of the sprint is one month (5 weeks lenght is way too long). If the team feels, that they can't finish their work in 4 weeks, I'm pretty sure, that there is something wrong with the size of the PBIs, they can be decomposed so that they are fitting in a shorter sprint. Most SCRUM teams I know are working with 2 weeks sprint lenght.

Greetings,
Peter

Of course it is possible to adjust future sprints length.
Scrum discourage having sprint of > 4 weeks.

What are the reasons the Scrum Team (or Dev Team ?) wants to increase sprint length ?

We could always adjust the story points for the original sprint duration

Why would the story points need to be adjusted based on a change to the sprint length? Story points need to reflect the size of a story. They have nothing to do with the size of the iteration.

Per the Scrum Guide, a sprint length must be one month or less (4 weeks or less). It isn't just that a length greater than 4 weeks is discouraged - it is a violation of Scrum.

I also agree with previous comments. It is acceptable to adjust the sprint length based on empirical feedback, but you don't state the reasons that the team wants to increase the sprint length. Keep in mind that adjusting the sprint length should not be done repeatedly, as it harms the team's ability to form a sprint heartbeat, and hurts the ability to form meaningful velocity metrics and thereby impedes the business' ability to plan.

Forgive me but there seems to be no way to add a new question to the forums on this site
my question is = Can the sprint backlog be altered during the Sprint

My Answer = yes it can be especially because if the development feels that the scope is more than what they had anticipated or if they are feeling they could add more work from the product backlog they are able to pull work,
Now I happened to be reading - Scrum Master Training Manual for PSM by Nader and Frank where they specifically say that ONCE THE SPRINT BACKLOG IS DEFINED IT CAN NOT CHANGE - Could someone kindly help me decide what the correct answer it?

This is from the Scrum guide - "The Development Team modifies the Sprint Backlog throughout the Sprint, and
the Sprint Backlog emerges during the Sprint."

Now I happened to be reading - Scrum Master Training Manual for PSM by Nader and Frank where they specifically say that ONCE THE SPRINT BACKLOG IS DEFINED IT CAN NOT CHANGE

Ravjote,

If that is what is stated, then the statement is incorrect. As mentioned many times before, be wary of any Scrum "source" other than the Scrum Guide.

Thanks for the replies everyone.

The Scrum Guide says: Sprints have consistent durations throughout a development effort....

OK... But it also says: 

Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

The latter suggests that changing the next Sprint lenght in Retrospective is a possibility....

So what is the conclusion?

You are correct, Kjell. During the retrospective (last event), the team can decide to shorten (to max a week) or to lengthen (to max 4 weeks) the sprint duration. I've done this in the past with several teams. Either as a means to temporarily adapt when there are significant events (ie around Black Friday, Christmas & NY) or as a "permanent" change to reflect the status quo (like moving from 4 to 2 weeks sprint to get to market sooner).

Note that topic doesn't necessarily need to be brought up and decided during the retrospective. Improvement/adapting is a continuous process, so decision to change the sprint length can be taken for example at the end of a refinement session if someone brings it up and there's time to discuss.

Here are few points from a different perspective (rhythm/pace) to consider change in Sprint Length:

Based on several factors after carefully selecting the Sprint length (max. one calendar month while there is no minimum prescribed as such), you may keep the following under consideration before changing Sprint Length:

#1. Once a sprint length is chosen development team develops a pattern of how to do their work in that particular length of sprint. In other words, a sort of rhythm/pace gets developed/established.

#2. If you change the sprint length after few sprints (for example downwards: 4 weeks to 3 weeks): development team most likely still try to approach the planning with the original sprint length and usually it will result in risk of not being able to deliver the 'done' increment, possibly. And similarly when it is changed upwards (for example: 2 weeks to 3 weeks) there is again a risk of delivering less, possibly.

#3. So whenever you change the sprint length, you need to note that once again it will take few sprints for the rhythm/pace to get developed/established again.

Note that topic doesn't necessarily need to be brought up and decided during the retrospective. Improvement/adapting is a continuous process, so decision to change the sprint length can be taken for example at the end of a refinement session if someone brings it up and there's time to discuss.

Yes, bearing in mind that it is of course the length of future sprints which is being negotiated.

Note that the Scrum Team should reconsider the matter of revising Sprint length during the Retrospective, even if it has been discussed thoroughly beforehand. The actual decision should be made just-in-time on the basis of the latest information available.

According to the MoSCoW method, which features/requirements can be termed as ' nice-to-have'? I am confused between 'Could have' and 'Would have, but not this time'. Please share your thoughts.

Yes you can. It is not recommended because it breaks consistency but if its better way to increase value, this can be done. Its entirely up to the Scrum team.

2 cents regarding Sprint duration.

From my experience, I noticed that many teams struggle to deliver the done valuable increment even within one-month-long Sprints. A typical reason might be - the test automation is very poor and the product requires a lot of manual UAT testing. Whenever a serious bug is found and fixed, they need to repeat a significant amount of manual regression testing since the product has to meet strict quality measures in order to be deliverable to the customer. 

In such a case, the team needs to juggle between two principles - Deliver at least one Done Increment per Sprint or stick to the one-month Sprint no matter what. 

In such cases, my preference is to have longer Sprints and deliver value. Identify the work needed to be done to shorten the Sprints (e.g improve automation test coverage, reduce technical dept) and shorten the Sprints when those problems are fixed.

What is your preference ?

Jacek Markiewicz 

Actually if team is struggling to deliver increment during one month long sprint the reason might be exactly that sprint is too long.

The opportunities to inspect and adapt frequently are lost, and team is not able to improve its performance

The success of Scrum is not based on delivering by any cost, but on the framework of inspection and adaptation, which allows the team to grow and deliver. So failure to deliver should be treated as a piece of valuable information and foundation to be more successful in the future, if it's properly inspected and if adaptation is made.

So the solution is opposite-to make the sprint shorter, inspect and adapt more frequently, which will help identify causes of the bad performance and help remove them, instead of pushing for the result.

Of course the whole environment where Scrum team is operating is a very important factor here-is it hostile, indifferent, stagnating or supportive?

How vital is the "failure" for keeping up the security of the environment where developers operate? How crucial or dangerous is stakeholders dissatisfaction? Depending on this, the team should  make the balanced decisions, based on what's good for its actual survival on a short term basis, and on the improvement on the long term basis.