Scrum and Fogbugz [closed]

Answer 1

We are currently in the process of trying out FogBugz on a SCRUM based project.

We are still very much finding our feet with SCRUM (and FogBugz) so what we are doing may not be 'pure' SCRUM.

First of all, we are using Excel for the release backlog e.g. what we will be delivering in version x.xx

I had actually written a blog post on using FogBugz as a backlog but ended up going with Excel as what I was proposing was a bit complicated in retrospect and I don't think I was really gaining anything.

In the backlog spreadsheet we keep the name of the back log item, a size estimates, so we can calculate velocity, and some other information such as which sprint we will deliver each item in.

We keep our product specifications in the FogBugz wiki and add links to this from each entry in the backlog.

In Fogbugz we map releases to sprints and use schedule items to track our tasks for each backlog item.

Before we start a sprint we choose which backlog items we are going to deliver in this sprint. In FogBugz I create a new release and set the end date to two weeks down the line. We then break down the chosen backlog items in to tasks and add them to the release as 'schedule items'.

Everyone estimates their own tasks and tracks time against them using the 'working on' menu as you normally would. Every day the team members revise their estimates and we can then use the various reports to see how things are progressing. The ship date confidence chart give you a sort of reverse burndown.

Each member of the team also has a 'status' schedule item that they edit every day to record there status report for the daily stand up meeting e.g. what did I do yesterday? , What am I doing today? What obstacles are in my way?

As you can see we a really just using FogBugz for task management.

We picked it more for the EBS and the Wiki.

So far it's working quite well but the project I'm using it one is a 3 person 6 week project.

Hope some of this helps. Let me know if you need any clarification.

Edit: I'm also not trying to get the perfect system up and running first time. I'm very much taking the approach of trying something out and if it's not working out, then change it. So far so good with FogBugz though.

Answer 2

Good comments so far. I'll take a look at Scrumworks. We really like Fogbugz and the team is comfortable with it, so that's why I'm trying to see if it's workable.

@Stefan, one of the suggestions for product backlog in the linked articles is that project backlog can be implemented in Fogbugz by creating an assignable release of the same name with no date, a date at the end of the formal contract, or a date far into the future. Have you tried that or have any thoughts on why your method might be better?

Answer 3

FogBugz & Scrum work together adequately. I think you're questions are good ones so I'll stick to answering thosse...

How do we prioritize a large backlog with only the 7 priority levels provided by Fogbugz? We can modify the database tables to add more levels, but is that an appropriate in the current/intended Fogbugz model?

IMHO 7 is too many to manage, I find that the top 3-4 are manageable and beyond that I might as well lump everything into a single "later" backlog. However, FogBugz documentation or KB articles occasionally give guidance to people who have added additional priority levels, so if FogBugz doesn't intend for you to use it they seem to be well aware of it and basically support people doing it.

How/where do we document a sprint goal? We have a "sprint review" page on the wiki for each project. We document the most recent sprint at the top and make it one huge page (although I imagine we'll eventually keep only the most recent year or something, as those pages are getting HUGE). The sprint review we use is simple and has a set of fields that must be completed by the team and the PM. Before the sprint we document a goal and and the SBL, after we add the fields for the review.

How do we document a canceled sprint?

In the sprint review page mentioned above.

How do we document sprint review? How do we track completed or canceled sprints?

I imagine you can guess how we deal with those two by now :)

I hope that is helpful to you and others reading. We do have a couple fogbugz hacks related to FB estimates that I haven't gone into here, but if you want to discuss any more I'll be happy to do so. Maybe you have some experiences to share that I could learn from?

-scott

Answer 4

FogBugz now (as of version 7) supports plugins, which should make it much easier to use with Scrum.

Tools for Agile / Scrum

Answer 5

At icanhascheezburger.com, we use FogBugz and we have found that FogBugz is great at a lot of things, but it does not work so well for agile development out of the box. Here are two things we do:

We use the discussion boards for daily scrum reports, though a wiki page might be better suited for that since you can subscribe to it.

We also use priority 7 for the backlog. To find all of the backlog cases just search for:

priority:7 project:"project name"

The API would make a writing a little scrum client pretty easy.

Kanban plugin for FogBugz

Answer 6

We use FogBugz for scrum by using a "release" for project backlog and then create releases for sprints, moving items from the project backlog release to the current sprint release. Every item has an estimate and from that we can build a burndown chart, as illustrated in this earlier SO question.

No, it's not ideal but it works well enough.