Experienced Devs

Does every issue need to be attached to an epic, though? A simple, well-described bug can be enough on its own, I think? You do need to regularly go through the backlog to re-order it, remove outdated tasks, combine duplicates, etc. for it not to become unwieldy.

My/our approach can be summed up as:

• if it's code-related, however small, it goes in the backlog, with or without an epic, and it follows the normal flow of things. We have weekly reviews where we maintain the backlog, basically.
• if it's not code-related, I personally have a markdown document, where I plan stuff day by day. It started out as a simple way to document the stuff I did so as to not forget anything in the daily standup. But now I routinely use it to jot things down a day in advance or in a special 'must not forget' section. It's proven to be very useful in remembering those little things people ask you throughout the day without jumping on them right away. The bonus is I have a very detailed archive of everything I did spanning literally years by now.

Depends on what you mean by miscellaneous.

Are we talking about things my team calls "chores"? Things like upgrade some dependencies, or fix something annoying about the DX or build, look into that new library the team's been talking about maybe using to replace some jank part of the app?

If so, we have an epic we simply name "chores". We stack the backlog of chores based on priority and we attempt to get at least one done a sprint.

It's not critical stuff. It's not blocking anything (yet). It's just housekeeping and maintenance stuff that doesn't fit into regularly planned and scheduled deliverables.

Whenever someone says something like "man, our version of Node is super old. We should really look into getting onto at least the current LTS". That's when you say "Add it to the chores!" so you all don't forget about it.

Vikunja (selfhosted https://vikunja.io/) and Gitlab

Our approach is by no means the best or even applicable for most organisations, but it goes like this:

There is no such thing as a miscellaneous task. Each hour spent on work should be accounted for towards business goals. If you are fixing bugs, you link the bugs to bug reports or features that describe how the system should behave. The same goes for testing tasks. If you are doing ops, it's either reactive or proactive. Reactive ops are linked to issues and incident reports. Proactive ops are linked to new releases or experiments. If you are doing R&D, link it to a new initiative. If you are doing process automation or dev QOL improvements, have a continuos initiative to account for that work. As a business stakeholder, I need to be able to see where the hours of my 2 dozen devs are going. Are we spending our time on bugs, QOL, KTLO or Features? If I see that half the logged hours are set under 'Miscellaneous', I can't really have that conversation.

Always ask yourself: "What problem am I actually trying to solve".

It can't be that you have a task, no matter how small, that can't be accounted towards any existing business goals.

If you're asking for a tool that contains shared tasks:

The Stack Overflow Survey dropped not too long ago. If you want to pick a tool, pick one that's admired. That means looking at this specific list and probably picking Linear - available at Linear.app.

Disclaimer: I have zero experience with Linear; I'm just going off on how admired it is. Choose at your own discretion :)

There are other tools but my favourite is something like Gitlab/Github's 'issues'. It's simple. You can add custom project tags (e.g. 'minor bug'), link it to other issues, comment, assign it to someone, etc. Gitlab itself pitches it that way:

https://docs.gitlab.com/ee/user/project/issues/

What I do is to generally avoid things that require others to learn a lot. Let's face it, most people won't be bothered and not to mention their time is best spent elsewhere. Gitlab and Github are essentially just a small step from Git, which makes it straightforward.

I have seen managers who were too eager and made their process unnecessarily complex. And I have seen managers who didn't give a rat's arse. Both sucked to work for about as much. Be careful with going the extra mile because upper management might think it good but us programming plebs might not. I hope you find a good balance.

If the work is expected to make it into the deliverable product, then it should fall under a feature. Either add it to an existing feature or create a new one. I prefer the former because it results in less deceptive forecasts.

One thing is to utilize your Google Calendar. I use the Task function to remind myself to review a document, or perform a deploy, etc...

Of course look at your current Jira tickets. As senior devs we're expected to multi-task all week long in addition to fire drills.