Ticket Systems Debate

Why do you think using ticket system for non-programming tasks is a problem?

You must be working in projects with a relatively small number of “problems to be solved” at any given time, and with the problems having relatively low complexity. In general there’s no way to keep everything in your head and not organize and track things across the team. That doesn’t mean that a lot of communication doesn’t still have to happen within the team and with the customers. Tickets don’t replace communication. But you have to write down the results of the communication, and the progr

Reality check.Complaint: tickets created by the QA team for developers, even seemingly trivial ones, stagnate in Jira for months and sometimes years without anyone looking.Written plan: Hire somebody who will be actually responsible for planning and prioritization. Hire more developers, so that the existing ones are not overloaded.Reality: "This is not a realistic plan. There is a budget, and you are not the one who makes hiring decisions, so shut up and stop creating tickets unles

Open tickets, assign a priority and party, and burn them down. I'm always surprised that people keep thinking that putting a prettier UI on top of this is somehow the next billion dollar efficiency.

No tech-debt JIRA ticket - no big refacroring. JIRA tickets gets assigned during planning and are usually talked through in the team and agree upon. Problem solved.

Bad advice. Keep tasks in issue tracker.

Why are PRs more likely to fall through the cracks than tickets? I think the opposite is the case...

Something that does not try to treat each "issue" the same way.Bug ? You want to enforce "Steps / Seen /Expected" structure". And maybe hint that people should estimate the severity / criticity / cost to fix.Feature ? You want to optimize for people discussing the spec, and make it damn easy to know which decisions have been made. Bonus point for baking the "five why" in.Task ? For developpers, Optimize for splitting the task

A very long time ago, my experience:Boss: Find all the holes.Engineers: (begin to iterate through a list instantly over the mic)Boss: Did we capture all of that?SilenceBoss: Okay, everyone please make a list and we will prioritize them.The next thing you know, other tickets like my business application just crashed came up and everyone started to work on them. Surely manager and project manager collected the list (from 1 or 2 people out of 10, 15), and asked tech lead to

One time I worked with someone who said multiple times, "I closed more tickets in this sprint than anyone else on the team."What I learned from that is to create a ticket for every slightest little thing.Correct a typo in a comment? A ticket.Combine a tiny bit of duplicate code? A ticket.Add a little error check? A ticket.Forget working together to create a great and well-supported product.What counts is whether I closed more tickets than you!