Experienced Devs

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.

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.

How do you organize miscellaneous tasks when using a task management system such as Jira?

(Context about me: I've only worked at companies with larger engineering department and mainly in a lead engineer role)

It depends on how miscellaneous it is and how long it's going to take to achieve.

If it's small enough, a member of the team will just do it, no ticket (or even make a ticket after the fact, if it was a little bigger than 'small'). Is it potentially uncaptured work, yes. Which is where the emphasis on this is small. Like a update to a dockerfile where we're incrementing to the next major update for the base image of an application that we don't touch that often. 99/100 there's nothing that goes wrong and it's 5 minutes of effort including the Merge into main.

Which if something goes wrong, we revert, make sure all's good and then probably make a ticket. Which leads us into ...

If it's not a small task, that's where my team figures if it has any sort of business impact. If so, we can talk to our product owner on why this task matters and the priority of it. Maybe it melds into an existing epic as a 'rider' feature. Which, to your point about:

an epic is supposed to have a well-defined end goal

Perfection, is the enemy of getting things done. However, if the task starts to get large enough then maybe it warrants its own epic. I personally think that any form of "method of getting work done" (i.e. Scrum Agile) should have an exception process for it's normal ways of handling things. The exceptions are there to be used on occasion, but not abused. Where that line in the sand is ... that takes a team with good feedback loops on how we feel about our process (i.e. retros). Then you adjust that line in the sand with the push and pull of work life.

However, I did mention business impact, because my team also keeps a separate 'log' of tasks that are tech-debt only. My Leadership and team value taking ~10% of our capacity and put it towards tech debt items each sprint. So that's usually where we end up putting things where we, engineers, want to get things done without having to wait for prioritization by our product owner whether or not it has that "direct business impact".

Regardless if this was helpful, best of luck.

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.

We habe feature or feature scope epics but also never ending category epics for improvements and support, and project sources. Support gets one task per sprint and subtasks to it. Bugs typically don't fall into epics.

I'm not clear on what misc and organized means for you.

We track (technical) opportunities separately. They put noise into the backlog and never get some. Unless a dev actually does them.

Epics serve for longer term planning and prio.

Other than for sprint planning and refinement the deeper backlog doesn't need much organization. Just some categorization, and to the degree those responsible for picking next tasks/work can do so.

I guess the main tool is epics for categorization. Other than that misc is misc, and order in the backlog is all you can do and is good enough.

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.

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

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 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 :)

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.