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

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

Avatar

1 badge earned

Collect

Participate in fun challenges

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

Challenges
Coins

Gift kudos to your peers

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

Recognition
Ribbon

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!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,462,167
Community Members
 
Community Events
176
Community Groups

Release Management & Discovery Projects

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

2 comments

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

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

Comment

Log in or Sign up to comment
TAGS

Atlassian Community Events