Question

I would like to find documentation on the best practices for using Projects and Areas in FogBugz. I notice a few questions around about this but maybe a tutorial that explains how the Fog Creek team envisioned FogBugz to be used and what are some examples of how a software development effort could be divided up into Projects, Areas, Categories and the use of Tags etc.

We have been using FogBugz for about a year now and it has proven to be an invaluable tool. We are planning to re-organize projects a bit next month and I thought that this is an appropriate time to ensure that we are actually getting th emost out of this tool.

Answer 1

One quick tip that really helps a lot of people figure out what Projects should represent is that often a project maps directly to a source code control repository.

For instance, if you have two efforts that are different enough to be in separate Mercurial repositories, it's likely that they should live in separate FogBugz projects.

Below that, Areas really depend on how multi-faceted your project is, and how big a team you have. For instance, our FogBugz project has about a dozen different areas, but our StackExchange project, which is a different team and a newer product, has only one: Misc. That's what works for that team.

Our Sales & Support project has a bunch of areas, and they change regularly based on process changes and improvements.

As to Categories, we use the default setup, which is pretty self-explanatory (with the possible exception of Schedule Items).

We haven't found a consistent use for Tags yet. They were oft-requested and the implementation is great, but we really use them not very much. They're great for temporary or shifting processes, which might last just a day or a week. The great thing is that you don't have to put a bunch of extra infrastructure in place to have one-off categorization.

Maybe others have some ideas?

Answer 2

Our implementation is similar:

• Some people are using projects to represent their system. They'll group milestones together for any "projects" they have in progress. For example:
  • ProjectA (Project A being a system)
    • milestone name: Gold Project - Construction
    • milestone name: Gold Project - Testing
    • milestone name: Red Project - Construction
    • milestone name: Red Project - Testing

(This kind of structure has some benefit because the milestones will be ordered by date. You can use the sliders on the reports to see how your milestones are expected to do as you include each one)

• Some other people are using project for an actual project - a temporary endeavor, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables)

  • We can have multiple releases in one project. Intelligent grouping of milestones can facilitate something like this.
  • The reports work as above but obviously for milestones in your project. With regard to milestones...
    • A milestone can represent a phase of work (planning/design/construction/testing/etc - whatever makes sense for your environment).
    • Milestones can also be set up for specific events and have dependencies between them if it really makes sense: You might have coding work that can be done at any time, and other work that absolutely can't start until the hardware shows up. So make a milestone called "Hardware Arrives" and set other milestones to be dependent on that (work in the milestones obviously should only be possible once the hardware arrives).

• Areas:

• We set up areas in ways that make sense for the task at hand. Since areas are set at the project level, you can have different areas that make sense for each project.
  • One project might have areas of (Plan, Design, Code, Test...)
  • Another project might have areas of (Project Management, Business Analysis, Development, Marketing, QA...)
• This might be obvious but areas are unique things. If I don't want a case to be able to be both Coding and Testing, Area is a good way of controlling that.

• Area is also helpful because you can help control the default assignee for a case.

• We use tags similarly to Rich with some expansion:

  • Grouping work (FeatureA, FeatureB, etc)
  • Noting builds (B20100206.1, B20100206.2, etc)
  • Shifting processes or "processes" that would choke the team if we tried to enforce through workflow (NeedsCutomerReview, NeedsScrub, etc)
  • Noting an attributes of the work when it makes sense for a case to have more than one (Part11, SOX, ISO9000, etc). A case might have work which applies to more than one of these attributes.

• Hierarchy is also used to group work. Sometimes we create a parent case for each Feature/Module and put related work under them. This is most effective when you don't have cases which could apply to more than one parent (obviously)

  • We'll do this even if we're also tagging by module. The reason being that it really cleans up filter results in the outline view. It's much easier to see what's going on and you can expand/collapse parents easily.

• We use the default workflow. The problem being that changes to workflow and categories impact EVERYONE. Once we start modifying workflow/categories, everyone wants something customized and things get ugly. It's actually easier for big groups to use the default.

• We also use the default categories:

  • Feature is any work related to building something new or modifying something that isn't broken (not performing as designed). We can get a count of features by looking for "parent" features and total effort of each feature by searching for all features.
  • Bug is anything that is not working as intended. This can even be documentation - if someone sends me a design doc and I find something wrong, I open a bug against the design doc. This might sound like overkill but we've been doing this for a few years and we love it now. We use hierarchy the same as for features - We'll open a parent bug and have subcases for all of the work associated with that bug so we can easily see how much time went into fixing what was broken.
  • Inquiry is pretty self explanatory. Any kind of "Can we..." "How does..." etc task come along, this is an inquiry.
  • Scheduled items are everything else. They don't really have to do with features or bugs or answering questions. I might make a case for myself to follow up with legal on a contract or prepare for a meeting. This would be a schedule item.