Context: We have a small team in a small company. We currently have no issue tracking system (Jira, Redmine, Mantis, Trello, etc), as the feedback loops are very short in-house. When we use contractors, we usually piggyback our issues on their issue tracking systems.
Our team actually like the idea of having our own issue tracking software, and we want to look at what such a system can mean for us. This research has fallen in my lap.
My first issue with this statement here is that “liking” software doesn’t mean that it can actually solve a problem.
This leads to my first question:
1. What problems can an issue tracking system help solve?
And since I know, based on personal experiences, that managing an issue tracking system can lead to some challenges, I have a second question:
2. What problems can an issue tracking system create?
How to avoid these pain-points may also be helpful.
Are you working on a single product or project or multiple?
Is your work shared across multiple teams or a single team?
Are you a manager/lead/decision maker?
Are you the person to setup the tool and admin it?
Who’s going to use the tool and how?
What’s the extent of issue tracking, volume, details, classification that you expect?
By referring to team usage, do you mean all IT and business working on a project/product?
Are people having interpersonal issues or maybe don’t like to have lists of bugs given to them?
You have two options from what I see generally with issues:
you track them
or you don’t…
If you track them, can be personal tracker or shared tracker:
each person has his own tracker for various issues types
multiple persons use the same tracker for various issues types
In case there’s multiple persons wanting to track some kind of issues, I’d suggest you take a meeting with them for about an hour and get the needs and expectations from everyone.
You might get away with something easy/light/free like https://www.bugzilla.org/ or https://guides.github.com/features/issues/ or a shared spreadsheet in Google Drive or Microsoft Sharepoint.
What problems can an issue tracking system create?
That depends on the context. Some cases I’ve noticed in the past:
If people like creating bug tickets, retesting them, reviewing, categorizing, etc… - they can spend a significant amount of time in the tracking system.
Some people will start hating it if it’s large and complex and open it only once a week.
Managing the backlog could be required by some managers - prioritization, classification, root-causes, impact, etc…
Metrics discussion could arise and some managers will want to play with data based on the issues - how long issues stay open, how many there are, how many of x priority, how many bugs were closed, how many fixed themselves or where bad reports, who reported what, how, how many, etc…
The people could start comparing each other on the number of bugs - taking away from the deep testing focus and highly consuming bugs investigations;
Wrong priorities can be set by some people who will want a bug fixed sooner than the other; Usually a Business representative is a good referee, and it can be nice to have one in;
Those are all outstanding questions. Unfortunately, I don’t have the answers to most of them (yet). But I can see that these context-building questions are quite important to the question of “Should we?”
Also a good observation. But I feel a “but” here. You track them… but you aren’t consistent in logging. You track them… but you spend a lot of time in administration. You don’t track them… but the team appears to be doing well.
To add some more context, I HAVE maintained project management software in the past (Jira, to be specific) for a mid-sized team, and the administrative overhead was my personal-primary issue. Combined with the continuous delivery (in the form of Bitbucket), it was a full time (and thankless) job.
Doesn’t everything? Still bears repeating.
I honestly hadn’t thought about that one. Good point.
I haven’t done Jira admin work for 2 years now, and I still have nightmares about backlog.grooming.
For the interest of discussion, I was interested in more context-free input, but since I see the value in having the right context for me (and I invite responses based on this), more information…
Are you part of the team or you’re outside?
I’m part of the team. Lone tester. Barely experienced in managing issue-tracking software.
Are you working on a single product or project or multiple?
Multiple projects and products.
Is your work shared across multiple teams or a single team?
Hardware team, software team, some remote work in the software side with their own issue management systems. We do NOT intend on duplicating or sharing between the “off-shore”.
Are you a manager/lead/decision maker?
Yes and no. The team will likely take my advice if I present it properly.
Are you the person to setup the tool and admin it?
Yes.
Who’s going to use the tool and how?
This is the question we can’t answer yet. The plan is to have the software people do a “test run” and expand it to the rest of the teams if we think it’s valuable.
What’s the extent of issue tracking, volume, details, classification that you expect?
My personal wish is for low volume, a lot of details, and agreed-upon classifications. My expectation is not-enough-details for issues.
By referring to team usage, do you mean all IT and business working on a project/product?
The team, in this case, is R&D. Other departments are on their own, with a couple of exceptions.
Are people having interpersonal issues or maybe don’t like to have lists of bugs given to them?
Bugs might be the wrong choice of words. The intent is to use the tool for organizing projects in more detail than is desirable by the other project management tool, which is horrible for the day-to-day stuff.
To really summarise my thoughts at a very high level:
Positives of Issue Tracking Systems: If you can’t measure it, you can’t manage it. So its a source of data to analyse trends in issues being found.
Negatives of Issue Tracking Systems: Its never the system thats the problem, its the discipline and knowing what the valuable information is that you want to analyze. So often discipline gets lost as with a lot of processes when time pressures hit.
So I would start before getting any issue tracking system, what questions do you want answered about the current state of issues being raised. If you have no questions, thats the first problem you need to solve.
Good answer. Measurement is certainly one valid reason for wanting to track issues.
So how could I know if I’m asking the wrong questions? (I will give an example, the wrong question might be, “Could this tool tell me (a manager) if a team member is underperforming?”)
While you raise valid points, I have to disagree with this one. The tool (system) has to be right for the problem which is wants to (help) resolve. Just like I wouldn’t want to use a screwdriver to hammer a nail. Some tools are too costly, too heavy, have horrible UI, high learning curves, etc. In those cases, I CAN say it’s the system which is the problem.
And to the thread, a progress update:
I haven’t fleshed out the “how can we use it?” issues or the “how much time will this cost?” issues, but I have a demo-bug tracker installed, and ready for the team to play with. Since the last time I installed the same software(some years ago), it took a week to configure, and now it took about an hour… I would say that is an improvement. So the cart is now FIRMLY in front of the horse.
(ok, it was a test to judge the potential cost-in-time for me-as-admin, and NOT an actual demo. If it was difficult, I would have said that it’s too much and killed the project.)
I think thats my point around the questions. A tool isn’t going to help you define what the right questions are, only experience is. So if you’re asking the wrong questions, you’ll be assessing a tool for the wrong reasons. In other words, because the wrong questions were asked, you picked a screwdriver…its not the screwdrivers fault.
