35

From a very high level view, to me it seems there are generally 2 types of Project Management tools:

  1. Traditional issue trackers like Fogbugz, JIRA, BugZilla, Trac, Redmine etc.
  2. Virtual card boards / agile project management tools like Pivotal Tracker, GreenHopper, AgileZen, Trello etc.

Sure, they overlap in one way or another, e.g. Pivotal Tracker tasks can be imported to JIRA, GreenHopper itself is implemented on top of JIRA issue base etc. but I think one can still see the difference in orientation between those two types of tools.

Traditional issue tracker seems to be used even in companies otherwise doing agile project management. My question is, why do they do that? I also feel that we should use an issue tracker in my company but when I'm thinking about it, I'm not actually sure why should we need it.

For example, Trello development seems to be managed by using Trello itself (see this virtual wall) even though they have access to Fogbugz, one of the best issue trackers around. So maybe we don't need traditional issue tracker when we'll be doing 100% of our work in an agile manner using one of the agile PM tools?

Joel Spolsky
  • 7,074
  • 21
  • 56
  • 49
Borek Bernard
  • 1,075
  • 1
  • 11
  • 16
  • 2
    I would expect trello to use trello anyway due to dogfooding so this doesn't necessarily tell you much – jk. Jun 19 '12 at 11:49

7 Answers7

34

There are (at least) three different ways a team could work. Choose the one that works for your team.

1. Detail vs. High-Level Overview

Use the issue tracker to keep track of individual tasks. Use the card board to maintain a big picture of the major features, as a summary of the tasks in the issue tracker.

2. Bugs vs. Features

Use the issue tracker to keep track of individual bugs and customer service requests. Use the card board to keep track of new features under development.

3. Milestone software delivery vs. continuous software delivery

Use an issue tracker if you deliver large blocks of new functionality irregularly (for example, if you are the Windows team and there's a new version every few years). It is ideal for a development process in which large, completed projects are delivered to customers all at once (that includes games, embedded software, and traditional software based on annual or semi-annual releases).

Use a card board if you are delivering new features continuously to customers as they are developed, for example, on a web team that has continuous or very frequent delivery of value to customers. In this scenario your software development process is almost like an assembly line and less like a project with a beginning and an end.

Joel Spolsky
  • 7,074
  • 21
  • 56
  • 49
  • Option 2 doesn't seem very workable to me, since you're effectively tracking the same thing (what people are doing) in 2 different places. This would be particularly problematic if you were using Kanban. Have I misunderstood something? – vaughandroid Jun 19 '12 at 10:01
  • 2
    Yes, you would be tracking what people are doing in two different places, but to the extent that they think of "fixing bugs" and "writing new code" as different activities, this may be the way people like to work. You're also tracking what people are doing in their calendar and their email inbox... so, four places! – Joel Spolsky Nov 28 '12 at 06:11
13

I think the simple answer is that traditional issue tracking software helps you to manage the backlog, whereas the scrum board helps you track the current sprint and the release.

Of course it's possible to use either type of tool to do both, but you end up having to make some compromises.

Bryan Oakley
  • 25,192
  • 5
  • 64
  • 89
  • Great answer. That may be why I feel JIRA + GreenHopper could be a great solution - it provides both a traditional issue tracker and a virtual board on top of the issues. – Borek Bernard Jan 01 '12 at 10:11
  • @Borek: I've used Jira + GreenHopper. I wouldn't choose to go that route again. If you don't have remote workers, physical cards on a board are the way to go for managing your sprint. – Bryan Oakley Jan 01 '12 at 15:19
  • 2
    We are a distributed team. Any other suggestions other than JIRA + GreenHopper? What you didn't like about that combo? – Borek Bernard Jan 01 '12 at 21:07
  • @borek: we spent way too much time fiddling with the UI -- it's not a particularly good UI IMO. – Bryan Oakley Jan 02 '12 at 00:23
  • UX is exactly my problem with JIRA, I was just hoping that GreenHopper fixed that but I will have to find out. – Borek Bernard Jan 02 '12 at 10:14
  • 5 years later... I'd be curious to hear your thoughts on [Clubhouse](https://clubhouse.io). We're trying to build something that provides a lot of the flexibility and features found in these older products, but without the complicated or bloated UI. – Andrew Childs Jul 24 '17 at 21:22
  • @AndrewChilds: quite honestly, as soon as I read "Make stand-ups easy— or totally redundant." I lost interest in the product. Standups are so very much more than just data gathering. I still might check it out, but I'm concerned that the product doesn't truly "get" what scrum is all about – Bryan Oakley Jul 24 '17 at 21:47
  • Good feedback @BryanOakley - we'll update that copy to make it clear that we're really trying to facilitate process, not replace it. Thanks! – Andrew Childs Jul 26 '17 at 01:00
5

Full disclosure: I'm a little biased because I'm the GreenHopper product manager at Atlassian, but I've also been involved with Agile development outside Atlassian for a long time

Having just an Agile planning tool or just an issue tracker is definitely viable. The problem is that it's sub optimal. In my experience it's sub optimal because:

  • Product planning usually occurs at the Epic and Story level in a backlog. Agile planning tools are great here
  • Yet as the old saying goes, no plan survives first contact with the enemy. In this case after your first few releases you are bound to end up with bugs (and other feedback) that is logged by QA, customers, support etc. These need to feed back in to your planning but not overwhelm it

As such, having just an Agile planning tool is great, but as your product matures and you get more external input it becomes harder and harder to effectively manage that input. Some of these external contributors simply can't contribute in a 'managed Agile backlog' type of way, they just want to submit their issue and move on. That's where having an issue tracker allows you to engage these contributors and successfully manage the ongoing business of keeping product development going.

I'd say that you need both tools. You also really need them to be integrated, otherwise you'll spend all of your time trying to keep the two in sync.

Shaun Clowes
  • 151
  • 1
  • 1
3

Some products are a little more optimized for stories and tasks versus defects, but really there isn't a big difference. Any good agile PM tool that doesn't impose too much overhead in terms of enforced structure or required fields, can easily be used for defect tracking. My current project is using a single tool for both tasks and defects and it works ok aside from the product being a POS :)

