RE: [scrumdevelopment] Re: Handling bugs in SCRUM
- 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!!
> -----Original Message------------------------------------------------------------------------------------
> From: Chuck Stump [mailto:beloc666@...]
> Sent: Monday, February 28, 2005 7:29 PM
> To: email@example.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
> (time and people) to CR work for those areas that are already being
> "touched" in the sprint. This way, we can address our "CR
> 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.
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> 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@...