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.
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.