Skip to main content

Sprint length and consistency for same product Backlock?

Last post 02:48 am April 7, 2014 by N Riz
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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.