nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Portfolio scheduling is not completing stories sequentially

Michael Baj

I am struggling to figure out how to use Portfolio to do release planning in what I would consider the natural intuitive fashion. In my simple example you can see two issues that I can not figure out how to address. The item listed as priority #10 is scheduled to start before issues 1-9. Secondly, the epic is not completed sequentially. Instead it is split up across several months!

Here is some context to the epics that are contained within this release.

The team (Analytics) is comprised of 2 developers.
A sprint is 2 weeks long.
All of my releases have fixed start and end dates.
Each developer can perform 8 story points per sprint, totaling 16 story points per 2 week sprint.
I have not set the fixVersion in any of the stories and epics.
I have only set scoping on all of the stories. I left the scoping on the epic blank as it should be using the sum-up of the story points.
There are no dependencies defined between any of the stories/epics.
The teams in Portfolio are shared teams, not private teams. They point to an actual board with a backlog. That backlog only has 4 sprints defined, yet the portfolio plan needs dozens to schedule the tasks (not sure if this is relevant).

I am relying on Portfolio to use the story point velocity, scoping and priority to suggest the target release. I would have expected that the work would be scheduled in one sprint if each developer is tasked with a single story. Alternatively it would take two sprints by the same developer. However this is not happening. I have experimented with all of the settings and different permutations in Portfolio but I always end up with the same results. This problem is not unique to this one epic/story. It happens with other epics as well that only have a single story. I can only imagine that I am doing something wrong since I can't imagine that this type of scheduling is useful for anyone.

Thank you in advance.

Screen Shot 2017-09-30 at 3.54.01 PM.png

Comments

Bree Davies_kv5afn

Hi Michael,

If you look at your scope table issue order (when all sorting is turned off), is the story order as you'd like it to be? 'Priority' of issues is derived from the story level, so give this a check and make sure they are in the order of priority you want.

I would also recommend making manual release assignments for your issues, given you have them set up. Especially if you have an expectation that certain issues should be done as part of a particular release. You don't have to do this, but it will 'force' issues that are assigned to a release to be done in the fixed timeframe you've set on the release.

In combination with story 'ranking' (or priority), you should get the result you're looking for.

Please don't hesitate if you have any other questions at all and please let me know if this works for you.

Thanks,
Bree

Liandro Rossini

"I can't imagine that this type of scheduling is useful for anyone." - TOTALLY AGREE!!

Michael, have you solved it?

Michael Baj

I have been told that in order to properly use Portfolio to manage your schedule and backlog, you have to prioritize by Story alone - not Epic. This is difficult, if not impossible for my business as we do not have a good way to organize Stories in a consistent way throughout our project. I was operating under the notion that Stories grouped under an Epic would inherit the relative Epic priority, but evidently that is not the case. It would be great to know if you organize by story alone that you can actually use Portfolio. I have yet to prove this myself.

Liandro Rossini

So, yesterday I created a project and a few stories to test this, as I also read somewhere.

Result: same problem. Inumerous tests, configurations.. always the same.

One of the most simple tests I've made that shows the problem:

- one new portfolio for a new test project

- team with just one person, capacity = 40 hours a week (1 week scrum)

- some stories with 21 hours each

Result

- one story per week

- remaining capacity of 19 hours a week! Incredible..

- if you have the last story of your backlog with less than 19 hours, it will put it in front of all the others..

Brian Freund

There isn't a lot of detailed documentation on the scheduling algorithm, but her is the link to Atlassian's documentation. Portfolio scheduling-and-timeline documentation

A few things I've learned from trial and error are:

