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:

founded 1 year ago
MODERATORS
snowe@programming.dev
jmk1ng@programming.dev
drewsiferr@programming.dev
19
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?

you are viewing a single comment's thread
view the rest of the comments
[–] 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.