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

RE: [scrumdevelopment] Requirements Changes

Expand Messages
  • 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 1 of 4 , Mar 1, 2004
      Thanks to all who have shared their thoughts on this.
      I really appreciate your input.


      --- 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
    Your message has been successfully submitted and would be delivered to recipients shortly.