The priority field means nothing to Portfolio scheduling. Portfolio uses Rank to determine the sequence items are desired. Rank can be set per issue in the Backlog of a Scrum board or at the Epic level. For it to be done at the Epic level you have to size your Epic so all the linked issues are worked on at the same time as compared to other Epics.
Portfolio starts to schedule based on your sprints respecting what issues have been assigned to a sprint and the dates of the sprint. When it schedules future sprints it starts at the top of the backlog and works it way down filling the sprint as it goes. Portfolio won't allow an infeasible schedule so it never overloads a sprint. If an issue is too large to fit in the sprint but there is still room in the sprint it moves to the next issue in the backlog to see if it will fit in the Sprint. This can cause some odd results as it picks a very small story from the bottom of the backlog because it was the only one small enough to fit. It also selects issues in a release before it selects issues without an associated release. This can cause problems if you backlog is not groomed and you've assigned items at the bottom of you backlog to a release and not earlier ones.
Use Initiatives, Versions and Epics in a way that facilitates the scheduling first. You can use them for other reporting purposes also, but if you use the primarily to group issue for reporting and that structure doesn't work well to schedule in Portfolio you're out of luck. If you Initiatives, versions and Epics the way that Portfolio schedule and that doesn't make your reporting easy then there are lots of other ways to attribute issues for reporting purposes.
You can also use skills, stages, and team member constraints to further refine your schedule. Our approach has been if we can't sequence our work sufficiently to plan at a team level we're not going to solve our planning problem by being more granular. If we can sequence our work at the team level sufficiently to have a credible plan we'll know exactly where we'll benefit from more granular scheduling.
Portfolio lets Scrum boards decide between story points or hours. Kanban boards have to use hours. If you use Kanban, but estimate using story points create a Scrum board just for importing your board to Portfolio so your Kanban team can still plan using story points.

Michael Baj

Brian, thank you for this detailed response. This is very helpful. In your first bullet point, you state: "For it to be done at the Epic level, you have to size your Epic so that all linked issues are worked on a the the same time as compared to other Epics". What does "sized right" mean in this setting? I use the Epic Sum Up module and let me Epic add up the effort of all its child issues (stories, tasks or bugs). Do you mean that the effort, be it story points or hours, depending on how I have Portfolio configured, needs to be set at the Epic level always?

Brian Freund

Michael,

By sized right I mean how you group work in Epics so it is delivered at the same time. Portfolio is going to respect the sequence in which you have organized your backlog on your board.

For example lets say we have 400 individual stories we are delivering for version 2.0 of our product. To build an accurate schedule for when each story will be delivered in Portfolio I have to sequence all 400 stories in their backlog... huge pain, right.

We're smarter than that so we use Epic to group stories in to Capabilities, Features, or some other grouping that makes sense, and say we have 40 Epics. Then I can sequence 40 Epics in Portfolio based on what adds the most value to the business. That way if the project gets stopped before I'm done I've already delivered the high value stuff. It's then easy if the business says the world has change Epic ABC is no longer important, instead we need XYZ. You move Epic XYZ up and ABC down in the rank and the stories in the backlog for those Epics are automatically reordered to the new sequence.

Of course you need to make sure you haven't started any of the stories in the Epic you're demoting, but I assume you're only moving things you could.

Now if you're not smart about grouping stories in Epics and say use them to track stories Joe asks about, banking issues, UI changes, or whatever, that is a mix of priority items and only grouped together so you can easily report how many of these are still open but none have to go together. Now my Epic rank in Portfolio is determined by the highest ranking story in the backlog for the Epic. If I move stories Joe ask about above banking issues that means all of Joe's stories move above banking issues which may not be the case. Maybe only some are and some need to be done in three months and the rest are next year. This means I can't move my Epics around to reorganize the sequence of my backlog, instead I have to sequence all 400 stories. The next downside this causes in Portfolio is the timeline view shows you when an Epic starts and is a solid bar until it finishes. So lets say I need to do 1 story from each Epic right now and then it is a mix of stories from different Epics until I finish version 2.0 with 1 story from each Epic. Portfolio will show all Epics Starting and Finishing together. I won't easily know what work is being delivered when unless I look at the story level. Plus if the business says swap feature ABC for XWZ I have to find all the individual stories that make that up and move them individually in my backlog.

Before we used Portfolio it never mattered, so we grouped things in a way that made it easier for us to report on. Once we started to use Portfolio we realized there are lots of ways to report on a group of tickets, but there is only one way to mange the sequence of a group of stories from Portfolio and that using Epic and setting the sequence.

Hope this helps.

Jira is a wonderful highly flexible and easy to configure software, but there is some stuff that if you don't use as intended you have no other way to get that functionality. I stub my toes on that all the time.