Rule Your Roadmap – No Matter How Much It Moves

Here’s Atlassian’s video of my talk at their 2011 International Summit where I describe how v1.0 of how to capture your roadmap data in JIRA and the kind of collaboration required to keep that data sufficiently accurate to support project and resource trade-off decisions. (We’ve come a long way since then and are still kicking it!)

I’m really interested to know if this is transferable and I’d love to help people try.

20 thoughts on “Rule Your Roadmap – No Matter How Much It Moves

  1. I’m amazed to find this video. It is super innovative and helpful. Is there a way to use this method without confluence? (I don’t have a confluence license at work).

    Happy New Year 2015!!
    Jack

    • Hey Jack, In the end what’s critical is to have 1) a single source of truth for dates and status that’s regularly updated by the delivery teams themselves and 2) a “change log” that captures the teams rationale for changing what’s in the source of truth.

      This means you could use JIRA dashboards directly for teams to review and update and a separate place to capture their notes on what’s changed and why…and any associated action items. We considered using the ‘comments’ field in JIRA directly to capture the reason a date or status changed but there’s a need for a consolidated view and there are also the day-to-day action items that need tracking so a separate place for notes works best. Does that help?

      • Yes, It did help and I totally agree with you. Btw, here is what I did, I wrote a custom query and used ‘Filter Results’ gadget to show all of the In-progress and upcoming projects onto the dashboard. So, there’s a Parent task (Project) and its sub-tasks (features to be built, that are assigned to the individual resources, with estimates), the roadmap looks good but how do we incorporate these projects into our Sprints? How PMO projects and daily scrum/ bi-weekly Sprint work gets along? Do we create stories under these Projects and assign those stories to one or more resources or we keep PMO Roadmap separate from our bi-weekly Sprints?
        Thanks,
        Jack

      • I went through your video once again and I see that you specifically mentioned how Executives, Managers and Developers “collaborate” to keep the Projects in Sync using JIRA, any change made at one place is reflected throughout our single source of truth, helps avoid confusion and effort duplication.

        So, here is my question – Does everything (all the epics, stories) for a specific project (let us say – JIRAsaurus Project in JIRA) lives under PMO project or you guys keep separate dashboards i.e. One for the PMO project and the other for JIRAsaurus project?
        If the latter is the case, how do we link JIRAsaurus project related epics, stories to the PMO project?

      • Hey Jack. Let me use the term jiraproject to indicate the individual data spaces inside JIRA that have their own unique indexes which Atlassian calls a ‘project’. Contrast this with the regular term ‘project’ I’ll use to mean the popular notion of a block of work that a team(s) deliver.

        We have a jiraproject called ‘PMO’. Every ticket in this jiraproject has a unique ID of ‘PMO-####…’. This PMO jiraproject has three issuetypes: project, subproject and resource; and nothing else. These custom issuetypes have custom fields and workflows specific to our project life-cycle. This PMO jiraproject is strictly for managing and collaborating across the +20 roadmaps we have at Shutterfly (Tinyprints.com, in the video, was bought by Shutterfly.com, my current gig.)

        Here’s the clarity you’re after. Counter to Atlassian’s approach, we do not create a new jiraproject for every software project we deliver. With over 400 projects per year across 36 scrum teams it would get too confusing. Rather, each scrum team has its own jiraproject based on its team name to track the many software projects they deliver over the years. For example, we have a ‘Cards & Stationery’ scrum team that calls their jiraproject ‘CARDS’. So, all of their stories, tasks, bugs, have the id CARDS-#####. When spinning up a new project, the team will choose a naming convention to put in the epic field for all of the stories and tasks for that project. For example, if the CARDS team is building a new project called ‘Home Decor’ (HD) and the project is logically broken into the pieces of Landing Page (LP), Category Page (CP), Product Page (PP), and Checkout (CO) the team may associate these stories using the epics of HD_LP, HD_CP, HD_PP and HD_CO. Its all greek to the rest of us but they know what it means which is all that matters. Their scrum monster has a filter looking for all of these epics in the CARDS jiraproject. The scrum monster might call this filter “Cards Home Decor”. The url for this filter can be shared with anyone or anything that needs to know everything being built for the Home Decor project. For example, the team feeds the ‘Cards Home Decor’ filter into a burndown gadget to show when the project will be done. (Again, sprint burndowns can be deceptive. Only project level burndowns predict completion dates.) So, the stories, tasks and bugs for the project exist inside the team’s jiraproject as captured by the teams filter called ‘Cards Home Decor’ And, lets say the team knows the Home Decor project will occupy 5 people over 6 sprints and go out in a release scheduled for August 15th.

        Next, to radiate this information out to the enterprise, the scrum monster creates a new ticket in the PMO jiraproject called “Home Decor” in which they capture gobs of interesting details about the project including: the url to the ‘Cards Home Decor’ filter, which roadmap team is delivering it, who are the 5 people on it, the sprints they are occupied, launch date of August 15th, the fact its ‘green’ for August 15th, a couple of sentences describing why the team thinks its on track and lots of details for other teams like marketing, manufacturing, procurement, IOPs, release engineering, architecture, finance, etc.

        This one single PMO ticket representing one project then comingles with the 400+ others entered by the other 20 scrum monsters who support our +34 scrum teams and 17 roadmaps.

        Other groups in the org filter on these +400 project tracking tickets to see just those they are interested in. For example, the team that has to buy the card stock wants to know when any new greeting cards are being put on the site. Data Warehouse is keeping track of any projects what will alter the data they capture and report. Finance is filtering for projects that are capitalizable.

        When a team sets the status of their project to ‘yellow’ or ‘red’, indicating the date might/will slip, the interested teams know almost instantly and will reach out to learn more and adjust their own schedules accordingly. Also, the stakeholders can get involved to cut scope or add resources to keep the date, if it matters.

        It really is a massive radiator.

  2. I have been looking at ways to avoid double-entry of information. Somehow, the information from all projects (and, in our case, operational work) has to be aggregated in one place. Here is what I have found so far:

    https://answers.atlassian.com/questions/89790/what-is-the-best-course-of-action-when-we-have-a-project-that-is-divided-into-3-4-others?page=1

    You can configure which projects in each application are linked together by going to the main project overview page (Administration > General tab, then select the project) and changing the “JIRA Project”, “Confluence Space”, etc. sections. This way you can set up each separate JIRA project to all be linked with the same Confluence space and so on.
    By Nick Mason [Atlassian] (871 karma) Sep 26 ’12 at 09:23 PM

    Is it possible to aggregate the information of all the projects using this method? Can I, for instance, find out who is assigned to multiple projects, perhaps on a dashboard?
    By Bob Stenson (1 karma) Jan 10 at 09:53 PM

    That’s as simple as creating your required filters (which can spread across projects) and getting the required gadgets added to the Dashaboard

    and also:

    https://answers.atlassian.com/questions/60067/how-can-i-create-a-child-project-of-an-existing-project-in-jira?page=1

    I have been looking for a method to manage the portfolio of all the projects plus the operational work of the department. Everyone is using JIRA, and this video about JIRA looked very promising: https://tinypmo.wordpress.com/2011/05/25/rule-your-roadmap-no-matter-how-much-it-moves/#comment-31. The problem with this method is that tasks and sub tasks are already being used–the method aggregates that needed information by making each task represent a project and each sub task represent a task. That would eliminate the possibility of having sub tasks since you cannot have a sub task of a sub task. I’m thinking that the solution presented may work: one project for the department, a component for each of the projects and also for each section of operational work, and then we would use tasks and sub tasks in the normal way. Do you think this would work, or is there a better way to do this?

    JIRA only have two levels of issue hierarchy. To achieve mult level management at a issue level, you can use the below plugins

    https://marketplace.atlassian.com/plugins/com.docminer.jira.issue-links

    https://marketplace.atlassian.com/plugins/com.almworks.jira.structure

    As I look at this, I wonder if there is an easier way. Any thoughts?

    • Hey Bob, There is an easier way. The confusion here is I keep my roadmap entirely separate from sprint work – it’s in a separate JIRA project called PMO where projects are captured as tasks and the people per sprint on those projects are captured as sub-tasks. The Scrum Masters bulk upload these “resource” tickets for everyone at the beginning of the year assigned to a placeholder project (“Remaining Capacity”). If Joe is assigned to Project A for 3 sprints the SM then drags those 3 tickets for Joe from the placeholder project to Project A as the new parent. In this way we ensure we don’t later double book Joe, everyone knows the remaining capacity for Joes team, and if we need Joe for something else we know it will impact “Project A”. We also rollup all the projects and resources across the enterprise.

      Joe does all his work, tasks and subtasks, somewhere else.

  3. Hello David, Thank you for a great concept. I have been assigned the task of creating a portfolio management system–we use JIRA for projects and for operational work in the same department. I saw your video on youtube.com and have been working on possible ways to integrate this into our culture at the university. The team is already using the sub-tasks as sub-tasks, so I will get resistance trying to get everyone to change the way they have been working. JIRA has no subprojects. I found this documentation on components. https://answers.atlassian.com/questions/100605/sub-projects-of-an-over-all-project. Perhaps it may be possible to create a component for each project, which would allow the team to still have the functionality of the sub-tasks. By the way, I also ran into the problem that they have changed Confluence so that wiki markup is no longer accessible–at least not in our environment. I’ll post any progress here and I’ll be watching this blog for any solutions that others may offer.

    • Hey Bob, Good luck with this and I’m happy to answer your questions. My roadmap/resource map lives in its own separate JIRA project, “PMO”, so the tasks, subtasks, custom fields and workflows don’t pollute anyone else’s workspace.

  4. I found a solution that I can live with.

    I use the external Jira gadget “filter results”, that finds a list of Jira issues based on a saved filter. Within that you can choose what fields to display, and here the wiki-markup custom fields are rendered as the should.

    You need to specify a saved filter for every project though, but we do keep that anyway so for us that’s not a restriction.

  5. This is bad. Really bad. Sorry I dont have a solution for you and thanks for the warning. We’re still on v3.x and may be there for awhile, unless our IT group wants to upgrade to fix the security hole. Nuts!

  6. Hi David,

    I loved your talk, and I’m in the process of implementing your way of linking Jira and Confluence to keep the roadmap updated.

    I have added the PMO project and I have a dashboard in Jira that shows the roadmap, including the status field for each epic in the PMO. That single dashboard made wonders for the visibility in the company.

    My next goal is to actually link Jira to confluence via the status field in Jira. However, I noticed that the jiraissues macro no longer renders wiki-markups from custom fields in Jira. (Confluence 4.1.3)

    This makes your integration less valuable since one would like to get the links clickable and the colors rendered in the status field. Now what you get is the crude XML (not very nice).

    Unfortunately, the confluence team is not going to fix this because generating html from other systems is a security issue. (See https://jira.atlassian.com/browse/CONF-23209?focusedCommentId=287689&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-287689)

    Since you have implemented this integration yourself I thought that you might know of some workaround so that you get the links rendered in confluence.

    Best regards,

    Mikael Hammar
    Product Manager
    Apptus Technologies AB

    • Im glad ypu liked the talk and found it useful. Are you sure Confluence 4.x doesn’t support wiki mark-up?, or just not html. The bug filed is specific to HTML. Please lmk. I could be in big trouble.

      • As I understand it, the wiki markup in Jira is translated into html and then sent to confluence. Next, confluence imports that and renders it (unfortunately no longer the html). If you look at the resulting XML you see that the wiki markup is translated. I followed all your instructions carefully. I kind of hoped that I’ve missed something but I cannot see what.

      • Oh oh. If you put this string into a jira wiki-renderer field (not a regular text field) and it displays in Confluence as raw HTML then we’ve all got big problems. I can’t upgrade confluence…
        *{color:red}RED{color}*

      • Yes, that’s the case. The description field and all other “standard” fields render OK, but custom fields are considered dangerous. I’ve been at it all day (I’m in Europe) and still can’t find any solution.

      • Our release engineer is hopeful he could fix/subvert this. But, we’re not on v4x yet so not sure when he’d get to working on it. Please stay in touch.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s