A practical introduction to the fundamentals of Jira Portfolio

Jul 23, 2018

A practical introduction to the fundamentals of Jira Portfolio

I never was a big fan of making product roadmaps. To create a product roadmap I would copy over issues to Excel, Google Docs or some other tool. The moment you finish your duplication effort, your roadmap is out of date. You need to update your roadmap, only to repeat it one day later.

Product roadmapping in external tools feels like watching Groundhog Day: you always end up repeating yourself.

So you begin to wonder — there must be a better way ?

Recently I started working at Bestseller E-commerce as a Product Owner for the Partner.com team. All seven development teams of the e-commerce department have their roadmap in Jira Portfolio. So when I started, I was introduced to Portfolio for the first time.

Portfolio promises to save you from wasting time copy & pasting over and over again. It makes Jira the source of truth for your roadmap. So if Jira changes, your roadmap changes as well. It is a plugin you can install with a few clicks in Jira. This made me really excited to start using it.

The first day of working with Portfolio, my excitement level dropped. Using Jira Portfolio is not self-explanatory. There are fundamental concepts you need to grasp to be able to use the tool. Portfolio has unexpected quirks. Prioritizing without understanding the quirks of Portfolio results in unexpected behavior.

I must have reworked my whole Portfolio around 3 times, until I figured what works best for me. I decided to write an article that combines theory and practice. I hope it will prevent others from sharing the same frustration. I will also provide clear do’s and don’ts when using Portfolio.

JIRA Portfolio fundamentals

So let’s start with the basics of Portfolio. In Portfolio you have the following hierarchy:

Initiatives > Epics > User stories

Initiative*: super-epic that groups epics which belong together. Spans many sprints.

*Caveat: this is not how we use initiatives at Bestseller. The definition used in this article is more universal and generic. This definition makes the article easier to follow and better applicable for other companies.

Epic: a chunk of work that does not fit in a single sprint. To plan epics in sprints you need to break them down in smaller chunks. Epics group these small chunks.

User story: a piece of work that fits in a single sprint and written from the perspective of an end-user. Belongs to an epic.

There is a parent-child relationship between initiatives, epics and user stories. An epic always belongs to one initiative and a user story always belongs to one epic. As visualized in this diagram:

By understanding and applying these basic concepts we can build our first simple roadmap.

Making a roadmap for a fashion company: J. LINDEBERG

Imagine the following hypothetical situation: you work at an e-commerce department of a fashion company called J. LINDEBERG. J. LINDEBERG has some clothes that are not moving as fast as anticipated. J. LINDEBERG wonders what they can do to make these clothes sell faster.

J. LINDEBERG decides to present strike-through prices to push the sales of certain clothes. They are willing to accept lower margins to move more inventory. Unfortunately strike-through prices are not yet supported, so development effort is necessary. Strike-through prices seem like a valuable feature that is worth the development effort.

The term ‘strike-through price’ may not ring a bell, but the chance you have never seen one before is close to zero. Here is an example of strike-through pricing of the BESTSELLER brand J. LINDEBERG:

So you think long and hard, and create the following initiative in Portfolio:

Awesome! We can start to build a roadmap from these humble beginnings. Before we do this, let’s first consider what teams we have at our disposal.

J. LINDEBERG has four development teams for potentially assigning work to:

ERP systems team (DATA). This team handles all master data related to product, stock and pricing.
E-commerce store-front team (BROWSE). This team handles all work related to the store-front before check-out: browsing and searching for products, filtering, creation of accounts, and more.
Check-out team (BUY). This team handles the shopping cart, payment and what happens after the check-out, such as displaying the order in the order history.
Financial reporting team (REPORT). This team handles all financial reporting.

It may seem like introducing strike-through pricing is easy, but it actually is a ton of work. We break down the initiative in epics for our four teams as follows:

Great! Now the big chunks of work that need to happen to introduce strike-through pricing are clear. All seven epics have been created. Each team needs to have refinement sessions to break down the work into User Stories that can be picked up.

All your teams work really hard and come back to you with estimated user stories for each epic. You enter the user stories for each team in Portfolio and assign them to the appropriate epic. This is the result for each team:

DATA epic work breakdown and estimates

BROWSE epic work breakdown and estimates

BUY epic work breakdown and estimates

