How do I represent features v. tasks in FogBugz 6?

Question

In FogBugz 6, how do I represent the concepts of a "feature" versus a "task"? As defined by Joel Spolsky, the owner of Fog Creek Software (which makes FogBugz), a feature is essentially a user-visible capability. To estimate the time to implement a feature, the developer should break the implementation into short tasks (2 days max) to ensure they think about each step.

FogBugz has only cases. I can't tell whether they're supposed to correspond to features or tasks. Some FogBugz documentation indicates that each case is a task, which is fine except there is no way to group all the tasks for a given feature together. This is especially odd given that, before FogBugz 6, Joel advocated using a spreadsheet with that grouped all the tasks for each feature. But his own software doesn't appear to meaningfully support that grouping.

I realize that the Joel article I reference includes a disclaimer pointing to a later article. However, the later article does not settle this issue, in fact it doesn't discuss features versus tasks at all, which is surprising given how well Joel advocates for those concepts in the first article.

Pouncey

The feature set in Fogbugz 7 addresses this in several different ways. – Oisin

Answer 1

Responding to AviD's comment/question to Joel:

So, if you have 10 new features coming in the next version, with each feature needing 5 tasks to implement, you recommend creating 10 releases? And how do I define that these are the features/"releases" that are to be included in the upcoming release?

Here is how we dealt with this specific problem in our development process:

1. First, we made a regular release schedule: monthly internal releases and quarterly external releases. This schedule never changes but task assignment / feature completion does. This is hugely important in terms of simplifying our inter-human communication: don't try to argue with the calendar.
2. Major features ("10 new features" in your example) are turned into cases (e.g., case 101 to case 110).
3. Each task that is a sub-component of a major feature also gets created as a sub-case with a description of what makes this chunk of work an important part of the larger picture. Previously, in Fogbugz 6, we used the "See also" feature by allowing it to search the text for us ("This is a sub-component of case 101" for example). This was effectively the same thing but less aesthetic.
4. Now that we've broken down the work to its finest level of usefulness, we bring the actual developers into the discussion. Each task and major feature is individually assigned to a particular developer.
5. The developer determines when they can get their assigned work done by picking the appropriate internal release date that they think they can commit to.
6. At this point, we have a rough sketch of what will get done for each release. Further refinements continue as the working people actually estimate the hours that they'll need to do the work, enabling evidence-based scheduling, etc.

For AviD's question, though, he would have the release-assignment problem solved by step 5 above.

However, I think point 6 is the most interesting as that's where you really get a solid schedule. For example, if developers are having trouble estimating a larger task, they break it down into sub-cases even further. Notice how my assessment of "finest level of usefulness" can differ (perhaps greatly) from the person who really needs to get the work done.

This is also a time when a developer can reach out to someone else and say "I can do most of this but it would really help if person X could help me with this little piece Y." This is actually where I get most of my development tasking: I personally sit in multiple places during this process, from large-scale planning meetings to little fiddly tasks that no-one else has time to do.

PS: Making it a personal goal to get this answer rated higher than Joel's.... ;-)

PPS: My original response is now overcome by events since Fogbugz 7 has lovely sub-tasks. Program managers love those reports.

Oisin

@dodgio, thanks - the details of this answer have changed a bit with Fogbugz 7 but the themes remain the same. – Oisin

Thanks Bob, didnt see this till now, but as you say its much simpler in FB7. – Yuen

@AviD, I agree. The sub-tasks also lead to an implicit total estimate to complete the super-task in the outline view. This prompts pretty quick question and answer sessions: "you can really deliver a fully test, documented and ready to ship feature set X in three days?" "Oh, sorry, I forgot this piece and that piece and the other piece...". ;-) – Oisin

Answer 2

For FogBugz 6.0 and earlier:

Make a case for each work item (task). FogBugz calls them "Features," only to distinguish them from bugs, but you do want one case for each task.

The best way to group a bunch of tasks is to make a Release (Fix-For) and assign all of the tasks to that release.

Gurnard

So, if you have 10 new features coming in the next version, with each feature needing 5 tasks to implement, you recommend creating 10 releases? And how do I define that these are the features/"releases" that are to be included in the upcoming release? – Yuen

On the other hand, I was thinking earlier about this, and I was considering using Areas - though this also has drawbacks, and is not very easy to add more features... And anyway, I agree the OP that this is something missing, being able to group tasks together (maybe even more than one level?) – Yuen

@AviD, tried to answer your question in my answer below: #88955 – Oisin

Joy! As a result of the semi-random ordering of equally rated answers, mine sometimes appears above Joel's. Personal vindication! ;-) – Oisin

Answer 3

You may have better luck asking your questions in the FogBugz Discussion Forum

Christianechristiania

Answer 4

We use a combination of projects in order to accomplish your grouping goals. We also commonly setup a project "parking" Wiki where links to development cases, technical documentation, systems requirements, user documentation, external links to resources etc. can all be placed. It provides a good "one-stop-shop" for everything related to that project.

As part of that Wiki, we would then setup two specific projects. One in relation to the large overall goals/outlines similar to what might correspond to your Project Management charts/whatnot. One in relation to the development tasks of each feature as they are broken down into the smaller and more manageable chunks. You can then, as was mentioned use case linking to both reference the "master" cases in the other project as well as reference the project Wiki itself so that you can quickly and easily get back to all of your project related information which is conveniently in one spot.

You can accomplish a pile of different organizational structures using FogBugz, you just have to approach things a little differently sometimes in order to hit each and every situation.

Hope that helps.

Perforated

Answer 5

haha, that article has a disclaimer, but I understand what you are saying.

We use Fogbugz and the only 'Feature' that I am aware of is under category and I don't think you can associated it with sub-tasks.

You can type in 'Case N' is the feature for this task if you just wanted to reference it in the case text.

That kind of stuff sound like is lies more in the project management domain instead of software used to track bugs.

Grind

Regardless of the name, Fog Creek (and Joel) DO present Fogbugz as project management software, and not just a "bug tracker". So it does seem that there are some core PM features still missing... Here's waiting for FB 7! :) – Yuen

Answer 6

thats a good question, i have asked that myself, too.. we currently test-drive fogbugz for 45 days in a group of 5 developers, and we currently create a "release" for major features. in fact we do not release it, but multiple releases together when something is ready.

there should definately be some sort of advanced task grouping in fogbugz.

Christophe