Forums

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

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Sprint length and consistency for same product Backlock?
Last Post 06 Apr 2014 09:48 PM by N Riz. 5 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Pablo Gonzalez
New Member
New Member
Posts:12
Pablo Gonzalez

--
30 Mar 2014 03:51 PM
    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.
    Joshua Partogi
    Basic Member
    Basic Member
    Posts:109
    Joshua Partogi

    --
    30 Mar 2014 05:40 PM
    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.
    Sanjay Saini
    Basic Member
    Basic Member
    Posts:151
    Sanjay Saini

    --
    30 Mar 2014 06:17 PM

    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
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1534
    Ian Mitchell

    --
    31 Mar 2014 05:24 AM
    > ...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.

    Pablo Gonzalez
    New Member
    New Member
    Posts:12
    Pablo Gonzalez

    --
    01 Apr 2014 01:38 AM
    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.
    N Riz
    New Member
    New Member
    Posts:1
    N Riz

    --
    06 Apr 2014 09:48 PM
    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.
    You are not authorized to post a reply.


    Feedback