Re: Bugs from previous Iteration
- --- In firstname.lastname@example.org, "Kier" <kieroneil@...> wrote:
>Ideally I would want to prevent this from happening. There are some
> Let's say that an iteration is complete and delivered to customers.
> While working on the next iteration several bug reports come in from
> the delivered code.
concrete steps I personally take to achieve this:
1. Have a discussion with the team about what "Done" means. I would
suggest that the definition of "Done" (at the very least) include:
Analysis, design, coding, testing and some level of end-to-end
functionality testing. In other words, all those activities need to be
included for something to be considered "Done".
2. Introduce the concept of "No new bugs for any new functionality".
In other words new functionality is only considered "Done" if there
are no outstanding bugs.
Adopting both of these steps will force the team to change it's
behaviour. In order to achieve these goals the testers will need to
get involved earlier and it will force the developers to deliver
earlier and more often.
Please keep us informed of your progress and what works for you.
- Dave et al,
The real problem is that we don't have our customers as involved as we
should. Our BA's talk to our customers and our PO talks to our Sales
& Marketing folks to determine user needs.
We are just now heading into our first iteration using scrum so it is
possible that the usual post-release bugs will not materialize using
the Scrum methodology.
In Waterfall it was inevitable that there would be a handful of tweaks
to be made post-delivery.
On this particular product we also have no automated testing either.
One of these days ...
- This depends on how bad the bug is. Is your customer willing to wait until the defect is planned, to be worked on. Or are they so angry they're ready to quit tomorrow?In any case you'll have to end up dealing with the defect (either unplanned in the current iteration, or planned in the next). Defects become a "debt" on your productivity, and if the quality is poor you'll find yourself scheduling more defects than features (or your velocity is lower because in a given sprint there are any number of unplanned defects to be worked on).Do you usually have a lot of in-production defects? Are they usually critical or just minor things? Do you practice TDD or any XP methods that might help reduce the errors in production?NicholasOn May 31, 2007, at 6:02 PM, Kier wrote: