Scrum and Fogbugz

Question

Anyone out there using Fogbugz and Scrum together?

We use Fogbugz extensively, and I'm looking for ideas from anyone who may be using it as part of Scrum. I found these two items, but they are archived and unvailable for further discussion. I'm specifically interested in ideas for mapping Scrum concepts into Fogbugz.

Some things are fairly obvious. Releases and sprints map well to each other. But other parts of Scrum don't really fit.

http://support.fogcreek.com/default.asp?fogbugz.4.12143.4
http://support.fogcreek.com/default.asp?fogbugz.4.19971.3

I'm also thinking it might not be too hard to create some lightweight custom stuff to wrap around Fogbugz so that we don't have to abandon one of our favorite tools in order to improve our software process integration.

Edit:

I'm adding a few more specific questions that have come up. Any suggestions on these items would be helpful:

• 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?
• How/where do we document a sprint goal?
• How do we document a canceled sprint?
• How do we document sprint review?
• How do we track completed or canceled sprints?

Edit #2:

Chris's reply below reminded me that we have indeed upgraded to Fogbugz v7. It has many great features that align it more closely with Agile, Scrum, and Lean including:

• Project Backlog (via plugin)
• Custom Workflow
• Burn Down Charts
• Kanban Board (via plugin)

See the following links for more info:
http://www.fogcreek.com/FogBugz/WhatsNew.html
http://www.fogcreek.com/FogBugz/Plugins/default.aspx?ixCategory=-3

Edit #3 Adding link that Perhentian mentioned in his answer as well as another I found:

http://www.danielroot.info/2009/08/how-to-apply-scrum-using-fogbugz-7.html
http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

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

After using FOGBUGZ and JIRA for agile, i have decided that neither tool is really ideal to support the model. Can you get either to work. Yes. JIRA is actually a little better because of the ability to customize more (Create user stories, etc) But if you really want your team in SCRUM mode, you need to have everyone looking at a burndown chart and everyone looking at a backlog and i think you should look at tools like SCRUMWORKS. The basic version is free and it will give you what you want. Use JIRA and Fogbugz for what they were meant to do, keep track of bugs and requests but not be a full SCRUM management tool.'

Update: You can use Greenhopper plugin to JIRA which is a little better to support agile projects.

Answer 3

We use Scrumworks and JIRA.

SCRUM doesn't really cover how you implement QA/QC procedures, part of agile is being able to define, improve, iterate processes.

Answer 4

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.

Answer 5

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 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.

Answer 7

Check ScrumDesk

Answer 8

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 9

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

Tools for Agile / Scrum

Answer 10

The open source tool trac has a FogBugz integration, and for the Scrum part you can use Agilo for Scrum, which is based on trac and supports Scrum comprehensively.

Answer 11

Check out the new version of FogBugz. There is a blog article here which summaries the improvements to support Scrum. We use it and it works well for us.

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

Answer 12

We had been using FB for a long time, but recently started formalizing our use of Scrum.

Found the following things PRETTY helpful:

1. Used a tag for each Scrum sprint.
2. The sprint tag is entered into each FB case in that sprint.
3. We have a Wiki called "Scrum Sprint Reports"
4. Within that Wiki, we add an article for each new sprint (we have them by weeks). That article has the same tag as that of the sprint.

Then, the following things help:

Firstly, if you simply search by the tag, you will find: all cases and the specific Wiki article (which even in headline view will show you the goals)

Secondly, we create two filters: one filter for showing the cases of that scrum in a list view, and second filter for showing cases open/closed in a pie chart. As you go through the week, you hope to have eaten more of the pie.

The only thing that I don't like about this is that I have to modify my two filters every Friday, but at least TGIF.

---

PS: Just feel like mentioning that FB Wiki Editor is better than one in 7.0, but really should be versioned 0.8. It is at least 2 editions away from being something stable.