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

RE: [scrumdevelopment] Requirements Changes

Expand Messages
  • Mike Cohn
    Here s a trivial little tip that helps avoid abnormally terminating a sprint (or having bad feelings about what did/didn t get done in a sprint): I used to ask
    Message 1 of 4 , Mar 1, 2004
    • 0 Attachment
      Here's a trivial little tip that helps avoid abnormally terminating a sprint
      (or having bad feelings about what did/didn't get done in a sprint):

      I used to ask the Product Owner(s): "Is there anything else you can think of
      you might need in this sprint?" Particularly common for interally-used
      software or websites (rather than commercial software) would be the need to
      launch a new client (perhaps needing a new web style sheet, moving data from
      a staging environment or something relatively minor). Say the sprint we're
      starting ends 3/31. The Product thinks through March and says "Nope." She
      says "nope" because the next client launch is really 4/7--clearly not needed
      this sprint. She'll just ask for it next sprint. But, uh-oh, the next sprint
      won't be done in time.

      Product Owners really need to think about things they need in the next
      sprint PLUS in the (next sprint - 1 day). Effectively, two sprints ahead.

      Now, instead of asking "Is there anything else you can think of you might
      need in this sprint?" I ask "Is there anything you need before the end of
      the sprint after this one." And often give a date to make it clear.

      A minor change but one that's saved me too many times to count.

      -Mike

      -----Original Message-----
      From: David A Barrett [mailto:dave.barrett@...]
      Sent: Monday, March 01, 2004 12:19 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Requirements Changes





      >Therefore, my question is what
      >happens if there are genuine requirements changes that must be
      >incorporated in the current sprint? Will Scrum allow the sprint
      >backlog to be changed? If not, how is this situation handled? Will
      >some items from the current sprint be tossed out (for now)?

      H,

      Although I'm a Scrum newbie, I'll try to answer this and more experience
      people can correct me if I'm way off base:

      I'm assuming that this is one of those "getting your mind wrapped around
      the concept" questions. This is a big problem with tradional development
      methodologies, but is probably very rare when Scrum is applied
      appropriately.

      Generally, the Product Backlog items are expressed generally enough to
      allow some latittude with specific requirements within the sprint. For
      instance, a Product Backlog item might be, "Customer Inquiry Screen" with
      an understanding that there will be enough functionality to be useful, but
      very little in regards to specific specifications. The Sprint Backlog
      items will be more detailed, but there is room to move within these.

      Second, the 30 day length of the sprint tends to minimize these changes
      impacting the current sprint. Then the question for changes becomes, "Are
      these so important they can't wait two weeks (or one week, or three weeks)
      until the end of the sprint?" The whole "Inspect and Adjust" cycle at the
      end of the sprint also tends to minimize the number of changes that happen
      early in the sprint.

      If the answer to the question above is yes, then you can "abnormally
      terminate" the sprint. Everyone stops working, all WIP is thrown out,
      nothing is delivered and there is a Sprint Review meeting the next day.
      Customers are given a choice, "Are these changes so important you are
      willing to throw out all of the work that has been done in the sprint so
      far?"

      This makes sense to me. The time period of the sprint is small enough that
      the team can commit to completing what they've agreed to do, and the
      customers can commit to leaving the team alone to do their work. If the
      customer's can't (or aren't willing) to put the required thought into
      prioritiztion process at the beginning of the sprint, they'll get hit with
      an abnormal termination of sprint. On the other hand, there are very few
      businesses that move so fast that the 30 day sprint process isn't agile
      enough to handle real shifting requirements. On those occasions that they
      do, then the best move is start the sprint over from scratch. If this
      persists, then perhaps the sprints should be shortened so that they can
      complete before the business issues can change.

      The worse thing you can do is to fiddle the Product Backlog covered by the
      sprint during the sprint.

      Dave Barrett



      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Harprit S. Grewal
      Thanks to all who have shared their thoughts on this. I really appreciate your input. Regards, Harprit ... Here s a trivial little tip that helps avoid ...
      Message 2 of 4 , Mar 1, 2004
      • 0 Attachment
        Thanks to all who have shared their thoughts on this.
        I really appreciate your input.

        Regards,
        Harprit

        --- Mike Cohn <mike@...> wrote: >
        Here's a trivial little tip that helps avoid
        > abnormally terminating a sprint
        > (or having bad feelings about what did/didn't get
        > done in a sprint):
        >
        > I used to ask the Product Owner(s): "Is there
        > anything else you can think of
        > you might need in this sprint?" Particularly common
        > for interally-used
        > software or websites (rather than commercial
        > software) would be the need to
        > launch a new client (perhaps needing a new web style
        > sheet, moving data from
        > a staging environment or something relatively
        > minor). Say the sprint we're
        > starting ends 3/31. The Product thinks through March
        > and says "Nope." She
        > says "nope" because the next client launch is really
        > 4/7--clearly not needed
        > this sprint. She'll just ask for it next sprint.
        > But, uh-oh, the next sprint
        > won't be done in time.
        >
        > Product Owners really need to think about things
        > they need in the next
        > sprint PLUS in the (next sprint - 1 day).
        > Effectively, two sprints ahead.
        >
        > Now, instead of asking "Is there anything else you
        > can think of you might
        > need in this sprint?" I ask "Is there anything you
        > need before the end of
        > the sprint after this one." And often give a date to
        > make it clear.
        >
        > A minor change but one that's saved me too many
        > times to count.
        >
        > -Mike
        >
        > -----Original Message-----
        > From: David A Barrett
        > [mailto:dave.barrett@...]
        > Sent: Monday, March 01, 2004 12:19 PM
        > To: scrumdevelopment@yahoogroups.com
        > Subject: [scrumdevelopment] Requirements Changes
        >
        >
        >
        >
        >
        > >Therefore, my question is what
        > >happens if there are genuine requirements changes
        > that must be
        > >incorporated in the current sprint? Will Scrum
        > allow the sprint
        > >backlog to be changed? If not, how is this
        > situation handled? Will
        > >some items from the current sprint be tossed out
        > (for now)?
        >
        > H,
        >
        > Although I'm a Scrum newbie, I'll try to answer this
        > and more experience
        > people can correct me if I'm way off base:
        >
        > I'm assuming that this is one of those "getting your
        > mind wrapped around
        > the concept" questions. This is a big problem with
        > tradional development
        > methodologies, but is probably very rare when Scrum
        > is applied
        > appropriately.
        >
        > Generally, the Product Backlog items are expressed
        > generally enough to
        > allow some latittude with specific requirements
        > within the sprint. For
        > instance, a Product Backlog item might be, "Customer
        > Inquiry Screen" with
        > an understanding that there will be enough
        > functionality to be useful, but
        > very little in regards to specific specifications.
        > The Sprint Backlog
        > items will be more detailed, but there is room to
        > move within these.
        >
        > Second, the 30 day length of the sprint tends to
        > minimize these changes
        > impacting the current sprint. Then the question for
        > changes becomes, "Are
        > these so important they can't wait two weeks (or one
        > week, or three weeks)
        > until the end of the sprint?" The whole "Inspect
        > and Adjust" cycle at the
        > end of the sprint also tends to minimize the number
        > of changes that happen
        > early in the sprint.
        >
        > If the answer to the question above is yes, then you
        > can "abnormally
        > terminate" the sprint. Everyone stops working, all
        > WIP is thrown out,
        > nothing is delivered and there is a Sprint Review
        > meeting the next day.
        > Customers are given a choice, "Are these changes so
        > important you are
        > willing to throw out all of the work that has been
        > done in the sprint so
        > far?"
        >
        > This makes sense to me. The time period of the
        > sprint is small enough that
        > the team can commit to completing what they've
        > agreed to do, and the
        > customers can commit to leaving the team alone to do
        > their work. If the
        > customer's can't (or aren't willing) to put the
        > required thought into
        > prioritiztion process at the beginning of the
        > sprint, they'll get hit with
        > an abnormal termination of sprint. On the other
        > hand, there are very few
        > businesses that move so fast that the 30 day sprint
        > process isn't agile
        > enough to handle real shifting requirements. On
        > those occasions that they
        > do, then the best move is start the sprint over from
        > scratch. If this
        > persists, then perhaps the sprints should be
        > shortened so that they can
        > complete before the business issues can change.
        >
        > The worse thing you can do is to fiddle the Product
        > Backlog covered by the
        > sprint during the sprint.
        >
        > Dave Barrett
        >
        >
        >
        > To Post a message, send it to:
        > scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >





        ___________________________________________________________
        Yahoo! Messenger - Communicate instantly..."Ping"
        your friends today! Download Messenger Now
        http://uk.messenger.yahoo.com/download/index.html
      Your message has been successfully submitted and would be delivered to recipients shortly.