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:
- Short “Sprints” that produce
“Product Iterations”:Each “Sprint” lasts around 15-30
days, and a release cycle can contain one or many product iterations.
- 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.
- Daily “Scrums”: Once the sprint
starts, the team holds daily 15-minute meetings, in which each member of the
What tasks he/she worked on yesterday
What tasks he/she will work on today
Any Issues that might limit his/her
- 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
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
- 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
- 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.