REPORT epic work breakdown and estimates

Now we have the raw ingredients to think about the different releases we want to have. Going for a big bang release is not an option.

How many different releases do we want to have?

Releases allow you to track progress toward a concrete release across many teams. Before we can do this, we need to think about the different releases we want to have.

We decide on three different releases:

I. Strike-through pricing 1.0 (STP 1.0). The goal of this release is to support storing of strike-through prices in the ERP system and e-commerce platform. This means that the business can prepare to manually enter strike-through prices for many products. Strike-through prices will not yet be visible anywhere yet after the release is completed.

II. STP 1.1. The goal of this release is to make it possible to display strike-through prices in all locations where regular prices are present. We should also add support for exporting strike-through prices from the ERP system to e-commerce platform.

III. STP 1.2. This is the final release where we included financial reporting that is not necessary to go live. In the beginning very few products are affected and financial reports can be adjusted manually. Correct prices in order history is also something we can go live without.

How do do you prioritize the work related to strike-through prices in Portfolio?

The best way to prioritize in Portfolio is by using releases. Releases allow you to track progress toward a concrete release across multiple teams. They also allow you to set a priority for each release. A release with a higher priority gets planned before a release with lower priority. In Portfolio you give priority by setting the order of releases (see picture below).

We can only start working on strike-through pricing 1.1 after 1.0 has been completed. We need the strike-through pricing data-model to be finished before we can work on displaying the strike-through prices in the front-end. Strike-through pricing 1.2 can be worked on at the same time as Strike-through pricing 1.1 (start-start dependency).

In Portfolio you can indicate this by doing the following:

Set the start date for release strike-through pricing 1.0 as early as possible.
Set the start date for release strike-through pricing 1.1 as relative to previous release date. This means the start date is relative to the end-date of strike-through pricing 1.0.
Manually set the start date for release strike-through pricing 1.2 to be the same as the start date of strike-through pricing 1.1. Unfortunately, Jira Portfolio does not support ‘relative to previous release start date’.

When you do this, this results in the following timelines in Epic level, grouped by the team handling the work:

At the bottom you can see a clear timeline for each release. So you have clear release dates across different teams for when STP 1.0, 1.1 and 1.2 are expected to be finished. Pretty cool, huh?

There are more ways to prioritize than just by using releases

In Portfolio, there are actually four different levels that affect priority:

Release
Initiative
Epic
User story

The ordering of initiatives, epics, and stories, influences the planning order of work by Portfolio. All other things being equal, an item that is ranked higher will be planned before an item that is ranked lower. If you take a look at the ordering of our epics:

Within the same release, epics that are higher on this list, are picked up with a higher priority. If one or more releases have ‘start as soon as possible’, Portfolio tries to plan both simultaneously. The highest priority user story determines the priority of the epic. Does that sound confusing? Let me elaborate.

The priority as set at the lowest level (user story) affects the priority at the highest level (initiative). If we move the least important user story to the top of the list, then this bumps up the priority of the epic that belongs to it. So if we move the user story to ‘Adjust financial reports to handle strike-through pricing’ to the top, then the epic it belongs to with the same name moves up in priority.

By changing the priority of a single user story, our epic overview would look like this:

So ‘Adjust financial reports to support strike-through pricing’ now suddenly became the most important epic! The priority yet would still be very low, as work on release ‘STP 1.2’ only starts when work on release ‘STP 1.1’ starts. The end result would be that you see no difference in the planning, even though you would expect it based on the priority you see. In the end, the release priority trumps the initiative, epic or user story order.

Portfolio best practices

Portfolio helps to make the high-level of what you are working on transparent to stakeholders. To get Portfolio to plan work in the desired order, you need to understand the quirks of the tool. Armed with the understanding of how prioritization works in Portfolio, this leads to the following best practices:

Epics (and User Stories) should belong to just one release. If you break this convention, changing the order of an epic will affect multiple releases. This leads to planning behavior hard to control and understand.
Plan all epics in the same order as the releases they belong to. This makes the planning behavior predictable and controllable. If you change the priority of the releases, you should also change the priority of the epics.
Only adjust the ordering of epics and user stories if you want to prioritize work within the same epic and release. If user stories need to be picked up with a higher priority than the epic they belong to, consider moving it to a different epic and/or release without breaking the conventions explained above.