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; } } }

Request: Create Plan Templates

Paul Dickinson_kyocec

Hi,

I'd like to be able to create a set of plan views that can be applied to multiple different boards / teams.

My use case is having a group of product managers and eng teams working on a single Jira Project, and managing their own plans. To promote greater consistency, I'd like to make it easy for them to copy a standard set of views. However, I don't want to limit them from managing the views on their own plan as they see fit.

One possible solution could be to enable cloning of boards with the ability to change the issue source.

Comments

Curt Holley

Interesting idea.

Ultimately, based on your use case, the ability to clone a view would do. That way, you could take an existing Plan (issue source) and simply overlay the view (or set of views) required.

Yeah?

That said, I'm not sure here is the right place to make such a request. If I were you, I'd "Give Feedback" via Advanced Roadmaps.

Screenshot 2020-12-21 090307.png

Dave

Hi Paul,

Thanks for the feedback. When we considered the view switching capabilities for Advanced Roadmaps we did think about these types of use cases and discussed the options for having a full ownership model for views as we recognised that there would be cases where you might want to create one view and share it between multiple plans and give others the ability to edit and work with it.

However, as is frequently the case we had to rein in those original plans in order to just get something to market that met the immediate needs of our customers. We have deliberately implemented views in such a way that they could be extended in the future but at the moment we don't have any plans to do so as there are a number of other features and improvements that we'd like to address first that we consider a higher priority.

I do expect us to return and enhance the views model at some point in the future, but just to re-iterate it is not on our immediate roadmap to do so,

Regards,
Dave

Paul Dickinson_kyocec

Yes, that would be another solution that could work.

Paul Dickinson_kyocec

Thanks Dave. I totally understand that trade-offs need to be made.

FWIW, the impact of this on our team is making it much harder to adopt advanced roadmaps, as it significantly increases the learning curve for new adopters.

Dave

Thanks Paul, that's useful feedback. Your idea of copying plans is an interesting one which would allow you to create a template plan with a set of views (and might be an interim solution that we could look at). Would you not be concerned about the divergence of views after copying? Or is it just that you need them to get started?

It would also be interesting to know what you'd be looking for in a default set of views, or is the set up of views very specific to your project structure?

Regards,

Dave

Curt Holley

@Paul Dickinson regarding "harder to adopt AR for new users". I (as Site Admin and Coach for Atlassian products) have just documented my findings on Confluence, via a combination of simple "How to" pages and links to Atlassian content (written and video) and held a couple of Advanced Roadmaps demo sessions/Q&A via Video conference and have been pleasantly surprised at the uptake and autonomy with which that uptake occurred.

#foodforthought

Paul Dickinson_kyocec

Hey Dave,

I think that the getting started piece is the most important initially. I think that a more robust view system could come later.

I think our views may be somewhat idiosyncratic, but happy to share the use cases. This may be more in the weeds than you want. If helpful, I'd be happy to jump on a call with someone.

1. Sprint planning with the team. We review progress against stated goals. Generally an ungrouped view. We use this for setting sprint goals at the epic level (custom field). Note that we don't use the sprint grouping for this, as it tends to obscure the objectives we're working towards. Sprint rollups would be more useful if they showed the story points in the sprint as well.

2. Cross functional stakeholder execution reviews. We focus on the current delivery cycle (which we use "releases" for). Here we group by release. One pain point here is that in the grouped view, there's not an easy way to drill down to stories and tasks, unless they all have their release set as well. Would be nice if these "rolled down" from the epic if not set explicitly. In these views we give a status update and use a project health field to color bars R/Y/G.

3. Long term planning and capacity estimation. Here I'm doing a higher level planning exercise, where we often don't have more details than the Epic, and a swag of its size. It's quite annoying that I don't seem able to drag epics into the appropriate release.

4. High level group overview (across teams). Haven't figured out a good way to do this one yet as different teams have different levels of adoption. In principle, grouping by team would be good, but it's somewhat duplicated with "component" in our context.

Dave

Thanks for sharing that information @Paul Dickinson , it's very useful. I also appreciate the offer of a call, but we're not planning on iterating on views at the moment so it might be a bit premature but I'll keep a not of this and cycle back at the appropriate time!

Regards,

Dave

Welcome!

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

Quick Links

Find more posts tagged with

cloud

advanced-roadmaps