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

RE: [scrumdevelopment] Re: Handling bugs in SCRUM

Expand Messages
  • Schiel James - SHS Malvern
    Chuck, for only having a formal process for a month or so, I d say you ve got an excellent concept going. You ve hit on all of the same elements that I ve
    Message 1 of 8 , Feb 28, 2005
      Chuck, for only having a formal process for a month or so, I'd say you've
      got an excellent concept going. You've hit on all of the same elements that
      I've tried to work into my team's processes. The opportunistic approach to
      managing CRs is the best way to handle them -- over the years, I've learned
      that CRs take the same amount of effort to report, whether they're critical
      or simply mis-spellings on the UI. A responsible development team quickly
      learns to recognize the difference between the critical CRs that really need
      attention and the CRs that are pretending to be critical today but rapidly
      lose their sense of urgency if told to wait a few days.

      What I'm interested in hearing more about is how to handle the really
      critical "fix me now"-type CRs. Are they handled outside your Sprints? Who
      modifies your tests to validate the completed CR? Does the modified software
      get "introduced" into the domain of the Sprint and then tested with the rest
      of the Sprint's software? If you handle your urgent/critical CRs within the
      Sprint, how do you add them and how do you manage work effort overruns?

      Thanks for sharing!!

      Jim Schiel

      > -----Original Message-----
      > From: Chuck Stump [mailto:beloc666@...]
      > Sent: Monday, February 28, 2005 7:29 PM
      > To: scrumdevelopment@yahoogroups.com
      > Subject: [scrumdevelopment] Re: Handling bugs in SCRUM
      > Hello all.
      > I recently started following this group and I would like to get some
      > opinions on my current approach to this question.
      > The following is one way to approach this aspect of change management.
      > I use different approaches dependign upon the project, the
      > constraints, the lice cycle, etc. My current set of projects is new to
      > SCRUM (5 months now) and new to formalized defect tracking (1 month).
      > We track all defects, enhancement requests, change requests, or other
      > similar issues in a defect tracking system. Let's call them all CRs
      > for simplicity.
      > We have a relatively simple but well defined process and associated
      > workflows for documenting, analyzing, implementing, building, testing,
      > and verifying CRs. CRs are entered into the system and then analyzed,
      > including effort estimates and impacted components, depending upon
      > their priority and severity. We use a combination of priority,
      > severity, and what is currently being worked on in a sprint to
      > schedule the CR to be worked. More on that in a moment.
      > We look at the CRs in the tracking tools as an adjunct to the product
      > backlog and an adjunct to the sprint backlog. Large CRs in terms of
      > effort or risk are physically added to the product backlog and worked
      > as any other backlog item since these CRs must be balanced against
      > other features in the backlog due to limited resources. High priority
      > CRs or high severity CRs are treated as exceptions to the sprint plan
      > and addressed as quickly as possible (usually within hours or small
      > number of days). If these high severity CRs can not be addressed
      > immediately due to size, risk, or other factors then they also get
      > added to the product backlog.
      > That leaves the majority of our CRs. Those that are not large and that
      > are not high severity. For these, we look at what work is encompassed
      > in a given sprint and what components/modules/applications will be
      > "touched" in that sprint. We then allocate a fixed number of
      > resources
      > (time and people) to CR work for those areas that are already being
      > "touched" in the sprint. This way, we can address our "CR
      > backlog"
      > within the context of the sprint goal without adding very much risk.
      > For example, if some work will be occurring on module A during a given
      > sprint, then we will review the open CRs associated with that module
      > and allocate 16 or 24 hours of CR work for that module to the sprint.
      > I look at this as an opportunistic way to handle the CRs. It also adds
      > a survival of the fittest flavor in that if CRs linger for a long
      > period of time at a medium or low priority and NO work is occurring on
      > the code areas in question (i.e. none of the product backlog in these
      > areas is important enough to the stakeholders to make it into a
      > sprint), then the CR probably does not deserve attention. Note that
      > this attitude works in my current projects mainly due to a very scarce
      > set of resources. One size does not fit all.
      > Opinions?
      > Chuck
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      > Yahoo! Groups Links

      This message and any included attachments are from Siemens Medical Solutions
      USA, Inc. and are intended only for the addressee(s).
      The information contained herein may include trade secrets or privileged or
      otherwise confidential information. Unauthorized review, forwarding, printing,
      copying, distributing, or using such information is strictly prohibited and may
      be unlawful. If you received this message in error, or have reason to believe
      you are not authorized to receive it, please promptly delete this message and
      notify the sender by e-mail with a copy to Central.SecurityOffice@...

      Thank you
    Your message has been successfully submitted and would be delivered to recipients shortly.