FogBugz 7 Feature Predictions

Per company policy, the folks at Fog Creek will not comment officially on the features of unreleased products.  So, users like us are left a bit in the dark about their development plans for FogBugz 7.  But the recent responses in the FogBugz Support Forum do provide some insight into the types of features we may see.

While Fog Creek does not comment officially on what features will be included, I think we can piece together frequent user requests that receive positive responses from the FogBugz team and blog posts from the FogBugz team to create a picture of the key features that are likely to be addressed in FogBugz 7.

Export Filter to CSV

This is an easy prediction because they explicitly said this would be a feature when describing a third party tool to achieve this.

In the next version of FogBugz, this action will just be one click, but right now you can [use John Januszczak's] awesome tool.

There is also a recent support response from Rich Armstrong, of Fog Creek, that explicitly says this feature is done.

I think I’m safe in saying that this feature is code-complete.  Unless some other, more important feature doesn’t play nice with it, kicking it off the card, it’s safe to say this will be there.

Discussion Forum Subscriptions

Very little has been said about the Discussion Forum and the feature set has not significantly changed in a long, long time (if ever).  But there are at least one or two nuggets we can expect to be added to the discussion forums: the ability to subscribe to a thread and the ability to attach files to posts.

While these two features will be greatly appreciated by customers, I’m not sure if those minor changes will be enough to dissuade some of the harsher critics of the discussion system.  We can say with pretty strong conviction, due to this request and response, that we won’t be seeing a major “social web” overhaul to the discussion forums to include voting of topics along the lines of UserVoice.com.

Rich Text Editor for Cases

Remarkably, looking at the recent entries in the user forum, there isn’t a lot of chatter about this right now.  But when FogBugz 6 was released, this was a hot topic because they added a custom rich text editor for the FogBugz wiki but did not include it in the case editor.  This question came up when I attended the local stop on the FogBugz World Tour for version 6 and the immediate answer was that they cut that feature in version 6 to achieve an earlier release.  We discussed it briefly and there appeared to be a strong desire within the company to remedy that in a future release.

You can find lots of forms of this feature request in the support forum and very little user  dissension.  Another reason to suspect that this feature will make the FB 7 release is the current difficulty of linking to a wiki article from within a case.  The wiki’s text editor handles linking to cases quite well but the case editor is very limited in that respect.  It seems unlikely that they will create a new linking mechanism from cases to wiki articles when they could kill two birds with one stone by implementing the wiki style editor for cases.

Which leads us to…

Static Wiki Article ID’s

I discussed this at the FB World Tour as well with one of their employees.  A key issue in the wiki linking system is the current dependence on the Title of a wiki article in some forms of linking.  The Fog Creek employee, I don’t remember which one, was well versed on this topic.  You could tell they had talked about it internally quite a bit.  Clearly, the current system is imperfect.  I suspect a change here may be very minor.  Linking by the Wxxx number in the URL is already possible.  Thus, you may find that ID value promoted more heavily in the next major release.

For reference, you may look at this support forum thread that touches on this topic.

Wiki Anchors

The same thread discusses this common feature request.  The current inability to establish good ol’ fashioned Anchors within a wiki article has annoyed many FogBugz users and is one of several wiki limitations that hurts the perception of the tool.  It will be interesting to see how Fog Creek handles this request.  As there is an easy, long standing HTML method of achieving this but it might not flow well with their current wiki implementation.

In general, there needs to be a way to link to a part of a wiki article rather than just linking to the top of the article.  

Case Descriptions

I don’t have the stats to back it up (this is a hobby after all), but I believe the single most requested feature for FogBugz is to add an editable Case Description field.  Apparently, this is quite the controversial feature request.  Given the nature of the other changes being considered for this release, more on that later, I have to suspect that this finally makes the cut in FogBugz 7.  

The primary reason I think it gets added, in one form or another, is that the lack of this feature is a barrier to sales and generates a small buzz of bad press.  However, I suspect that the feature may either be downplayed slightly in the UI or it may be optionally removed from the UI because of the perception that extra fields overly complicate the tool and decrease the likelihood that a user will actually use FogBugz.  And if nobody uses the tool, the initial sale will be for naught as the customers won’t renew their contract with Fog Creek.

Custom Work Flow

I believe that the second leading user request, and possibly the most boisterous request, is for the ability to customize the work flow of FogBugz.  In several recent versions of this request, the official response has been along the lines of this response by Rich Armstrong:

A definite design goal for FogBugz 7.  The usual disclaimers about it actually making it in there, but it’s a biggie.  Thanks!

How customizable will it be?  That is a very good question.  From what I’ve read I think there are two primary areas of concern that they are likely to try to resolve.  The first issue is that FogBugz has always assigned resolved cases back to the original person that opened the case.  Many users have stated that they would rather resolved cases be assigned to a specific person, usually a member of the QA team.

The second issue is that many potential users have previously established workflows that include more states than FogBugz uses.  For example, teams may be used to assigning resolved cases to a state such as “To Review” and then after validating they may move the case to a “Reviewed” state.  Finally, when the feature is deployed it may move to the “Closed” state.  Everybody has a slightly different take on this process and FogBugz’s rigid workflow grates at users of other tools.

Of course, the beauty of FogBugz is its simplicity.  Implementing this feature and maintaining simplicity seems like a mighty challenge.  But if Fog Creek hopes to capture a significantly larger market share this is a challenge they need to “resolve (complete).”

Sub Tasks

FogBugz’s case linking system, though brilliant in its simplicity, drives many users crazy.  Add to that the fervor of EBS (Evidence Based Scheduling) junkies and the growing masses of Agile Developers that are wired into the User Story and Task mindset and you have a minor revolt among some users due to the lack of a formal sub-task system.

I think users had issues with this in earlier versions of FogBugz, but the EBS system encouraged these complaints with the release of version 6.  The basic issues are best described in an example.  

Let’s say I have a request to add Feature X to my product and as the developer I set an estimate of 16 hours on the corresponding case.  I tell FogBugz I’m working on the case, so the timer is set against my 16 hour estimate.  I then decide there are really three steps in the solution and thus I create a case for each step and assign an estimate to each of these three new cases.  As far as FogBugz is concerned, I can only be working on one task at a time and the cases are not hierarchical in any way.  This causes several problems.

First, FB totals my estimates from the original case and the three new cases where as I intended for the three cases to be included in the original cases estimate.  Second, if I tell FB I’m now working on Task One of Feature X, it stops the counter on Feature X.  According to some users, this is akin to something terrible happening to the Time Space Continuum and Marty McFly’s death is now imminent.

Granted, there are obvious ways to work around this issue.  But the perception of a limitation is a problem even if they don’t all agree that the current design is wrong.  Fog Creek, according to their support forum responses, is taking it seriously.  But their response has not been overly encouraging.

We’re looking into sub-tasks for FogBugz 7, but have not yet determined whether we’re going to include this functionality.  We certainly recognize the usefulness of this kind of organization, but we’re not yet sure whether we’re going to be able to deliver, much as we’d like to, as it’s not as simple as it seems.

I have to believe they can find a way to add some support for this feature without crippling the system with complexity.  But this is obviously not an easy feature to add to FogBugz.

Agile Friendly Priorities

FogBugz was built by a decidely non-agile team and thus the feature set does not play nice with a lot of the more common Agile Development practices.  A relatively common request by the agile crowd is the ability to assign specific and unique priorities to each case to create a strictly prioritized product backlog or a sprint backlog.

I’m not sure this is a high priority item within the Fog Creek team because they don’t use an agile methodology and so they don’t need the feature for internal use.  However, I think they acknowledge that a significant portion of their potential user base is using or wants to use Agile Development.  By supporting this feature they could put FogBugz in a much stronger market position and possibly challenge some of the more established Agile Project Management tools.

What would a feature like this look like in FogBugz?  One possibility is to increase the ties between the wiki and the case list and leverage the power of the wiki and HTML to do some basic case management outside of the normal FogBugz paradigm.  The other, more brute force approach would be to add one or more optional fields to the existing case management for sequencing cases and Agile Project Management.

I think this feature request is a specific instance of a more general problem that FogBugz 7 may try to address.  How do they change FogBugz to more clearly position it as a general Project Management Tool while retaining the simplicity and usefulness of the core product?

With any luck, we may see some answers to these issues soon.  Whatever they do, this release could drastically alter, for better or for worse, the general opinion of FogBugz in the development community.

Okay, When?

Of course, that leaves us with one final question.  Regardless of what features are included, when will we get it?  All indicators are that we can expect FogBugz 7 to be released this year if at all possible.  But the safe bet, given the current pace of communication out of Fog Creek and the time spent on beta testing of FogBugz 6, would be that it will be at least the 3rd quarter of 2009 before a new release could hit the streets.