How should I implement User Stories in Bugzilla?

Question

A few individuals at my work have come together to form a group whose goal is to analyze the benefits of implementing some Agile software development / project management principles.

As a developer, I see great benefit in User Stories. We're looking to put together an information radiator that can be used for monitoring stages of the current release and planning future releases. I'd like to use User Stories for this process.

Right now, we're using Bugzilla for issue tracking. Most release planning is done using bugs from this system. The use of Bugzilla will probably not change. It provides most of what we need at the right cost ($0).

One concern is the mapping of User Stories to bugs. Release management is currently done using bug numbers. The problem is that one User Story could include three bugs or vice-versa.

In the scenario of having multiple reported bugs for a single User Story, one idea is to have a User Story Bug that spells out the story and set dependencies on child bugs that make up that story. I'm worried this may end up being too complex and create confusion among stakeholders, development, and QA. Also, it will clutter Bugzilla quite a bit.

Has anyone already been down this road? If so, what have you done? Should I push to abandon the idea of User Stories in Bugzilla? Is there a simpler solution?

Any thoughts would be appreciated.

Answer 1

I've done similar things before in Bugzilla, and the solution I found was not to implement hierarchical "story bugs" or the like; we decided as well that that would cause confusion and was simply too complicated for what we wanted. The solution I've used before was simply to put the User Story number in the description for the bug; you can throw a link in there as well, to make it easier to dereference. It's a bit patchworkish, but it works pretty well.

Answer 2

I would say, that if your user stories need more than one bug case - they are too big. With good abstraction of the required functionality, you can split your user stories to a smaller ones, which require only one case per story, and then plan and proceed that way.

We have tried to use the approach @McWafflestix describes, with links from the cases to the official (wiki) document of the user story, but after some time we found, that creating smaller user stories is better - it also leads to a better application design, because each user story is implemented as abstracted as possible, providing better testability and maintainability of the code.