How do you use FogBugz with an Agile methodology?

Question

"Evidence-based scheduling" in FogBugz is interesting, but how do I use it w/ an Agile methodology?

Answer 1

I asked the FogBugz guys the same thing because in XP for example you'd provide the estimate in IET (ideal engineering time). Their answer was to be consistent in the way you provide the estimate.

Answer 2

As eed3si9n said, if you are consistent in your estimates for EBS, FogBugz will take care of this for you.

As to the more general, how does FogBugz fit with the Agile methodology, your best bet is to do sprints as mini-releases. Create a sprint and add the cases you want to achieve for that sprint to that release (or milestone). Give it an end date, say a week away, if you do week long sprints. Then EBS can track it and tell you if you are on schedule.

The graphs in the Reports section will also show you a burndown chart. The terminology is a bit different because FogBugz isn't Agile-only but the info is there.

You want to see if the expected time you are going to finish your sprint is staying steady or going forward. If it is steady you are on track and your burndown rate is on target. If it is creeping up, you are losing ground and your sprint is getting delayed. Time to move things to the next sprint or figure out why you messed up your estimates :)

Essentially I suppose this is a burn-up chart instead of a burndown chart, but it gives you the same answer to the same question. Am I going to finish on time? What do I have left to do?

Atalasoft's Lou Franco wrote an excellent post on this as well. Patrick Altman also has an article.

Answer 3

Hi,

We started using FogBugz for pretty much everything within our technical team: Documentation, bug reporting, managing tasks. We have progressively got more Agile as time has gone on.

What I have done is created a release which is called the Product Backlog, and this is given an arbitrary release date in the future. I changed the FogBugz field "Version" to "Priority" so we can sort by priority. To manage the product backlog I heavily use Areas to categorise the user stories. Areas could be Themes or Epics. Each Iteration is a Release in FogBugz.

Now, one thing we have recently started using is Story Points as opposed to Ideal Task Days for estimating our Product Backlog. FogBugz doesn't understand a unit of measurement of Story Points so rather confusingly, 1 SP in our Product Backlog is reported as 1 Day in FogBugz. This could be dangerous if there is any confusion. But our team is small. I don't use the in built reporting tools in FogBugz, but it would be great if I could.

So, all my Story Point and Velocity calculations are done outside of FogBugz in Excel. This seems to be fine for now. We're tracking tasks using index cards for user stories and post-it notes as tasks on our boards in the office. Have a look at the book "Scrum and XP from the Trenches" book by Kniberg which influenced my decision. Actually having a big board with everything on it which we are staring at in our morning Scrums really helps.

I do think the historical estimation history and reporting in FogBugz is excellent. Does this work with the planning poker world? I suppose at least from a team's estimation history it does.

As User Stories in the Product Backlog often evolve as there are iterative planning sessions, (Agile Planning) it would be great if there was a wiki style editing of cases as opposed to a thread of descriptions.

There is talk that the next major version will be more supportive of Agile processes so am very much looking forward to seeing that this offers.

Edit: FogBugz 7 is now out with much better management of Product "Project" Backlogs. Take a look!

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

Answer 4

Here are some suggestions for including Story Points in your planning:

When you enter your Story into FB7 you can do it as a Case and include the number of Story Points from Planning Poker in a new custom field that you create called "Story Points" (how to do this below). Then, when you get around to working on that Story, you can break it down further into Sub-Cases, if necessary, and also enter the estimated time to complete each Sub-Case (the estimated times will add up in the Story (top) Case's "Estimate" field, as well as feed Evidence Based Scheduling / Burndown Charts)

Here are two things to consider modifying in your FogBugz installation to reflect your Agile nomenclature.

(1) Out of the box, the FB Category "Feature" is most like your "Story." But you can change your Category names, and add new ones at Admin > Workflow > Customize Categories. Here's additional information on this:

http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457

(2) To capture Story Points, you'll probably want to create a Custom Field in the Case dialogue. This is accomplished with the included Custom Fields Plugin. Additional information on this is available at isl=174461

Note that with Custom Fields, you can also add a text edit box for the Story which will always appear in the Case dialogue header (no matter how lengthy the case activity history below it gets.)