Release Management & Discovery Projects

[Matt Evered]

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

[Jimi Wikman]

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.

[Jan-Hendrik Spieth]

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:
  
• 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?

[Jimi Wikman]

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.