I am an experienced developer, but not an experienced manager. I’d prefer if organizing tasks was not my responsibility, but I work at a small company and no one else is inclined to do it. How do you organize miscellaneous tasks when using a task management system such as Jira? We’re using GitLab, but it has the same basic features, such as epics, milestones, tasks, and subtasks.
I don’t want to have miscellaneous tasks floating around in the ether, because things like that tend to get lost. But an epic is supposed to have a well-defined end goal, right? A good epic is something like “Implement this complex feature” or “Reach this level of maturity” - not “Miscellaneous stuff”.
The majority of the work we do fits fairly clearly into specific goals, such as “Release the next version of <this> feature.” But what about bug fixes and other random improvements and miscellaneous tasks? How do you keep those organized?
You must log in or # to comment.
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.
We have a similar epic called ‘quality’, from the idea that all the little odd jobs and chores have the goal of improving overall quality. Very generic, I know, but it helps to create some focus.
I’d say the biggest categories are chores and minor updates. For example (for the latter category), we finished an overhaul of the API; we developed and tested it, then deployed it to the test environment and had users and app developers test it, then we deployed it to production and closed the epic. And now that it’s on production and more people are using it, we’ve realized it needs some improvements. Where do those tasks belong? They’re not high enough priority to do now (there are other things higher on the list), but they should get done eventually, and there’s not enough of them to merit an epic.
New epic called “<PROJECT> v2” 😅
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.
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.
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.
What about improvements to the feature after it’s been delivered? You develop, test, review, validate, etc, then deliver the feature, and then you get user feedback that you need to make some minor changes or improvements. The original epic is closed and there’s not enough work to warrant a new epic, so where does the task go?
Epics don’t have to be huge. And stories don’t need to be attached to epics in the first place.
An epic is just a way to organize features. There’s no hard and fast rule for how many features are needed to form an epic.
My team has an epic for miscellaneous stuff
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
Always ask yourself: “What problem am I actually trying to solve here”.
Vikunja (selfhosted https://vikunja.io/) and Gitlab
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 :)
Oh, and for myself: A markdown file, where I have a custom syntax to track what I need to do, what I’m done with, working on, etc.
I separate each day with a
== yyyy-mm-dd(the==is literal, the letters are replaced by an iso8601 formatted date.Then I have a symbol at the start of each line, indicating what’s what. Here’s an example
== 2023-06-18 + this item is something I still need to do * stars are used for tasks that I'm currently working on (though I tend to immediately replace + with -) - this is a task I'm already done with % this is for events that have happened on that day, that I've deemed important (birthday, someone left the company, etc) @ this is for ideas that I want to come back to one day - I can just search for '@' and dig through my .plan file to find them # this is for general comments about the items (not used that often) ? this is for questions that I have, that I need answering ! this is for questions I have answered | the bar separates the question I had from the answer I found for it; this way I can track my open questions (via ?) and find out what answer I got to that one question I used to have.
This format is somewhat copied and personalized from John Carmack’s .plan files. His format was based on the ye olde
fingercommand for Unix operating systems, but I’m on Windows, so I just made my own format that made sense to me.In the long run, I’ll have one super long log file of what I did when. It’s nice to see myself evolve and grow.
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.
