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

38309Re: Best Practices on Defect Management

Expand Messages
  • davenicolette
    May 4, 2009
    • 0 Attachment
      Hi Brent,

      Here are some off-the-cuff ideas, FWIW.

      --- In scrumdevelopment@yahoogroups.com, "Brent Walker" <brent.walker@...> wrote:
      >
      > I would like to see some discussions around various best practices for managing defects especially around multi-product teams (i.e. inter-related products from different teams)?
      >
      > 1) Do you reduce your capacity for your team members and set that time aside for working defects
      > a) These defects are preventing other teams from completing their sprint (a blocker of sort)
      > 2) Do you plan your sprint to include a set amount of defects for the iteration
      > 3) What level of flexibility does your team plan for in managing defects?

      Option (1) amounts to defining a buffer in hopes it will be sufficient to allow for unplanned work during the sprint. Key word: /hope/. Hope is not a plan, as the saying goes. I consider this approach a "painkiller" - it addresses the symptom and not the disease.

      Option (2) is practical. The way I've used this approach in the past is to set a limit on work in process, and allow for x number of unplanned work items to be inserted into the process. So far, I've never allowed for more than 1 or 2 unplanned items at a time, with a preference for 1. The mechanism to accommodate high priority unplanned work items is to complete wip before inserting the unplanned item; don't interrupt unfinished tasks that are in flight. As soon as wip falls below the limit, insert the highest-priority unplanned item and drop the lowest priority planned item from the sprint backlog. This way, stakeholders know their unplanned items will be addressed, and they also know the cost.

      >
      > I work with infrastructure teams and struggle to find a balance between the sprint contract and the flexibility needed to fix blocking defects requried by the consumers of the infrastructure.
      >
      > Here is an example:
      > Application Team "A" has identified several defects that my infrastructure team needs to provide fixes for but are not currently preventing any stories in their current iteration. They just want them fixed prior to their "hardening" phase of their release.
      > Application Team "B" has a story in their current iteration that is unable to be completed due to a defect the infrastructure team needs to fix.
      >
      > Iteration Planning for Infrastructure Team: Planned to fix a few of Team "A's" defects but did not plan for the one defect from Team "B". Based on the planning contract/comittment we push the defect from Team "B" into the backlog and say sorry? We will add it to our next iteration?
      >
      > Again, looking for best practices from the perspective of an infrastructure team.


      Okay, my personal view about all this is an iterative process like Scrum works best for software development projects - either greenfield or a major enhancement project. My guess is an iterative process is working well for the application development teams your group is supporting (except that they have a "hardening" phase, the existence of which is a process smell; different topic, though). The thing is, your work flow is quite different from that of an application development project.

      To handle an ongoing series of ad-hoc work items that come in at a variable rate, I think a non-iterative process may fit the circumstances more naturally. Some sort of "work queue" or "kanban" style process may work better for the sort of infrastructure support work you're describing. This will allow for both planned enhancements and unplanned items (what you're calling "defects", but sound like they may actually just be infrastructure features an application team will need) to be handled smoothly.

      I hope this helps.

      Cheers,
      Dave
    • Show all 10 messages in this topic