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.

4 week sprints
Last Post 29 Jun 2014 10:15 PM by Ludwig Harsch. 9 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Adrian Turcanu
New Member
New Member
Posts:12
Adrian Turcanu

--
26 Jun 2014 03:04 AM
    Hi,

    How do you think, what could be the primary reason why a team might choose to work with 4 weeks sprints.

    Thanks,
    Adrian.
    Muthaiya Nallalam Parasuraman
    New Member
    New Member
    Posts:16
    Muthaiya Nallalam Parasuraman

    --
    26 Jun 2014 03:09 AM
    One justification is the transaction cost. If it takes 35 hours to make a release, it consumes 1 developer for a week. So we cannot have 2 week sprints, because then we know one developer will be dedicated for this release responsibility. It also depends and what we can afford and what is needed by the stakeholders.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    26 Jun 2014 03:14 AM
    Another reason might be that the Product Backlog Items cannot be decomposed further and are too big to fit in a 2- or 3-week-sprint.
    Adrian Turcanu
    New Member
    New Member
    Posts:12
    Adrian Turcanu

    --
    26 Jun 2014 03:23 AM

    Posted By Ludwig on 26 Jun 2014 08:14 AM
    Another reason might be that the Product Backlog Items cannot be decomposed further and are too big to fit in a 2- or 3-week-sprint.


    this is an interesting point, as usually the work work (PBI's) are split to tasks of 1 day or less. when you say PBI's cannot be decomposed any further what do you mean?
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1677
    Ian Mitchell

    --
    26 Jun 2014 06:23 AM
    The *primary* consideration in determining Sprint length is the ability to service and receive feedback from the market, rather than any engineering or production constraints.

    In other words an agile team should be able to respond to the pull that is exerted on them by environmental conditions. If the market is sluggish then a 4 week sprint may be the most plausible option.
    Ilia Pavlichenko
    New Member
    New Member
    Posts:71
    Ilia Pavlichenko

    --
    26 Jun 2014 06:35 AM
    Agree with Ian. I always say that Product Owner should drive the process of choosing the length of the Sprint. Engineering or other constraints are secondary.
    Carl Adamson
    New Member
    New Member
    Posts:3
    Carl Adamson

    --
    26 Jun 2014 08:28 AM
    Whilst I also agree with Ian, you should be looking for every opportunity to inspect and adapt in everything that you do. For this reason, I prefer 1-week sprints, especially for new Scrum teams who are dealing with complex problems. You will potentially fail faster but equally you will be able to inspect and adapt faster. With experience, you will be able to see impediments looming even before they happen. That’s Scrumming the Scrum!

    I gratefully received this advice from Jeff Sutherland on my CSM course 3 years ago, when he was looking at a Waterfall project plan that I had produced for a complex 1 year project. Since then I have trained a number of Development Teams as well as Product Owners to work with 1 week sprints and with great success. Everyone is more engaged. Feedback opportunities are greater. Scrum events are shorter but more regular and focused.

    With regard to large PBIs or epics, break them down. If you think that they are too big and too complex to be broken down then…..even more reason to break them down! Again, more good advice from Jeff. Unfortunately, I haven’t worked on a simple project yet and this always comes to my rescue. Thanks to Jeff!
    Adrian Turcanu
    New Member
    New Member
    Posts:12
    Adrian Turcanu

    --
    26 Jun 2014 09:50 AM
    thanks to all for the excellent tips, this more than answers my question.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:411
    Charles Bradley

    --
    26 Jun 2014 11:20 AM
    > Another reason might be that the Product Backlog Items cannot be decomposed further and are too big to fit in a 2- or 3-week-sprint.

    Disagree. Inability to decompose items is not a good reason to choose a longer sprint length, because almost anything can be decomposed to units of 1 week or less. I've yet to come across a situation where this wasn't true.

    +1 to Ian's answer.
    Ludwig Harsch
    Basic Member
    Basic Member
    Posts:272
    Ludwig Harsch

    --
    29 Jun 2014 10:15 PM
    You are right that this should not be the *primary* reason, but still it can be *another* reason. Maybe you didn't work in environments where hardware is included, or in highly regulated industries like medical technology.
    You are not authorized to post a reply.


    Feedback