best approach for defects

[Sam Dsoca]

Hi,

What would be the best approach for working on bugs and defects,
Is is good to rewrite write them as new stories with high priority or
just allocate some time during the iteration for defect fixing work ?


Regards

[RonJeffries]

Sam,

Would you rather have the Product Owner aware of and guiding the work, or just let defect fixing happen randomly?

Ron Jeffries

www.XProgramming.com

I know we always like to say it'll be easier to do it now than it

will be to do it later. Not likely. I plan to be smarter later than

I am now, so I think it'll be just as easy later, maybe even easier.

Why pay now when we can pay later?

[Joshua Partogi]

Put it on the Sprint Backlog and fix it right away.

> --
> You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
> To post to this group, send email to scruma...@googlegroups.com.
> To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.
>
>

--
@jpartogi

[Ernesto R. Corona (BHP)]

Sam,

From our experience, I would recommend not to write stories for each defect. We only use stories when defects are "legacy" (when they comes from previous phases, before agile was in place for the team), or when they have strong impact on traceability to several components or functionality.

Sometimes (most of them) we fix ASAP when they appear, and after several sprints we agree with the product owner to have a bug fixing sprint. 

Obviously that's what we do, not what you have to do.

--
Ernesto

[Embrenchia Snyman]

If you write defects as stories and take it up in the backlog - does it count towards velocity? And if so, is that not rewarding a quality problem that should be addressed?

Embrenchia

Mobile   +27 84 727 9436
Fax       +27 86 541 6252
Email     embre...@gmail.com

[George Dinwiddie]

Sam,

The BEST approach is to not create defects. Honestly! Make that a goal
and work toward it. You can get closer than you think.

Beyond that, the context matters.

Is it still in the same sprint? Then fix the defect. The story is not done.

Did you just discover something small that can easily be fixed without
risk of introducing new problems? Then fix the defect. Note: this
requires good backup with automated tests, or you're probably fooling
yourself about the risk of introducing new problems. Isn't that how the
defect was created in the first place?

Otherwise, or if in doubt, talk with the Product Owner.

Finally, take a look at your process to understand how the defect
occurred. What can you fix in your process to prevent similar defects in
the future?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[John Miller]

Yes, put them in the backlog of they are defects from a work not in
the current Sprint. I think defects need to be evaluated against all
other work in the backlog and prioritized and then committed to by the
team. The team should be working on the highest value work.

The question about if this counts against velocity is interesting and
I would like to hear other view points. I like to assign sizes to
defects and count it in the velocity if the team commits and complete
the work. I do not see how story points and velocity reward the team
in anyway, it is just a metric that helps guide decisions. I think
there is something wrong if points are seen as some type incentive or
evaluation of team members, IMO.

If arises out of work in the current Sprint, that is just part of
getting the feature to done.

Thank You,
John
Sent from my iPhone. It likes to sabotage my grammar.

[Dan Rawsthorne]

So, then, you're not using the Backlog to manage your work, just order the business priorities?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Dan Rawsthorne]

Velocity is not a reward, it is a measure. And, when you measure the defects in your velocity, your story is: if we didn't have all the defects, our Velocity (of business value) would increase by xx%. Let's get a better Definition of Done, shall we?

Dan Rawsthorne, PhD, PMP, CST
3Back.com
Author of Exploring Scrum: the Fundamentals

[Ernesto R. Corona (BHP)]

Dan, 

" So, then, you're not using the Backlog to manage your work, just order the business priorities? "

yes we do. 

--
Ernesto

[Charles Bradley - Scrum Coach]

Sam,

Here is my preferred method for handling bugs in Scrum. 
http://www.scrumcrazy.com/bugs

Note that this is just ONE WAY to do it, though I think this way is consistent with Scrum principles.

Charles

[Glenn Thimmes]

My advice is to get clean and stay clean. When a bug is reported, decide if it will get fixed or not. If not, delete it. If it is truly a defect and there is value in fixing it, schedule it at the front of the next sprint. Don't write software on top of bugs that you know you are going to fix later.

 

Have you ever played Jenga? It's the same idea. The higher you stack blocks on the top, the scarier it is to pull them from the bottom. Writing new code over your bugs creates indirect (or direct) dependencies on the defects. When you fix the defects, your new features might break. Hopefully you have a good test suite that alerts you to this, but it's an unsound architectural practice to work this way. Anyone who has been in the business for long has seen this play out, over and over.

 

Managing a bug backlog is a bad idea. It has a very negative impact on the morale of developers to know there is a working backlog of 1000+ bugs in the system. They know they will never get through them. You are better off just deleting the backlog and vowing to fix anything that get's reported from there on.

 

This is just my experience, and I hope it is useful.

 

-Glenn

On Thursday, August 23, 2012 5:08:18 AM UTC-6, SAM wrote:

[RonJeffries]

Embrenchia,

On Aug 23, 2012, at 8:34 AM, Embrenchia Snyman <embre...@gmail.com> wrote:

If you write defects as stories and take it up in the backlog - does it count towards velocity? And if so, is that not rewarding a quality problem that should be addressed?

Here is how I treat the issue. I prefer not to play "bring me a rock", so I do not want the PO saying, at or near the end, "that's not what I wanted". Instead, we pretend that if it meets the original spec and tests, we treat it as done, no matter what the PO wants NOW. That makes any changes PO-requested and therefore they count as new.

The quality problem, I suggest, is that we didn't know before you started how to tell whether we were done. If the story meets whatever the agreed done criteria were at the beginning of the Sprint, then I suggest that we treat the story as done. We recognize that now we wish we had said something different. We retrospect to see whether we need to change our approach at the beginning, and change if need be. And we write a new story to add the new capability. 

If you are counting velocity (and IMO you should not be), then yes, the story counts.

If, on the other hand, the story does not meet the originally agreed criteria, it was never done and therefore does not count the first time. So when we schedule it again for the second time, when it finally works, we count it.

Ron Jeffries

www.XProgramming.com

Sometimes I give myself admirable advice, but I am incapable of taking it.

-- Mary Wortley Montagu

[Aquarius]

Hi there,

IMO, bugs that come from integration of stories of the current sprints should be treated just as story tasks (as per definition of done). 

The ones from production must be addressed immediately (if with the impact on running sprint, then probably causing overtime or leaving stories out, thus impacting velocity) :). 

Assigning velocity to bugs (unless old legacy) is a trap as undermines an idea of "paying for value" as value is only stories and never defects.

So to summarize: team should "feel" negative impact of bugs on productivity (less time for stories, possible impact on commitment) and continuously work to eliminate their causes.

HTH,

R.