Forums

By posting to our forums you are agreeing to the Forum terms of use.
Reasons for choosing a month sprint over a two-weeks sprint
Last Post 02 Jan 2014 10:07 PM by Millard. 4 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Robert Stone
New Member
New Member
Posts:5
Robert Stone

--
15 Dec 2013 09:22 AM
    Hi everybody,

    One question about Scrum framework.

    What reasons would be reasonable for choosing a month sprint over a two-weeks sprint?

    Thank you in advance.
    Ravi Vajaria
    New Member
    New Member
    Posts:12
    Ravi Vajaria

    --
    15 Dec 2013 04:47 PM
    - When work is too big to decompose and team can't complete within 2 weeks. That said, I am not 100% convinced with this answer. I.e. this is not the primary reason for 1 month sprint in my opinion.
    - Project with long time duration commitment (> 1 year?) so that stakeholders/PO are willing to risk 1 month. I.e. loosing 1 month is not that significant loss than loosing 2 weeks (from stakeholders' and PO perspective).
    - 2 weeks sprint is getting in the way for company to do other work
    - I think 1 month is too long. 2 to 3 weeks is a good balance.
    - 1 week sprint is quite normal as well (eventually team will know how to decompose PBIs to fit into 1 sprint)
    Ian Mitchell
    Advanced Member
    Advanced Member
    Posts:575
    Ian Mitchell

    --
    16 Dec 2013 05:00 AM
    > What reasons would be reasonable for choosing a month sprint over a two-weeks sprint?

    1) When the organization is known to have a release cadence of one month, and half of the two-week sprints would therefore not be potentially releasable
    2) When the Product Owner cannot articulate Sprint Goals and the corresponding release of Incremental value in timeboxes of less than one month
    3) When the Development Team cannot commit to two-weekly Sprints, but can commit to monthly ones.
    Fredrik Vestin
    New Member
    New Member
    Posts:61
    Fredrik Vestin

    --
    18 Dec 2013 01:49 PM
    When determining the sprint length consider the following:

    How long can the team be protected from outside interference?
    How long does it take the team to build something of significant value?
    How often do we need to inspect the current status and progress of a project/product and adapt the plan?

    Answering these questions will help the team decide a proper sprint length.
    Millard
    New Member
    New Member
    Posts:4
    Millard

    --
    02 Jan 2014 10:07 PM
    Wish there was a way to +1 Fredrik's answer.

    There's also a slightly different way I'd think about his third point: When you consider the continuous improvement aspect of Scrum, driven by the retrospective, the more often you have them, the more opportunities to discuss and implement improvements.

    In general, with teams new to Scrum, I push for 2 week sprints (rather than 4 weeks). This helps us build our scrum muscles more quickly. Depending on how agile the new team is, there can be so much to absorb (you'd think that would argue for longer sprints, but my experience tells me that new teams will wander too much and lose the scrum focus). Some teams have no idea how hard it is to get "done" -- they've never done it (not without 4-6 weeks of QA and hardening). Some teams have never self-organized. Put those two together and you could have a month of chaos (so let's make it just 2 weeks and get to a quick inspection). And that's ignoring important technical practices they may also need to master.

    Biting off a small piece of functionality while really nailing the "done" criteria is eye-opening and empowering and encouraging.
    You are not authorized to post a reply.


    Feedback