Roadmap visualization for spontaneous tasks

Question

In my setting we have a jira board where me, the Software Lead, together with developers and product owner want to collaborate in planing and overseeing our work. One major challenge that we have is balancing between having a plan which we follow and tackling spontaneous tasks that we need to do which are not necessarily associated with epics.

Our current setup is to have Epics to bundle up large chunks of work. The epics are then split in to Technical Tasks, User Stories and Bugs. These are pretty straight forward. Investigate work, define work to be done, plan in the roadmap.

The situation that creates problems is however the spontaneous tasks. After a sprint meeting, we find things that need to be done. These do not go under any epic because they are not part of the epic original definition. Adding issues to the epics would mean the epic will keep growing and in the roadmap the product owner won't see progress done, all that he sees is that the epic keeps getting delayed in completion. For that reason anything that is not part of the original epic definition or that has no epic to which it can be associated, is created as a separate issue.

The issue with these is that, without an epic, the issues are not displayed in the roadmap and therefore unaccounted when planing. The issues can also span over several days of work sometime so the delay in the epics we where supposed to work on in the first place is affected significantly because of these.

How could I balance the two types of work process, planned vs spontaneous issues, in a way where I can show to the PO the impact that the spontaneous issues have on our original timeline?

Edit: by spontaneous issues I mean, bugs, smaller tasks that pop-up and need to be done such small improvement in our UI or in deployment pipeline. These things currently do not go under a specific epic since we use epics to describe big use cases of the application.

Answer 1

There is a difference between a roadmap and planning.

It seems to me that you try to plan all the work so that the PO knows when it is done and thus omit work to an epic eventhough it belongs there. That looks wrong to me.

A roadmap, in my eyes, shows the priority of things you want to work on but has no deadlines. The team (to be clear: all roles in the scrum team (dev, PO, SM)) should work together to create a roadmap that can be communicated to stakeholders. Again, without deadlines. This helps to have conversations over what is important to do.

Hope my 2 cents help

Answer 2

As pointed out by other answers, a roadmap and making a plan are different in concept. In practice, however the two often mix.

A roadmap is a big picture of your product strategy or direction. It lays out the things that need to come together to build an useful project and meet your goals. If you think about the roadmap as a plan, then it's the high level plan of WHAT you think you need to build and WHY.

Unfortunately, may software development tools mix the two concepts to large extent, and you risk having the roadmap become just a fancy Gantt chart that - even if it keeps a helicopter view of what you need to accomplish and doesn't go deep in tasks, resources, and timelines - still lays out the activities of your project over a timeline and results in a plan of HOW and WHEN to achieve to goals laid out in the roadmap.

You don't say what those "spontaneous" issues are, and how they are unrelated to epics (which I find weird by the way, because work you do should add value to the products and support the realization of the features in the roadmap in some form or another), but "spontaneous" issues should not be laid out on a roadmap, simply because they are spontaneous. They just show up.

It's just like in a classical motorists roadmap, which lays down roads from getting from place to place. You can make a plan to get from A to B, as a series of steps, but things can show up that throw your plan out the window (all of it or some of it). Like in a traffic accident. At that point you can build another plan of how to reach point B, but this new plan doesn't affect the roadmap itself, only the timeline (a detour might take more time, for example). You update the roadmap if the WHY/WHAT changes. Maybe you decide you no longer want to go to B, because it's too long of a detour, so you decide to go to C, and now you need to look that up on your roadmap and build a new plan to figure out how to get there.

If you need to balance planned vs spontaneous issues, then one way is to add buffers to your planned schedules (to account for stuff happening, like the traffic accident), or you spend some time to identify these "spontaneous" issues. Again, you didn't mention what they are, but maybe they are something that you failed to add to your roadmap? Something that you missed, perhaps. Sarov suggested a 'Spontaneous' Epic, as a bucket where you can dump this work and make it visible in the schedule, but maybe you are missing something that you failed to include on the roadmap?!

