RE: [scrumdevelopment] Requirements Changes
- 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.
> -----Original Message-----
> From: David A Barrett
> Sent: Monday, March 01, 2004 12:19 PM
> To: email@example.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)?
> 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
> 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
> 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:
> To Unsubscribe, send a blank message to:
> Yahoo! Groups Links
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now