I’ve been excited about the new 2.0 version of Portfolio for Jira ever since I learned about the objectives of the release at Atlassian Summit. Last week I discovered that I’ve been using it for a few months now through the Live Plans beta.
It’s actually really easy to activate the Live Plans lab release… though it’s so easy that some people are missing it. Here’s a gif of the process:
activate Labs for Portfolio Live Plans
It’s literally just adding permissions to the labs features. If you’re using Jira server, updating the V1 version of the Portfolio for Jira add-on gives you the latest lab features. If you’re on cloud it’s already updated for you.
The word from the Portfolio for Jira team is that when V2 is released it will not convert V1 plans to use V2 features. I’m kind of on the fence about this, but normally I would be really upset by such a decision.

Why I don’t expect the ability to convert my Version 1.0 plan to a Version 2.0 plan is important

In short I have always agreed with this statement:
In preparing for battle I have always found that plans are useless, but planning is indispensable.
– Dwight D. Eisenhower

I can get to planning faster

More specifically, the new version dramatically improves the speed with which I can model all the activities expressed in my Jira projects so that I can get to the hard work of doing the planning activity. Furthermore, it makes it far less painful for me to push those plans into Jira projects after I have the plans figured out.
Put another way: Though I am not pleased about losing the work I put into creating my V1.0 plans, I am far more pleased that I will no longer have to spend as much time doing that work on my new plans.

I can push the plans back into Jira project without getting confused

I always needed to push my plans into Jira projects, but I never felt confident doing it. I have a well worn Confluence page that summarizes the errors I would encounter and how to fix them so I could complete the process of publishing my plans into Jira. While I could successfully complete the publishing process, I never felt 100% confident at the end of the process. I’m a lot more interested in getting people to start executing against the plan than I am in looking at the plan in Portfolio for Jira. The new ‘commit’ to Jira approach is way, way easier to use.

I would rather generate a plan and deploy it each time I need one

I prefer the ability to spin up a plan quickly as I’ve never been happy with roadmaps that don’t have any context. My roadmaps are more specific to each product. This is a personal preference that puts more of an emphasis on modeling the resource availability and using Jira for the global view of resource commitments.

There are three ways people use Portfolio

  • The global view of all ‘planned work’ is in one definitive Portfolio for Jira Plan. This is the way most teams start with the tool as they really want the reporting to relate to the long-term plan.
  • Plans are created, consensus is reached, plans are pushed into Jira and the plans are only used as references. Then the resource assumptions are updated over time so the reporting still works. In this scenario the team likes using a small collection of portfolio plans rather than one definitive plan.
  • As a pure ‘what if’ planning tool, Portfolio for Jira actually works really well. I’ve seen teams that don’t ever push the plans into Jira issues and don’t seem to mind that they are not getting any reporting back, as they are quite happy updating status directly in the plan.

What’s not in the Labs release (as of 5/11/2016)

At the time of this writing the following V1.0 features are not yet present in the new version:

  • Modeling different long term phases of a production lifecycle (stages)
  • Associating and allocating the required skills for those different phases
  • Attributing skills to team members
  • Creating and managing dependencies in your Portfolio for Jira plan
  • Increasing the number of issues you can import into Portfolio for Jira