Long time Jira user having a VERY hard time understanding and trying to use Advanced Roadmaps

[accum_bway]

Let me start by saying that I've been using Jira for years with both scrum and kanban projects for software development. I consider myself fairly competent in its base operation and I am now trying to bolster our long term planning by utilizing Portfolio which JUST turned into Advanced Roadmaps.

I must say that although there seems to be a lot of written documentation I am not finding it very helpful. I've been spinning my wheels for days trying to understand how things should work and what needs to be done to get a plan that looks anything like the examples. Are there ANY other resources or tutorials out there other than the "documentation?" I've found a couple of videos, some only a couple of months old, but they all seem to use a UI that no longer exists.

I've got a ton of specific questions, but I'll start with just one for now. I am attempting to follow the guide for including an Initiative issue type found here: 

https://confluence.atlassian.com/advancedroadmapscloud/configuring-hierarchy-levels-998650959.html

I have created the issue type and I mapped the issue type in roadmaps. I used the "Alternative instructions to create a new project just for holding the Initiatives. 

Alternatively, you can consider creating a dedicated project, and then create all the initiatives you need in that project. You can then link the epics across all your projects to the Initiatives in that dedicated project for initiatives.

Maybe I'm linking my epics improperly, nothing explicitly says HOW to link the Epics, but I end up with this view of my plan when choosing the initiative scope.

You might also notice that all of the fields are blank. Not sure what else I need to, but this does not match the example. 

I think I like the idea of Advanced Roadmaps, but it is NOT intuitive and thus far the documentation has proven to be very frustrating.

Any guidance on how to try and understand this functionality would be greatly appreciated!

[Pete Morris]

Hi @accum_bway - I'm a Product Manager in the Advanced Roadmaps team. I'm sorry you're having a hard time with our new interface. 

It looks as though your initiatives are showing up in the plan correctly, but the desired child epics are not yet linked to the parent, is that right?

You can link epics (or any other issue, for that matter) to a new parent in a variety of ways.

1. You can drag and drop the issue underneath its new parent;
2. You can expose the "Parent" field in the plan by clicking on the "..." and checking the box next to "Parent". Once visible on the plan you can change the parent by clicking on the dropdown in the field;
3. You can select a number of issues using the checkbox on the far left of the screen, click on "Bulk actions", select "Parent", and then select the new Parent issue.

All of the above must then be committed back to Jira Software by clicking the "Review changes" button in the top right of the screen.

Finally, you can also expose the "Parent Link" field on your issue screen scheme in order to update the Epic's parent in the issue view (outside of your plan).

Once you're comfortable with that, you can schedule any issue by clicking on the timeline or by modifying the start/due dates directly. If you use different date fields on your issues then you can update this in your plan's settings.

We have an upcoming webinar you may be interested in here: https://www.atlassian.com/webinars/software/roadmaps-in-jira-software

I hope that helps. Please let me know if you need anything else.

[accum_bway]

Pete,

Thanks for the reply. I did finally figure out the "Parent Link
 was a completely different field than using the Issue Links to relate the Initiative. It makes perfect sense, once I already know how it works, but it is not intuitive to go looking for a hidden "Parent Link" field. It would really be nice if things like that were included in the directions.

I have another question about scheduling work. From what I saw of the previous version it looked like Jira would tackle the scheduling for me. It would fill in estimates for issues without them and then provide a plan with anticipated dates based on anticipated velocity. It sounds like now I am required to schedule everything myself? Is there a still a way to view a plan that fills in estimates and predicts what the schedule would be based on velocity? I really don't want to have to start planning EVERYTHING out to get dates on the plan, that feels very waterfall and anti-agile to me.

I have also registered for that webinar, but I'm very concerned that it is going to be a giant sales pitch with very little in depth discussion of the concepts of how it works. 

Thanks again!

Ben

[accum_bway]

I had one more question. Is it possible to schedule some time to actually talk to someone about our setup and how we should be utilizing Advanced Roadmaps?

[Pete Morris]

