Skip to main content

Scrum Forum

Sprint length and consistency for same product Backlock?

Last post 02:48 am April 7, 2014
by Anonymous
5 replies
08:51 pm March 30, 2014

Hey community, i was addressed by this question from my team and I didn't know the answer: "Is it allowed to change the sprint length for every iteration?" Basically, if we see that we did a two-weeks sprint length for the first iteration and it worked well, resulting on a potentially shipable product, but for the next sprint the team realize that the work requires 4 weeks to produce an increment based on the remaining PBIs. Does Scrum has strict guidelines concerning the consistency of sprints? Or it's totally normal and permitted to vary the length of several sprints accordingly when the need arise?

Thank you for your feedback and advice.

10:40 pm March 30, 2014

One guideline that I always follow: consistency reduces complexity. Changing Sprint duration every now and then just adds an extra layer of complexity. You are already dealing with complex problems, why add more complexity to it?

What I suggest my team to do is break down the PBI in a such that it would fit in a 2 weeks Sprint. Another guideline that I always follow is: A Sprint is not a contract. The whole PBI may be ready after 4 weeks.

11:17 pm March 30, 2014

Yep, break up the work so that it fits into 2 weeks sprint. It should potentially releasable and demoable. During the sprint review team can demo it and inform stakeholders that the complete feature needs one more sprint for customer release.

It should be a vertical slice of the feature, don't work on DB layer in one sprint and Middle layer in next sprint.


10:24 am March 31, 2014

> ...for the next sprint the team realize that the work requires 4 weeks to
> produce an increment based on the remaining PBIs...

That indicates Sprint Planning has not been done well. Working from the top of the ordered Product Backlog, the Development Team should induct as many items into the Sprint Backlog as they estimate they can accomplish in the Sprint timebox...which in this case is 2 weeks.

The length of a Sprint may be:
- increased if a Retrospective reveals the established length to be unworkable, or
- shortened if there is a clear opportunity to consistently reduce batch sizes and deliver increments more quickly.

06:38 am April 1, 2014

Thank you Joshua, Sanjay and Ian. All of these are great responses. I agree, the PB wasn't analyzed well by the team resulting on this dilemma. It's a good learned lesson for a better analysis work and to only add to the Sprint backlog the PBIs that will fit into a consistent sprint size.

02:48 am April 7, 2014

Hi there! I am new to the community but I appreciate the way response and help is activated. In my opinion "Sprint Planning" is the key. If the back log identified requires more time then it should be allocated otherwise "Done" state may not be achieved. More so the team must be clearly notified that what all is to be included once "Done" would be achieved.