Yes, that's very important. I made the mistake of taking a job where they were into full blown "planning poker" nonsense. It was hell. "Is this a 2 or a 3?" The discussion could go on for ages. "This can't be an 8! Can we break down this into a 5 and a 3 point ticket?" No estimate was allowed to be an 8. I better stop, since I'm having flashbacks...
Hah I got in trouble once for just going through a grab bag of bugs from our designer (mostly trivial CSS issues) and fixing them. My manager got upset because the tickets never got their costs estimated, and I never put them in jira. (Even though the “3, 5 or 8” conversation would have taken more engineer time than just fixing the bugs directly).
I asked him why he was so upset. Eventually he admitted that closing tickets in jira was how upper management measured how well our team was doing - and by extension him. I thought that sounded like his problem and still refused to put the issues in jira. So he did it - meticulously creating a couple dozen issues, making up a BS point estimation and closing them all as complete.
Whenever I think about bullshit jobs, I think about those silly cost estimation cards, that guy, and how deeply satisfying it was that day just diving in and making our product actually better.
Tickets can also be some documentation about why some code is why it is. Put the ticket number in your commit message and use git blame when you want to understand something better. By fixing code without tickets you make this impossible for future developers.
Yes tracability etc... but to be honest: For such a trivial thing, this thing called commit message right before or after the ticket reference can do the job as well with one less indirection ;)
There is some tiny marginal benefit to what you’re talking about (there’s a chance someone might later want to look at the corresponding issue). But you aren’t acknowledging the cost, measured in my sanity making a bunch of one-line issues in jira, and the team’s time doing cost estimation.
It’s nice to leave breadcrumbs for future code historians. But our job is shipping product. Cost estimation, jira, etc all only have value proportional to how much they help us ship. If the meetings are pointless, and jira isn’t needed then doing that anyway is a waste of time.
I remember the endless Scrum meetings where we debated points with all the seriousness of medieval monks discussing how many angels could dance on the head of a pin. As a rough heuristic points aren't bad, per se, and they are a bit better than straight time estimates.
But when they become the subject of endless meetings it's a tell that maybe the company has hired too many people too quickly and is in the "bullshit jobs" phase where it's happy to waste precious salaried hours on meaningless debate.
You're lucky not having been discussing money budget per ticket instead.
I have had projects where sprints got money budgets assigned to them, which divided by the cost per hour of each developer got us the amount of hours available for the sprint.
Those hours were the budget for the sprint, no more no less, better chose wisely the stories that fit in.
To make it even better, some project activities only were given such kind of budgets in specific times of the year, then one of the external consulting partners would have the go at that specific sprint.
So not only were the tickets chosen to fit the budget, every few couple of months, the teams doing the work were always rotating.
Hmm every job I have had uses points this way. I find points discussions particularly mind numbing and have no love for them but I also can see the utility. What is the alternative?
When it ceases to be a useful tool to stay organized, and becomes a burden, it's very frustrating. The alternative is to use the tool when it helps you and ignore it when it's not.
