Skip to content

Feature Request: Trello and Fogbugz list consolidation, aka You can only have one boss

I have an idea for a feature enhancement to my two favorite project management tools. To set the stage: let’s ponder the following question. “What should I work on next?”

An individual can only divide their attention so many ways. Some are better than others, but a working set of anything more than 4 or 5 is unrealistic. The only way the extend this working set is to begin working off of a list. By building a list we are able to mentally “shelve” a piece of work until we are able to address it fully. Lists are fantastic productivity tools, instead of an interruption we simply put it on the list to be prioritized later.

When it comes to the real world, different types of tasks call for different types of lists. One reason we see so many different todo list management programs out there (don’t remember the milk, omnifocus, toodledoo, etc…) is that everyone approachs list management from a slightly different viewpoint. Software development is no different, and while there is also a great proliferation of software management tools I have yet to see a software project management tool that acknowledges and addresses the truth that the way most developers approach writing features is significantly different than how they approach fixing bugs. Those two primary tasks require different types of lists.

Sit down and watch a Project Manager while their team is in bug fixing mode, and then watch them when they are designing and implementing new features. The workflows are often drastically different.

Fixing bugs requires a lot of list management, sorting, filtering, categorizing, and bulk editing. The barrier to entering a bug needs to be low, and there needs to be good workflow automation to ensure that bugs don’t fall through the cracks. Often we are watching the list, assigning cases, tracking cases written vs. resolved vs. verified, in different functional areas and across priorities. A few high level charts help us see the big picture above the churn of the individual cases, but we need to be able to easily drill down to see if a specific concern has been addressed.

Organizing new features requires a high level of flexibility and visibility, along with the ability to attach design specs and user stories. Sitting down with users and doing interviews, capturing brainstorming sessions and fluidly adjusting priorities as new competitive possibilities emerge.

Great, so we’ve got one tool for bugs and one tool for features. No problem… except for one tiny little… hiccup. A developer can only really pull from one list at a time. As soon as you give someone two lists you have given up your ability to prioritize. Not only have you given up some control, but you’ve introduced an additional hurtle for the developer. Each time they complete a task, the developer needs to ask: “From which list should I pull my next task?” If I am required to stop and answer that question every time something is completed, what was the point of building the priotized list in the first place?

The result of this multiple list model is often that bugs get batched into discrete phases in software development. Developing features happens first, and fixing bugs happens second. Even if the bugs already exist, they are prioritized below the bugs. This is because you can really only work from one list at a time.

So how do we solve this problem?

I believe the solution is to allow users to create a Trello card checklist from a Fogbugz stored filter. With the appropriate cross product linking. How should that work? I dunno exactly, presumably it should work like an embedded version of fogbugz inside a trello card. Something that lets me batch up bugs and integrate them into the feature workflow. I’d like to be able to tell my developers, as quickly and easily as dragging a card to a list, “hey, fix these 10 bugs before you get to that next feature” without them needing to hop back and forth between products to see what they should do next.

There are 100 ways to do this wrong, and probably 6 ways to do this right. And the brilliance isn’t in the idea, but in the working bits at the end of the day.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: