Using FogBugz On Demand or FogBugz On Site? You should check out the Iteration Planner instead.
FogBugz is flexible. Whether your team uses Scrum, other agile practices, or any software development methodology, FogBugz is built to adapt to your team’s needs. FogBugz is hungry for your team’s data, and has been designed so that getting your cases into FogBugz is quick, easy, and automatable.
While there are many different ways to approach agile software development—from a light-weight Scrum approach to a full embracing of a defined agile process—FogBugz can support your team however you choose to get started.
At the end of the day, your job is not to “do agile” or “do scrum.” Your job is to ship software. Implementing agile practices while using FogBugz will help you to do that.
Projects to group cases together
Use FogBugz projects to group cases together at the highest level. If you’re a product company, your projects will usually map to your products. If you’re a consultancy, your projects might follow a pattern of “Company Name – Project Name”.
Areas represent subdivisions within a project, which might indicate separations in your codebase or scope of responsibility.
Iterations and Sprints = FogBugz Milestones
With agile and Scrum, you’ll be more interested in subdividing projects by time. Iterations or sprints are represented by FogBugz milestones. A FogBugz milestone (a sprint) is a collection of cases grouped by a target completion date. Milestones generally are project-specific, but can be global to all projects as well.
You’ll want to add one global milestone called Backlog that represents any case that doesn’t belong to a particular sprint. Set the completion date far into the future. Most new cases will originate in the Backlog milestone until they are ready to be added to a sprint.
At the beginning of each iteration, you’re going to create a project-specific milestone for the cases to be included in the upcoming sprint. Name this milestone with an agile convention – either the sprint number or iteration end date. You might name it Iteration 23 or Sprint March 8. Set up a due date that aligns with the end of the sprint. You can make previous milestones not assignable so only the new sprint milestone and the backlog milestone can receive cases.
Setting up filters to track cases
FogBugz filters make tracking cases a snap. Use a filter to display the entire project’s backlog of cases. Create a filter that looks for active cases within your project that are in the Backlog milestone. Save it and name it e.g. Project Backlog.
You’ll also want to create a “Sprint Backlog” or “Current Iteration” filter that represents all of the work to be done in the current sprint. You should update this filter at the beginning of each iteration to point to the newest milestone.
Share any filters that are going to be used by the entire team. Once your milestones are planned, you can see their planning order in filter view with the Backlog Order column. Also, take a look at the Iteration Planner for convenient ways to organize cases for your sprints in the latest version of FogBugz.
Estimating developer effort
A case in the backlog can represent a user story, requirement, or anything that adds value to the project at hand. Usually, items will be prioritized based on a combination of development effort and business value. Items with high business value that are easy to implement will naturally be prioritized over items with lower business value that are more difficult to implement.
One way to estimate development effort is based on time. We usually recommend estimating software tasks once these tasks have been broken down to small units of work, but your team might choose a more general approach and allow for cases to be estimated more broadly, e.g. “1 hour”, “4 hours”, “1 day”, “3 days”. If you use time to estimate development effort, you’ll be able to take advantage of Evidence-Based Scheduling in FogBugz (more on this below).
You can break cases up into sub-cases, which helps make estimation easier. The sum total of estimated hours will bubble up to the parent case.
Alternatively, you might choose to add a custom field to e.g. track story points, but keep in mind that you lose some of the built-in features of FogBugz when you don’t track time-based estimates against cases. This may be fine, but you want to be aware of the tradeoffs before you get started, namely, that you won’t be able to take advantage of the time-tracking capabilities of FogBugz and the reports that come with it.
FogBugz also has a priority field with seven levels which you can use to help indicate what you should work on next.
Choosing cases for an upcoming sprint or iteration
Whether you use Story Points, Business Value, or some other weighting mechanism, your project backlog filter needs to be sorted appropriately so that the cases you should be working on next make their way to the top.
When choosing cases for an upcoming sprint, you’ll be using your project backlog filter and bulk editing items from the top of that filter to move them into the next iteration.
If you’re adding estimates to cases to represent developer effort, you’ll see a sum of the total estimated hours at the bottom of your Current Iteration filter:
Tracking time spent on cases
Use “Working On” to let FogBugz track time in cases. When FogBugz tracks time, you’ll know how much time is remaining on cases. This also helps to generate scheduling reports (such as a burndown chart) that take into account work remaining and the accuracy of the estimator.
Keeping tabs on the current sprint
Everything is set up, you’re tracking time, and you need to check on how things are going. Your first recourse is to use FogBugz filters to look at which cases are still open and how much time is remaining.
If you’re using estimates and tracking what you’re working on, you can use the Burndown Chart, part of Evidence-Based Scheduling in FogBugz. Go to the Scheduling menu and select your project. Then choose “Burn Down Chart”.
Note that the Burndown Chart provides a confidence interval around the number of hours remaining, contrary to the filter which simply displays the estimated time remaining. The Burndown Chart is driven by Evidence Based Scheduling, which uses developers’ historical estimation accuracy to predict how long the estimated work will actually take. This chart will automatically update when you modify estimates or add time to a case.
If you have a long history with agile software development, there might be tools missing from FogBugz that you simply can’t live without. If that’s the case, please contact us. FogBugz is under active development and we’re always looking for ways to improve.