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!
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.
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.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.