So, a few months ago I came across a video by Fog Creek demonstrating the latest version of their project management software FogBugz. Wow. It looked great and appeared to have many of the features I had been searching for across the project management software terrain.

It was not until a couple of weeks ago that I actually set up a trial account. I signed up and began configuring FogBugz to manage a small project that would likely run its full course over three to four 2 week iterations. Let me start by saying that FogBugz has been a pleasure to work with.

Simple and Intuitive

The folks over at Fog Creek have done a good job minimizing the amount of clicks required to accomplish some basic tasks like creating new cases/features/bugs. Lists of bugs and features can be viewed by various characteristics through filters or by easily accessible reports. It might seem like these features would be difficult to get excited about in a world filled with things like Django and Rails, but FogBugz managed to get its factors right making the process “flow” really well.

Oh, The Integration

Wiki, bug tracker, project management/prioritization view, customer email (support), and source control all talking to one another… Again, while other applications might offer these same tools and integrate some subset of them, FogBugz goes a step further. The integration is tight and using these utilities feels like you are just dealing with another dimension of the same data as opposed to using two independent applications that are similarly branded and share some ability to markup references.

That being said, I still have not yet figured out how to integrate source control. You can download a plugin for Visual Studio if that’s your tool of choice, but my experiments have been taking place in a Linux environment. There are a pair of shell scripts available for download that should solve my problem, but it was not immediately clear to me how to use them. That’s my next mission.

Evidence-based Planning

I am a huge proponent of evidence-based planning and it looks like they’ve done a good job bringing this capability to those who might not be familiar with the process. The gist of it is that by capturing both project estimates (at the feature level) and actual time taken you can build a model of your estimate accuracy, development velocity and then in turn generate release forecasts based on historical data. So with a click of a button (and disciplined engineers who enter their estimates and elapsed times) you can have nice reports and charts showing when you are most likely to deliver your releases and with what features — all based on historical data. It is a powerful concept and well executed here.

FogBugz goes as far as to model the estimation error of individual developers. This sounds great and is a good story, but I wonder how useful this actually is in reality where developers learn from past experiences and self-correct; without some Bayesian filtering I could see these values become noninformative fairly quickly.

I am also still playing around with the best way of capturing my existing process where we use team-based story point estimation. It seems like it will be straightforward, but I am waiting for a few gotchyas lurking in the darkness.

Things That Make Me Go “Hmmm”

I have struggled a bit to fit my Scrum-based backlog management mindset into FogBugz. The bugtracker allows features and bugs to be prioritized. Those priority levels are totally configurable and could be defined for whatever level of detail you need. One thing I am missing is the ability to deal with micro sprint-level priorities (i.e. what order should this set of features be implemented in to minimize overall project risk?). I realize I could define as many priority levels as I need, but it would start getting a bit tedious defining that many sublevels. Fortunately, the project I am currently using FogBugz for is small enough that I can manage without that functionality. It does however become important when you start increasing the team size and dealing with projects where you really do have a rank ordering of feature priorities. It could be that ScrumWorks by Danube Technologies has just spoiled me with their Scrum-based backlog system.

Another thing that has detracted from my experience is its response latency, but let me say that it is not bad. I think it might be the case that the application’s simplicity and overall experience allows me to forget that it is a remotely hosted application. I wonder how responsive the server license version is, where you host the code and the server is just working with your projects and perhaps on-site. Maybe I will find out one day.

Conclusion

My preliminary run through FogBugz has been overwhelmingly positive. It is a powerfully usable application that offers tight integration amongst core tools used in not only the development, but also the support of software applications. Check out the official highlighted feature list.
If you are looking around for some project management software then definitely check FogBugz out and see how it fits with your current process. I am still waiting to see how FogBugz will fit into our overall process once it has had a chance to run the full cycle — so far, it is looking good.