How to manage bigger JPD idea/project divided into multiple smaller chunks of ideas

[Atul Patil]

Hi everyone,

We are working on one big project in JPD which is divided into 5 different smaller chunks of ideas, which we want to iterate on one by one to complete the bigger project.

Out of these 5 ideas, at a given point only 1 will be in "Now" bucket and rest would sit in "Next" or "Later". 

Now the question is - With the ideology of the JPD, where should we keep the bigger project/idea in the JPD  - in Now, Next or Later ? 

Considering there smaller work item of the original big idea is in the Now bucket. 

[Tanguy Crusson]

Great question @Atul Patil 

The way we've been doing this in the JPD team is moving the bigger idea to the Now section (as in: "we are committed to this"), and explaining what we're working on exactly in the description. Then, when we're done iterating, we either move it back to "next/later" or create a new idea "e.g. "Timeline view improvements" to represent everything we didn't do yet, move all relevant insights to it and add it back with the rest for prioritization. 

It's not ideal, but it worked for us so far. We are currently looking at how we could make this better with custom issue types/hierarchies:

Would something like this be useful to you?

[Adrian_Lester]

Massively useful, yes.

[Stephen_Lugton]

Incredibly useful for us

[Megan Fox]

This is very useful to us as well we were looking for some type of initiative level parent that could have many features/solutions underneath. 

[Andrew]

Yes! Currently we really like to group work into milestones so we can connect a milestone of value delivered to the customer with development work planned in out product increment (PI planning). 

Having a separate issue type with a milestone that can act as a parent to a feature would be great!

[Jason Cox]

This would be hugely useful for me also.

[Johan Lejdung]

This would be absolutely amazing! As of now Product Discovery lives in this weird middle-ground, where it's awesome to discover, specify and prioritise medium size work with stakeholders and then link it to delivery epics/tickets. But for any kind of roadmap or collection of tasks it becomes rather unmanageable, we've resorted to either custom fields & filters or third party apps to solve this for the time being. I've managed to keep people to the product with the promise this will be fixed soon though :)  

[Berit Schulze]

Having child issues like features or milestones underneath idea level would be a big and relevant step forward!

[Stephen_Lugton]

One way we've been getting round this kind of thing is to use Atlas for the big project then in JPD we link each of the smaller ideas to the Atlas project

[Patrick McAndrew]

I will answer your question with another question: why not have 2 roadmaps to show both levels of progress? For us, we struggled with a similar problem and how to communicate the progress of ideas most accurately. Ultimately, it came down to how granular the progress needed to be shared and who the consumers of the progress updates were.

[Tanguy Crusson]

yep, here's how we do it in the Jira Product Discovery team:

Demo: a roadmap with 2 levels

[Stephen_Lugton]

@Atul Patil You could also edit the roadmap field to have more than just Now, Next and Later e.g.:

• Phase 1
• Phase 2
• Phase 3
• Phase 4
• Phase 5
• Final Delivery

Using this approach you could have your big project as Final Delivery, and each of the 5 smaller chunks in the appropriate Phase.

This may look like a waterfall approach, but it would help with differentiating each chunk of work, and you can just move them to Now when ready to be worked on.

[Kyrstin Dittenhafer-Swartz]

I see 2 schools of thought on this:

1. Place the bigger project in Now. Justification: Each of the smaller projects are key components to the realization of the bigger project. Therefore, by proxy, as soon as you start any of the smaller projects, the overall bigger project is effectively being actively worked on now. 

2. Place the bigger project in Later. Justification: Each of the smaller projects are needed to be completed before the bigger project can be realized. Therefore, the principle of the bigger project will be realized later. 

I don't personally see a justification for setting the bigger project as Next. But, as far as Now vs. Later, I would go based on either your product organization's/team's line of thinking or based on the subject matter of the bigger project itself (in other words, if ROI of the bigger project begins as soon as one of the smaller projects is completed, go with Now; if ROI of the bigger project can't be realized until all of the smaller projects are completed, go with Later).