How issue tracking systems fit agile development?

July 17, 2008 by Przemysław Bielicki

Let's assume you work in an agile team and follow the Scrum framework. Let's also assume that you collect and track requirements "using" user stories. Mike Cohn in his brilliant book User Stories Applied somehow discourages from putting user stories into "digital tracker". In his opinion the best place for user story (most probably yellow or green sticker) is cork- or whiteboard.

As far user stories are concerned I totally agree - but what about programming tasks, bugs and other ah-hoc "low-level" developer's communication? How can small sticker with information like this As a user I want to ... [in order to ...] help itself developers deliver the user story to the customer?

Isn't some tool help needed here?

Agile development process
In my previous team we used Scrum i.e. we collected user stories from Product Owner, estimated them during planning poker session, planned the release and Scrum iteration, were meeting everyday during daily Scrum meetings, demoed product after iteration and finally we retrospected finished iteration. This is all about high level project tracking i.e. on the user story level. But we - developers - need to track also issues i.e. smaller tasks that can be implemented, fixed, commented, investigated, discovered, applied, etc.

The tool that was helping us track project from the developer's perspective was JIRA. This is not sponsored post and nobody pays me for advertising JIRA (maybe they should :) but I'm going to recommend this tool in the next paragraphs.

Let's break the story
OK - we have a user story As a user I want to create new account in the system. And this user story is cool from the user's perspective but it needs to be split into tasks during planning session. You need to:

• Create database table for users
• Create class representing the user
• Create Data Access Object (DAO) for user objects
• Create service class that integrate everything i.e. (basic flow) checks input parameters, creates user object from given input parameters, create transaction, stores user into database, handle exceptions, close transaction, return OK or error message back to the UI
• Probably create UI to access this feature from webpage or thick client
• Create automated tests including UI tests

As you see developers have a lot of work here with one simple user story. And these single tasks should be tracked.

Why to track it?
You should track your issues in order to store useful information about each task, decisions taken, problems occurred, etc. You should track your issues also because after couple of months you could ask someone a question why something was implemented this way not the other way. The answer will be in the issue tracker with links to the source code (you could see single lines that solved the problem). The communication history will be there for you.

Developers also need to communicate with stakeholders, users, bug reporters, etc. in an effective way. And it's not always possible to have them on-site. They have to be able to give the team feedback even if there is nobody in the office - you cannot call development team members when they are at home or during vacation.

As you can see there is many arguments for tracking your projects' issues.

How to track it?
Tracking issues is the job for issue tracker, of course :) Issue trackers enable bi-directional communication i.e. on the one hand customers can report problems and new features (?) and developers on the other hand can ask customers (or other developers) for clarifications (whether they correctly understand the issue, what is really necessary, etc.).

Of course, you can employ Excel sheet to track your issues but this "solution" does not scale and if your team is bigger then you alone you should resign from this concept - employ issue tracker instead.

Which issue tracker to choose?
You can find quite comprehensive comparison here. The decision is not easy because there is many systems that do the job but I would personally recommend JIRA.

JIRA is the best issue tracker I've ever seen and worked with. This tool is cool, sexy, easy to use, intuitive, easy searchable, etc. I can enumerate many many more advantages but I want to keep the size of this post reasonable.
This tool encourages everybody to add new issues/bugs, to comment, to fix them! It is the tool every decent software development team should use - and not only the agile one. JIRA is not only a great toy (yes, developers love toys) but extremely valuable stuff that helps us doing the software.

Of course JIRA is not the only choice and it's not very objective recommendation as I don't know many other trackers. However I worked also with Mantis and many internal issue trackers (yes, you know this kind of crap).

Should I resign from paper stickers?
NO! Keep your user stories on the board and meet everyday by it. It's much better to meet by the physical table and stickers that you can actually touch and move around the board. Don't abstract and digitize things that work good in the real world.

But when it comes to bugs, task and issues use issue tracker. It cannot be tracked other way effectively.

What about being agile?
If you are using issue tracker you still can "be agile", however your tracker has to be agile-compliant. Some issue trackers - most probably your internal corporation-wide crap - are not able to fit the agile world. With some trackers it's hard to create an issue, not to mention commenting it and passing some communicates at all. Some issue trackers can be successfully interchanged with an Excel sheet and the quality of the "tracking" will be the same.

Conclusion
Originally I wanted to conclude this post using such sentence "Issue trackers are definitely part of the Agile Development world!". However, later I realized that it's not true. JIRA issue tracker is one of the tools that definitely fits the agile world but it doesn't mean that all issue tracking systems fit this world too.

Not every issue tracker fits the Agile Development world - you should definitely track your projects' issues but if you want to stay agile use an agile issue tracker.

Permalink