What is the best issue tracking solution for an Agile team? Agile development stresses the use of “the whole-team approach” as well as transparency so that
The whole-team approach
A software development team typically contains people who fill roles such as:
- Business Analysts
- System Administrators
- Support Staff
Historically, people in these roles have been working in isolated silos, where work was often
"thrown over the wall" among these roles, with development processes that involve gated passages of
documentation, signoffs, and similar ceremony.
In recent times, Agile proponents recommend a whole-team approach to the development workflow, with every member of the team being aware of the work being done by other members of the team at all times. This allows for a smooth and efficient transfer of information about the work being done. This also promotes higher quality, since ambiguities and mistakes can be spotted by anyone on the team who has an interest in any aspect of the work.
In Agile teams, the work of software development is usually broken down into understandable bits called "stories," small bits of work usually requiring attention from everyone on the team at some point in the workflow. In co‑located teams, stories are often represented as index cards on a board. These index cards may be different colors designating different kinds of work to be done, so a development story may be yellow where a defect may be red and a database update may be blue. These physical cards are moved around on the board, where their positions designate some sort of status of the work in progress.
For distributed teams and for teams larger than a typical Agile development team, designating work with physical cards is impractical. Nonetheless, the core practice is sound, and distributed or large teams can get the same benefit as a story board by using issue‑tracking software tools.
What is an issue?
Software development teams evolve their own ways of working over time. Before deciding on an
approach to issue tracking, it is important that the team have a well understood workflow in place.
Also, it must be understood that the workflow will change over time, and any issue tracking system
the team adopts will be required to change in step with that evolution. Put another way, it is
important that the issue tracking tool serve the team, rather than the team serving the tool.
Again, it is good practice to make all issues in play in the development process available to all members of team at all times. Examples of the kinds of issues that might concern the team are:
- Requirements being worked on
- Development tasks (these could be broken down, for instance between new development and refactoring existing code)
- Testing tasks
- Defects to be fixed
- Deployment tasks
- System Administration tasks
Given a defined set of issues, each issue will be assigned a state, and the state will change as the development work proceeds. Possible states could be:
- In progress
- Needs clarification
- Ready for review
- Ready for testing
- Defect found
- Ready for deployment
Tools for issue tracking
Beyond the cards‑on‑a‑board approach that is effective for small co‑located teams, there are three tool‑based approaches to issue tracking that are more appropriate for distributed teams or for larger teams. Each approach has merit, and each is worth considering in light of the team's existing development workflow. These approaches are:
- Commercial issue tracking tools
- Dedicated tools built in house
In recent years there has been an explosion of commercial issue tracking tools available to software development teams. Some are more appropriate to particular development styles like Scrum or Kanban, while others are more general, and may even be designed more as general-purpose issue tracking systems (think of customer support or project management) than for dedicated software development teams.
When choosing among such tools, it is critically important to keep in mind that the tool must
serve the team, rather than the team serving the tool. Any issue tracking tool that mandates
particular steps in a particular order should be treated with suspicion. Instead, look for issue
tracking tools that are highly configurable with regard to types of issues and the sorts of status
that can used to manage those issues. Keep in mind that workflow in high functioning software
development evolves over time, often in unexpected ways, to meet unforeseen challenges. Any issue
tracking tool should be capable of easily and painlessly accommodating that evolution, regardless
of what direction that evolution takes.
Because of that need for freedom and configurability, wikis can be exceptionally effective issue tracking tools. Modern wikis have a wealth of convenient features such as sophisticated presentation capabilities, tagging, aggregation, built‑in RSS feeds for monitoring, APIs for building custom features or for integration with other software systems, social networking features, etc. Teams whose workflows evolve quickly, teams with a strong need for fast customization and teams with a high degree of collaboration and understanding already in place should strongly consider a powerful wiki for issue management.
Finally, some teams have workflows that are simply not easily accommodated by existing tools. In
such cases the team (or the entire organization) may consider creating their own dedicated issue
tracking system. This approach has some benefits that should be considered. For one thing, the team
will get an issue tracking system that exactly matches their workflow. For another thing, the
organization can accommodate any workflow desired, without recourse to a third party. However, such
systems are typically expensive to create and expensive to maintain, and there is a real risk of an
impedance mismatch causing inefficiency and decline in quality if the homegrown issue tracking tool
fails to keep up with the team's actual practice of delivering software.
Everything is an issue
Exposing all the tasks in the software development workflow to everyone on the development team as the development process proceeds enables a highly effective "whole-team approach” to software development. Instead of being in silos with gated handoffs, such an approach achieves a transparency that allows the whole team to move forward as one, instead of the inefficient stop‑and‑go‑and‑stop sort of development processes that have been common historically.
The process for handling Agile "stories" has been well understood for small co‑located teams for some time; however, the process for handling development issues for distributed teams and for larger teams is not so well understood. Treating every development task in the workflow as an issue to be managed in a dedicated, sophisticated, configurable issue tracking tool is a way to implement an effective whole-team approach to software development for such teams.
This was first published in November 2011