Ever since I joined Atlassian as a product manager for Portfolio for Jira, there is one thing that keeps blowing my mind: the quantity and quality of feedback we’re receiving from you, our users. It’s humbling to see how much effort you put into providing us with great ideas, detailed descriptions of challenges you are facing, and positive feedback. I love passing your feedback on to the dev team (yes, even the critiques) – often times, it makes someone’s day!
One important feedback channel is jira.atlassian.com (or JAC, as we call it internally). It’s the place to suggest improvements and up-vote other users’ suggestions. Over the past year, one obvious theme emerged: seamless integration. Our users need to keep their sprints, backlog rankings, epic-story relationships – in other words, everything they do in Jira Software – in sync with their long-term plans in Portfolio for Jira.
Recognizing a theme is one thing. Actually addressing it is a different story – integration is a tough challenge. Doing it right required us to take a big step back and rethink how a portfolio tool should ideally interact with Jira Software:
- The portfolio tool always needs to be up to date for reporting purposes.
- For planning, the portfolio tool needs to reflect teams’ current status, but also provide the flexibility to try what-if scenarios before actually committing to a plan and putting it to action.
Solving this challenge turned out to be a mammoth effort, but we’re now finally getting on top of it with Portfolio live plans, currently available as a labs feature. Let’s take a closer look at some of the top-voted suggestion tickets and how they are addressed by live plans. I’ll include links to each of the original enhancement requests so you can dig in for more details.
1: Keep sprints in sync with agile boards (JPO-10)
JPO-10 suggests that sprints planned on agile boards should automatically be reflected in Portfolio. After all, teams do their sprint planning on the board, whilst product and program managers will do long-term planning in Portfolio.
This now happens with Portfolio live plans. When creating a new live plan, you can connect it directly to one or more boards as data sources, and any sprints on these boards will directly show up in Portfolio as you calculate the schedule.
2: Keep priority rank in sync between boards and Portfolio plans (JPO-13)
JPO-13 is all about priority ranking: when prioritizing issues on the board, reflect this priority order in Portfolio, and vice versa.
In order to make this integration seamless, we actually had to go back and extend the agile boards themselves. We also introduced a flat story list in Portfolio so we can allow prioritization across epics (this actually addresses a separate suggestion: JPO-294). With that foundation, priority changes made on the board now automatically reflect in live plans. Priority rank changes made in Portfolio can easily be committed back to the board when you’re happy with the resulting schedule, but whilst you are playing through a what-if planning scenario shuffling priorities, you don’t mess up your teams’ boards.
3: Use issue links as dependencies (JPO-25)
JPO-25 suggests that existing links between Jira issues should be considered as dependencies in a Portfolio plan. Given that often times these issue links are already set when starting out with planning, this makes total sense (vs. having to re-model these dependencies inside Portfolio).
When designing a solution for this, we first gathered more feedback around the usage of issue links, and we noticed that actually not all issue link types are scheduling dependencies. For example, there are issue link type like “duplicates”, or “relates to”. If those link types are set, it does not mean one issue has to be scheduled before the other. So the approach we decided on is to allow you to choose which issue link types shall be treated as dependencies in Portfolio live plans, which is configured in the Portfolio administration (“blocks/is blocked by” is set per default). Once these are set up, those issue links will be accounted for in scheduling automatically.
4: Fully integrate sub-tasks into Portfolio (JPO-325)
JPO-325 is an interesting one: when we initially started out with Portfolio, we didn’t give sub-tasks all the love they deserved. After all, we wanted to focus on higher-level planning first. However, Portfolio’s automated scheduling makes perfect sense for both detailed short-term planning, and also high-level long-term planning. In fact, most plans have high granularity in the short term, let’s say the coming 2-4 weeks for which the work is already broken down in detail, and become more coarse-grained the longer they point into the future.
In live plans, sub-tasks finally get a place in the sun, too: an explicit level of hierarchy underneath the story level with proper aggregation of estimates and progress, and an easy way to directly create them in Portfolio.
5: Keep epic-story relationships up to date (JPO-276, JPO-284)
If you watched the screencasts above, you have a good idea about the new integration model, so I’ll keep this short. JPO-276 and JPO-284 suggest to keep changes of epic-story relations in sync. For example, when a story is moved to a different epic on the board, have that reflect in Portfolio, and vice versa.
This now happens in live plans. When making the change in Portfolio, you’ll again have an “uncommitted change” first, and when you’re ready you can commit it so your Jira issues and boards are updated.
6: Allow sharing of teams across plans (JPO-55)
Finally, a suggestion that is not about sync – yay! 😉 JPO-55 revolves around having a shared, global definition of a team, so this team can be referenced within multiple Portfolio plans. There are lots of aspects to this, but the most essential first step to be taken is actually suggested straight in the ticket:
I think the solution is to move the "people" feature out of the plan and into a bigger object (...)
Right on. Portfolio’s live plans introduce a concept of “shared team management”, allowing you to define a team once, and reference it in multiple Portfolio plans. For example, there could be a very specialized data science team in your organization that contributes to multiple departments and products. In this case, you define the data science team once in shared team management, and then each department references it inside their plan.
For the moment, this mainly improves maintainability. But it opens the door to fully implement some of the other suggestions and comments on this ticket. Visibility when a team is overbooked by multiple divisions requiring its contribution, or reserving time of a team for a particular plan, to name a couple.
7: Automatically assign issues to the right team (JPO-73)
The original suggestion JPO-73 is actually about being able to select a team upon issue import. With the new integration model, it is actually not needed anymore to regularly import new issues – they’ll be loaded dynamically based on the data sources your choose. However, one challenge remains: how can we directly schedule those new issues for the right teams (or at least, make a sensible initial suggestion)?
The solution approach for this in live plans is that a team can be associated with an issue source. A board, perhaps. If the team is associated with its board, then all issues coming from that board will be automatically pre-assigned to that team.
8: Sync all versions and their dates to releases in Portfolio (JPO-156, JPO-42, JPO-416)
Next to issues, the second integration hotspot is releases (the “fix versions” in your Jira projects). There are a bunch of sync-related suggestions, including JPO-156, JPO-42, and JPO-416. Again, we had to take a step back and look at the bigger picture of releases in Portfolio and how they should relate to versions in Jira.
In particular, versions are specific to a project. Portfolio aims to help with both planning individual projects, but also across projects. As a result, live plans offer the following model for releases:
- You can choose which existing versions you want to include into your Portfolio plan
- New versions created in Jira automatically show up in Portfolio as releases
- Releases in Portfolio are grouped by Jira projects automatically
- There is an explicit concept of cross-project releases in order to coordinate a joint release across multiple projects
Here’s a quick overview:
9: Use issue assignees for scheduling (JPO-161, JPO-403)
Up next: issue assignees and scheduling (JPO-161, JPO-403). This is a double-edged sword. Sometimes, the issue assignee is the one actually doing the work. This is usually the case for sub-tasks. In other cases, the issue assignee is the owner or overall responsible person for that work item, but there will be multiple team members actually doing the work. This is typically the case of higher-level items like epics or initiatives.
In this model, stories sit somewhere in-between. In some teams, the story assignee is the only person working on the story. In other teams, stories get broken down into sub-tasks which are then assigned to the individual people working on them. Tricky.
So in the latest iteration of live plans, the issue assignee in Jira will also be the person that gets the work scheduled in Portfolio, at the hierarchy level you choose. By default, this happens just for sub-tasks. But you can also have stories auto-scheduled for the issue assignee too.
10: Automatically consider work items completed when they are resolved in Jira (JPO-369)
This sounds easy, right? If an issue gets closed in Jira, just tick it off the list in Portfolio (JPO-369).
Well, not that easy after all. If Portfolio excludes completed items, but the plan keeps the same static start date, things would get massively out of order. For Portfolio to automatically consider when things are completed, it also needs to constantly keep the start date of the plan moving forward to schedule from now on, whatever is remaining.
Essentially, this is why live plans are… well, live. They start from the current sprint onwards, and automatically consider what is still open and needs to be scheduled as future work.
Get started with live plans
Live plans aren’t feature complete yet. We still need to bring back several capabilities of standard plans onto the new integration model. If you’re missing an important feature, please keep watching for updates. We’re working hard to bring all major current capabilities back into live plans.
If all this sounds great, the good news is that you can start using live plans today. They are available for both Cloud and Server as a labs feature (compatible with Jira 6.3 or higher .. yep, we’ve considered that, too). Start from here if you need more info.
You can also join our Portfolio Pioneers LinkedIn group to get updates and discuss with fellow Portfolians. I’m looking forward to your (continued) feedback! 🙂
Live plans are just the beginning. Take a tour of Portfolio for Jira and see all the ways it helps teams of teams tackle long-term planning.
Did you find this post helpful? Share it on your social network of choice so your fellow agile portfolio managers can get hip to live plans!