Wednesday, June 23, 2010

Simple Bug Tracking with Google Docs

It may seem strange for the maker of a commercial bug tracking tool to be advocating the use of Google Docs for a simple bug tracking solution, but that's what I'm going to do in this post. Don't get me wrong - I don't really believe that Google Docs is the best way to track issues in the long run, but there is a substantial amount of learning that can be gleaned when you start out with the simple spreadsheet.

Bug tracking, first and foremost, is about communication and your team's process. Even if you don't adhere to a structured methodology, you still follow some sort of process. Your process may be "Work on whatever you feel like working on." You might have standup meetings each morning. You might even (gasp) be following an old-school waterfall process.

But whatever the case, you and your team do have a flow to the way you do things. Don't interrupt that flow without a good reason. If it's working, keep doing it.

So when you start out a new project with a new group of people, you'll need to find that flow. It is not the time to enforce rules, but to figure out what works. Every team and project is different. What worked well on the last client project may not work as well on your new internal project. This is true for pretty much everything - including bug tracking.

In the early days, the flexibility of a spreadsheet can be very helpful in finding your team's bug tracking groove. We like Goolge Docs because they're easily sharable and easy to work with, but any multiuser (online) spreadsheet will do the trick.

Start off with a single page with a sinlge column titled "Bugs". If you're used to monstrous bug trackers, you might be surprised how far this can get you.

Pretty soon, you'll want to add more columns. Dates, status, priority. Go ahead add them.

Eventually, you may find you want to group tickets together. Tabs are great for this. Cut and paste is your friend.

Charts? Try a few.

After a week or two, take a break. Stop and evaluate how your team is functioning with your spreadsheet. Some things will be well used and working smoothy. Others, not so much. Is that column for severity really helping? What about those charts you added? Do they give you actionable information or just look pretty? Are you breaking out your tasks in a logical way? Most importantly, does everyone know what they're supposed to be working on? Are your milestones being held, or are they just a date field that gets changed when you run out of time?

At this point, you have some good insight into your team. It's time to break away from the spreadsheet and get something a little more robust. Alas, the flexibility of the spreadsheet is it's downfall. They're also fragile, and every team I've ever been on eventually moved away from them for that reason. They get cluttered and messed up over time.

But since you started with the humble spreadsheet, you now know exactly what to look for when you go shopping for a bug tracker. You know what you need to make the software work for your team, not the other way around.

Incidentally, this is exactly how TrackJumper was developed. We started out with a Google Spreadsheet to track bugs. Once we figured out the best process for managing manage bugs in real life, we turned it into an app. We built in just enough flexibility to cover our experiences without introducing an unnecessary level of complexity. We're pretty proud of the end result, and hope you'll like it too.

No comments:

Post a Comment