One of the major features Joel mentioned in the official launch of FogBugz 7 was "Scrum support."  Distilled to its essence, Scrum is characterized by:

1. Short "Sprints" that produce "Product Iterations": Each "Sprint" lasts around 15-30 days, and a release cycle can contain one or many product iterations.
2. The "Product Backlog": For each project, a "Product Backlog" list is kept that's essentially a feature wish list sorted by priority. The features are sometimes represented as brief "stories," such as "Allow FogBugz users to create subcases," and each is assigned a rough work estimate. The features that are higher up the list are given more detailed analysis in terms of work estimates and are broken down into greater detail.
3. Daily "Scrums": Once the sprint starts, the team holds daily 15-minute meetings, in which each member of the team summarizes:
   What tasks he/she worked on yesterday
   What tasks he/she will work on today
   Any Issues that might limit his/her progress
4. Burn Down Chart: Sprint progress is tracked through the use of the "Burn Down Chart," which plots the overall estimated time remaining (in the sprint task list) against the date. The goal is to keep things on track for a zero time remaining by the end of the 15-30 day sprint.

FogBugz 6 – already Scrum friendly?

Many of our customers told us that FogBugz felt too heavy for them to use in their Scrum shop, and we weren’t exactly sure why.  "FogBugz supports all of these things," we thought.  A Fix For in FogBugz can be used for every sprint.  Just order things by priority, and bam! Average-sized backlog.  Daily scrums have no place in a online tool, since that is antithetical to a short, daily meeting that is really not meant to be recorded. And the burn down chart was just a way of reading EBS graphs with your head tilted to the side a little.

Nah. FogBugz 6 didn’t work well for Scrum

Creating a Fix-For in FogBugz 6 took 5 clicks, and then you still had to change the Fix For on all the cases that were going into the sprint.  That’s pretty heavy.  Release notes were only useful if you used 1 Fix For per release.  That’s not the way Scrum works; usually there are multiple sprints per release, so whoever was responsible for release notes would have to splice together the FogBugz release notes by hand.

Also, FogBugz priorities are too coarse-grained to be useful for a product backlog; the backlog should be a full ordering, not just a set of buckets where we say "well, these cases are all pretty important, but these over here? Mega important." And if you use it that way, once you move cases into the sprint backlog from the release backlog, you have to reprioritize them, since they’re all going to be in the top 1 or 2 priorities anyway.  It just didn’t work.

Another big mistake was thinking that the Completion Date Over Time graph in EBS was essentially just a burn down chart. We were correct, in a way: the data source for the graph was the same data one would use to make a burn down chart. But the two graphs are used for different purposes:

For a sprint, which tends to be short, the work schedule-agnostic burn down chart actually makes a lot of sense, for three reasons:

• It illustrates an absolute finishing point. The date of completion is asserted, not predicted. If the burn down line is not on track for completion, functionality is removed from implemented features.

• Sprinting team members are likely to violate their work schedule. An "all-out" mentality is often applied to the latter stages of a sprint, and teams are often given an extended breather between sprints.

• Team members are more likely to pick up each other's slack. The team maintains a sharp focus on achieving sprint goals, even if one team member's schedule serves as a roadblock. They are likely to adapt in an unpredictable fashion and take on each other's tasks as necessary.

In contrast, the existing EBS-predicted ship dates are superior for planning a larger release further down the road:

• It predicts a finishing point. For a full release cycle, you want to identify feature goals first, and then let EBS produce a set of reasonable dates.

• Huge values of "hours remaining" are cumbersome.

• Work schedules will average out over a long release cycle, even if they vary during a sprint.

• Team members will maintain ownership over specific features over the long run, even if tasks shift around a bit during a sprint.

We fixed FogBugz 7 for Scrum shops

The first thing we did was to lighten up Fix Fors.  We renamed them to "milestones," which lets them be used more generically. The release notes page was tuned up to let more than one milestone be part of the list of release notes. Finally, the biggest improvement to milestones was on the grid view, where you can now create a new milestone and move all selected cases into it using 2 clicks. Changing the milestone on some cases is even easier, using the same button.

Secondly, the Project Backlog plugin was created to map product backlogs into the FogBugz world view.  For each project in FogBugz, the plugin keeps a fully-ordered list of cases in the project, and lets users move them around within that ordering.  When your team has an idea, they put a case containing the user story into the backlog.  If that user story gets into a sprint from the top of the backlog, then it’s time to start adding subcases to flesh out the different parts of the bug fix or feature.

Finally, we added evidence-based burn down charts.  Using the EBS 2.0 algorithms, we can calculate 5%, 50%, and 95% envelopes for how many hours are remaining in a milestone.  With this innovation, we use your developers’ estimation histories as a predictor for their estimation accuracy, and we can give you more accurate burn down charts than simply accepting those estimates at face value.  The deadline for the sprint is clearly marked with a vertical line.  If it looks like the Hours Remaining will chug down to zero before the deadline, you’re fine.  If not, it’s time to start cutting features like the BLINK tag that should’ve been cut so many years ago.