RE: [scrumdevelopment] Re: Agile Test Strategies
- perhaps his sprint is a year long! <g>
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Cenk Çivici
Sent: 26 July 2008 21:14
Subject: Re: [scrumdevelopment] Re: Agile Test Strategies
I havent followed the discussion from the beginning but if my team had
100 defects in a sprint I would be really depressed.
Each sprint should end with tested high quality, ready to be used
software. That means you should have no defects.
It may be acceptable to see a bug backlog of 20-30 bugs and 100
defects is way too many.
I would try to find the cause of the bugs through a root cause
analysis and fix the real problem.
The question to ask is why do we have too many bugs? What are doing
wrong? What should we do to minimize bugs?
Are there areas in the code that are replicated for instance? Or
complex designs that need refactorings?
On Sat, Jul 26, 2008 at 7:23 PM, Michael James <michael@danube. com> wrote:
> --- In scrumdevelopment@ yahoogroups. com, Giorgio Basilisco <softnew123@ ...>
>> I mean that if for you the easy way is declare the sprint "not done" you
>> are free to do. The Agile is open to all ;)
> Except you're not describing Scrum, the topic of this moderated list,
> and it doesn't sound very Agile either.
> We do have a word for this way of working that involves violating
> timeboxes, creating 100 bugs every Sprint, and allocating half of
> each Sprint to fix the results of the previous Sprint:
> "Scrum, but."
> If ScrumBut meets your current needs, keep doing it. I'd prefer
> you didn't advocate ScrumBut to people who are trying to learn
> about Scrum.