Can Scrum Sprint duration change from 4 weeks to 2 weeks during the project?

Question

Does it makes sense to adjust Sprint duration during the project?
Consider a 10 months project for a web portal, requirements are a little obscure right now, so I expect that at the beginning (first and maybe second month) there will be much more analysis and background/infrastructure implementation than following months. So does it make sense to start first two sprint of 4 weeks and then shorten them to 2 weeks when development speed will raise and will be possible to deliver quickly portal functionality?

Thanks

Answer 1

Great question. Start with your 4 weeks (or whatever you decided to use first). Then make sure to have a Retrospective at the end of each Sprint. If during the Retrospective the team thinks that 2 weeks would be better (for example, so that you can get faster feedback on new features), the team can decide to change Sprint duration for the next Sprint. Then you should analyze in the next Retrospective whether that was a more effective choice for your sprint.

I am a bit concerned by your statement that the first few sprints would only include analysis and infrastructure implementation. This is counter to Scrum, where you start delivering features in the first Sprint, doing only as much analysis and infrastructure as are needed to support those first features. Did you have a specific reason for doing it this way?

Answer 2

I know teams which has their sprint length floating so that's not an issue to change sprint length over time.

The main value you get from keeping the sprints equally-sized is you can measure how much work the team can do over the next chunk of time. If you change sprint length during the project it will be more difficult to estimate velocity.

Besides in Scrum sprint length determines frequency of planning meetings, demos and retrospectives. If the team is new to Scrum I'd probably go for shorter iterations from the beginning - you don't have to treat as the rule that you have to deliver presentable demo after each sprint, but the more frequently you meet to improve your process (retrospective!) the faster you'll be adjusting your method to the optimal one.

In short: if you have rather experienced team and measuring velocity isn't crucial I wouldn't object changing sprint during the project. However if the team isn't that experienced (so you prepare for frequent process adjustments) or learning how fast you can run is important I'd prefer to start with 2-week-long sprints on the beginning.

Answer 3

In my opinion, you can adjust the duration of the sprint since your team see the benefits.

Retrospective is the key to keep the process good and efficient.

See this question about Strict or Pragmatic Scrum.

ashes999 says:

Scrum and Agile are loosely-defined. Every company implements it differently depending on how much they can "tolerate."

Also look at this question about Improving your Scrum Sprint!.

Answer 4

You might like to consider a shorter sprint/iteration to begin with, it solves many problems. In this instance you will get a shorter feedback loop which will enable you to adjust sooner. As your requirements are a bit obscure planning out 4 weeks just might be a bit risky. There is nothing inherently wrong with varying your sprint length although it will disrupt your rhythm and your velocity chart will look like the Loch Ness monster. The golden rule is not to change your sprint length once you're in it.