What is the role of traditional issue tracker when Scrum / Kanban board is used?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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 :)

Answer 5

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.

Answer 6

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.

Answer 7

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.