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

Re: [scrumdevelopment] Alternatives to Canceling and Re-Doing Scrum

Expand Messages
  • 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 1 of 11 , May 9 4:20 PM
    • 0 Attachment
       
      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.