How well does Bugzilla work for managing Scrum projects? [closed]

Question

We have MS Sharepoint -- which isn't all bad for managing a task list. The data's publicly available, people are notified of changes and assignments.

I think that Bugzilla might be a little easier for management and reporting purposes. While there are some nice Open Source Scrum management tools, I've used up a lot of my political capital and can't ask for too much more than what we've got now. Money isn't the object -- obviously -- it's the idea that my team has too many specialized tools.

Will Bugzilla work out as a more general project management tool -- outside the bug fix use cases?

Will I be bitterly disappointed and wish I'd downloaded something else and made my case for a better project management tool?

Answer 1

Bugzilla Is a great bug tracking system. We have tried to use it for other project management tasks and the results are less then stellar. I would recommend finding something designed with your goals in mind.

Answer 2

Try it for yourself.

Get a $15/month account at wush.net and use it yourself for a while (no business relationship besides satisfied customer).

Bugzilla is powerful and has a lot of configuration options, which can be confusing.

I personally used it three years ago on a project I was working on. I had no project manager and I was the developer, so I needed a very-light-overhead systtem. Bugzilla gave me that. I put my main goal as an enhancement "productionalized system" and then I made dependencies to reach that point. I ended up having 160 nodes all dependent on each other. This essentially was a work breakdown structure. I didn't bother with time estimates, and I didn't bother with creating any other kind of project documentation.

A cool advantage was that as I coded, if I noticed something needed to be done, I would just pop it into bugzilla (20 second process once it's set up), tie it as a dependency, and go back to what I was doing.

Whenever I completed a task, I would look at the dependency diagram and find the outermost leaves (bugs that blocked other but weren't themselves blocked), and work at it.

The advantage of this method for me is that if a task had looked simple and had one node associated with it, but when doing the thing itself I realized it was more complex, I would just split it into different subtasks. This took only a minute and absolutely didn't involve a meeting with a project manager.

Other people on the team could track my progress by looking at open bugs, closed bugs sorted by dates, etc. They saw action, they left me alone. When I had external dependecies, I would make a bug, detail the work, and send that person a link via email. They could then see why this was needed by looking at the dependency diagram.

Note that unless previously agreed upon, I did not assign them the bug.

It worked really well and the system was ready one month early.

How will it work with SCRUM? Having only had a cursory glance at scrum I can't tell you. But that was my experience.

Using a dedicated host will allow you three things:

• support
• easy upgrades (unless you got gurus in-house, bugzilla management ain't easy--for me at least)
• users across organizational boundaries.

Note that bugzilla has all sorts of security features, so it's easy to lock-down the users to what they need to see.

Answer 3

My stand-alone solution is DokuWiki + MantisBT + Subversion + Review Board, which can be integrated with relative ease. Hosted alternative is Bitbucket.org. The rationale is you write user stories on Wiki and can reference them specific tasks. Larger bugs can be collaboratively designed and the "wiki" link is provided on the bug report by Mantis. Review board lets you do peer code reviews against svn diff before change is committed.

Answer 4

We've used Trac and Subversion very successfully for several projects.

The main advantage here is being able to tailor reports, some very Scrum specific, to provide information to management.