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

Re: 4 Week vs 3 Week vs 2 Week Cycle

Expand Messages
  • 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 1 of 19 , Feb 28, 2007
    • 0 Attachment
      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 2 of 19 , Feb 28, 2007
      • 0 Attachment
        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 3 of 19 , Feb 28, 2007
        • 0 Attachment
          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 4 of 19 , Feb 28, 2007
          • 0 Attachment
            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 5 of 19 , Feb 28, 2007
            • 0 Attachment
              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 6 of 19 , Feb 28, 2007
              • 0 Attachment
                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.