4 week sprints

One justification is the transaction cost. If it takes 35 hours to make a release, it consumes 1 developer for a week. So we cannot have 2 week sprints, because then we know one developer will be dedicated for this release responsibility. It also depends and what we can afford and what is needed by the stakeholders.

Another reason might be that the Product Backlog Items cannot be decomposed further and are too big to fit in a 2- or 3-week-sprint.

Posted By Ludwig on 26 Jun 2014 08:14 AM
Another reason might be that the Product Backlog Items cannot be decomposed further and are too big to fit in a 2- or 3-week-sprint.

this is an interesting point, as usually the work work (PBI's) are split to tasks of 1 day or less. when you say PBI's cannot be decomposed any further what do you mean?

The *primary* consideration in determining Sprint length is the ability to service and receive feedback from the market, rather than any engineering or production constraints.

In other words an agile team should be able to respond to the pull that is exerted on them by environmental conditions. If the market is sluggish then a 4 week sprint may be the most plausible option.

Agree with Ian. I always say that Product Owner should drive the process of choosing the length of the Sprint. Engineering or other constraints are secondary.

Whilst I also agree with Ian, you should be looking for every opportunity to inspect and adapt in everything that you do. For this reason, I prefer 1-week sprints, especially for new Scrum teams who are dealing with complex problems. You will potentially fail faster but equally you will be able to inspect and adapt faster. With experience, you will be able to see impediments looming even before they happen. That’s Scrumming the Scrum!

I gratefully received this advice from Jeff Sutherland on my CSM course 3 years ago, when he was looking at a Waterfall project plan that I had produced for a complex 1 year project. Since then I have trained a number of Development Teams as well as Product Owners to work with 1 week sprints and with great success. Everyone is more engaged. Feedback opportunities are greater. Scrum events are shorter but more regular and focused.

With regard to large PBIs or epics, break them down. If you think that they are too big and too complex to be broken down then…..even more reason to break them down! Again, more good advice from Jeff. Unfortunately, I haven’t worked on a simple project yet and this always comes to my rescue. Thanks to Jeff!

thanks to all for the excellent tips, this more than answers my question.

> Another reason might be that the Product Backlog Items cannot be decomposed further and are too big to fit in a 2- or 3-week-sprint.

Disagree. Inability to decompose items is not a good reason to choose a longer sprint length, because almost anything can be decomposed to units of 1 week or less. I've yet to come across a situation where this wasn't true.

+1 to Ian's answer.

You are right that this should not be the *primary* reason, but still it can be *another* reason. Maybe you didn't work in environments where hardware is included, or in highly regulated industries like medical technology.