📣 Feature update: Hierarchies in Jira Product Discovery
You can now sign-up to the Jira Product Discovery Premium plan.
Other features of the Premium plan are described here and we've also published an implementation guide.
Up until today Jira Product Discovery only supported a flat model, where every idea was at the same level. This made a few scenarios difficult to model, for example creating Opportunity/Solution trees or showing how work from each team was contributing to a higher level initiative.
As part of the Premium plan of Jira Product Discovery we’re introducing a feature that lets you create custom product hierarchies - for example this view that shows Opportunities, Solutions and Experiments and how they ladder up:
The following demo walks you through use cases, how it works and how to set it up in your project:
This feature is in open beta and is part of the Premium plan
This feature is part of the Premium plan of Jira Product Discovery. Today it is available in open beta - anyone on the Premium plan can turn it on and use it, whether you are on the trial or paid version.
We’ve been using this feature for the past couple of months at Atlassian and so have a dozen customers who had early access and use it successfully in their JPD projects. The feature is in good shape and evolving fast, but there are limitations you’ll find in most beta features. You'll need to watch the videos on this page to understand how to use it successfully (self-service onboarding wasn’t done yet).
How to turn it on
First things first a Jira administrator will need to approve the use of this feature. As a Site admin: open any JPD project, go to Project Settings, go to Connections [Beta] and follow the prompts.
Note: even though the settings are in Jira product admin settings, you need to be a site or org admin to turn it on!
Then your teams can start using it in all Jira Product Discovery projects for that site.
How it works
In Jira Product Discovery you have projects, projects have ideas (up until today you could only have one type of object in Discovery projects: ideas), ideas have fields, fields have values, and you can create views that help you visualize ideas based on field values. This system works with different types of fields: select, multi-select, rating, votes, etc.
Here we are introducing two new concepts so you can create hierarchies:
-
Custom Types - so you can have different types of objects in your discovery projects - e.g. Opportunity, Solution, Experiment - instead of just Ideas.
- A new type of field: Connection - which lets you connect ideas of different types. The easiest way to think about this: ideas can be field values for other ideas. For example an Opportunity called “An opportunity” can have the field value “A solution” for its field “Solution”.
- Integration of these fields into JPD views: you can use Connections fields as you would any other field in JPD to create custom views. For example in a list view:
Or in a board view:
Under the hood connections between ideas are stored as Jira issue links. It’s still a flat model, where all ideas are at the same level in a graph, but you can use views to visualize them in a hierarchy:
When you connect ideas via a connection field, this connection will show on both ideas - it’s bi-directional:
Connection fields behave a bit differently to other JPD field types (select, multi-select, etc.) in that they don’t really store any value - the connections between ideas are stored as Jira issue links.
How to set it up
Create types and connection fields
You need to create one type and one connection field for each type. For example if you have 2 types, Opportunity and Solution, the steps are:
-
Create a Type “Opportunity”
-
Create a Connection field “Opportunity” pointing to that Type
-
Create a Type “Solution”
-
Create a Connection field “Solution” pointing to that Type
Here’s a demo for how to do that.
Here are a few things you should be aware of:
-
Make sure you create one Connection field for each type - otherwise if you connect 2 ideas the connection will only show on one of them, not both. There’s no point creating more than one Connection field for each Type - because it stores connections as Jira issue links, if you connect ideas via one Connection field, it will also show in any other field pointing to the same Type
-
Pro-tip: You can create connection fields as Global or Project fields, depending on your overall set up. It’s OK if you don’t get it right from the first go: you can create a Global field, add it to the project, and delete the project field - and ideas will still be connected as before.
Configure views
You can then set up a view to show up to 3 levels of ideas, e.g. Opportunity/Solution/Experiment:
To do so:
-
Create a filter to only show ideas of a specific Type (Solution) - this “focuses” the view on Solutions
-
Group by a Connection field (Opportunity) - it shows Opportunities as “Parents” of Solutions
-
Add a Connection field to the view (Experiments) - it shows Experiments as “Children” of Solutions
Watch this demo for how to reproduce this view.
Understanding filtering
You can filter ideas at 3 levels:
-
Ideas you are grouping by (e.g. Opportunity): you can select which ideas to show as groups, the same way you would when grouping by any other field type
-
Ideas that are shown on the view (e.g. Solution): it works the same way as filtering ideas in a view today
-
Ideas that show in a connection field (e.g. Experiments): for this one it’s probably best to watch this 3min demo video to understand how that works - for the moment you can only filter them based on the group by / board column configuration, as per this example:
We are currently looking at ways to simplify this and let you filter all ideas at the 3 different levels the same way.
Set up automation rules
If you want to use Connection fields in Automation rules and/or JQL, just remember that connection fields don’t really store any value - the connections between ideas are stored as Jira issue links.
Here’s a demo of an automation rule with connection fields.
Connect ideas from different projects
You can connect ideas from different Discovery projects. Let’s take the example of a set up where you have:
-
A Discovery project that has opportunities at the company-level
-
2 Discovery projects, one for each team, that have solutions
-
And you want solutions that teams work on to be connected to company-level opportunities
You can achieve this with connection fields:
In this sample view in the company project, you can see how opportunities connect to solutions from the two separate team projects:
Here’s a demo for to replicate this set up:
Using Connection fields in Roadmaps
You can use Connection fields in Roadmaps as long as you create them as Global fields.
Jira Product Discovery was built on Jira team-managed projects, which means that we don’t yet support Global Types. This means that if you want to use a Type called “Solution” in 2 different projects you’ll need to create that Type in both projects. But then you can point the Global Connection field to both these Types as long as they have the exact same name.
You can use these global fields in Projects and in Roadmaps. The best way to understand when and how to do that is to watch this 4min demo:
What’s next?
This feature is showing a lot of promise, but it’s still early days. Over the next little while we will keep improving this feature up until we feel it’s good enough to make it generally available. We will then see how we can improve existing views (list view, timeline view) to better work with it. And we plan to introduce a new view type: the tree view.
Current limitations
- Product hierarchies are not yet integrated with Jira Plans. That's on the roadmap.
- You cannot connect ideas of the same Type. We need to do some testing to understand how it makes sense and if we can make that work
- We are going to look at improving the list view to add a second level of group by so you can show 3 levels of ideas in a tree there - but that's not there yet
- We need to do some work to integrate this into the timeline view better - today the only thing you can do is group by a connection type, which has value, but we'd like to see if we can go further there.
- Connection fields are only available as multi-select today. We might add a way to restrict to a single option if that's useful.
- Connections are not inherited: e.g. if you connect A to B, and B to C, it doesn't connect A to C. But you can do that via an automation rule with a bit of fiddling.
- You cannot yet "roll up" field values to connections unless you do this via an automation rule (e.g. roll up "impact" from "children" to the "parent" idea)
Was this helpful?
Thanks!
Tanguy Crusson
About this author
Product @ Atlassian
Atlassian
Nice, France
300 accepted answers
25 comments