Adopting JPD has acted as a forcing function to discuss what details or requirements should go into Ideas, vs what info should be contained in Epics. For reference, in my background I'm used to crafting concise narratives that combine the business aspects with problem-orientated capabilities, that dynamically becomes a sort of live feature scope for the roadmap item over time. A living artefact. And before JPD, often times this would just reside in the Epic itself. My initial thinking on this: * Ideas should be problem-focussed, and act as the single source of truth answering why a roadmap item is being done, with enough details on what is being done as part of that item so people fundamentally understand what is being delivered, without being overly technical. This is key for stakeholder alignment and collaboration, and fundamentally the main reason we went for JPD. * And with Epics... they should be more solution-focussed, looking at the more nitty gritty technical aspects for whatever we are building, including specifics of acceptance criteria, super tactical detail on features, tech scope, tech risks etc etc... My main concern is I don't want to result, ironically, in a situation where someone has to refer to a large number of artefacts to really understand what the scope of work is. Obviously quite a few stakeholders only need the high level that will reside in an Idea, but some people want all the details, all of the time. Any thoughts? How is everyone else approaching this?

@Freddie Bendzius-Drennan Great write up thanks for sharing! Just to validate your thoughts, this is how we run JPD today! Ideas define what and why we need to address a problem. Epics are used to document the how of what we are going to deliver to do it in incremented value steps. For Example * Idea* Adapt Administrator tooling for Super-Users * Why - Feedback from interviews, platform stats, etc * What - Revamp workflows, add A, B, C integrations, etc * Epics* Build Workflow X * Build Workflow Y * Integrate into C * Integrate into A * Integrate into B Addressing your concern, I haven't really experienced this issue with stakeholders myself. Generally, the people interested in the Why and What are different than the delivery-focused how cohort of stakeholders. Regards, - C

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How is everyone treating Ideas in relation to Epics?

Former user

Adopting JPD has acted as a forcing function to discuss what details or requirements should go into Ideas, vs what info should be contained in Epics. For reference, in my background I'm used to crafting concise narratives that combine the business aspects with problem-orientated capabilities, that dynamically becomes a sort of live feature scope for the roadmap item over time. A living artefact. And before JPD, often times this would just reside in the Epic itself.

My initial thinking on this:

Ideas should be problem-focussed, and act as the single source of truth answering why a roadmap item is being done, with enough details on what is being done as part of that item so people fundamentally understand what is being delivered, without being overly technical. This is key for stakeholder alignment and collaboration, and fundamentally the main reason we went for JPD.
And with Epics... they should be more solution-focussed, looking at the more nitty gritty technical aspects for whatever we are building, including specifics of acceptance criteria, super tactical detail on features, tech scope, tech risks etc etc...

My main concern is I don't want to result, ironically, in a situation where someone has to refer to a large number of artefacts to really understand what the scope of work is. Obviously quite a few stakeholders only need the high level that will reside in an Idea, but some people want all the details, all of the time.

Any thoughts? How is everyone else approaching this?

Accepted answers

Chris Timms

@Freddie Bendzius-Drennan Great write up thanks for sharing!

Just to validate your thoughts, this is how we run JPD today! Ideas define what and why we need to address a problem. Epics are used to document the how of what we are going to deliver to do it in incremented value steps. For Example

Idea
- Adapt Administrator tooling for Super-Users
  - Why - Feedback from interviews, platform stats, etc
  - What - Revamp workflows, add A, B, C integrations, etc
Epics
- Build Workflow X
- Build Workflow Y
- Integrate into C
- Integrate into A
- Integrate into B

Addressing your concern, I haven't really experienced this issue with stakeholders myself. Generally, the people interested in the Why and What are different than the delivery-focused how cohort of stakeholders.

Regards,

- C

All comments

Akeem P

Well JPD does allow you to create and link an epic from an idea which has been really handy and they recently started showing you the epic progress on the idea which is handy as well. We do something similar to what you describe (though maybe not as thoroughly) and our devs really are focused more on the epic side of things. I use the idea in the JPD to give context when the epic is presented in refinement but we don't generally have the devs on the JPD side of things.

Rohan Swami

hi @Freddie Bendzius-Drennan Rohan from the JPD Product Management team here. Thanks for asking this question. We're exploring how we can help customers with this set up. Would you be willing to have a chat over Zoom so we can understand your use case in more detail? You can book time with me on Calendly.

Former user

100% I really like how you can link them, and how it goes a step further to show delivery status. Though we aren't using delivery progress as we find that inaccurate, scope changes as we discover more and refine scope etc when building things.

Chris Timms

@Freddie Bendzius-Drennan Great write up thanks for sharing!

Idea
- Adapt Administrator tooling for Super-Users
  - Why - Feedback from interviews, platform stats, etc
  - What - Revamp workflows, add A, B, C integrations, etc
