Introduction
I have noticed many bug tracking products attempting to add "Agile" project management to their offerings. I use the word "attempting" because I have yet to use one that really works. I also find it frustrating that many of these same products are setting aside useful features (like case commenting permissions in FogBugz) and enhancements in favor of failed attempts at making an agile PM tool. Here I'll try to outline, as I see them, the problems faced in trying to make an AGILE PM TOOL.Users Believe that they want an online Card Board (or kanban)
Unfortunately, most of us have believed for a long time that a nice Trello style online board would be perfect for managing an Agile Project. So far, IMHO, none of the tools have gotten this right AND I doubt they ever will. The great thing about a card board or board full of sticky notes is that you can grab the card, pass it around, set them out on a table, return them to board or put them on another board very easily. All of this while having a full visceral interaction with the rest of the team.The electronic card boards fail to allow uninhibited control of the cards. You have to click then drag a card somewhere AND unless you have a huge (45+ inches) touch screen monitor many of your cards end up falling off the screen or are unreadable. We always do our planning using physical cards. Even though the tool we use (FogBugz) has a so-called Agile Planner built in. It's just to unwieldy to use BUT we keep telling these companies that this board is what we want.
Suggestion #1: Stop trying to create online card boards and focus on managing the backlog (see below) or workflows (see below). When we ask for the card boards we really don't know what we're asking for.
Agile Projects all follow different workflows
Agile teams rarely have the same exact workflow. The workflows differ from team to team for good reasons. Differing product schedules, team size, organizational demands, etc. The tools that try to prescribe a single workflow, do so at the loss of potential market share. The tools that have a super flexible workflow editor don't always go far enough or it becomes difficult to see what the workflow really looks like. The tools that try to have a one size fits all approach tend to be berated for not really meeting anyone's needs.
Suggestion #2: Workflow is one place I think these tools can make big differences. If you are going to have a workflow editor then it needs to be robust enough to allow good workflows to be described. Managing the workflows is the absolute best use of these tools. It allows developers and users to easily move cases along the pipeline that your team has described. It does suggest "kanban" but as mentioned above it doesn't need to be visually like kanban, just conceptually. It's really just a pipeline approach.
The BACKLOG is what really needs to be managed
Some backlogs have tens of thousands of user stories in them. Managing that backlog effectively and allowing product owners to more easily garden is a missed opportunity in most of these tools. Once again no visual representation of cards is going to help here. It's too cumbersome and time consuming. The ability search and order stories in a backlog based on factors such as priority, area and cost are very important BUT also being able to tie these stories to epics on a road-map is even more important.
Suggestion #3: My backlog order rarely drives the priority of work. We follow a constantly changing road-map of EPICs based on current business needs. Being able to associate stories with Epics and then to a product road-map AND have that automatically fix the backlog order would be THE KILLER FEATURE! Being able to bring up a road-map of EPICS that I can modify then have the backlog automatically changed would be amazing.
Story Points versus Man Hours
Fogbugz just recently added story points as a second class citizen but still has no good burn down chart capability that uses story points. Most tools do have a burn down but the problem we always face is that some teams use hours while others prefer story points. To further compound this is how and when do you receive story points (or hours) for a story or task? Some teams allocate points once the developer has completed the work, other teams only allocate once a QA review has been done and still other teams use completely different methods.
Suggestion #4: This is a point I am less confident about. My gut says this capability can be fleshed out if attention is given to it (see suggestion 1). This may be a matter of allowing point allocation to be defined as part of the workflow. I believe that would work but once again the workflow editor must give a solid representation of how that workflow will be enforced.
Final Thoughts
At the end of the day my preference is for a basic issue tracker that allows me to stay in continuity with our end users and allocate engineers/QA to stories. We've used the FogBugz API extensively to build our own burn downs and other information radiators. For us having the programmatic access to our stories is of greatest importance, along with the added workflow capabilities. Enhancements in the areas mentioned above would be of most value to us.
