Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Release Management & Discovery Projects

How are people managing releases of multiple child projects when the parent project is a discovery project? 



Log in or Sign up to comment
Jimi Wikman
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 19, 2022

I would assume most don't yet as JPD is still pretty new.

If you look at it from a process flow, then a discovery project is just the initiation of a potential need. One discovery item can lead to one or many requirements, which in term can lead to one or many development tasks.

So a release that fulfill a requirement is what you are looking for and that is not what you have in Jira Software. Jira Software have release of code packages. That means that you would track the closure of the Feature, or Epic that is a child of the discovery item. Not releases.

So you would track when the connected epics/features are closed. Just as you would track stories in an epic.

I'm not totally sure what your question is about, @Matt Evered Actual release management tasks? Or more something like, how to organize fields so that they fit several delivery projects?

Anyway, adding to what Jimi Wikman already wrote, for our experiments with JPD, we have in fact chosen a "one JPD project for several related Jira software projects"-approach.

This is how we use it:

  • an idea allows us to plan ahead (which teams/projects will be involved?) and gives delivery issues context (why are we doing this?), but we don't worry about tracking status too much on JPD side - just a bit of visual info on some board cards:
    Screenshot 2022-10-19 215717.png
  • Progress tracking and release status info is all done in Jira (or other tools). JPD status follows the status of the delivery issues. Keeping it simple, JPD DONE = all delivery issues are DONE. Just like Jimi wrote.
  • Additionally, we're experimenting with Atlas to define, track and communicate goals and tasks, on a higher level.

JPD and Atlas give us a different "angle" on things, and that can maybe help with release management, because you're more likely to understand how all your works connect.

Coming back to what I wrote earlier, JPD does indeed have some features that relate to release management, such as the roadmap field. And indeed, it's not a trivial question whether you can use one common Roadmap field for all your Jira projects, or whether you need several?

Or also, if you do "MoSCoW" prioritization, is one Jira project's/team's "Must have" necessarily also a "Must have" for another, or do you need separate moscow fields for each Jira project?(Wait a moment, if we duplicate all fields for each Jira project, shouldn't we rather have one JPD project per Jira project? *head spinning* ;-)

We decided to ignore all this for now.

Maybe the Atlassian team has some thoughts to share?

Like Jimi Wikman likes this
Jimi Wikman
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Oct 20, 2022 • edited

It is also important to distinguish between Feature availability and code releases. Jira does not have feature availability, unless perhaps it is available in Jira Align. In fact, besides Jira Align, that you can't really test at the moment, there are no strategic tools for the users, only operational.

Jira product Discovery is the first product that touches on that. Confluence can of course also be used strategically, but that is because it is a neutral documentation tool.

It would be awesome if we could have a release tool from a strategic perspective...or an operational tool for that matter, connected to Jira Service Management since the ITSM tool is usually the one having that since changes go that way.

Normally I use Confluence for feature and product availability since that is also where Requirements live. That makes it easy to follow the chain up to vision level and down to execution level in one tool. I am still not sure if Jira Product Discovery can fill that function, at least not yet.

Like # people like this
AUG Leaders

Atlassian Community Events