How does JIRA backlog order and portfolio rank influence each other?

[Stephan Dreyer]

First I wanted to say that Portfolio for JIRA is a great add on that enables us to finally create realistic release plans and manage capacities with JIRA.

We have a Kanban process for a product that is currently in MVP development stage. There are two different orders, the one of the JIRA backlog itself and the rank of portfolio.

While working with Portfolio, many questions came up:

1. When reordering stories in the JIRA backlog, how does it influence the ranking in Portfolio?
2. On the hand, when reordering stories in Portfolio, does it influence the JIRA backlog?
3. We faced an effect that a developer dragged a story to another board column which results in a status change. The story ranking in the Portfolio backlog changed. How is that possible?
4. Is there a way to prevent Portfolio ranking from being changed, e.g. lock rank?
5. How do the epic rank and the story rank influence each other? Generally we want to keep stories of epics together.
6. Does the epic rank influence the scheduling of stories?
7. What is the recommended way of ordering items? JIRA backlog, Portfolio story backlog or epic backlog?
8. Is it a good idea to influence the scheduling order by adding "X blocks Y" dependencies?
9. Is there a way to keep stories in progress always at the top of the ranking?

Thanks in forward.

[Thomas · Accepted solution]

2019/10/10 Edit: The ranking behaviour described here relates to Portfolio Live Plans (Portfolio 2.x) and Portfolio Cloud. The Portfolio improved experience introduced in Portfolio 3.X behaves differently. (See https://confluence.atlassian.com/jiraportfolioserver/prioritizing-issues-967895243.html)

Hi @Stephan Dreyer,

1. The story ranking in your backlog and in your Portfolio plan is the same
2. Re-ordering stories in Portfolio will have the same effect as re-ordering in your backlog (But the changes need to be committed from Portfolio to impact Jira)
3. It is possible when dragging an issue from one column to the other you also applied a rank change (i.e This card was put above that other card...) or that the status made it no longer appear in the Plan which could have an impact on its parent rank in Portfolio (See 5.)
4. No, this is using the same rank as Jira / Backlog and will always be in sync (+ uncommitted changes)
5. If an issue has children (e.g. Epic with some stories) then the rank of the parent becomes the rank of its highest-ranked child. The reason for that is that we want to make the parent rank represent what will be done first, if the top story of an epic is ranked last this epic will be scheduled last so it should appear last in the ranking. Re-ranking a parent will re-rank both the parent itself and all its children.
6. No (see 5.)
7. The story needs to be ranked properly and this can happen in either the Agile board or you Portfolio Plan. Re-ranking your epics (or above) issues in Portfolio has the advantage or re-ranking all the children issues for you which can be more convenient depending on your use case.
8. Using dependency is good if it is realistic. If those issues could really be started independently given infinite resources (if only!) then working on the ranking might be a better solution.
9. No (see 1.), but if the ranking represents the order used to work on items then this should already "mostly" match. The latest version of Portfolio for Jira Server would allow you to filter by status and status categories which could be convenient to have a quick idea of what is in progress.

Thanks for the questions, I'm sure this will be useful to many other community members! Please share your feedback on the ranking behaviour and what you would like to see happen differently.

Cheers,

Thomas

[Jens Heiligenstadt]

Interesting information

[Stephan Dreyer]

Hi @Thomas,

thanks for your comprehensive answer. I think it's hard to understand for many people (and me too) whether the Portfolio plan is a target plan or does reflect what's actually going on in a kind a status report. The difference between both is:

• Target plan: At some point during whole project planning, a product owner has to commit to the plan and stick with it. Once the long term plan is final, the order (at least of epics) should not change. Major changes in scheduling of stories / epics are hard to communicate and should be prevented.
• Status report: Sometimes unexpected things happen and stories are started sooner than scheduled. Portfolio does not reflect that without manual adjustments. It is hard to communicate to stakeholders that a story developers are actually working on is still scheduled somewhere in the future. For the short term view, Portfolio should adapt to such changes.

As a result of your answer, my feature requests / proposals to the Portfolio development team are:

1. Introduce a button to freeze the schedule. This would submit the scheduled start / end dates to the target start / end dates of epics or stories. I think this is very easy to accomplish and helps a lot for long term planning.
2. Allow to mark a plan as target plan. Technically this could be a special scenario. Future schedule calculations should respect the target plan and keep stories/epics in their order and nearly at their start/end dates as much as possible. Deviations between the target plan and the current situation would become visible.
3. Enhance the scheduling algorithm to respect story status. The first scheduling round would schedule all stories with status "In Progress" because there still has to be an order due to limited capacity. The second scheduling round would schedule all other stories after the stories in progress.

Best regards,

Stephan

[Nathan Green]

@Thomas 

How does ranking work on a portfolio plan that takes its inputs from multiple boards?
Suppose I have 2 boards, A and B.

Board A contains:
Epic A1 with storys A1,A2,A3
Epic A2 with stories A4,A5,A6

Board B contains
Epic B1 with stories B1,B2,B3
Epic B2 with stories B4,B5,B6

Epic B1 belongs to deliverable D1
Epic A1 belongs to deliverable D2
Epic A2 and B2 belongs to deliverable D3

Deliverable priority is D1 then D2 followed by D3.

I want portfolio board to show the following hierarchy.

D1
Epic B1
D2
Epic A1
D3
Epic A2
Epic B2

I drag the deliverables in to the order I want them, but will often find they re-order, presumably on off the back of someone changing story ranking on their individual board.

[Thomas]

Hi @Nathan Green,

As mentioned in my previous comment (point 5.) in Portfolio the rank of a parent item (in this case your deliverables) is defined by its highest child rank.

Having multiple issue sources (project, boards, JQL filters) does not change that behavior as all the issues are relatively ranked against each others in Jira, even across issue-types and projects.

Cheers,

Thomas

[Nathan Green]

Thanks @Thomas

I acknowledge your earlier response that the rank of the epic is the rank of it's highest ranked child. Yet as far as I knew, ranking of JIRA's is done on a per board (Portfolio aside) basis. You mention above that all issues are ranked against each other in JIRA across issue types and projects. How does JIRA determine the relative ranking of 2 JIRA's that have been raised on different projects, when it could be that they have completely different contexts? Setting up a couple of test issues across multiple projects, all same type, same piority ordering by rank seems to indicate rank is based on creation date with most recent highest ranked. Is this correct?

Going further, if I have 2 child JIRA's on 2 different projects and they are both ranked top on their respective boards, and I have a portfolio plan which reads both boards, how is the overall rank determined?

Board A (project A):

Epic A1 - with children ranked A1>A2>A3

Board B (project B)

Epic B1 - with children ranked B1>B2>B3

Who decides that A1 s higher ranked than B1?

Thanks for your input.

[Nathan Green]

@Thomas so it turns out some of our users , instead of ranking items through a board, their items from JIRA using "rank to top" option. When you rank on a board, JIRA re-assigns the rank of the item that has been moved so that it slots into the ranks only in relation to the items on that board. However when you use "rank to top", the JIRA is moved to the number one ranked slot across the entire JIRA instance, not just limited to the board(s) on which that JIRA appears. It's the use of this function which is causing our items to re-order on our portfolio plan in unexpected ways. I'm going to get the folks here to stop ranking to top, and rank instead form their JIRA boards.

[Thomas]

> How does JIRA determine the relative ranking of 2 JIRA's that have been raised on different projects, when it could be that they have completely different contexts?

In short, when a new issue is created it is ranked at the bottom, then relative ranking may happen as per user interaction through boards or Portfolio for example. A way to visualize ranking across projects would be to do a simple JQL query like "projects in (a, b) order by rank asc".

> Setting up a couple of test issues across multiple projects, all same type, same priority ordering by rank seems to indicate rank is based on creation date with most recent highest ranked. Is this correct?

Creating a new issue puts it at the bottom (not highest) of the Jira ranking, but boards can have custom ranking defined in the board configuration, so it's not impossible that it looks different in your case. Issue type, project (and all else really) have no incidence on ranking (e.g. an Epic does not get a special ranking treatment). Also note that issue workflows may include some special actions that may include ranking, another reason for things to look potentially different after a create action.

> Going further, if I have 2 child JIRA's on 2 different projects and they are both ranked top on their respective boards, and I have a portfolio plan which reads both boards, how is the overall rank determined?

As mentioned above, there is only one global ranking, there is no "board ranking". Boards will just present you a selection of issues. So if everything is "default" and no custom ranking or user-interaction have changed ranking for 2 issues, then the one created first would be on top.

Hope that helps!

Cheers,

Thomas

[Michael Kerr]

@Thomas  Keying off of #5 above:  

5. If an issue has children (e.g. Epic with some stories) then the rank of the parent becomes the rank of its highest-ranked child. The reason for that is that we want to make the parent rank represent what will be done first, if the top story of an epic is ranked last this epic will be scheduled last so it should appear last in the ranking. Re-ranking a parent will re-rank both the parent itself and all its children.

We have a more complex setup. Portfolio Epic, Initiative, then Project Epics.  Do PE & Initiatives take the ranking from the highest Project Epic in this case? Is there a way we can use Portfolio Epics to drive the priorities (ranking) across the organization instead of the stories driving the priorities from bottom up? Portfolio Plans don't seem to drive ranking/priorities to JIRA.  Other Portfolio Plans are not affected by ranking changes from One Master Portfolio Plan.  Any pointers?

Thank you, 

Michael

[Thomas]

Hi @Michael Kerr,

Re-ranking issues in Portfolio and committing them will impact the ranking in other plans and in Jira. The ranking is bottom-up as Portfolio schedules pieces of work, and the issues estimated are usually the bottom ones. As a result, starting an epic first means starting the story first. Starting a story first means it has to out-rank all other stories to be pulled into the next sprint in Jira by the dev team.

Re-ranking a parent should re-rank all children issues accordingly.

Hope that helps!

Cheers,

Thomas

[Charanya (CK) Kannan]

Is it possible to re-link two portfolios, meaning if I change the rank in one I don't want the other one to get impacted (even after committing)