Does it literally have to be individual JIRA tickets? No way, but going off for 2-3 weeks doesn't give the business the insight it needs to in order to wisely invest time/effort into work being executed.
[1] https://medium.com/machine-words/a-guy-in-a-room-bbbe058645e... (I thought Joel Spolsky said this but I can't actually find the original source, if anyone has it I'd appreciate it!)
Assuming that it is important to fix the bug and that the developer is competent and trusted - why not? What would communicating progress improve here?
Mind that you cannot communicate when it is done (otherwise it would not be a hard bug) you can only communicate what you have done so far and what you try next. But what kind of business value does that create?
Not that they couldn’t make the call if they had all the info, but the time required to gather and understand all the context would be a second full-time job.
Sorry, that English doesn't make sense to me. The value is that... the developer doesn't have context? How is not having context a value?
Maybe you meant "the reason"? But then that doesn't answer the question what the value is.
Are you saying that without communicating progress there is no person who understands the context in which the issue is being worked in?
That doesn't make sense to me and seems to be totally orthogonal to any communication of progress.