How to handle bugs outside of epics? Edited

[AQ666]

What’s the best way to handle bugs that’s too small to have an epic and yet needs to be in line with epics in advanced roadmap?

We usually close epics once it’s deployed. However, there are times that a bug is discovered  maybe after 2 to 3 days after that epic goes live. Since the epic aid already closed, what’s the best practice to handle this that the bug can still be seen in advanced roadmaps?

I can think of some solutions.

1. Reopen epic and add bug (kinda awkward to reopen closed epics)
2. Create an epic and add bug (this is redundant)

any feedback is highly appreciated 😘

[Dave]

Hey @AQ666 ,

This is an interesting question and also one that I have to address within my team. I personally don't think that you should re-open an epic if you've previously considered it to be finished, nor should you add more work to it.

One interesting aspect about the Advanced Roadmaps interface is that that the scope section has the appearance of a folder structure (when you have the hierarchy range configured to show multiple hierarchies) and it can be tempting to create epics for the purpose of organising your backlog.

This is actually something that I reluctantly do on our plan, however when it comes to actually planning work that we plan to deliver I will organise it into specific deliverable epics. This allows me to categorise and plan to deliver "value bundles" of fixes together.

We're not completely fixed to this and if an urgent bug comes in then we might not go to the trouble of creating an epic for it, but for lower priority bugs this can work well.

Other options you might want to consider for categorisation might be to have an epic of bugs per month or quarter - this might be a useful approach if you have allocate a specific percentage of engineering time for bug fixing or KTLO ("Keeping the Lights On") type work.

We have discussed various alternatives for this (such as having a "virtual" hierarchy) in order to allow issues without parents to not be hidden away at the bottom of the plan, but we haven't come to any great solution yet.

We also typically switch between multiple views at different hierarchy levels (for example we have a view that is just story level so that it helps us plan our upcoming sprints) but also switch to views for different hierarchy levels for more thematic or longer term planning.

What I'd be interested here is to understand more about your specific use case ... is the concern that bugs without an epic are not easily detectable because they are at the bottom of the plan in the "Issues without parent" section?

Regards,

Dave