Wednesday, August 12, 2009

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.

imageA 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!


Josh K said...

We have been doing something similar for a while. We don't do full Scrum, but it's close.

Our testing team tends to work on a seperate schedule than our dev team, we have to compensate for this.

As a result, we have two milestones 'Web Dev Cycle'(Dev Sprint) and 'Web QA Cycle' (QA Sprint). We have a weekly handoff meeting that moves cases from Dev to QA. If a case is reopened due to a bug, we can clearly see that it is holding the release because it is a 'Web QA Cycle' case, not a dev case.

What ends up happening is that the two cycles overlap a bit.


10:00 AM - 10:15 AM: “Cycle Progress” meeting

All day: Developers working on next release and fixing bugs in current release.

All day: QA working on current release.


All day: Developers working on next release and fixing bugs in current release.

All day: QA working to move current release to production.

Sometime: Site released to production.


9:00 AM - 9:30 AM: “CS Weekly Top 10” Meeting

10:00 AM - 10:30 AM: “Cycle Progress” meeting

All day: Prep for next cycle (department meetings, new bug data gathering, retrospectives, etc)

All day: Developers finalizing next release


9:15 AM - 9:30 AM: “Dev to QA Code Handoff” meeting

10:00 AM - 11:00 AM: “Management Priority” meeting

1:00 AM - 2:00 AM: “Next Release Task Assignment” Meeting

Afternoon: Developers working on next release and fixing bugs in current release.

Afternoon: QA working on current release.


All day: Developers working on next release and fixing bugs in current release.

All day: QA working on current release.

“Cycle Progress” – Discuss current progress, any issues or questions, last minute changes, and drop tasks that won’t make code freeze.

“Dev to QA Code Handoff” – We call this “Code Freeze”. Discuss release details, QA questions, database changes, and any other info important for testing.

“Management Priority” – Discuss new issues and priorities.

“CS Weekly Top 10”– Discuss top 10 customer support issues and possible solutions for next web release.

This has been working fairly well.

Thought I would share.

Daniel Root said...

Thanks Josh! Sounds like a good flow, definitely seems to work well. Have you all looked into the Kanban plugin for FB7?

Josh K said...

I have, but it looks a bit buggy right now. I plan on adding something similar, but just using the custom fields plug-in.

The company I work for (wink) wants to start using FogBugz as a full blown project management tool.

My biggest issue right now is how to organize things so I can get a big list of projects and their estimates for management. They tend not to care about the millions of individual cases floating around.

I'm thinking I can setup each major project as a top level case and make all the real work sub-cases underneath. This way management can see the status of projects quickly. They can then order these high level projects using the Backlog plugin.

Some limitations with this method, but it's the only way I know to create a priority sortable list of projects.

Daniel Root said...

At first this gave me pause, but the more I thought about it, it's really a matter of 'what is a project' vs 'what is a feature'. In our consulting company, it's pretty clear what a project is: we have a contract for each one :) In your situation, though, I could see it being fuzzier. What management calls a "project" may well be a complex "feature request", and therefore just a case w/ subcases as you describe.

The only other thing I could see doing would be to write a plugin. It wouldn't be too difficult, but it would be another project. Or feature request... :)

Josh K said...

A gnarly bug could also be considered a 'Project', even though it is not technically a 'Feature'.

FogBugz really does a great job organizing developer tasks. However, move up the food chain a bit and we're better off aggregating the data in some other tool.

I could probably figure out a 'do this, not that' work around for what we need, but it would be very hard to maintain at production speeds.

paul said...

I am having a series of difficulties very similar to Joshk. In house development is a lot more fuzzy, for example I have got 32 seperate inhouse "products" to support and then email etc. however "projects" cut across product boundaries, and the reporting "upwards" issue is a big thorn in my side - I have written tools to extract tasks from bugz and push into MS Project or taskjuggler, none of which entirely satisfies.

I would be very interested in seeing how others tackle this - for some reason the conceptual light has not come on.

Willem said...

I'm applying your suggested method in FogBugz, but I'm running into an issue. In my product backlog it becomes non-trivial to see which are the most important issues in a certain project because issues of all project are combined in one backlog (unless you apply a filter of course). Is there a reason why you use a cross-project backlog instead of a backlog per project? Am I missing a fundamental part of the Scrum methodology here?

John Fuex said...

Enjoyed the article, but I have one question. You are using the Milestone feature to break the work into Sprints. So how are you representing releases in this model?

For example, although the release notes feature in FB is nice. I generally compile them manually by filtering on the milestone. It feels like you need a higher level grouping for releases if milestone=sptring.

Jade Bond said...

"most of our customers don't even know we're doing this to them!"

Good for you! That's as far as I got and I already know I'm gonna like this. Your customers shouldn't care, shouldn't need to know, and frankly, most orgs. who do think otherwise are probably using fancy phrases and pitches to impress them rather than what one is supposed to deliver -- a quality product. Your products are better for having used this, right?