Loading ...
Sorry, an error occurred while loading the content.
 

Re: [scrumdevelopment] 4 Week vs 3 Week vs 2 Week Cycle

Expand Messages
  • Alexey Krivitsky
    Hi Sam, We ve tried different approaches, you can read the summary we came up with here:
    Message 1 of 19 , Feb 1, 2007
      Hi Sam,

      We've tried different approaches, you can read the summary we came up with here:
      http://www.scrumalliance.org/index.php/scrum_alliance/for_everyone/learning_scrum/weekly_column/weekly_column_10_9_2006

      Hope this helps.

      But I think you and your team should try multiple try-and-fail cycles until you find what works for you
      and uncover the real issues.

      // Alexey

      On 1/31/07, Sam Beckman <Sam_Beckman@...> wrote:

      Hi. I am new to scrum and am in the process of doing a trial run of it
      with my group. I have a question about the length of the sprint.

      Has anyone had success with a 2 week sprint or a 3 week sprint?

      Does it have to be a 4 week sprint?

      Sam


    • Bob Schatz
      Hi Sam, I think you re getting some good feedback on your question. I just wanted to stress a couple of things. First, that the length of the sprint sometimes
      Message 2 of 19 , Feb 1, 2007
        Hi Sam,

        I think you're getting some good feedback on your question. I just
        wanted to stress a couple of things.

        First, that the length of the sprint sometimes is driven by the length
        of the project. So if a project is only 3 months long for example, we'd
        probably want to shorten the sprints to gain the opportunity for more
        feedback through sprint reviews. I see teams that have been doing Scrum
        for a while often try to shorten their sprints for the same reason.

        Second, it is important to stick with whatever sprint timebox you pick
        and be consistent. That helps set up the rhythm and flow that a team
        needs to establish in order to meet sprint goals. They get a feel for
        how they need orchestrate their activities in that time period. It does
        take some getting used to.

        Bob Schatz
        Agile Infusion, LLC
      • Jeff Martin
        We currently do 2 week sprints and it works great. Reading some of the other replies, I realize we ve had some issues that would justify a shorter sprint (PO
        Message 3 of 19 , Feb 27, 2007
          We currently do 2 week sprints and it works great.  Reading some of the other replies, I realize we've had some issues that would justify a shorter sprint (PO adding/changing things) and other issues that would justify a longer sprint (not enough feedback, not enough time to get complete features done at the beginning of the project).  I think 2 weeks is a happy medium.  I know we couldn't do 4 week sprints with our current PO.  I've often thought about trying 1 week sprints, especially during the "beta" period when we are fixing defects and making small changes to behavior.  I noticed at the end of our last project, we lost our rhythm because we couldn't really plan 2 weeks of work at a time because it was reactive work.


          From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sam Beckman
          Sent: Wednesday, January 31, 2007 10:31 AM
          To: scrumdevelopment@yahoogroups.com
          Subject: [scrumdevelopment] 4 Week vs 3 Week vs 2 Week Cycle

          Hi. I am new to scrum and am in the process of doing a trial run of it
          with my group. I have a question about the length of the sprint.

          Has anyone had success with a 2 week sprint or a 3 week sprint?

          Does it have to be a 4 week sprint?

          Sam

        • c_prokscha
          I have come from a development house that was doing 1 week sprints, we found this to be very inefficient as it was mandatory for developers to do a release
          Message 4 of 19 , Feb 27, 2007
            I have come from a development house that was doing 1 week sprints,
            we found this to be very inefficient as it was mandatory for
            developers to do a release after the week of dev work. Mind you the
            developers were not the best I have worked with.
            I did find that a 3 week sprint was a good medium as more dev work
            was pushed through and less stress on a weekly release of the beta
            software.
            In the end I would say it depends on the requirements and your
            deadlines as well as backlog.

            --- In scrumdevelopment@yahoogroups.com, "Jeff Martin" <jmartin@...>
            wrote:
            >
            > We currently do 2 week sprints and it works great. Reading some of
            the
            > other replies, I realize we've had some issues that would justify a
            > shorter sprint (PO adding/changing things) and other issues that
            would
            > justify a longer sprint (not enough feedback, not enough time to get
            > complete features done at the beginning of the project). I think 2
            > weeks is a happy medium. I know we couldn't do 4 week sprints with
            our
            > current PO. I've often thought about trying 1 week sprints,
            especially
            > during the "beta" period when we are fixing defects and making small
            > changes to behavior. I noticed at the end of our last project, we
            lost
            > our rhythm because we couldn't really plan 2 weeks of work at a time
            > because it was reactive work.
            >
            >
            > ________________________________
            >
            > From: scrumdevelopment@yahoogroups.com
            > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Sam Beckman
            > Sent: Wednesday, January 31, 2007 10:31 AM
            > To: scrumdevelopment@yahoogroups.com
            > Subject: [scrumdevelopment] 4 Week vs 3 Week vs 2 Week Cycle
            >
            >
            >
            > Hi. I am new to scrum and am in the process of doing a trial
            run
            > of it
            > with my group. I have a question about the length of the
            sprint.
            >
            > Has anyone had success with a 2 week sprint or a 3 week
            sprint?
            >
            > Does it have to be a 4 week sprint?
            >
            > Sam
            >
          • Adrian Howard
            ... [snip] Why was it inefficient? Why was doing a release hard? Adrian
            Message 5 of 19 , Feb 28, 2007
              On 28 Feb 2007, at 03:56, c_prokscha wrote:

              > I have come from a development house that was doing 1 week sprints,
              > we found this to be very inefficient as it was mandatory for
              > developers to do a release after the week of dev work. Mind you the
              > developers were not the best I have worked with.
              [snip]

              Why was it inefficient? Why was doing a release hard?

              Adrian
            • Chris Leslie
              Hi All Have you seen a relationship in sprint length and team skill levels agile knowledge. I understand shorter sprints (1-2 weeks) requiring smaller stories
              Message 6 of 19 , Feb 28, 2007
                Hi All

                Have you seen a relationship in sprint length and team skill levels\
                agile knowledge.

                I understand shorter sprints (1-2 weeks) requiring smaller stories
                (approx. half sprint length) whereas in longer sprints (3-4 weeks) your
                stories cold be bigger.

                For new teams does this not mean more effort\skill to break down
                epics\large stories for shorter sprints.

                Thanks in advance Chris
                PS any good references in breaking down epics into smaller stories ;-)
              • towardsunderstanding
                Chris wrote: I understand shorter sprints (1-2 weeks) requiring smaller stories (approx. half sprint length) whereas in longer sprints (3-4 weeks) your
                Message 7 of 19 , Feb 28, 2007
                  Chris wrote:

                  "I understand shorter sprints (1-2 weeks) requiring smaller stories
                  (approx. half sprint length) whereas in longer sprints (3-4 weeks) your
                  stories cold be bigger.

                  For new teams does this not mean more effort\skill to break down
                  epics\large stories for shorter sprints."

                  From my understanding (and I am not saying I am right, so correct me
                  if I am wrong), the iteration length should not effect the size of the
                  user stories.

                  From 'User Stories Applied', Mike Cohn says 'The ultimate
                  determination of whether a a story is appropriately sized is based on
                  the team, its capabilities, and the technologies in use.'

                  But I guess we must adapt the guidelines to fit our situations. Once
                  we start getting all up tight (like I am!) about the 'rules', the
                  process (i.e. Scrum/Agile/XP/whatever) loses its power...
                • Joseph Little
                  Hi all, A few comments from my experience. YMMV. Newer teams need 2 week sprints. A main reason (not mentioned recently) is the feedback cycles that occur at
                  Message 8 of 19 , Feb 28, 2007
                    Hi all,

                    A few comments from my experience. YMMV.

                    Newer teams need 2 week sprints. A main reason (not mentioned
                    recently) is the feedback cycles that occur at the end of each sprint.
                    In that regard, 1 week would be better, but I find that too short for
                    most new teams to get to done.

                    There is a strong argument for a monthly cycle. The nice thing about
                    2 weeks is that you have 2 of those cycles in a month (about).

                    3 weeks I find (a) too long for most new team...they can't estimate
                    what can go into 3 weeks well because it is so long, and (b) it does
                    not fit nicely into a monthly cycle.

                    Releasing. Almost always a problem. Almost always an important and
                    useful impediment to work on. "If it's hard, do it more often." ...an
                    adage that probably applies here. And use the releases to get
                    feedback (feedback requires taking action on it). We're not proposing
                    pain for pain's sake. The real definition of done is always something
                    like "released into production and we are getting the benefits from
                    it". Nothing like knowing you are done (and it works for sure).

                    Stories should be small, in any case. It should take 2-3 days for
                    part of the team to complete one story. Helps everyone to see that
                    flow. Yes, it does take some experience to slice the stories well.
                    With 2 week and smaller sprints, it is immediately clear why the small
                    stories help (they help in more ways than that).

                    Rules, rules, rules, rules. Ah. Do the best you can with the best
                    attitude the team can muster. Expect to be imperfect. Then inspect
                    and adapt. Re-read the rules. And improve. (A small number of rules
                    (eg, the very spare rules of Scrum) is useful if you all have the
                    right attitude toward them.)

                    Regards, Joe

                    Kitty Hawk Consulting
                    Charlotte, NC


                    --- In scrumdevelopment@yahoogroups.com, "towardsunderstanding"
                    <norris1976@...> wrote:
                    >
                    > Chris wrote:
                    >
                    > "I understand shorter sprints (1-2 weeks) requiring smaller stories
                    > (approx. half sprint length) whereas in longer sprints (3-4 weeks) your
                    > stories cold be bigger.
                    >
                    > For new teams does this not mean more effort\skill to break down
                    > epics\large stories for shorter sprints."
                    >
                    > From my understanding (and I am not saying I am right, so correct me
                    > if I am wrong), the iteration length should not effect the size of the
                    > user stories.
                    >
                    > From 'User Stories Applied', Mike Cohn says 'The ultimate
                    > determination of whether a a story is appropriately sized is based on
                    > the team, its capabilities, and the technologies in use.'
                    >
                    > But I guess we must adapt the guidelines to fit our situations. Once
                    > we start getting all up tight (like I am!) about the 'rules', the
                    > process (i.e. Scrum/Agile/XP/whatever) loses its power...
                    >
                  • Ron Jeffries
                    Hello, Chris. On Wednesday, February 28, 2007, at 8:41:35 AM, you ... Yes, just as making pyramids out of relatively small blocks of stone is more effort than
                    Message 9 of 19 , Feb 28, 2007
                      Hello, Chris. On Wednesday, February 28, 2007, at 8:41:35 AM, you
                      wrote:

                      > Have you seen a relationship in sprint length and team skill levels\
                      > agile knowledge.

                      > I understand shorter sprints (1-2 weeks) requiring smaller stories
                      > (approx. half sprint length) whereas in longer sprints (3-4 weeks) your
                      > stories cold be bigger.

                      > For new teams does this not mean more effort\skill to break down
                      > epics\large stories for shorter sprints.

                      Yes, just as making pyramids out of relatively small blocks of stone
                      is more effort than just carving one big block. Exactly where you
                      want it. Without flaw.

                      Ron Jeffries
                      www.XProgramming.com
                      Design is the thinking one does before, during, and after
                      implementation. It works best for me with a little up front, most of
                      it during implementation, and very little after it's too late.
                    • Pascal Thivent
                      Hi all, regarding the iteration size, RUP (which is more heavy on ceremonies) says something like your iteration should allow the team to implement at least a
                      Message 10 of 19 , Feb 28, 2007
                        Hi all,

                        regarding the iteration size, RUP (which is more heavy on ceremonies) says something like "your iteration should allow the team to implement at least a complete UC or UC scenario" (2 or 3 are better IMO). If I transpose this to SCRUM, I would say "your iteration should be long enough to allow the team to implement enough shippable items". And OFC, this depends on the team size, items size,  velocity...

                        Then, regarding long vs short sprints :
                         - short are good : "agile" (you can change your mind often), more feedback, less time spent doing a wrong thing...
                         - long are good : easier to recover from a problem, less overhead in ceremonies (sprint planning meeting, demo, retrospective)
                        I  don't spend too much time in analysing the ideal sprint length. Just choose a decent length (2 weeks seem to be a common length for agile methodologies) and start experimenting, then adapt if required.

                        And about the size of your items :
                         - too big = more risks to not complete an item, big items are more difficult to plan (over commitment or under commitment)
                         - too small = you're doing too much micromanagement
                        For these reasons, I think (and I may be wrong too) that the size of the iteration can impact the size of your items backlog and force you to review the breakdown.

                        On 2/28/07, towardsunderstanding <norris1976@...> wrote:

                        Chris wrote:

                        "I understand shorter sprints (1-2 weeks) requiring smaller stories
                        (approx. half sprint length) whereas in longer sprints (3-4 weeks) your
                        stories cold be bigger.

                        For new teams does this not mean more effort\skill to break down
                        epics\large stories for shorter sprints."

                        From my understanding (and I am not saying I am right, so correct me
                        if I am wrong), the iteration length should not effect the size of the
                        user stories.

                        From 'User Stories Applied', Mike Cohn says 'The ultimate
                        determination of whether a a story is appropriately sized is based on
                        the team, its capabilities, and the technologies in use.'

                        But I guess we must adapt the guidelines to fit our situations. Once
                        we start getting all up tight (like I am!) about the 'rules', the
                        process (i.e. Scrum/Agile/XP/whatever) loses its power...


                        --
                        Pascal
                      • Steven Gordon
                        ... Longer makes it harder to recover from a problem because the problem generally becomes bigger before you discover it is a problem. Also, with longer
                        Message 11 of 19 , Feb 28, 2007
                          On 2/28/07, Pascal Thivent <pascal@...> wrote:
                          >
                          > Hi all,
                          >
                          > regarding the iteration size, RUP (which is more heavy on ceremonies) says something like "your iteration should allow the team to implement at least a complete UC or UC scenario" (2 or 3 are better IMO). If I transpose this to SCRUM, I would say "your iteration should be long enough to allow the team to implement enough shippable items". And OFC, this depends on the team size, items size, velocity...
                          >
                          > Then, regarding long vs short sprints :
                          > - short are good : "agile" (you can change your mind often), more feedback, less time spent doing a wrong thing...
                          > - long are good : easier to recover from a problem, less overhead in ceremonies (sprint planning meeting, demo, retrospective)

                          Longer makes it harder to recover from a problem because the problem
                          generally becomes bigger before you discover it is a problem. Also,
                          with longer iterations, you tend to give a problem more time to fix
                          itself.

                          Longer just makes the meetings proportionally longer, so the overhead
                          ratio is the same either way, but it is much harder to schedule and
                          stay focussed in longer meetings than a shorter ones. This is
                          especially true when comparing a 4-hour sprint planning meeting to a
                          2-hour one.

                          I see absolutely no advantage to sprints being longer than 2 weeks in practice.

                          > I don't spend too much time in analysing the ideal sprint length. Just choose a decent length (2 weeks seem to be a common length for agile methodologies) and start experimenting, then adapt if required.
                          >
                          > And about the size of your items :
                          > - too big = more risks to not complete an item, big items are more difficult to plan (over commitment or under commitment)
                          > - too small = you're doing too much micromanagement
                          > For these reasons, I think (and I may be wrong too) that the size of the iteration can impact the size of your items backlog and force you to review the breakdown.
                          >
                          >
                        Your message has been successfully submitted and would be delivered to recipients shortly.