Is a ticket management system necessary for our org?

Question

Our team looks like this

1. 4 developers
2. 2 testers
3. 1 Boss (Product owner, CEO etc.)
4. A designer

We have tried 4 different boards till now. Assembla, Youtrack, JIRA as scrum and JIRA as Kanban. Every single time, what ends up happening is that the list of tickets grows and becomes pretty large and becomes unapproachable from my perspective. There are about 250 unresolved issues. I would never want to go through that list and pick something out of it.

As a whole team, we have sometimes given up on long lists of issues and we have moved on to create new boards hoping to have a good process. But we have not achieved this at all.

We always go back to something like a simple todo list or an excel sheet till we delete everything and start a new board. A list of 10 items seems far more easier to fathom than say 250. How can we fix this?

Answer 1

Dispose of your low value cards.

Stuff you won't do is inventory and there is a cost of keeping them around, which you're encountering now. You should have a good idea of what the rough value order of your cards are, and you need to be disciplined about binning the ones under a cut-off point. If you make a mistake, and dispose of something important, it will reappear.

Ron Jeffries has another idea for dealing with these infinite backlogs. Petition the King. Essentially, if it’s important to a stakeholder but can’t be done now (ie, isn’t the most important thing) rather than record it in ( / lose-in-the-depths-of) your backlog you can rely on them asking for it again later on.

Even if the Petition the King is a bit radical for you, if you want to keep a tight backlog you will have to delete things. (Note: Moving into some folder, like "low priority items", is just cowardly deletion without the benefits. It's never going to be worth someone’s time to dig into a walled-off non-current part of the backlog). Petition the King is just a way to make sure the customer continues to agitate for the known issues that are currently important to them. It depends, I would say if you don't see yourself doing a task within your current release planning horizon: bin it.

Use physical cards on a board. Your main problem is unchecked growth, if no more physical cards will fit on a physical board, it will be pretty clear what will have to be done.

They're also tangible, a physical artefact that forms a focal point for human interaction. As well as the board being fixed size, so are the cards, so it keeps their descriptions terse.

Answer 2

I really don't understand how you manage to collect so many issues. And if I understand you right, you try to use something like SCRUM.
In this way, firstly, you have to learn base terms of it - like product backlog and sprint backlog. Since tasks should be put on the board only from sprint backlog.

Answer 3

It might be worth suggesting that the problem may not be with the tracking system but with the sheer quantity of cases. It sounds like you might be taking on more work that you have capacity for.

I'd print all the cases out on a big spreadsheet and go through them, prioritise them (using something like Red, Amber, Green) and set up timeboxes for the Dev team to get through them.

Answer 4

Product ideas and defects are so hard to collect. You should not regularly dump them to trash.

250 work items is a very small number for 4 developers and 1 designer. Issue tracking system is useful exactly when you have a lot of work.

Just introduce notion of versions. It's both good for you and for the business, because users should be reminded about your product with a regular version cadence, even for web-sites. Without milestones/versions it's nearly impossible to introduce major changes, you may end up with a lot of technical debt, which eventually leads to complete rewrite.

Let you boss put all visible improvements/defects to 3 version buckets: V.Next, V.Next+1, TBD. Or make the preliminary decisions yourself.

If your boss wants all work items selected for some version be worked simultaneously, it will slow down your work. You need to manage your boss by selling him/her Kanban.

Answer 5

From my perspective and experience in important to keep track of all issues your projects/products have. Your team is already big enough to justify a ticket management system, but you need to be sure what do you want:

A way to organize work inside team

If your need is only to organize your work inside of the team, an excel is enough, but with a ticket management system you can have many benefits:

1. focus discussions inside a single ticket, not all whole project again and again
2. keep track of all changes of status (analysis, design, development, testing, etc.. ) from all the team. In excel this is a pain

A way to communicate advancement outside of the team

This is the tricky part. If you need to do it, you need the right costumer. I really don't know about your market, type of customers or so on, but anyone in the world read manuals, think about issues.. I think a report from project manager is enough! If you are lucky and have a collaborative customer, you can add customer as part of the system, with even issues assigned to him/her.

Conclusion

As tool, a ticket management system require discipline: you simply can't grow a list of 250 issues. Any issue must be evaluated before insertion into the system and assigned to someone to work on it, with a scheduled time, otherwise is simply a backlog and .. maybe is not really an issue, but a "future idea". It's the duty of any project manager to control advancements, help the team and find a way to organize better teamwork.

Bonus: I'm not a fan of kanban board, like Trello, but you can use them for manage different projects, but again, you have to keep control on issues lifecycle.