Some tips for using Advanced Roadmaps (as I leave the team)

[#1]

Hi all,

In the spirit of the Atlassian Community I thought that I'd write a short message to say that I'm going to be moving to a new team in Atlassian and will no longer be working on Advanced Roadmaps so you won't see me answering a lot of questions here any more - but I'm confident that the rest of the team will pick up where I leave off. I've personally found the community questions incredibly helpful to understand all the different ways in which people are using Advanced Roadmaps.

As I leave I thought it would be worth sharing a few of my top tips on how I use Advanced Roadmaps (as I've become heavily dependant upon it myself over the past few years)

Create views for each hierarchy level

We only currently use one additional hierarchy level (Initiative) at the moment but I have a few for each level (Initiative, Epic and Story) and have different fields, filters and time range for each. I spend the most time in the Story view which I use to plan our next few sprints but switch to the Epic view and Initiative view when I want to get a better idea of progress or need to do more high level planning. It's much fast to switch between views than to be modifying the various filters and view settings.

Create shared teams and use them in board filters

We have multiple teams working within the same project and each team has its own board (with a JQL filter that matches issues assigned to that team in the project).

Each team has it's own plan but we also have a large plan pulling in all the boards so we can more easily plan cross-team work and understand the dependencies (the dependencies report is your friend here).

Use sprint inferred dates

We plan all our work by assigning issues to sprints and allow the timeline to show the issues based on the start and end date inferred from the sprints. We never set dates on epics or initiative but allow dates to "roll-up" to them to give us a good understanding of when the work is expected to finish. However, I will often set the start date on an epic/initiative once it's actually started and the end date once it's actually finished so that as resolved issues drop out of the plan you still can see when it started - this information is then available in the issue details view for the epic initiative as well.

Use Relative Custom Timeline

I know that people have been asking for timeline scrolling for a long time (and it's coming!) but since we introduced relative custom timeline settings I've never needed to adjust my timeline. For example in my Story level view (see above) I want to see all of the current sprint and the next 6 sprints so I have a relative timeline set from 2 weeks ago to 3 months in the future. Every day when I refresh my plan it has moved along with me - I'm rarely interested in anything outside of this window of time so have never needed to scroll. My (unproven) hypothesis on this is that scrolling is more a requirement for consumers of a plan rather than the actual planners. 

Manage your rank

In my story level view I am always careful to ensure that the issue rank reflects the order of when work is planned (so that as you scroll down the plan the issues are scheduled to start further into the future). By keeping on top of this (and using the "Rank selected issues below" option in the meatball menu when you've selected another issue is a very fast way to do this). The benefit of having an organised plan like this is that it makes it very easy to know which issues to move between sprints when planning according to available team capacity.

Issue counting is a fast way to plan team capacity

I've always been a fan of story point estimation, but we switched to issue counting to reduce the cost of capacity planning and it was very successful. Working on the assumption that sprints always contain the same distribution of issue estimates you can effectively just measure velocity in the number of issues completed. Setting the estimate of every issue to be one allows you to set the velocity of the team to be the number of issues expected to be completed and this allows you to very quickly build up a roadmap without the cost of estimating a huge percentage of the backlog.

I'll be honest that my team weren't huge fans of this ("But it's not a 1 pointer!") but in practice it is a very efficient way to plan and no more inaccurate that story point estimation (providing that you plan your sprints with some insight into the work being planned).

Make sure everything has a parent

I always ensure that every story belongs to an epic and every epic belongs to an initiative. My goal is to ensure that all work "ladders up" to a high level objective to ensure that we know we're working on things that matter. Sometimes this means creating Epics that might live indefinitely (e.g. "Bugs") but you can also create time-boxed work (e.g "Bugs for Q1") to help you plan effectively. 

Happy to discuss any of those in more detail in the comments if nothing is clear, but hopefully this will be useful !

Thanks again to everyone who contributes to the Atlassian Community in the Advanced Roadmaps space (questioners and answerers - both are hugely valuable!)

[Curt Holley]

All the best @Dave I'll miss your AR wisdom.