Slack stories and bugs tracking

[Chet Hendrickson]

Hello All,

When working with groups new to XP the subject of bug tracking software often comes up. I tell them that instead of tracking the bugs, they should fix them. (I do this in that loving and non-confrontation style I learned from Jeffries)

One of the underpinnings of these techniques is the assumption that completing the delivery of a feature scheduled in iteration N by removing a bug will always be more important than the delivery of an iteration N+Y feature. (I am speaking of bugs that matter to the customer)

So, what do we do with bugs in slack feature? I really don't want to inventory bugs, because that gives me a technology debt that I must now account for in my reporting and planning. I don't what to push delivery of a Gold feature down the schedule to make room for the fix of a Copper feature.

[Joel Shellman]

On Thu, 3 Mar 2005 09:50:34 -0500, Chet Hendrickson

Post by Chet Hendrickson
When working with groups new to XP the subject of bug tracking
software often comes up. I tell them that instead of tracking the
bugs, they should fix them. (I do this in that loving and
non-confrontation style I learned from Jeffries)

I agree. I think it's silly how people think that bug fixing can be
done at the end of the development cycle. Far less efficient that way.

Post by Chet Hendrickson
So, what do we do with bugs in slack feature? I really don't want to
inventory bugs, because that gives me a technology debt that I must
now account for in my reporting and planning. I don't what to push
delivery of a Gold feature down the schedule to make room for the fix
of a Copper feature.

How do you keep track of them (especially big ones) such that they
don't get lost? You have to keep track of them somehow or they will be
forgotten--if nothing else, they are "kept track of" during the
communication from the bug finder to the developer who is going to fix
it. Well... what if it requires further clarification, what if that
may take time, you do need somehow to keep track of them or else they
may get lost and forgotten. Also, there are situations where the
customer may say fixing a certain bug (especially if it may take
significant effort) is less important than moving forward on other
items. Ie. some bugs are shippable. If they want, they can then
schedule fixing that bug as a story in some iteration. Of course, this
is where people start debating on whether something is a "bug" or is a
missing/incorrect "feature".

It seems to me that issue tracking is a customer (which includes QA)
responsibility because it enables them to organize themselves and
produce the proper stories/tasks for each organization.

Joel Shellman

[Ilja Preuss]

Post by Chet Hendrickson
So, what do we do with bugs in slack feature? I really don't
want to inventory bugs, because that gives me a technology
debt that I must now account for in my reporting and
planning. I don't what to push delivery of a Gold feature
down the schedule to make room for the fix of a Copper feature.

Good question. Can't comment until I understand why we'd want slack features
to be copper features, not gold features, though.

Still confused, Ilja