RE: [scrumdevelopment] Bugs from previous Iteration
- (responding to Kier)
> While working on the next iteration several bugIt's up to the PO to decide on priorities; the
> reports come in from the delivered code.
> Should we fix those in the current iteration
> even though they weren't planned or should we
> wait and prioritize them in the next iteration.
> I was thinking that I could have a Programmer
> and BA in reserve to handle such issues.
work you have planned for the iteration may be
more important, or it may not.
There are a couple of suggestions. In case you think
this is a common occurrence, it may be sensible
to get the PO to either plan in some time to spend
working on top priority bugs, or to plan in some
work that can be dropped in case any top priority
Without either of these, you have a choice between
1/ defer the bugfix and the PO can plan it into the
2/ Stop the iteration and re-plan (probably what you
should do if the bug is critical and needs considerable
3/ Slip the bugfix into your current plans for this
iteration. Not recommended, but could be the
pragmatic way to proceed for a current iteration
until you get a way of dealing with the contingency
agreed (i.e. you only ever do it once).
It shouldn't need to be said that you should look
for ways of ensuring bugs don't get into the
product, so the situation will not arise in
future. Okay, agreed, those skills take some time
to learn and polish, and you have a body of code
that hasn't been developed using TDD or similar,
that may have bugs appearing for a while yet.
- My understanding of Ken's "Canary in a Coal Mine" talk is that defects should be handled by putting them at the top of the Product Backlog and only a C-level executive can de-prioritize them on a case-by-case basis. This is in line with the related "lean" approach to removing waste.
More here: Quality is Not Negotiable
"Truthfulness is the foundation of all human virtues" - Baha'u'llah
Shape Yahoo! in your own image. Join our Network Research Panel today!
- (responding to Mishkin)
> My understanding of Ken's "Canary in a Coal Mine" talk is thatThis makes sense, but might not be practical where there's already
> defects should be handled by putting them at the top of the
> Product Backlog and only a C-level executive can de-prioritize
> them on a case-by-case basis. This is in line with the related
> "lean" approach to removing waste.
a high technical debt. In a 'steady state' of low technical debt,
putting new defects to the top of the backlog so they get into
the next sprint is what I would want to do. Don't let the path by
which the defect crept into the product remain open.
From a practical point of view, one should be able to try out
the process improvements on new functionality, so fixing
defects where there is high technical debt might need to be
folded in with new work to exercise the improved process.
- I've seen projects that leave time and people aside to deal with bugs
mid-sprint; I can see how a team might have to resort to that, but I
think it may be a "process smell." Two questions come to mind. First,
why are so many defects being produced? Second, why can't the defects
be prioritized by the PO for a future sprint; that is, why can't the
These may be different problems that call for different solutions.
Could be a good topic for the next retrospective.
If the problem is that the team is producing more defects than one
would normally expect in the course of development, then maybe the
team needs to reconsider its development/testing practices. Are they
doing TDD? Are they doing code reviews? Is the build taking too long
to run, and therefore discouraging developers from using good practices?
This smell may also be caused by poor communication with (or low
participation by) the PO. Are the developers getting the information
they need about /what/ to build? Maybe the defects aren't programming
bugs at all, but misunderstood or incomplete requirements.
If the problem is that the PO can't afford to leave defects unfixed
until the next sprint, then maybe the sprint length is too long. If
the team is doing, say, four-week sprints, maybe they could try
two-week sprints. It's possible that with two-week sprints, the
urgency would be alleviated and it would become feasible to put the
defects on the backlog for consideration in the next sprint planning
--- In email@example.com, "Oldfield, Paul \(ASPIRE\)"
> (responding to Mishkin)
> > My understanding of Ken's "Canary in a Coal Mine" talk is that
> > defects should be handled by putting them at the top of the
> > Product Backlog and only a C-level executive can de-prioritize
> > them on a case-by-case basis. This is in line with the related
> > "lean" approach to removing waste.
> This makes sense, but might not be practical where there's already
> a high technical debt. In a 'steady state' of low technical debt,
> putting new defects to the top of the backlog so they get into
> the next sprint is what I would want to do. Don't let the path by
> which the defect crept into the product remain open.
> From a practical point of view, one should be able to try out
> the process improvements on new functionality, so fixing
> defects where there is high technical debt might need to be
> folded in with new work to exercise the improved process.
> Paul Oldfield
>Should we fix those in the current iteration even though they weren't
Yes. There will always be bugs, and they always need to be addressed.
Our team is constantly releasing, since our internal customers always want to use the latest version of our software, so bugs need to be handled quickly. We just deal with them and move on. Our velocity suffers, but we expect there to always be some bugs, so it all comes out in the wash.
Of course, you have to be careful that they really are bugs and not feature requests dressed in sheeps clothing.On 5/31/07, Kier < kieroneil@...> wrote:
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.
Should we fix those in the current iteration even though they weren't
planned or should we wait and prioritize them in the next iteration.
I was thinking that I could have a Programmer and BA in reserve to
handle such issues.
Please give your opinions...
I rather like the idea of being thought of as a shit - a common conceit among those who don't realize just how shitty they really are." - Clive James
- --- 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: