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?

Improve this question
1
  • 2
    I would expect trello to use trello anyway due to dogfooding so this doesn't necessarily tell you much
    – jk.
    Jun 19, 2012 at 11:49

7 Answers 7

Reset to default
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.

Improve this answer
2
  • 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, 2012 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, 2012 at 6: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.

Improve this answer
8
  • 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 1, 2012 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 1, 2012 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 1, 2012 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 2, 2012 at 0: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 2, 2012 at 10:14
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.

Improve this answer
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 :)

Improve this answer
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.

Improve this answer
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, 2012 at 2: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.

Improve this answer
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.