this post was submitted on 16 Jun 2023

19 points (100.0% liked)

Experienced Devs

125 readers

1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

snowe@programming.dev

jmk1ng@programming.dev

drewsiferr@programming.dev

How do you organize miscellaneous tasks? (programming.dev)

submitted 1 year ago by firelizzard@programming.dev to c/experienced_devs@programming.dev

24 comments fedilink hide all child comments

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 feature." But what about bug fixes and other random improvements and miscellaneous tasks? How do you keep those organized?

top 16 comments

sorted by: hot top controversial new old

[–] jmk1ng@programming.dev 5 points 1 year ago (2 children)

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.

[–] firelizzard@programming.dev 1 points 1 year ago (1 children)

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.

[–] valence_engineer@programming.dev 1 points 1 year ago* (last edited 1 year ago)

and there’s not enough of them to merit an epic.

Why? Other than having more backlog Jira epics in the UI this seems the best approach? Put them into an Epic and once the Epic is large enough you prioritize work on it. If it never gets to that size then you can re-evaluate.

[–] drlecompte@discuss.tchncs.de 1 points 1 year ago

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.

[–] tonkaTruck@programming.dev 5 points 1 year ago* (last edited 1 year ago)

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.

[–] drlecompte@discuss.tchncs.de 4 points 1 year ago

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.

[–] nibblebit@programming.dev 4 points 1 year ago* (last edited 1 year ago)

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.

[–] danielintempesta@programming.dev 2 points 1 year ago

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

[–] Kissaki@feddit.de 2 points 1 year ago

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.

[–] psudo 1 points 1 year ago

So, my go to is generally to include it in a related epic. I think this is a slam dunk for your "reach maturity level x" examples. To me that doesn't just mean "we added x/y features," but "we have established features x and y, plus everything we needed to make that stable." It won't help with generalized legacy tech debt, but if you stop think of it as debt that can be paid off whenever and instead as part of your normal operations you can get out ahead of your problems. But I'm also a little spoiled as our PM is overworked and generally trusts us to not add it stupid things.

[–] baturkey@programming.dev 1 points 1 year ago

My team has an epic for miscellaneous stuff

[–] lasagna@programming.dev 1 points 1 year ago* (last edited 1 year ago) (1 children)

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.

[–] firelizzard@programming.dev 1 points 1 year ago

We are already using GitLab

[–] NostraDavid@programming.dev 0 points 1 year ago (2 children)

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

[–] NostraDavid@programming.dev 3 points 1 year ago* (last edited 1 year ago)

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 finger command 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.

[–] firelizzard@programming.dev 2 points 1 year ago

We're already committed to using GitLab, so I'm asking devs who use similar tools how they organize tasks.

load more comments