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 register 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.
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.
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.
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.
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.
We are already using GitLab
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.
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.