jiggy
  • 1,590
  • 11
  • 15
2

We run an issue tracker called DoneDone which fits #3 in Joel's answer - the more traditional role of a bug tracker. Indeed, we built it because our consultancy historically delivers lots of code (in the form of websites) at non-regular intervals.

We did a little outreach to our DoneDone user base a month ago though and quite a few of them have requested a front-end akin to Trello and Sprint.ly for their more continuous code/release cycles. Another useful piece of insight was that many of these folks are using DoneDone before their QA ever begins so they'd like all that data in one place as their projects (or features) move between cycles.

My two cents is it's all data with a bit of workflow applied. The distinction is really the UI and how it accommodates the team and whichever methodology and/or project phase they're in at the time.

Community
  • 1
Craig
  • 21
  • 1
  • 1
    Hi Craig, welcome to Programmers SE! Thank you for your answer and for following our policy of disclosing your affiliation with products you include in your answer. What you did is perfectly acceptable. (Just be careful you don't overdo it and that, like this answer, what you post is applicable to the question ;) ) +1, and welcome to Programmers SE :) – jmort253 Jun 19 '12 at 02:01
1

Issue tracking isn't project management, even though many of the tools are designed to allow you to do both, so therefore one system doesn't really replace the other,

A Kanban board gives you a lovely overview of the work you have that is current and outstanding, and let's you know at a glance what the priorities are, whereas an issue tracker allows you to tie your issues to your version control system, and works better as a means of logging everything that should be in your Kanban backlog, but with additional detail that would otherwise make your Kanban board a real mess to read.

The thing is that the two concepts work well together and support each other nicely. Of course, if you have a system that can give you the best of both worlds inside one neat application, then it may blur the lines a little, however the concepts still remain reasonably separate.

S.Robins
  • 11,385
  • 2
  • 36
  • 52
1

I don't know if there is a clear answer, so I'm just reporting my experience...

For years I was completely sold on true bug tracking systems, like FogBugz, Jira, Trac, etc. However, I recently took a job where we are Agile (truly being agile, not just doing Agile). We don't have long, historical lists of bugs or nice-to-have items.

There's just no use for such a tool. Anything that's important we get to pretty quick. Anything not so important, well, what's the point?

It is quite liberating to not have a huge backlog of stuff we know we won't have time to do, while at the same time knowing we are delivering the best value every day.

David Frahm
  • 121
  • 1