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

Re: What constitutes "New Work" druing a Sprint?

Expand Messages
  • chris poulton
    Thanks for the input Alan. You are absolutely correct in that the team is committing to a set of product backlog items for the sprint and not a set of tasks.
    Message 1 of 3 , Feb 23, 2009
    • 0 Attachment
      Thanks for the input Alan. You are absolutely correct in that the
      team is committing to a set of product backlog items for the sprint
      and not a set of tasks. That's a great way to think about it and
      remind ourselves of the implied flexibility.

      To clarify:

      "User Stories/Product Backlog Descriptions"
      We do not have User Stories but do have Product Backlog descriptions
      that are expanded during our planning sessions to better articulate
      the scope of a feature. The difficulty this causes (in my opinion) is
      that requirements may be more easily missed since the feature
      descriptions may not be as well thought through given the format.

      "What does the team say?"
      The team has been willing to accommodate the "New Work" requests due
      mostly to the fact that we're in our last Sprint before a release
      Sprint and they are trying to absorb that which is necessary to best
      complete the product.

      Again, thanks for the input. This is exactly the sort of thing I was
      looking for.


      --- In scrumdevelopment@yahoogroups.com, Alan Dayley <alandd@...>
      > Remember that in the sprint planning the team is committing to a
      > particular set of stories, not a list of tasks. If the tasks change
      > under the stories, that's OK, IF the tasks are changing to enable
      > committed stories to complete. If a change in tasks reflects a
      > in the sprint backlog of stories, that is "new work."
      > Given the above definition I would judge...
      > 1) Is a bug because it is an incomplete feature from a story in a
      > prior sprint. It is "new work" for the current sprint since it is
      > directly related to the current sprint backlog.
      > 2) This is just a task shift in the current sprint since it is
      > directly related to the currently committed sprint backlog.
      > I am a bit confused about your statement that "user stories are
      > non-existent." It sounds like you have a backlog of feature
      > descriptions. These are your "stories" even if they are not written
      > in a story-like format.
      > As for when to work on these items, I'd say the default rules would
      > be: Add 1) to the Product Backlog for consideration in the next
      > and 2) is part of the current sprint so just do it now. Obviously
      > these default directions may be adjusted by the team and
      > circumstances. For example, if the bug in 1) is blocking progress
      > the current sprint, it may need to be addressed immediately.
      > What does the team say about all this?
      > On Mon, Feb 23, 2009 at 1:38 PM, chris poulton <cpoulton@...> wrote:
      > > Looking for a little direction regarding the practical application
      > > controlling subtle "New Work" requests (noise) during a Sprint.
      > > obvious request from someone outside the team to "Squeeze this in"
      > > the current Sprint isn't the issue. It's the more subtle issues
      > > arise when a requirement was missed and isn't discovered until
      > > testing. Let's consider two examples. What of the following
      > > you consider to be "New Work" and therefore a candidate for a
      > > Backlog Item (or Bug) vs. something that would be added to the
      > > Sprint backlog?
      > >
      > > 1) A missed requirement for a feature completed in a prior Sprint
      > > within the same release?
      > >
      > > 2) A missed requirement for a feature under development in the
      > > Sprint?
      > >
      > > *Consider also that user stories are non-existent and feature
      > > descriptions and definitions are identified up front. Further
      > > may occur during the Sprint as needed (usually screen mock-ups and
      > > further discussion).
      > >
      > > For either of both of these scenarios, is it
      > > possible/allowable/practical to have the team consider and absorb
      > > these items as non-critical items for the current sprint?
      > > they don't have to be completed or even worked on during the
      > > Sprint if there isn't time? What happens if this work isn't
      > > during the current Sprint? ...does it then become a product
      > > item?
      > >
      > > I guess what I'm struggling a bit with is finding that balance
      > > going strictly by the book and practical application.
      > > anyone?
      > >
      > > Thanks in advance for any comments.
      > >
      > > chris
      > >
      > >
      > >
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to: scrumdevelopment@...
      > > To Unsubscribe, send a blank message to: scrumdevelopment-
      unsubscribe@...! Groups Links
      > >
      > >
      > >
      > >
    Your message has been successfully submitted and would be delivered to recipients shortly.