Sprint length and consistency for same product Backlock?
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.
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.
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.
Cheers
Sanjay
> ...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.
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.
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.