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

RE: [XP] Estimating those extra features called bugs

Expand Messages
  • John Emery
    In my shop, we use the red card concept and place the card on the iteration board. This red card MUST be selected by the next available pair. These bug cards
    Message 1 of 5 , May 31, 2006
    • 0 Attachment
      In my shop, we use the red card concept and place the card on the
      iteration board. This red card MUST be selected by the next available
      pair. These bug cards are usually the result of a 'not completed' story
      from the current or previous iteration. The effort measurement is added
      to the actual of the current iteration.

      This keeps the developers focused on satisfying the customer's
      expectations for the story before they submit it as completed. This
      strategy helps keep the estimate to actual ratio honest for specific
      story. Red cards are an 'embarrassment' to the team. Since
      implementing this strategy, the effort for bugs has dropped to a range
      of 8% to 0% of the iteration actual effort.

      -----Original Message-----
      From: extremeprogramming@yahoogroups.com
      [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Jeffrey Palermo
      Sent: Wednesday, May 31, 2006 8:29 AM
      To: extremeprogramming@yahoogroups.com
      Subject: Re: [XP] Estimating those extra features called bugs

      On 5/31/06, PierG <piergiorgio.grossi@...> wrote:
      > We sometimes put extra features in our code. We will call these
      > features 'bugs' :)
      >
      > We treat them as red cards that we schedule with (or sometimes
      > without) the users during planning games.
      >
      > Now the problem is how to estimate them. How many story points do we
      > need to find and fix a bug??
      >
      > Do you guys have solved this problem?
      >
      > Ciao,
      > PierG
      >

      PierG,
      My team tends not to estimate a bug until we decide that it's a big
      one (which has only happened a few times). We pick up bugs with
      velocity (seems like a wierd term to use, but it's our slack time).
      We put a card with the bug number on our story wall and work on it
      depending on priority. We tend to focus on why our automated tests
      let that bug slip through, and we spend some time analyzing and fixing
      our tests. In short, these are our tendencies, but we are constantly
      evolving our process.

      This process seems to be working for us, and because we heavily
      emphasize automated tests, we have few bugs. We work them in between
      other stories.
      --

      Best regards,
      Jeffrey Palermo, C# MVP, MCSD.Net





      To Post a message, send it to: extremeprogramming@...

      To Unsubscribe, send a blank message to:
      extremeprogramming-unsubscribe@...

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links





      NOTICE: This electronic mail message and any files transmitted with it are intended exclusively
      for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged
      information. Any unauthorized review, use, printing, saving, copying, disclosure
      or distribution is strictly prohibited. If you have received this message in error, please immediately
      advise the sender by reply email and delete all copies.
    Your message has been successfully submitted and would be delivered to recipients shortly.