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

Re: [scrumdevelopment] Re: Handling bugs in SCRUM

Expand Messages
  • todd
    ... Seems quite sensible.
    Message 1 of 8 , Feb 23, 2005
    • 0 Attachment
      Bill McMichael wrote:

      >
      >
      > We use a hybrid approach. All defects are tracked in our defect
      > tracking system, so we can analyze our defects and generate
      > appropriate defect metrics. Bugs that are found during a sprint for
      > new development and handled strictly through defect tracking. For
      > pre-existing issues from previous releases that need to be addressed ,
      > we also track as backlog. A budget is established at the beginning of
      > the release to resolve old defects which customer support prioritizes.

      Seems quite sensible.
    • mike.dwyer1@comcast.net
      Take a look at my article on this. It can be found through a google of Mike Dwyer Business Rules -- Mike Dwyer I Keep six faithful serving-men Who serve me
      Message 2 of 8 , Feb 24, 2005
      • 0 Attachment
        Take a look at my article on this.  It can be found through a google of "Mike Dwyer Business Rules"
         
        --
        Mike Dwyer

        "I Keep six faithful serving-men
        Who serve me well and true:
        Their names are What and Where and When
        And How and Why and Who." - Kipling
         
        -------------- Original message --------------

        >
        >
        > --- In scrumdevelopment@yahoogroups.com, "David Roberts"
        > wrote:
        > > Anyone,
        > >
        > >
        > >
        > > This is probably old hat to many of you. I'm curious to hear how you
        > > manage bugs.
        > >
        > >
        > >
        > > Do you use a bug tracker separate from a backlog? If so, how do you
        > > easily consolidate the priorities and time required?
        > >
        > > Maybe you enter bugs into the backlog directly so they can be
        > > prioritized against other features. If so, how do you manage a MUCH
        > > large backlog?
        > >
        > >
        > >
        > > David Roberts
        > >
        > > InnovaSystems
        > >
        > > (619) 368-9621
        >
        > We use a hybrid approach. All defects are tracked in our defect
        > tracking system, so we can analyze our defects and generate
        > appropriate defect metrics. Bugs that are found during a sprint for
        > new development and handled strictly through defect tracking. For
        > pre-existing issues from previous releases that need to be addressed ,
        > we also track as backlog. A budget is established at the beginning of
        > the release to resolve old defects which customer support prioritizes.
        >
        > Bill
        >
        >
        >
        >
        >
        > To Post a message, send it to: scrumdevelopment@...
        > To Unsubscribe, send a blank message to:
        > scrumdevelopment-unsubscribe@...
        > Yahoo! Groups Links
        >
        > <*> To visit your group on the web, go to:
        > http://groups.yahoo.com/group/scrumdevelopment/
        >
        > <*> To unsubscribe from this group, send an email to:
        > scrumdevelopment-unsubscribe@yahoogroups.com
        >
        > <*> Your use of Yahoo! Groups is subject to:
        > http://docs.yahoo.com/info/terms/
        >
        >
        >
        >
      • Chuck Stump
        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
        Message 3 of 8 , Feb 28, 2005
        • 0 Attachment
          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
        • 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 4 of 8 , Feb 28, 2005
          • 0 Attachment
            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.