How To: Apply Scrum Using FogBugz 7

I should preface this post by saying I'm by no means a Scrum expert, or even very good at applying it in our workplace. What follows is what I try to do on our projects, and I'm posting here as much for feedback as for instruction.

If you're not familiar with Scrum, it's an agile project management methodology that developed in the 1990s that values getting work done over excessive, time wasting processes. The history is rather fascinating, but you can read more about all that on the WikiPedia article. Here's a quick overview of the process.

A team is formed of a Scrum Master to oversee the process, a Product Owner who represents the customer in the process, and team members who will be doing the work or are interested in the outcome. The team starts or add to a Product Backlog, which is a list of all of the features needed for a project. These tasks are given a priority and estimated. The project is worked on in chunks, typically from 2 to 4 weeks long, called Sprints. Each Sprint begins with a Sprint Planning meeting in which the team members decide which items from the Product Backlog will be completed in the Sprint. Every day of the Sprint, a very short meeting is held where the each team member says what they did yesterday, what they will do next, and if there's anything holding them up. If something is holding them up, it's up to the Scrum Master to make sure the problem gets resolved. At the end of the Sprint, the Team has a working product that is shown to the customer in a Sprint Review and/or deployed into production. Feedback is received and items added to the product backlog, and the process repeats until the project is complete. I'm sure true Scrum Masters will balk at some of this - we typically combine what would be a Sprint Review and Sprint Retrospective, and are fairly informal with the process. We don't call the meetings or people by their official scrum names- in fact most of our customers don't even know we're doing this to them!

Setting up a Project For Scrum in FogBugz 7

Most of our projects start out with one or more meetings with the customer where we gather requirements and make sure we understand the problem domain, and all of the features that the customer expects. Especially useful at this stage is learning the roles and vocabulary that the customer uses. Job roles, like 'Manager' or 'Human Resources Staff" are cues for application roles that are needed, and can be used to ask the customer more about what sorts of things each type of user needs to be able to accomplish in the app. We gather any applicable paper forms or screenshots. Depending on the customer, we may have the customer prioritize each feature, or since the customer often sees everything as 'high priority', we may do this ourselves.

After all of this, set up a new project in FogBugz with a name like [CustomerName] - [ProjectName], and set up a few Milestones, each named 'Sprint [DueDate]', with the due date set. In addition, an "all projects" Product Backlog milestone has been set up, with a due date in the distant future for reasons that will soon be apparent. Each feature is entered into the project and assigned to the 'Product Backlog', and the team estimates it. If new features get requested during the project, they get added here as well. The case list is sorted by priority, then Milestone. In the end, we have something that looks like this:

Estimation Tip: You can click on the 'Estimate' cell in list view to quickly enter an estimate.

As you can see, high priority (2) items are at the top and low priority (3) items at the bottom. There is a plugin to allow assigning each case to it's own product backlog priority, but the default 1-7 work ok for our typical project size. Here is where you first see the fruits of your efforts - the most important work is bubbled to the top of the list. You can safely pull from the top and be confident you're working on the most valuable items for the customer.

Scrum Workflow in Fogbugz 7

With the product backlog started, it's time to get started working. Get the team together for a Sprint Planning meeting and select a sprint's worth of tasks from the top- typically about 2 - 4 weeks worth - and click 'Set Milestone' to set the milestone to Sprint - [Due Date]. Sort by Milestone, and get something like this:

Clarify any items that need clarifying, and add subcases as needed to break up tasks. Items may be assigned to individuals, but an alternative is to leave them assigned to a 'Virtual User' like 'All Developers' and let developers pull what they are interested in working on. Don't plan additional sprints yet, though. Scrum is about managing change, at it could well be that by the end of the first sprint, the product backlog has changed. Priorities shift and features get added or removed, so any time you spend beyond planning the immediate sprint is most likely wasted.

Now everybody gets to work. Each day, the scrum master should spend 15 minutes in a Daily Sprint with the team asking what each one did, what they're doing next, and if there is anything holding them up. If something's holding them up, the Scrum Master's job is to unstick them as fast as possible. Workers should work from the top of the list, to the bottom and use the 'Working on' feature to track time and mark cases as resolved once they're done. The scrum master closes the tasks once he's confirmed they are really done.

Working this way gives you one of the signature outputs of Scrum - a burn down chart. To view it, go to Reports -> [Project] and choose the Milestones (typically, just a single sprint) and priority. You see a chart like this:

Report Tip: most reports show estimated actual time, as opposed to the estimates you’ve entered. This takes some getting used to.

This shows, over time, how much work remains, and how fast you are reaching the official due date. As the line goes up, more time is being added to the sprint. As it goes down, tasks are being resolved. In this one, you see some tasks were added initially, and slowly got worked on, and then finally a big chunk got knocked out. Then a pause, and work began again. Our hours are off because we have a bunch of cleaning up to do in FB. In this case, it's saying we have as much as 140 'real' hours left, and as little as 5. The bottom is more accurate in this case. This really shows how good FogBugz algorithms are though - even with a bunch of garbage in the system, it's producing relevant info about the velocity of this project. Hopefully yours looks better than this one, but I had something come up in the middle of this particular project.

Once the sprint is done, show the work to the product owner and team in a Sprint Review. Discuss and note any changes, new features, bugs, etc. and put them in the product backlog. Prioritize, estimate, and then have another Sprint Planning meeting. Lather, rinse, repeat!

Parting Notes

I’ve left out a few key points to making this work. First, meetings should be timeboxed. That is, they should be a set time and if you hit the limit, then quit anyway and do better next time. Daily Sprints should be 15 minutes, Sprint Planning and Reviews are longer – 1 – 4 hours, but should be short. Second, estimation and prioritization are their own topics. There are several common tactics for approaching these in Scrum. Find one that works and use it!

Like I said, I’m no pro on this stuff, and with the variety of work we do, I can’t say we apply this well in all cases. Sometimes real-world concerns like fixed prices, time crunches, and customer demands make us abandon parts of this just to get the job done. However, to the degree we do, FogBugz helps tremendously in allowing us to very easily manage and track projects. If you’re using FogBugz for Agile development, I’d love to hear about it! Leave a comment, email or tweet me!