> Lightweight tasks exist. As much as I generally agree with you, following your rules means you either do not ever do them, or you bloat them to multiple times larger than necessary. And correcting a company's task-management process as a whole is not always feasible either.
Creating a short Jira issue and poking someone about including it in the current sprint should take about 10 minutes in total, if you want a decent description and are okay with occasionally not focusing on the "ceremonies" of sprint grooming too much, since as you say, some tasks are indeed small (and as long as this doesn't lead to scope creep, e.g. fixes/refactoring instead of new features this way).
Of course, that may always not be viable and i see where you're coming from - yours is also a valid stance to take and i see why focusing on an issue tracker too much would be cumbersome. Then again, in my eyes that's a bit like the difference between having almost entirely empty pull/merge requests and having a description of why the changes exist, a summary of what's done (high level overview), additional relevant details and images/GIFs of the changes in action, DB schema diagrams or anything of the sort.
I feel like additional information will always be useful, as long as it doesn't get in the way of getting things done (for an analogy, think along the lines of covering most of the business logic with tests vs doing TDD against a bloated web framework and thus not getting anything done - a few tradeoffs to be made).
Creating a short Jira issue and poking someone about including it in the current sprint should take about 10 minutes in total, if you want a decent description and are okay with occasionally not focusing on the "ceremonies" of sprint grooming too much, since as you say, some tasks are indeed small (and as long as this doesn't lead to scope creep, e.g. fixes/refactoring instead of new features this way).
Of course, that may always not be viable and i see where you're coming from - yours is also a valid stance to take and i see why focusing on an issue tracker too much would be cumbersome. Then again, in my eyes that's a bit like the difference between having almost entirely empty pull/merge requests and having a description of why the changes exist, a summary of what's done (high level overview), additional relevant details and images/GIFs of the changes in action, DB schema diagrams or anything of the sort.
I feel like additional information will always be useful, as long as it doesn't get in the way of getting things done (for an analogy, think along the lines of covering most of the business logic with tests vs doing TDD against a bloated web framework and thus not getting anything done - a few tradeoffs to be made).