Re: What constitutes "New Work" druing a Sprint?
- 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.
"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
--- In firstname.lastname@example.org, 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 achange
> in the sprint backlog of stories, that is "new work."not
> 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.sprint
> 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. Obviouslyin
> 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.of
> 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.The
> > obvious request from someone outside the team to "Squeeze this in"to
> > the current Sprint isn't the issue. It's the more subtle issuesthat
> > arise when a requirement was missed and isn't discovered untilunit
> > testing. Let's consider two examples. What of the followingwould
> > you consider to be "New Work" and therefore a candidate for aProduct
> > Backlog Item (or Bug) vs. something that would be added to thecurrent
> > Sprint backlog?current
> > 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?design
> > *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...meaning
> > 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 thecurrent
> > Sprint if there isn't time? What happens if this work isn'tcompleted
> > during the current Sprint? ...does it then become a productbacklog
> > item?between
> > I guess what I'm struggling a bit with is finding that balance
> > going strictly by the book and practical application....thoughts
> > anyone?unsubscribe@...! Groups Links
> > Thanks in advance for any comments.
> > chris
> > ------------------------------------
> > To Post a message, send it to: scrumdevelopment@...
> > To Unsubscribe, send a blank message to: scrumdevelopment-