Hi @accum_bway - we don't normally provide guided setups with the product team, but we'd love to learn more about what you and your team are trying to achieve as part of a customer interview where we can perhaps offer a few tips towards the end. Let me know if you're interested at pmorris@atlassian.com

[Freddy]

I too have found the transition quite difficult with documentation that is a bit cumbersome and missing a better walk-through or set-up guide. The newest 5 tips documentation was more helpful but it was just a teaser. 

Customer success stories, samples of how others have implemented are very helpful ways for a new user to imagine how to set-up their own environment. If your Jira isn't organized in the way Roadmaps works, then you have to go back and re-organize Jira. 

Other suggestions:

1. When a plan is made up of Cross-project releases, the creation of Releases in each product was much simpler in Portfolio. It feels like the scheduling dependency on Releases is quite cumbersome since in reality, if we have continual releases but work in sprints, we should be able to schedule based on sprints, not releases. The team settings are defined by Sprint information - how long are your sprints, what's the team velocity per sprint? If this is the case, shouldn't the timelines and schedule be based on Sprints and not 'Fix Versions' (which is not a very friendly concept in Jira since you must have a fix version for every project, even if one team works on multiple projects). 
2. Another challenge is when working on a scrum team, the concept of work is built based on sprints but unless you create all the future sprints in Jira, there doesn't seem to be a concept of "Later" planning in Advanced Roadmaps.
3. If we had estimated every story in my backlog (would take weeks to do and we would need fully fleshed out tickets - sounds like waterfall to me) and wanted to see how long it would take a build with the current resources on the team, it seems like I would need to create many sprints and estimate every story first so the planning can fill them out in front.
4. Another suggestion for the product is to allow for a t-shirt size (est. story points) or some other gauge that is not related to the scrum team defined Story Points field to allow us to start planning into the future.  

Overall, there were big improvements with Advanced Roadmaps and the product looks to be much more user ready but it feels like phase I was released, and the product is not completely usable until phase III or IV gets released. 

Thanks for considering my challenges. 

[Pete Morris]

Hi @Freddy - thanks for your feedback, we really appreciate it.

You are currently able to work without releases in Advanced Roadmaps and you shouldn't have to create all future sprints either. We project out future sprints that haven't yet been created in Jira based on your configured sprint cadence and the dates of your current sprints. You can see these in your timeline by grouping by either team or sprint and enabling "Show capacity on timeline" under view settings - you also need to make sure you've got the relevant boards as issue sources and you've associated those boards with teams.

You'll end up with something like this (you can see that the last three sprints on the timeline are not "real" sprints, but rather projected ones):

As for forecasting work, you could consider assigning a "blended" (average) story point value to otherwise un-estimated issues (via bulk updates or using Jira's automation to assign story points on issue creation) and using the auto-scheduler to see how long this would take to complete with current sprint velocity. Do you have another method of forecasting without story points that you'd like us to consider? I believe t-shirt sizing would still require some kind of conversion to story points in order to factor into sprint capacity.

[Freddy]

@Pete Morris  Thanks for this. The configuration recommendations made a big difference. "You can see these in your timeline by grouping by either team or sprint and enabling "Show capacity on timeline" under view settings"

For Forecasting:

I will look into setting up automation for Story Points but I think the challenge will still remain where it is hard to know the difference between what is est. story points (PM defined), vs what is scrum team defined story points, and why I suggested another field getting used for auto-scheduling. What I envision is there is a configuration setting to allow us to choose field A vs field B for auto-scheduling. 

Field A = estimated story points (PM defined)

Field B = scrum team assigned story point (scrum team defined)

As a product manager, we could add an est story point to use for auto-scheduler then when the scrum team updates "assigned story point" we could have an automation rule to replace the estimated story point with the new real one. This could help us plan (rough estimate) and then improve planning accuracy as the scrum team revises the "story point" field. Just a thought to consider and maybe you have a better idea. 

I can certainly revise our process, based on issue status, to know which tickets are accurate story points and which are estimated story points. 

Thanks again for your reply and guided information. Very helpful.