Question

We are currently running FB6, about to switch to FB7 and was wondering how FogCreek and others recommend handling user stories in FB7? My thinking is to enter a case which would be a story and have sub cases which are the supporting task level work (development, QA, docs, etc) that support the user story.

My question is, when entering the user story as a FB case, do you use the tagging system to identify that this FB case is a user story or do you make a new FB category, call it "user story"?

Is there a benefit from one to another? Would one be better for reporting purposes?

Or do you use the FB (or other) wiki for capturing user stories?

BTW, having a wiki entry for cases as described in this plugin proposal would be great: http://fogbugzplugins.uservoice.com/pages/20251-fogbugz-plugin-ideas/suggestions/212018-markdown-case-editing

thanks

Answer 1

Pros and Cons I see...

Case Hierarchy

• This makes it pretty easy to group your work. A filter showing all of the cases in the project will make it easy to see how much Elapsed and Estimated Remaining time exists for each story (the "story" case will show summary information for all of its children)
• The downside to this approach is that the reports can't differentiate between story1 and story2. They'll report on the project as a whole and you won't be able to easily see how each story is progressing

Area

• You can limit the available stories. You can also have a default contact for each story, which could be helpful.
• This has the same downsides as Case Hierarchy.

Milestone

• This is my favorite:
  • You can still limit the available stories.
  • The real benefit is that each story will show up on the slider in the reports.
  • You can give them all the same release date if you want to but you'll have the option of including them one at a time and seeing how things change as each is included.
  • Furthermore, you'll also be able the use the "Burndown Chart (this milestone) report to see how that specific milestone/story is doing. It's almost like they created that report specifically for this scenario.
  • It doesn't really require extra discipline to use this method because you already have to pick a milestone when you open a new case.
• I don't personally see any real downside...

Tag

• You can tag each case with the story name and build filters based on them. The benefit here is that tags are really flexible and easily entered.
• I can see a few downsides in this approach:
  • The pro listed above could also be a con - tags are easily edited. You might not like people creating stories however they like.
  • Tags are at risk (though low) for typos which will screw up the reliability of your filters.
  • Tags can't be used to drive the reports. The reports will operate as described for Hierarchy.
  • Tags will require some discipline. It's easier to forget to tag a case so you'll have to scrub every once in a while to make sure that every case has a tag relevant to a story.

Answer 2

First thing I thought of was that if you use a Category you will have an icon that shows up in and can be used to sort release notes. The Category can also be assigned when you create the Case from the Outline View; you have to edit the case to add a Tag.