Hey community, my name is Sam from Atlassian and I'm a designer on the Portfolio for Jira team. Our team has seen that no two roadmaps look the same and come in many different shapes and sizes. Getting stakeholder buy-in, making tough prioritisation decisions, and turning those plans into actions is a huge challenge and it can feel like there's no "right way" to do it.
We'd love to hear from you. How are you dealing with some of these challenges at the moment? What are the things you've found have made it easier to communicate and collaborate on roadmaps?
We're hoping this discussion will give us insights that we can use to improve our products such as Jira , and Portfolio for Jira. Also, if you're interested in having a more in-depth or private discussion with us about this topic, you can email us at: portfolio-feedback [at] atlassian [dot] com
@Jack Brickey, we're interested to learn more about things like:
Whether Atlassian tools are used or not doesn't mater so much for this. If you use a spreadsheet, or even a whiteboard that's still things we're interested in learning about why that works. Because sometimes, those basic solutions can work well. Thanks.
Sam, sorry for delay in getting back. Here is some input from my current and past road-mapping activities.
- The ability to show history on roadmaps is important.
- Communication of "committed" changes need instantaneous communication and that communication often needs to reflect the why as changes understandably drive Sales and others crazy.
Agreed on these two points especially. If there was a way to notify a group when changes are made, with comments, and a version history, that would help our PMs track changes and have conversations around pushed target end dates for instance.
Some things that would be nice in Portfolio.
1) Being able to bring in more than 5000 issues - I know programmes are coming but don't yet know how they work as we're on the cloud version.
2) Flexible hierarchy; both parent linking to issues higher on the hierarchy (eg user story to initiative) and having multiple hierarchies to support different business units
3) Legends on the charts for scope, schedule and themes. With clear statements about where the source data comes from.
4) Clearer 'hints' at where constraints are moving items on the schedules
5) Percentage of teams/peoples efforts against initiatives - not just the remaining capacity
6) A consistent edit/view screen for issues as Jira has
+ Ability to see a historical view of work completed based on initiative with linked hierarchy and estimates so early high level planning can have some chance of being in the right ball park
Hey @Steven Dodd,
Thanks for joining in on the discussion. For the topics we're trying to learn about most, I'd be interested to dive deeper into #3, #4, #5. The other issues are important too, but might not match the topic theme of this. When it comes to sharing your roadmap at the moment.
Hiya,
The top things I am trying to communicate are:
1) What we are going to deliver looking forward
2) How much it will cost
3) The ability to drill down in to it - epics
4) The other stuff that we also put work into but is not directly delivering the agreed business value
5) How much effort individuals and teams spent on each initiative
6) I am happy to present directly from portfolio and am not too fused about the medium although the senior executives in my current organisation like power points which are highly customised and the information coming from Portfolio is only a subsection of that information.
It all boils down to ensure we can align future and historically delivered business value to agreed budget.
@Steven Dodd those are all great insights. Is this something that happens weekly, quarterly, annually? How often are you doing these kinds of presentations?
Live data is always best - I would rather they could self help if possible. Less presentations and meetings are always desirable. The data coming from Jira populates weekly, monthly and quarterly reporting.
@Steven Dodd, couldn't agree more. The worse thing about roadmaps is that as soon as they go on paper they are out of date.
+1 On this point. Any road map that is disconnected from my data in a tool like Jira is immediately obsolete. It's a real pain to manage and update these manually.
@samrobertsofficial I my experience as a Product Manager, the best tool I've used is Product Plan. It always for flexible date ranges (unlike Portfolio which is based on estimates). You can also add things like links to scope docs, comments, resources, and feature grouping.
But at the very minimum, the helpful thing is being able to add a feature as a horizontal block, and then manipulate the length and location of that block horizontally across a defined timeline.
I would also add that it's essential to be able to share the roadmap as a private link without requiring a user login. Not all teams (especially C-Levels) have access to or know how to use the Atlassian products. So any roadmap tool needs to allow a user to share the roadmap to anyone via a link.
@Josh Carter so after you've added a few features as horizontal blocks and moved them around on the timeline, I can imagine there'd be various secondary pieces of information that you'd want to bring along with that.
Lets just say you've got all these bars laid out and they are all grey and in a list, I'm guessing that probably wouldn't be enough for meaningful discussion. What are the other things that you'd like to include, and why would you say those things are must-have?
The hardest (most time consuming) part about building out a roadmap that will be used to communicate UP (C-Level) is the flexibility of features (epics or projects). While Portfolio does a good job of creating a roadmap based on Epics and Stories, it uses story estimates to determine the timeline, which means it's not flexible.
You're right that a bunch of grey boxes isn't all that helpful. So the ability to change their colors, create a legend, and group them would be great.
One last thing, while not essential, but the ability to attach information to each block would be helpful. It's not essential because most Execs won't take the time to dive deeper into the weeds. Usually they just want a high level.
Another helpful thing might be a list of "What Didn't Make It". Product Plan calls this the Parking Lot. But just to tell the story of resource management and trade offs made.
@Josh Carter when it comes to "change their colours" and "group them", what are the ways you're wanting to do this?
Absolutely agree with the above thread regarding only using estimates for the timeline of the road map - it is a real challenge. It's a nice first look but not the ultimate schedule.
One of our biggest challenges is bringing in several 'solutions', each with thousands of Initiatives, Features, and Epics. It becomes difficult to properly estimate the hours and that skews the roadmap projections. We have been trying to standardize our estimation since the company uses mixed methodologies of SCRUM and Kanban and both estimate differently.
On top of that, the executive management likes 'old school' presentations as indicated above, but again challenging when the road map is an enterprise event and not just a small sunset of projects.
A roadmap is only as good as its prioritization
Prioritization is only as good as the ratio of benefit vs. cost
Ratio is only as good as estimation accuracy
Accuracy is only as good as known factors
Known factors are sometimes limited
Therefore: gathering, sorting, and evaluating information prior to roadmapping is most critical. The difficult part has to do with time constraints. Documenting everything isn't viable, and not everyone uses the same tech stack in a large organization. Therefore, balancing time vs. research vs. Communication is the most difficult aspect.
Finding better methods/tools to quickly and accurately identify, evaluate, contextualize and share known factors is critical.
Well said @Brian Pohuski, a roadmap is only as good as its prioritisation. I think If you're solving the wrong problem for your customers, it doesn't matter how good you are at executing it. Its definitely very messy to make those trade-off decisions. Is there anything in particular you've found effective?
Not putting anything important along the creases ..
@samrobertsofficial Roadmaps are always tricky as they mean different things to different people.
Clearly, talking to people helps to build and shape the roadmap, but as others here are showing, Exec teams prefer PowerPoint.
I’ve recently used an interactive Visio diagram linked to SharePoint pages and this has had very good feedback from end users. They have the high level detail in the visual, but more detail on the linked pages. This was done because the previous PPT route just wasn’t engaging enough and people just saw a Gantt chart and we’re turned off.
As has been noted, this is all extra effort as the majority of our work is planned and executed in JIRA as we use it for Development and IT Operations who also run sprints.
One absolute critical element for me is accessibility. Roadmaps are great visual tools, but very rarely can they be navigated by a screen reader in any logical manner.
Thats why we took the Visio / SharePoint route. Although visual there is a clear text / keyboard navigation for blind users.
Great to hear about some success there, @Richard Billam! How has linking to an interactive version been received by stakeholders who are used to the more traditional formats? Are they comfortable in the tool?
As you can imagine the click through rate is pretty low. The Exec team have the high level view they’re used to and are comfortable the detail is there if they needed it.
However, those that are accessing it love it. They have they detail they need without having to come and ask for it. We find making this information more accessible helps significantly with engagement and understanding.
+1 for catering for accessibility! Did not know visio and sharepoint can do that. Are you able to share a little more on how that works?
Being able to rank a story above an EPIC in Portfolio - I require to be able to show this within Portfolio, and the story will not always be assigned within an EPIC.
Hi @Sanjay Athwal, lets get in touch with the problem you're having. Could you create an issue at
Server - https://jira.atlassian.com/projects/JPOSERVER
Cloud - https://jira.atlassian.com/projects/JPOCLOUD
So that others can vote and comment on this request. Try to leave as much detail as the scenario or problem you're facing, so we can understand it better.
Thanks,
Sam
The hardest thing about creating a Roadmap is bringing digital data to the analogue space of “Big room planning” as this form of planning is a social event. Most team and leadership are to tied to a digital tool overhaving shared space to frame and iterate on ideas. To visibly recognize the dependencies and out of sync ideas on a Roadmap.
Finally when all is said and done making the Roadmap relevant and having it linked to the work as it is being done. This allows reality to creep back in.
Completely second Tarang!
Roadmap strategy sessions are the big picture in an event / easy to digest format. At the same time being able to access the underpinning information quickly.
Technical dependencies, opportunity cost and all the other data needs to be available on demand. Our session toggle between Themes in the sense of a bunch of mostly independent epics and the actual epics, the latter usually come up when cost and dependencies are an issue.
~Mark
Have also had this issue. Probably the biggest trouble here is highlighting the cross-team dependencies as they arise, particularly across environments. This is important for the product folks too, because of when and how they are scheduling User Acceptance Testing.
Hello,
Most of the issues written here resonate with me.
Hi,
Main whys for making roadmap:
High level product planning
- to ensure compliance towards strategy and product market fit
- to enlighten and support stakeholders (board, sales, customer success, stakeholders)
- to keep team aligned and reflective on the direction after the next sprint
Main pains with roadmaps (apart from regular change):
Visualisation requires (Google) slide format to:
- show a (Horisontal) timeline view
- show 5-10 items including small text + image over 12 months time line
- flexibility to move stuff around and optimise for different stakeholders
- show on screen
Issues about slides:
- Disconnected, so not possible to map epics into high level roadmap items.
- Disconnected, so not possible to see completion rate of roadmap items
/Anders
Speaking for our company we use a simple Excel file to handle our roadmpap.
After discussing the topics with the stakeholders and prioritizing we create epics and tasks within Jira.
We don't use Portfolio at the moment and never tested it, so I don't know if this could help us in integrating our roadmap better with Jira.
We also use Mindmaps (especially before we create an Excel) to group bigger topics and subtasks to discuss in our product management team.
@Jason Walther, is there a particular Mindmapping tool you leverage? Or is that analog as well?
@Doug, we use Mindmanager, it's available for Windows and Mac. Some also use Freemind as a OpenSource Tool.
Hi, not sure if your question @samrobertsofficial relates in any way to the Roadmap (beta) view that I discovered today after creating a new Agile project in Jira Cloud but I was really positively surprised to see FINALLY a working roadmap view by Atlassian!
Even in it's current simplicity it would already offer significant benefits to my organization in which I've always answered repeatedly to the question "Does Jira show roadmaps" the same way: you can use some 3rd party things but they seem pretty expensive and many does not even work in Cloud.
On the other hand a big disappointment for me was when I found out that the Board view (with statuses) only shows Stories and it seems that I cannot influence the filter to show Epic's only - it would be so nice to follow the scheduling and prioritization from Roadmap and then the statuses from Board. It seemed to nicely sync the statuses that I created on Board also to Epic's on Roadmap - which was not so logical, since I believe that in many cases your Epic's would have different lifecycle than your stories.
My need would be to show / follow Epic's with management and perhaps then create only few stories for project managers.
Would you have anything to share about this feature's future plans?
I have an IT project management background and have worked primarily in Microsoft shops. I joined a new company this summer that uses Jira and Confluence and have been coming up to speed on those tools (kudos to the great documentation on this site). Jira is great for issue management and Agile development, but is limited in project management for larger efforts. The company added Portfolio, as it’s needed to provide the type of hierarchical reporting the executive team would like to see.
For one-year and five-year roadmaps, I used Visio and PowerPoint at my last company and have used PowerPoint here for some presentations. Swim Lanes keep track of the categorization by business area with key deliverables mapped in on the timeline. Confluence offers good options for communicating Roadmaps, as the author can import various visuals.
Being able to keep track of changes with versioning or a good history is essential, as this company works with government mandated changes that take priority over planned efforts. Even if we try to plan for regulation changes, there are always unexpected changes that crop up. We must communicate them and keep track of the original roadmap planned to actual deliverables.
Hi,
In my company we use Portfolio to create roadmaps on two distinct axes:
- Project Roadmaps
- Team Roadmaps
Where Projects and Teams are n-n relationship. One team can work on several projects and one project can be done by several teams.
Then we use extensively Cross-Project Releases because a Release can span out on multiple Projects.
We have a hard time using Portfolio because, as it seems, we need to put everything in one big plan which makes it a nightmare to manage Cross-Releases as we have hundred of Releases to chose from and there's no easy way to select them.
We would rather use a Program with multiple Plans in them. But we are facing the following problems:
- Cross-Project Release cannot be used at Program level on another Plan from which they were created.
- Shared Teams velocity can only be set within a Plan and not aggregated at Program level if we wanted to make a Plan per Project.
Any insight on how we could handle this?
Thanks for asking about Portfolio! However, it would probably be best to create a new community question about this. That way it will be more searchable for others in the future.
This community discussion is more about challenges of creating roadmaps in general.
Sorry if this is a bit annoying but I just want to make sure this doesn't get lost.
Thanks,
Sam
@samrobertsofficial - New to this discussion but I'd love to share with you a view we've manually created for our roadmap - in PowerPoint. Right now I'm attempting to recreate it in Jira Portfolio view and it's painful as we can't color code easily and it's not as visually appealing. We end up having to recreate it in multiple forms for our executive discussions. Anyway - if you can share your contact info, I can share the ppt so you can see what I mean.
Hi @Stefana Muller I would love to see what you're trying to achieve. You can reach out to us at the email address: portfoliofeedback@atlassian.com
Awesome! Thanks - email sent.
Clearly showing features/issues that are developed across a wide variety of platforms, e.g. where is "feature x" on desktop vs. mobile clients?
Epics of next-gen projects are counted as stories and we moved all our projects to next-gens :(
A lot of feedback gathered here: https://jira.atlassian.com/browse/JPOCLOUD-2652?_ga=2.243165572.708497736.1547044711-1142840442.1523709668
At my last job, they were looking at using a tool called SharpCloud to record the roadmap and have every item on the roadmap link to projects, which would contain task and other items. It's quite a basic and simple to use tool in it's 'viewer' mode (basic enough even for the c-suite to use :) ) - but thats where the power is. They were talking about having large touch screens in various locations so folk could get an update on the project work and the roadmap whenever they needed to.
I've seen a bit about SharpCloud before, but it does way more than roadmapping, right? Is the roadmapping robust/good enough?
Curious how you linked out to projects, was that using JIRA for the tasks and other items?
They didn't use JIRA - they used MSP and Excel. So SharpCloud was just going to be used to display some of that data. I left before it really got going.
The current portfolio is a bit complicated. It would be great to just have something like the next-gen project roadmap and kanban combined, divided to swimlanes of projects, and have a progress bar, issue counter, team members, and an estimation date for each one.
The portfolio roadmap should be based on the individual roadmap of each project. Having the users filter will help the management and team leaders understand the statue of their employees, and would also allow each user to see their individual tasks.
I think the individual ones should even be part of the dashboard along with a simple To-Do list. It would be great if each user could change the view from kanban to a simple list - a lot prefer it that way (Asana has these features :)
This is how I envision it:
So to sum it up: There should be a portfolio that suits a few levels: Management, Team and Personal. It should be simple (like next-gen projects) indicative and effortless.
Across many tools that I've used for product roadmaps, the one thing I've always found difficult and had to rely on Excel for is defining product features.
The issue is that there is no one size fits all approach here- there are orgs that think of complete platform level functionality as features, and then there are others where PMs dig deep and define features to be much smaller steps of functionality.
The reason I add this here is that product features have been almost always the key defining milestones in my roadmapping exercises, but I've had to waste a lot of time first defining what a feature is for each client of mine.
@PMs, what is your take on this- is it even possible to define as a standard what a feature should be, and hence how roadmaps should be designed?
Eeshan ... I am about to trial Portfolio and your post rings very true with me; I am hoping that Portfolio will help me surface a roadmap at a feature level, rolling up to larger containers of features (modules? initiatives?). We generally think of features at the epic level, and often use components to portray a container of features (e.g. a component could be an invoice processing module, where epics would be things like "bring in invoices from sell-side vendors" and "allow users to reconcile invoice against campaign" etc.) I would very much like to be able to see a roadmap both at the module/initiative level and at the feature level, but have little need to see roadmap bars for individual epics or stories/tasks (though being able to drill down would be a nice bonus). Am I barking up the right tree with Portfolio?
And, to directly reply to your question ... I think the answer is no. :) I don't think a standard definition of the product hierarchy will be broadly achievable, since to your point, so many people approach this in so many different ways. But, I am hoping that I can find a roadmapping tool that will let me select the part(s) of the hierarchy that I want to surface.
I noticed that when I'm in Jira proper, we're able to describe the relationships that inhere between entities in an accurate and precise way (for instance, we're able to indicate that Epic A relates to Programs 1 and 2). I'm not able to do this in Portfolio (where, for instance, we're constrained to relate Epic A to Program 1 to the exclusion of Program 2). Most of my team's business stakeholders use Portfolio to learn about our work, and this design decision negatively impacts the degree to which we're able to communicate the scope and impact of our work.
Any plans to enable Jira-proper-style relationship attribution in Portfolio?
Hi,
Here are some things I am trying to communicate are:
1. The ability to drill down in to it - epics
2. What we are going to deliver looking forward
3. How much effort individuals and teams spent on each initiativent.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Apply agile practices
Transform how you manage your work with agile practices, including kanban and scrum frameworks.
Learning Path
Configure agile boards for Jira projects
Learn how to create and configure agile Jira boards so you can plan, prioritize, and estimate upcoming work.
Jira Essentials with Agile Mindset
Suitable for beginners, this live instructor-led full-day course will set up your whole team to understand how to use Jira with an agile methodology.