Give us an LLM with better reasoning capabilities, please! All this other stuff just feels like a distraction.
I've been using the Atlassian MCP for nearly a month now, and it's completely changed (and eliminated) the feeling of having an overwhelming backlog.
I can have it do things like "find all the tickets related to profile editing and combine them into one epic" where it works perfectly. Or "help me prioritize the 15 tickets assigned to me this sprint" and it'll actually go through and suggest "maybe you can do these two tickets first since they seem smaller, then do this big one" – i haven't hooked it up to my calendar yet.
But I'd love for it to suggest things like "do this one ticket that requires a lot of heads down time on wednesday since you don't have any meetings. I can create a block on your calendar so that nobody will schedule a meeting then"
Those are all superhuman things that can be done with MCP and a smart model.
I've defined rules in cursor that say "when I ask you to mark something ready for test, change the status and assign it to <x person>, and leave a comment summarizing the changes"
If you look at my JIRA comments now, you'd wonder how I had so much time to write such thorough comments. I don't, Cursor and whatever model is doing it for me.
It's been an absolute game changer. MCP is going to be what the App store was to mobile. Yes you can get by without it, but actually hooking into all your daily tool is when this stuff gets insanely valuable in a practical sense.
How do your colleagues feel about it?
I also don’t want to read too many unnecessary words.
Can’t we point an LLM to a sqlite db and tell it to treat it as an issue tracking db and have everyone do the same.
The service (jira) would materialize inside the LLMs then.
Why even use abstractions like tickets etc. Ask LLM what to do.
Unless you can provide the same visibility, long-term planning features and compliance aspects of JIRA on top of you sqlite db, you won't compete with JIRA. But if you do add those things on top of SQLite and LLMs, you probably have a solid business idea. But you'd first need to understand JIRA well enough to know why they are there in the first place.
[0] https://en.wikipedia.org/w/index.php?title=Wikipedia:FENCE
One of them said “yeah I was wondering cuz you never write that much” - as a leader, I actually don’t set a good example of how to leave quality JIRA comments. And my view with all these things is that I have to lead by example, not by orders.
With the help of these kinds of tools, we can improve the quality of these comments. And I wouldn’t expect others to write them manually, more that I wanted to show that everyone’s use of JIRA on the team can improve.
I don't think it's good leadership to unleash drivel on an organisation, have people waste time reading and perhaps replying to it, thinking it's something important and thoughtful coming from atonse.
Good thing you told them though, now they can ignore it.
Also, a lot of the kinds of comments are things like, when you combine a bunch of tickets, leaving comments on the cancelled tickets to show why they were cancelled.
In the past, that info simply wouldn’t be there.
There's nothing I hate more than people sending me their AI messages, be it in a ticket or a PR or even on Slack. I'm forced to engage and spend effort on something it took them all of 3 seconds to generate without even proofreading what they're sending me says. The amount of times I've had to ask 11 clarifying questions because their message has 11 contradictions within itself is maddening to the highest degree.
The worst is when I call out one of these numerous contradictions, and the reply is "oh haha, stupid Claude :)", makes my blood boil and at the same time amazes me that someone has so little pride and respect for their fellow humans to do crap like that.
I’m not remotely interested in throwing random slop in there.
In fact, we did try a year ago to have AI help write our tickets and it was very clear that they were AI generated. There was way too much nonsense in there that wasn’t relevant to our product.
So we don’t do that.
I'm not in that world at the moment, but I've been the lead on several projects where the backlog has became a dumping ground of years of neglect. You end up with this tiered backlog thing where one level of backlog gets too big so you create a second tier of backlog for the stuff you are actually going to work on. Pretty soon you end up with duplicates in the second tier backlog for items already in the base level backlog since no one even looks at that old backlog anymore.
I've done a lot of tidy up myself when I inherit this kind of mess, just closing tickets we definitely will never get to, de-duping, adding context when available, grouping into epics, tagging with relevant "tech-debt", "security", "bug", "automation", etc. But when there are 100s of tickets it is a slog. Having an LLM do this makes so much sense.