Question

I'm looking for some advice from those who have tried (successfully or not) to use FogBugz as an end-to-end development tracking tool; from requirements right through to deployment. It would be compelling to have a tool where we could track requirements and specs, then make sure each are covered (or deferred by choice) in a release.

Some of the questions I would have would be to the effect of:

1. What category definitions did you find useful? Best to leverage the Custom Workflow Plugin and roll your own?

2. How did you manage the situation where a specification case satisfied multiple requirements? In many cases the requirements to specification chain is a many-to-many relationship rather than a strict parent-child relationship.

3. Could the Wiki be used for the requirements and spec definitions, then associate cases to each of the specs? If so, can we report whether or not each requirement and/or spec was covered?

4. What worked well for you, and/or what gotchas did you have to work around?

Thx in advance!

Answer 1

I'm one of the engineers at Fog Creek so I'm obviously a little biased, but I just wanted to chime in to mention that we almost always end up putting our specifications into the wiki for the FogBugz team.

This not only makes it easy to tie them together with underlying cases if necessary (Insert -> Link -> enter case # -> automagically creates a link to that case with our standard "case preview on hover" behavior), but it also makes it easy for others to comment on the spec as it evolves.

For example, one thing we do fairly often is to post a specification on the wiki and then mention it and link to it in our weekly company-wide status update (which is also a wiki article) requesting feedback from our peers. Others can then read the spec and just insert a sub-heading with their name at the bottom of the article and voice their concerns/comments. The spec author can subscribe to the wiki article and be notified whenever it's modified and then reply to the newly posted feedback.

Some other benefits of keeping things in the wiki are that each spec then gets a single, canonical location for others to find them that's available online, and the built-in revision history that comes along with using wiki articles. It's much nicer (imho) to deal with the built-in revision history viewer of our wiki than to be constantly merging and diffing word documents (or dealing with "track changes").

I guess that's not really an answer (at least not a full answer), but I hope it's helpful. :)

Answer 2

I'm not biased but I do use FogBugz pretty much the way db outlined. I don't enjoy the Wiki authoring experience, but like any other tool you learn to use it and you get better.

I'll outline our general process at the bottom, but to specifically answer your questions:

1. We use the default Categories of Schedule Item, Inquiry, Bug and Feature. We have products in maintenance mode and other in development and although we have found the Workflow plug-in useful to change how some of the default assignments work we've found the categories provided are good enough.

2. I'm not clear on what you mean by specification and requirement. To me a specification is a requirements document - it specifies all the requirements a product must meet. Maybe what you are referring to as "specification case" is the Case Category: Feature; Maybe what you are thinking of as a specification we use the FogBugz Milestone for...see below for how we use them.

3. Yes, Wiki articles and Cases can be easily cross linked as described by db (Ctrl-K 10346 Enter puts a link to Case 10346 in the Wiki article and automatically puts a link to the Wiki page in Case 10346) I haven't found an efficient way to show a central requirements traceback matrix that instantly shows what requirements have been covered. Our Roadmap is the plan of what we want to do, but to see if we've done it, you have to look at the Wiki articles that describe the feature, or look at the product itself.

4. Here's what we do:

Our product spec is all the articles in a Wiki. Each article is either a high level description that links to detailed articles, or the detailed articles themselves. You can think of one of the high level articles as the introduction to a major section of a traditional specification document and the other articles as the list of detailed requirements. The requirements lists are in tables, one requirement per row, with a column for Case/Origin, which is where we put the link to the specific Case or the general Milestone that the requirement was implemented in.

We organize the Wiki spec with two particular Wiki pages: a table of contents and a roadmap. The table of contents is a hierarchical listing of Wiki pages - it looks just like the table of contents of a big 'ol spec document - by its structure it shows some of the architecture of the product and links to every detailed requirement page. The roadmap is a chronological list of features, in the order of when we want to implement them.

We grow the table of contents and the roadmap by creating empty wiki pages that will hold detailed requirements as soon as we get to them. Having the empty page is good because it's a placeholder for ideas that the final spec author must organize before that article comes up in the roadmap.

Each stage in our product development is grouped by a named Milestone in FogBugz. When we are planning that stage, we create a FogBugz case for each feature in the roadmap. We review each related Wiki article and link the requirement(s) back to the Case that owns it. Then, we assign the Case to a developer.

Answer 3

I'm also a biased engineer at Fog Creek...

I just wanted to add that at the final stages of development, release notes are your friend, especially if you're putting out a new iteration of your product. You can view all of the resolved cases within a milestone, and add (/have others add) release notes on a per-case basis. So, when you fix a bug, you quickly type up a public-facing description of the fix, and then forget about it. Later, when releasing, you just compile the release notes and you have a changelog ready to go.

Throughout your project, EBS can be very useful (should you choose to use it) in keeping track of a ship date. I've never had a better shipdate estimation experience than I've had with EBS.