Epics
- Build Workflow X
- Build Workflow Y
- Integrate into C
- Integrate into A
- Integrate into B

Regards,

- C

Former user

This is great, thanks! I sometimes get what and how mixed up, but this is exactly what I meant.

Joris Roulleau

What you write makes sense to me. I'd add one aspect.

From my perspective, there's a blurry line between the type and level of information stored in JPD and Jira Software, and there's another important dimension that dictates what is an idea and what is an epic: an epic is on the delivery backlog and will definitely get done, whereas an idea may turn into an epic or may get canned.

In other words, I'm planning to use JPD (note, I've not road tested what I'm saying yet...) partly as a way to keep clutter away from the delivery backlog.

For me it's important that epics retain elements of the why and what, because I don't expect developers, QA etc, in short, the delivery team, to go back to the original idea ticket, and this information is important to them. Therefore I expect some overlap of information between ideas and epics. (Hopefully Atlassian does a great job at automating the duplication of specific information from an idea in an epic.)

Conversely, and related to the original question, I'm wondering whether defining solutions at a high level in JPD is a good idea, or whether I should leave that to the epic refinement after an idea has definitely been selected for development.

I'm keen on the Opportunity solution tree model, so on the plus side, considering solutions in JPD may help me and colleagues to consider several possible options, and keep a record of them. This may be useful when selecting, for example, a tactical quick and dirty solution or workaround, but we want to come back to a better solution at some stage (in a Jira delivery backlog, these rarely resurface). On the downside, we may end up doing that for something that will never get done (hopefully we will prioritise ideas well before getting to that stage).

I'm going to try this out, but if anyone's already done it, I'd also be interested in their thoughts :-)

Cheers

Adam Gustafsson

My view is that you do the investigation, analysis, insight work, assessment etc. of an idea in JPD, and once it is prioritised for delivery within the foreseeable future (say within maximum 6-12 months, otherwise it doesn't make too much sense to add it to a backlog since it would be bloated otherwise), then an epic is created in the backlog(s) in Jira Software (and/or Jira Work Management for that matter, if you also use that product). Of course, if the item is very small, it could be a story or task that is created instead.

The epic still contain the what, but on high level. It is then further broken down into stories/tasks to flesh out the what in more detail. If the devs want, they can add subtasks under the story/task detailing the how.

But this is just my view, and how I like to order things.

Tanguy Crusson

That's a great way to frame it, thanks @Chris Timms !

Pretty similar to how we do it in the Jira Product Discovery team:

Recording of a webinar about that here

Stavros_Rougas_EasyApps

Actionable yet simple suggestion:

Why and What in JPD then Build/Integrate in the Epic.

For me JPD is messy by nature. Insights are a bit of a 'data dump'.

The Why and What is drafted and re-drafted in JPD. If done well the What and the What we will clear and short.

Then I would add Why and What to the Epic as they add value without creating a mess/confusion. The 'kitchen sink' remains in ideas to consult as needed, valuable to have available, but without creating a mess in the Epic right from the start.

Developers in particular often prefer to 'move quickly' to the Epic. It is annoying to draft and re-draft, more work short term but 'more quickly' (e.g. skip the mockups) normally ends up meaning more time and/or a lower quality result.

Helena Jeret-Mäe

Miro is where I keep my opportunity-solution tree. Here is where we brainstorm ideas for solutions, prioritize, map the user story and identify assumptions we need to test.

So if a solution idea is a contender, I will add it to JPD. Anything that is of lower importance will keep living in Miro on a sticky note.

I try to add only those ideas to JPD that have been vetted to some extent because it's much easier to collect and organize preliminary ideas in Miro on sticky notes: cheap, fast, efficient. No problem if you ditch most of them.

But I wouldn't want to go through all the labelling and categorizing of ideas that are most likely garbage.

1. JPD collects the what, the why and the context around the idea.

2. Conflunce captures the refined solution descriptions/specifications (if applicable). This should be as close to the ready-to-deliver solution as possible and this documentation serves as a snapshot in time for how things were.

3. Delivery project: epics have tasks that refer to delivery of an idea (or might be one idea and a number of delivery tasks). Those tasks refer to the confluence page for implementation notes for devs, diagrams, wireframes etc. And the broader backstory is available via the linked JPD ticket.

This is how I do it currently.

Evgeny Zakharov

@Helena Jeret-Mäe May I please ask if you figured a way of linking Ideas with the delivery tasks for the purposes of creating a reporting dashboard that can provide an overview of the high level and corresponding epics/issues etc.?

Andre_vwl667

I agree with this but.

Where do you track the "investigation, analysis, insight work, assessment etc" work? where are these "stories"?

Welcome!

It looks like you're new here. Sign in or register to get started.