One thing you mention in the ending is:

[...] show to the PO the impact that the spontaneous issues have on our original timeline?

This is about communication. This is about backlog refinement. This is about strategic planning. You made a plan and built a timeline, so where are you now vs where you believed you will be? You don't need to "show" the impact, you all need to "look" at the impact and see what corrections are needed. That might mean building new plans, or looking at the roadmap and figuring out if there is something you could drop or do differently (even in a motorist map things change - new roads are added, bridges are built, roads decommissioned, etc). If you can't (or don't want to) separate the WHY/WHAT from the HOW/WHEN, then figure out the nature of the "spontaneous" work and add it at the appropriate places in the roadmap to make it visible (as the workaround Sarov mentioned). But even so, even for work on planned epics things can always take more time than your original timeline. So when that happens how do you represent it in the roadmap? Your epics will still remain the same and progress won't be reflected in the roadmap. The epics just get delayed again.

Answer 3

As you say, your overall goal is

to have an overview of the work being done, which would be visualized in the bigger time span, as opposed to our week to week work where we focus on smaller tasks at a time

In that case... why not just have a catch-all 'Spontaneous' Epic to which you assign all such spontaneous Tasks?

The reason why I wouldn't use a catch all epic is because our issue in the past has been that epics keep getting bigger and bigger as we uncover the process and in our jira setup the timeline just kept getting expanded instead of seeing any progress done.

When I hear statements like this, my brain translates them to "the reason I stopped using a scale was because it kept showing my weight going up. How can I change the scale so that my weight goes down instead?".

Repeat after me: Every plan is wrong. If you originally thought an Epic would take 20 days, and then 10 days later you realize it's doubled in size because of things you missed... that means your initial estimate was wrong. So, good - increase the size of the Epic. Change your plan, because it was wrong before, and now it can be less wrong.

That is what is actually happening, so why would you want to change your tool to not show it? Good project management practices show the reality, regardless of whether it's good or bad.

---

Also, worth noting the difference between a roadmap and the project's status. As I said in a comment,

Consider a literal roadmap. To get from footown to barcity, the map shows that you need to travel 10 km west from footown to snathorp, 3 km north to fuvillage, then 8 km north to barcity... but it doesn't tell you when you'll arrive, because it doesn't know when you'll leave or how fast you move. It's a map; it doesn't know anything about who's using it. Compare that to the plan of "We'll leave at 8am and hope to reach barcity by 2pm, assuming the car doesn't break down again, in which case we should arrive by the next day."

Answer 4

I surmise that what you're calling a "spontaneous task" is when a trouble-ticket is filed that has to be dealt with right away. These activities are separate from the project that you're roadmapping, and don't belong in it. But you do need to record and account for the time. You do need to know what percentage of your work-day is available for allocation on your road map, and you need data to back it up.

There is another important consideration which has to do with corporate taxes. These "trouble tickets" are usually accounted-for on the company's books as operational expenses ("OpEx"), while development activities are accounted as capital expenses ("CapEx"). So, you really do need to be careful not to intermingle the two. Part of your workday will be spent doing the things that in the road map, while part of it will not, and those two expenses might be "booked" in entirely different ways. When the end of the fiscal year comes rolling around, somebody's going to be asking somebody for a definite number that will stand up to an audit. (That's the real reason why you're required to turn in a time-sheet ...)

Answer 5

I would never recommend to leave a task/user story/bug without been mapped to Epic / Feature.

Spontaneous tasks should be mapped with an Epic / Feature. This is how we followed in my previous organization,

The Epic is broken down into several feature and features are mapped to Epics. Features are mapped to the user stories.

The tasks and bugs are mapped to user stories. So, the final hierarchy will be something like this, Epic - > Feature - > User story - > Tasks / Bugs.

From your statement, I could see you are not following the above hierarchy. In order to answer your question, I would say create another EPIC and map the spontaneous tasks to them.

There is no harm in creating multiple Epics under one stream.

Hope this is helpful.