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

38307Best Practices on Defect Management

Expand Messages
  • Brent Walker
    May 4, 2009
      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?

      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.

    • Show all 10 messages in this topic