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

Alternatives to Canceling and Re-Doing Scrum

Expand Messages
  • furashgf
    I m sure this is obvious and I m dumb for not finding it via Google or remembering it from Ken s book, but... Consider the following two situations: 1. you
    Message 1 of 11 , May 4, 2007
      I'm sure this is obvious and I'm dumb for not finding it via Google
      or remembering it from Ken's book, but...

      Consider the following two situations:

      1. you EXPECT a given amount of bug fixing, ad hoc reports, or
      something. This stuff isn't known during sprint planning, is of high
      value to the business, and won't be known by the business until it
      becomes an emergency. You have no other resources to apply to this.

      2. users, product owners, etc. have given you as much info as they
      can, but, invariably, when they see the results of your work (or
      while you work with them an they test), stuff comes up - oh, it needs
      to do X, it needs to do Y. Some of this stuff will BLOW PAST THE
      INITIAL ESTIMATES. You can't just toss it in the feature list for
      the future, because it might be critical for actually making the
      feature usable.

      It seems like overkill to cancel and redo the scrum every 3 days to
      handle this stuff. Is there any reason you couldn't plan a
      bucket/budget for handling this kind of stuff.

      I'd guess over time it would wash out, as yesterday's weather (sprint
      velocity) would gradually make you put fewer and fewer tasks in the
      bucket to accommodate 1 and 2 allowances.

      Thanks! :-)
    • Jeffrey Faust
      The goal is to build incrementally. When the sprint is complete, the feature/story does not have to be in its final state. It only has to satisfy the story.
      Message 2 of 11 , May 4, 2007
        The goal is to build incrementally. When the sprint is complete, the
        feature/story does not have to be in its final state. It only has to
        satisfy the story. Why can't the stuff that comes up be backlogged to
        be handled with the next sprint?

        You can't expect the team to re-commit mid-sprint. The external
        pressure to accept added responsibility will put the sprint at greater
        risk of over-commitment. The scrum master and product owner should work
        together to keep these external pressures at bay.

        If I had to, I would guess that your sprints are too long for the
        environment you work in. The longer they are, the harder it is to hold
        off external pressures.

        Jeff

        furashgf wrote:
        >
        > I'm sure this is obvious and I'm dumb for not finding it via Google
        > or remembering it from Ken's book, but...
        >
        > Consider the following two situations:
        >
        > 1. you EXPECT a given amount of bug fixing, ad hoc reports, or
        > something. This stuff isn't known during sprint planning, is of high
        > value to the business, and won't be known by the business until it
        > becomes an emergency. You have no other resources to apply to this.
        >
        > 2. users, product owners, etc. have given you as much info as they
        > can, but, invariably, when they see the results of your work (or
        > while you work with them an they test), stuff comes up - oh, it needs
        > to do X, it needs to do Y. Some of this stuff will BLOW PAST THE
        > INITIAL ESTIMATES. You can't just toss it in the feature list for
        > the future, because it might be critical for actually making the
        > feature usable.
        >
        > It seems like overkill to cancel and redo the scrum every 3 days to
        > handle this stuff. Is there any reason you couldn't plan a
        > bucket/budget for handling this kind of stuff.
        >
        > I'd guess over time it would wash out, as yesterday's weather (sprint
        > velocity) would gradually make you put fewer and fewer tasks in the
        > bucket to accommodate 1 and 2 allowances.
        >
        > Thanks! :-)
        >
        >
      • Ryan Cooper
        Have you found that this sometimes means finishing the sprint with something that is not considered (by the P.O.) to be potentially shippable ? I have had
        Message 3 of 11 , May 4, 2007
          Have you found that this sometimes means finishing the sprint with something that is not considered (by the P.O.) to be "potentially shippable"? I have had this experience, and it has been a challenge to deal with. In these cases, we have moved other stories off the sprint backlog or postponed the whole feature in question to a later iteration. (And then, in our retrospective, address why the change in scope became visible after the iteration started.)

          Have others experienced this situation? How did you address it?

          Thanks,
          Ryan

          On 5/4/07, Jeffrey Faust < jeff@...> wrote:

          The goal is to build incrementally. When the sprint is complete, the
          feature/story does not have to be in its final state. It only has to
          satisfy the story. Why can't the stuff that comes up be backlogged to
          be handled with the next sprint?

          <snip>

          _

        • Jeffrey Faust
          You do learn things as you go, and the POs vision of the feature/story may change during the sprint. Rarely, in my experience, does this correspond to the
          Message 4 of 11 , May 4, 2007
            You do learn things as you go, and the POs vision of the feature/story
            may change during the sprint. Rarely, in my experience, does this
            correspond to the sprint implementation being incorrect. In other
            words, it has value even though it's not intended to be the final
            customer version. The value is the knowledge earned, the feedback
            generated, and the new stories created.

            I see "potentially shippable" as being something that stands up to
            internal quality and documentation.

            Now, I think it reasonable that the team takes small changes of
            direction as they learn. However, micro-iterating on requirements
            within a sprint can lead to something that is difficult to test and
            document by the end of the sprint.

            Those items that are high risk, that the original vision/stroy may in
            fact be wrong, should probably be spiked (time-boxed R&D).

            Jeff

            Ryan Cooper wrote:
            >
            > Have you found that this sometimes means finishing the sprint with
            > something that is not considered (by the P.O.) to be "potentially
            > shippable"? I have had this experience, and it has been a challenge to
            > deal with. In these cases, we have moved other stories off the sprint
            > backlog or postponed the whole feature in question to a later
            > iteration. (And then, in our retrospective, address why the change in
            > scope became visible after the iteration started.)
            >
            > Have others experienced this situation? How did you address it?
            >
          • Ryan Cooper
            Hi Jeffrey; I generally base my definition of potentially shippable on 2 criteria: 1) are we willing to ship it? (does the product meet our quality
            Message 5 of 11 , May 4, 2007
              Hi Jeffrey;

              I generally base my definition of "potentially shippable" on 2 criteria:

              1) are we willing to ship it? (does the product meet our quality standards?)
              2) is the customer/P.O. willing to ship it?

              Often in cases when our understanding of a story changed drastically within an iteration, the answer to number 2 became "Hell no!"

              Is it unusual to take the phrase "potentially shippable" so literally?

              Cheers,
              Ryan

              On 5/4/07, Jeffrey Faust <jeff@...> wrote:

              snip

               

              I see "potentially shippable" as being something that stands up to
              internal quality and documentation.

              snip


            • Jeffrey Faust
              Ryan, I think the only way to achieve your criteria in one sprint is to have full understanding up front, requiring a large requirements effort. Scrum avoids
              Message 6 of 11 , May 4, 2007
                Ryan,

                I think the only way to achieve your criteria in one sprint is to have
                full understanding up front, requiring a large requirements effort.
                Scrum avoids this large, and sometimes futile, effort by iterating. I
                don't see criteria #2 working in general. The rule is to define the
                sprint and then get out of the way of the team. If the team delivers
                what you asked for, with internal standards all satisfied, it's a success.

                Jeff

                Ryan Cooper wrote:
                >
                > Hi Jeffrey;
                >
                > I generally base my definition of "potentially shippable" on 2 criteria:
                >
                > 1) are we willing to ship it? (does the product meet our quality
                > standards?)
                > 2) is the customer/P.O. willing to ship it?
                >
                > Often in cases when our understanding of a story changed drastically
                > within an iteration, the answer to number 2 became "Hell no!"
                >
                > Is it unusual to take the phrase "potentially shippable" so literally?
                >
                > Cheers,
                > Ryan
                >
              • Ryan Cooper
                Hi Jeff; I disagree. In my experience, sometimes it is possible to deliver reduced/different functionality than the original sprint goal/backlog, by dropping
                Message 7 of 11 , May 4, 2007
                  Hi Jeff;

                  I disagree. In my experience, sometimes it is possible to deliver reduced/different functionality than the original sprint goal/backlog, by dropping the story who's scope has changed drastically. Whether this is preferable is another question. :)

                  There is a tradeoff here. One choice (plow forward and deliver something that may not be really shippable) emphasizes productivity (or perceived productivity, depending on who you ask). The other choice emphasizes the integrity of the 'definition of done'. Which of those is more important is a judgment call. (Perhaps we are emphasizing the wrong details, since what we do in the retrospective, and how we move forward, is more important than what we do in a particular sprint. Maybe this is why Ken suggests terminating an abnormal sprint.)

                  I'd really like to hear from the rest of the scrum community on this topic. Do you prefer one of these two approaches, or another one entirely? Is it "un-Scrum" to suggest alternatives to terminating an abnormal sprint? Does the situation we describe qualify as an abnormal sprint? I think this is one of the areas where teams have the most trouble doing Scrum "by the book".

                  Cheers,
                  Ryan


                  On 5/4/07, Jeffrey Faust <jeff@...> wrote:

                  Ryan,

                  I think the only way to achieve your criteria in one sprint is to have
                  full understanding up front, requiring a large requirements effort.
                  Scrum avoids this large, and sometimes futile, effort by iterating. I
                  don't see criteria #2 working in general. The rule is to define the
                  sprint and then get out of the way of the team. If the team delivers
                  what you asked for, with internal standards all satisfied, it's a success.

                  Jeff

                  Ryan Cooper wrote:
                  >
                  > Hi Jeffrey;
                  >
                  > I generally base my definition of "potentially shippable" on 2 criteria:
                  >
                  > 1) are we willing to ship it? (does the product meet our quality
                  > standards?)
                  > 2) is the customer/P.O. willing to ship it?
                  >
                  > Often in cases when our understanding of a story changed drastically
                  > within an iteration, the answer to number 2 became "Hell no!"
                  >
                  > Is it unusual to take the phrase "potentially shippable" so literally?
                  >
                  > Cheers,
                  > Ryan
                  >


                • Hunt Sparra
                  I think potentially shippable means different things to different organizations. Your interpretation is the ideal, but most organizations are not at that
                  Message 8 of 11 , May 4, 2007
                    I think "potentially shippable" means different things to different
                    organizations. Your interpretation is the ideal, but most organizations
                    are not at that point. Other issues also intrude on the "willing to
                    ship" part. Depending on the domain, shipping small increments may not
                    make sense. I am guessing imbedded systems type work may fall in this
                    area. Domains that have large user populations that must be trained also
                    tend to be unwilling to ship small increments due to training costs and
                    churn. Many organizations may start with "Done" being passing all systen
                    tests and then slowly progress over time to a more ideal condition.

                    It sounds to me like at least 2 of the problems might be:
                    1. The items in the Product Backlog are at the wrong level for the team
                    to effectively size. There are obviously key components missing. Can you
                    try smaller stories? Another option would be more upfront supporting
                    information for the story such as screen mockups, business workflow,
                    etc. I would go for smaller items in the backlog first if possible. Does
                    each item in the Backlog, at least those that might be worked on in the
                    next sprint, have conditions of acceptance? Conditions of acceptance can
                    really clear up what is really being requested. It is ok for the team to
                    say there is not enough information to estimate a story/feature, or that
                    the story/feature is to large to estimate with any confidence. During a
                    sprint, is a small percent, 5%-10%, of the developers time allocated to
                    helping the Product Owner get the highest priority items in good,
                    estimatable condition? Only the team estimates. If the Team cannot
                    estimate the items about to be worked on, then they need to reject those
                    items until more information is available. If the item is important, it
                    should not take long. The key is for the Team and the Product Owner to
                    work together to the backlog item into a state that is ready for work.

                    2. The size of what the customer wants shipped is larger than your
                    organization can effectively produce within a single sprint. I would say
                    this is the norm for most business spaces. Is this new for your
                    organization? Was your new organization shipping new product every 3-4
                    weeks before? There is nothing in Scrum that says you have to ship at
                    the end of each sprint. That is at least one reason why there is also a
                    Release Plan.

                    The key is to reliable deliver a functional piece of software and all
                    supporting components by the end of the sprint. Perhaps what is
                    delivered does not yet have enough benefit to ship, but it does have
                    value. Some, no make that many, people expect production ready software
                    to be as quick as some simple hack that only handles the ideal case.
                    Part of the Scrum Master's job is to educate these people. Your
                    organization can always lower quality standards. Lowering quality is
                    what has traditionally been done in software development.

                    --- In scrumdevelopment@yahoogroups.com, "Ryan Cooper"
                    <ryan.p.cooper@...> wrote:
                    >
                    > Hi Jeffrey;
                    >
                    > I generally base my definition of "potentially shippable" on 2
                    criteria:
                    >
                    > 1) are we willing to ship it? (does the product meet our quality
                    standards?)
                    > 2) is the customer/P.O. willing to ship it?
                    >
                    > Often in cases when our understanding of a story changed drastically
                    within
                    > an iteration, the answer to number 2 became "Hell no!"
                    >
                    > Is it unusual to take the phrase "potentially shippable" so literally?
                    >
                    > Cheers,
                    > Ryan
                    >
                    > On 5/4/07, Jeffrey Faust jeff@... wrote:
                    > >
                    > > snip
                    > >
                    >
                    >
                    > I see "potentially shippable" as being something that stands up to
                    > > internal quality and documentation.
                    > >
                    > > snip
                    > >
                    >
                  • Jeffrey Faust
                    Ryan, My dogmatism is tempered with pragmatism. The final goal is delivering what the customer wants, on time, and on budget. We all learn as we go, and
                    Message 9 of 11 , May 4, 2007
                      Ryan,

                      My dogmatism is tempered with pragmatism. The final goal is delivering
                      what the customer wants, on time, and on budget. We all learn as we go,
                      and flexibility is important. We regularly change things as we go, as
                      long as the overall sprint goal is met. However, such changes should be
                      accepted by the team, and should be simple enough not to require a re-plan.

                      I would also like to hear from others.

                      Jeff

                      Ryan Cooper wrote:
                      >
                      > Hi Jeff;
                      >
                      > I disagree. In my experience, sometimes it is possible to deliver
                      > reduced/different functionality than the original sprint goal/backlog,
                      > by dropping the story who's scope has changed drastically. Whether
                      > this is preferable is another question. :)
                      >
                      > There is a tradeoff here. One choice (plow forward and deliver
                      > something that may not be really shippable) emphasizes productivity
                      > (or perceived productivity, depending on who you ask). The other
                      > choice emphasizes the integrity of the 'definition of done'. Which of
                      > those is more important is a judgment call. (Perhaps we are
                      > emphasizing the wrong details, since what we do in the retrospective,
                      > and how we move forward, is more important than what we do in a
                      > particular sprint. Maybe this is why Ken suggests terminating an
                      > abnormal sprint.)
                      >
                      > I'd really like to hear from the rest of the scrum community on this
                      > topic. Do you prefer one of these two approaches, or another one
                      > entirely? Is it "un-Scrum" to suggest alternatives to terminating an
                      > abnormal sprint? Does the situation we describe qualify as an abnormal
                      > sprint? I think this is one of the areas where teams have the most
                      > trouble doing Scrum "by the book".
                      >
                      > Cheers,
                      > Ryan
                      >
                    • petriheiramo
                      Hi, ... While there are certainly some obvious things, I don t think this is one. :) ... While not a text book example, I ve recommended teams to reserve an
                      Message 10 of 11 , May 7, 2007
                        Hi,


                        > I'm sure this is obvious and I'm dumb for not finding it via Google
                        > or remembering it from Ken's book, but...

                        While there are certainly some obvious things, I don't think this is
                        one. :)

                        > 1. you EXPECT a given amount of bug fixing, ad hoc reports, or
                        > something. This stuff isn't known during sprint planning, is of high
                        > value to the business, and won't be known by the business until it
                        > becomes an emergency. You have no other resources to apply to this.

                        While not a text book example, I've recommended teams to reserve an
                        appropriate % of their time to these ad-hoc tasks, and then track them
                        (and the time spent on them) in daily scrums. The rest of the time is
                        spent on planned work. Since this situation is not optimal, I also
                        encourage the team to seek ways in which this ad-hoc work _could_ be
                        transferred to product backlog and handled in sprint planning, in
                        order to reduce the % of time needed for this. It may also be wise to
                        set up a cap for the time spent on the support tasks, and prioritize
                        stricter when the cap is nearing.

                        It is important to recognize the nature of the ad-hoc work.
                        - If it's errors from previous sprints, the team has a quality
                        problem. That should be adressed by the team.
                        - If it's from external testing etc., the team should try to seek ways
                        in which it could integrate/test at least some of that work in the
                        sprint cycle (i.e. expand the definition of done).
                        - If it's new requirements, communicate with the product owner so that
                        they would be put to product backlog. If that is not possible, then
                        something else should be taken out of the sprint.
                        - If it's truly out of the team's hands, they probably should try to
                        talk to the product owner so that person can act to reduce the amount
                        of ad-hoc work.

                        IMHO, terminating a sprint is a very powerful (and harmful) operation,
                        and should be used only when the benefits clearly outweigh the costs
                        (unfinished work, ruined work optimization, wasted planning effort, etc.).

                        > 2. users, product owners, etc. have given you as much info as they
                        > can, but, invariably, when they see the results of your work (or
                        > while you work with them an they test), stuff comes up - oh, it needs
                        > to do X, it needs to do Y. Some of this stuff will BLOW PAST THE
                        > INITIAL ESTIMATES. You can't just toss it in the feature list for
                        > the future, because it might be critical for actually making the
                        > feature usable.

                        This is just something that you sometimes learn. I'd have the team
                        communicate with the product owner and suggest something they _could_
                        deliver, and have the product owner approve the scope change. If this
                        "something" is major enough to warrant terminating the sprint and
                        replanning, then maybe the team should suggest that to the product owner.

                        > It seems like overkill to cancel and redo the scrum every 3 days to
                        > handle this stuff. Is there any reason you couldn't plan a
                        > bucket/budget for handling this kind of stuff.

                        For case 1, I'd recommend wise use of the bucket, but case 2 is not
                        "bucketable". It's simply an unexpected, unforeseen discovery and you
                        have to handle it there and then; accounting for such changes in
                        sprint planning would mean adding "waste" into the sprints and should
                        therefore be avoided. And if it's not "unexpected, unforeseen", it's
                        an identified risk and should be accounted for in sprint planning,
                        just like any other risk would be.

                        > I'd guess over time it would wash out, as yesterday's weather (sprint
                        > velocity) would gradually make you put fewer and fewer tasks in the
                        > bucket to accommodate 1 and 2 allowances.

                        Exactly, and that could be one focus issue in sprint retrospectives. :)


                        Petri Heiramo
                        Process Improvement Manager
                        SYSOPENDIGIA Plc., Finland
                      • Nicholas Cancelliere
                        The goal of any project plan is predictability. Scrum provides this through the use of velocity and sprints (fixed time-boxed cycles). If you are spending X
                        Message 11 of 11 , May 9, 2007
                           
                          The goal of any project plan is predictability.  Scrum provides this through the use of velocity and sprints (fixed time-boxed cycles).  If you are spending X hrs every iteration fixing bugs and other things - you don't need to schedule a bucket for this.  This time inevitably encroaches on the time you spend on features.  Thus velocity will reflect this, and then your planning.  In short - you are still able to predict accurately what can be accomplished each sprint.
                           
                          You don't abort your sprints every time you hit a road-bump.  You only abort and re-plan when the goal of what your working towards has completely changed.  For example the goal originally for your sprint was to enhance the shopping cart, but now the business needs a new search engine -- well stop working on the shopping cart sprint.  (That's when you abort.)
                           
                          Nicholas
                           
                           
                           
                          On 5/4/07, furashgf <furashg@...> wrote:

                          I'm sure this is obvious and I'm dumb for not finding it via Google
                          or remembering it from Ken's book, but...

                          Consider the following two situations:

                          1. you EXPECT a given amount of bug fixing, ad hoc reports, or
                          something. This stuff isn't known during sprint planning, is of high
                          value to the business, and won't be known by the business until it
                          becomes an emergency. You have no other resources to apply to this.

                          2. users, product owners, etc. have given you as much info as they
                          can, but, invariably, when they see the results of your work (or
                          while you work with them an they test), stuff comes up - oh, it needs
                          to do X, it needs to do Y. Some of this stuff will BLOW PAST THE
                          INITIAL ESTIMATES. You can't just toss it in the feature list for
                          the future, because it might be critical for actually making the
                          feature usable.

                          It seems like overkill to cancel and redo the scrum every 3 days to
                          handle this stuff. Is there any reason you couldn't plan a
                          bucket/budget for handling this kind of stuff.

                          I'd guess over time it would wash out, as yesterday's weather (sprint
                          velocity) would gradually make you put fewer and fewer tasks in the
                          bucket to accommodate 1 and 2 allowances.

                          Thanks! :-)




                          --
                          Nicholas Cancelliere, Austin TX
                          "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                        Your message has been successfully submitted and would be delivered to recipients shortly.