How do you use FogBugz with an Agile methodology? [closed]

Question

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

Answer 1

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.

Update: fixed link to Altman's article

Answer 2

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 3

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