Feature or Bug Syndrome or How to use my bugtracking software for project management?

Question

I started using FogBugz as my project management tool. So I keep adding bugs and new features to it.

The problem is FogBugz doesn't support subtasks for features, therefore I'm ending up adding all steps of implementing a feature as a text into the description box. But so far this is quite inefficient in many ways. It's not clear "what are the steps?", "Which steps related with which step?" and it's impossible to change steps after you enter. You can only add new text.

Am I trying to do something wrong? Shall I use another product or shall I use a bugtracker and a separate tool such as Office Project. Also I've noticed that most of the bug trackers don't support multiple step tasks.

Answer 1

Here's a number of ideas:

1. You probably want smaller feature items.
2. You can go as far as creating projects for each feature to group them to gether
3. Use the "Case 123" feature to reference Feature 123 in feature 100 or 140 (just type that key in the text box and the cases will be forever linked), and then you can leave your projects for the more macro projects. In this situation, I would have a "master case" and all the substeps and "sub cases" that are linked back to the master case - even if they are not displayed in a tree view; it basically gets you what you want (its kind of like thinking in pointers)
4. Use FogBugz for estimating and tracking the small feature items, and then you can harvest that data and pull it into any other tool. You probably don't need to if you have EVERYTHING in FogBugz; but you can if you want to do more fancy reporting.

Answer 2

I would recommend using Project, It has some problems at first but experience will overcome the small glitches, this I can assure you. I managed a one year project to implement a fully comprehensive system using the STAR methodology and this could be represented well in Project. You are able to create tasks, subtasks and milestones very easily and are displayed clearly. You can perform PERT analysis for analysing the Critical Path as a tool from converting your Work Breakdown Structure.

Answer 3

For smaller jobs I use Areas or put the feature name in the title, so I can sort by that, e.g. "Widget1 Step01 - blah blah..".

For something more complicated I use a wiki as an overall design document, then decompose that into the tasks that you actually need to do by creating cases linked to the wiki. The tasks (and other external documents) for a feature are grouped in the wiki. This gets around the problem you mention where you can't edit the description box.

Answer 4

Because I'm a believer in Extreme Programming, I think that each "feature" should be small enough that you don't need to keep track of much in the way of progress. You should be able to add real customer value in less than a day. With short iterations, there doesn't seem to be much point in writing down which parts are done and which parts are still left open.

Answer 5

For small projects (1-2 weeks or less) using a bug-tracking like tool would probably work...however for larger projects and larger teams a base bug tracking system often adds confusion to what needs to be done, dependencies and next steps...I often see bug tracking being used for project management in small shops started by developers. Where there's a need for coordination amongst internal teams, external teams, timing with business units - you can't escape some form of project management tool even if it's a spreadsheet (I think google docs is a good next step from bug tracking). A project management tool should allow for grouping of tasks, changing task status, adding files/artifacts to the plan and/or task and be highly collaborative (web based). Bug tracking should be incorporated within a project once QA starts testing, if it's not directly built into the pm tool. Using a bug tracker for a complex project is like a contractor using an inventory list to build a house (instead of the floor plans and diagrams).

Answer 6

Currently I'm experimenting with http://www.abstractspoon.com/ - Todolist and http://www.liquidplanner.com/

Even though todolist looks so basic, to be honest it's the best tool so far. Biggest problem is that it's not developed for a team, however it's easy to hack.

I think I'll got with todolist after looking into about 10+ project management solutions.

Answer 7

You may also want to check out Intervals, a web-based task management tool with project management and time tracking capabilities. Tasks can be grouped into milestones/deliverables, which my help with your situation.

Answer 8

We at Fog Creek have definitely run into this with the coding of a bunch of new features for FogBugz 7. We haven't started dogfooding the stuff we're working on that could help with this, so I can't talk about it too much. Suffice to say that we don't have a good solution to this right now, but we're working on it.

Edit:

What we have done in the meantime is this:

• Made a case for each feature to figure out what had a chance of making it into the release.
• Once we'd determined a feature set, created a wiki page for each feature, as a placeholder for the detailed specification.
• Had developers break that out into a list of cases to which they gave estimates.

The missing piece here is in arranging those cases in a coherent fashion. For this, you'd need something like tagging or case hierarchy, both of which are ideas that have been strongly bandied.

Answer 9

Ohhh, if only we could get subtasks in FogBugz, life would be grand. Right now I'm using Rally to communicate and plan (with managers/planners/shot-callers), and FogBugz to execute (with programmers). FogBugz is SO much more usable in so many ways, not to mention cheaper -- if I could just have a feature thread for managers and subthreads for programmers, I could throw Rally out the window. Go Fog Creek, you can do it, you can do it, rah rah rah!