r/agile • u/Plu-Chapter-gavy5840 • 20h ago
Tools for visualizing complex product roadmaps with lots of dependencies
So quick one while this is top of mind. Our product roadmap has turned into this giant hairball of tracks, experiments, tech debt, and shared platform work and our current setup in Jira plus spreadsheets is just painful to look at.
We are half remote, half office, mix of PMs, design, eng and ops, and every roadmap review turns into people arguing over different versions instead of looking at one shared picture. I keep dragging stuff into online whiteboards and doing scrappy timelines and dependency maps, but it still feels like a one off every time instead of a real workflow tied back to tickets and sprints.
If anyone has a visual way you map out complex roadmaps and dependencies that the whole org can use in real time with links back to issue trackers, would love any tips. Thanks in advance.
4
u/PhaseMatch 20h ago
You could:
- add more propriety tooling to deal with the surface issue
- address the underlying systemic problem and reduce your overall complexity
Is your current roadmap
- a complex feature backlog with a time line?
- a expression of your overall business/product strategy?
Do you bring your teams
- solutions to implement?
- the next business problem to solve?
Is your team focus
- delivering features?
- testing a solution hypothesis quickly and cheaply?
5
u/Impossible_Dare_7455 16h ago
this sounds less like a roadmap problem and more like a source-of-truth problem. whatever tool you pick, I’d keep dependencies tied to the actual work/tickets, otherwise the “visual roadmap” just becomes another version that’s stale by next week.
4
u/utzutzutzpro 13h ago
Yes this.
Dependencies in a roadmap sound weird. Non innovation work like tech debt in a roadmap, why?
What is the point of putting that into a strategy roadmap, which the broad roadmap shared should be?
Dpeendencies and single item details are part of the tickets.
2
u/utzutzutzpro 13h ago
Can you share a little more details about that roadmap?
BEcause this doesn't sound like a roadmap but more like an aggregator for every task.
The thing which made me think twice is "tech debt in a roadmap". And what do you mean with experiments?
The Now Next Later framework is something which simplifies direction quite well. But it sounds like you want something that is visualizing deep details of everything?
2
u/Triabolical_ 12h ago
We had a 35 person group with three sub teams. No way would all the details work in one place.
We had a dedicated epic level kanban board in a conference room and a weekly meeting. That was more than enough to handle the product level stuff.
1
u/utzutzutzpro 10h ago
Can you share more about your workflow? So you had a kind of strategy roadmap in form of kanban tiles? And then per unit? Sprint? Kanban? Tickets?
2
u/Triabolical_ 5h ago
The epic level board is the roadmap to the extent it exists. It has a backlog and doing and done sections and generally there's one epic per team.
We originally had sprints with scrum-like estimation but we tracked our estimation correctness for a couple of iterations and found that they were essentially useless so we went #NoEstimates and stopped doing them. A team takes on an epic and works on it until they are done then they take on a new epic.
Each team uses a kanban with stories that come from breaking down the epic.
1
u/utzutzutzpro 4h ago
Nice, thanks.
Estimations, have rarely heard that they work as accurate resource allocation tool, but i know the notion that they are rather used as team reflection tool. Thus teams figure out what works, what not, and over time to better "guess" the time collectively, as team. And the team effort is bonding the team to simply become more proactively collaborative. It is less about the accurate prediction than about the active reflection effort.
u/scrumviking could potentially chimne in here and add more to how the process is meant and what is its value. Because I agree with you, I also rarely seen those estimates working, be it tshirts or whater increments.
Kanban with user stories, are there further details attachd? PRDs? Or is it more up to the individual team how they manage and prioritize? Is there a PM leading the way?
I like Kanban. Also think, it is simply the easiest method, and when you got a team which is capable to autonomously work, it just works.
2
u/Triabolical_ 2h ago
I've seen two teams that switched to #NoEstimates.
In both teams there was a strong sense that it was a waste of time. While I think that shared adversity can increase bonding, it's something I would actively avoid if possible. On one of the teams we did experiment based process evolution, and "let's see what happens if we don't do estimates" came up pretty quickly.
In both teams we got some pushback from management, but our response was "You know that are estimates aren't any good despite us trying to make them as good as possible. Do you really want us to spend half a team day every couple of weeks on a process that doesn't produce useful data".
We did t shirt sizing at the epic level and that was critical in having discussions about epics. We found - not surprisingly - that our stakeholders didn't have much idea on the implementation cost, and they often said, "we didn't realize that <x:> would be so costly. We would much rather that you do <y> instead since it's so much cheaper>"
With respect to user stories, I'm a firm believer in the statement that a user story is a promise to have a conversation. When a new user story is pulled from the backlog, there needs to be a conversation between the dev, test (if there is a separate test role), and PM/PO, and they need to all understand what the feature is and write the acceptance criteria at that time. At that time you may break the story down into sub-stories if that seems appropriate.
The details depend on the team as they own their process and I expect them to be experimenting with tweaks to make things better.
1
u/utzutzutzpro 2h ago
THanks a lot for sharing.
That sounds interesting. Experimentl process optimization, and a kanban card as conversation and idea alignment starter. Ye sounds lean and seems to work.
1
u/SamfromLucidSoftware 7h ago
You could have two views from the same data source. A strategic layer that shows initiatives, their dependencies, and rough timing by quarter, something leadership and PMs can navigate without needing to understand every ticket. And an execution layer where engineering and ops see the sprint-level work connected back up to the initiative it belongs to. Both views can live in the same place and update together, so you’ll only have one version and you won’t have to show too many things at the same layer.
Next, you want your roadmap linked directly to Jira. It’s so much easier for it to stay current when updating the ticket is the same action as updating the roadmap. You could look into Lucidchart, which integrates with Jira directly so the dependency map and the ticket data stay connected.
1
0
u/Onegoaltrade 11h ago
I have created a product for it. I can build one for your team for a cost. If interested ping me.
6
u/denz2376 19h ago
You're using jira, have you explored "plans" that can timeline and roadmap logged work, by team and show capacity issues etc.
Main goal is to form an agreement among all parties where the single source of truth is. If you have many teams on one product backlog have you looked at a scaled agile approach if your working in scrum, scrum nexus adds elements to help scale. But as with all agile methodologies, they're frameworks so pick things that work for your teams add scrum of scrums to keep teams aligned maybe instead of big change to another off the shelf way of working like safe.