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; } } }

Splitting tasks across sprints in JIRA Portfolio

Scott Finneran

When scheduling work, JIRA Portfolio attempts to pull stories into a sprint until the team's capacity is "full". If the team has a small amount of available story points, Portfolio will pull tasks in from future projects.This can have the unfortunate effect of having the team appear to be starting a much later project WAYYYY before that will actually happen.

What I would prefer is for Portfolio to schedule the next story even if capacity indicates that the story won't complete in a single sprint. This much more closely reflects reality for my team.

My question of course: "Is this possible"?

Accepted answers

All comments

Martin Suntinger

Hi Scott, this is currently not possible - the intention was basically to guarantee that always full work packages (stories) can be delivered in a sprint, and if that is not possible, to rather consciously split something up into 2 stories with one fitting into the sprint if that is actually possible, rather than "squeezing" it in and then do only parts of it. This aligns closely with the philosophy of sprints and shippable increments at the end of it.

How would this turn out in practice in your team? Would you then complete a part of the story in that sprint, and after the sprint shift it on to the next one (whatever is remaining)?

Another question: These later projects that get scheduled way too early: Are those broken down into small-sized user stories already, or are those epics with a rough, epic-level estimate?
If it is epics estimates only, you could experiment with the maximum work package size setting in plan configuration (Scheduling settings) - this controls how small the "packages" of an epic can get which might get filled into the schedule, with a larger value, you'll see less "space filling", but only if that's epics without stories.

Another thing you could work with is releases and start dates: If things are not supposed to start as soon as there is capacity, but only after a particular date, you could assign them to a future release, with a fixed start date, to make sure they don't get scheduled earlier.

Scott Finneran

Hi Martin,

Thanks for the reply. The work arounds you describe do work and I've been using a number of them. Apart from the additional workload, they also cause either completion dates or capacity reports to be unrealistic.

I do agree that ideally, a sprint ends with everything nicely tied up with a bow and shippable and we certainly don't ship anything partially complete. But realistically, if we wrap the sprint's committed work a day ahead of schedule, my team want the option to make a start on "the next thing" rather than being forced to reach into the future for a relatively low priority task just because the process demands it. There are also other factors such as being able to manage scope of development changes so that QA, operations and others "down the line" don't get blind sided by included funcationality they weren't expecting.

In some ways we aren't by "by the book" SCRUM but it is how we (and many others) work. It would be really great if the portfolio scheduler could (optionally) allow for this.

Liandro Rossini

Hi Scott.

We have the same problem here.. how did you fixed id?

Liandro Rossini

Hi @Martin Suntinger.

Is there any update for this subject? We have the same scenario here.

Actually, this Portfolio behavior causes two different impacts on planning:
1) described by Scott

A problem here trying to create a work around (manually set a start date, create a dependency, create and define releases) is that if the priority of our backlog changes (and it will) we'll have all the unnecessary work again.... (check start date, check dependency...).

2) if there is no "small stories" further in backlog (to fill the empty spaces), you'll have lots of sprints ahead with available team capacity...

Considering that we are using scrum, we just have little part of our backlog splitted into "well estimated stories". All the rest of the backlog is at a high level estimate. Doesn't make sense to me having to split and estimate all the backlog to have the work done.

Even setting "Enforce concurrent work" to OFF ("When set to 'On', if multiple team members are assigned to a single item, the scheduling algorithm ensures that all the work for that item is scheduled into a single sprint. When set to 'Off', individual team members' work can be scheduled whenever there is free capacity allowing a work item to span multiple sprints.")

what I understood that should fix this, we still have lots of available work in sprints..

Portfolio must have an option to work like this:

- "split stories for using all available capacity, and consider the priority above anything else".

No extra repeated work would be needed.

Priorities changes a lot, the less input the better.

Roi Fine

Hi @Liandro Rossini,

I'm a product manager in the Portfolio for Jira server team. I understand your problem. In order to auto-schedule issues on the timeline, Portfolio needs issues to be estimated. You can use the default estimates feature if your teams do not tend to estimate well in advance. More info here: https://confluence.atlassian.com/jiraportfolioserver/scheduling-unestimated-items-943544098.html#Schedulingunestimateditems-defaultestimates

Otherwise, assuming you are a server customer, my team is exploring a feature that will allow you override the auto-schedule output via drag and drop. In practice this will means you would be able to manually drag issues into the different sprints even if they are not estimated or even if it will cause an overbooked sprint.

I would like to know if that can work for you,

Cheers,

Liandro Rossini

Hi @Roi Fine.

Nice to know that you're the product manager!!

So, we are using default estimates. Now we understood a little bit of the portfolio algorithm and it got a little bit easier for us to configure it. By the way, do you have the basic logic somewhere? It will help a lot to understand some behaviors and to know how to use it.

For example.. we understood that the free spaces were happening because we were using default estimates for stories.. by doing this, portfolio just put into the sprints stories that "fit" (end to end). Using "nothing" as default estimates for stories and using epic default estimates, portfolio uses all the available team capacity (as you can have little stories that will fit any gap).. nice!

Yes, we use a server instance. About the new feature... it would be better for us (and for other users apparently) if you create one option for portfolio NOT to antecipate a further story just to use any available capacity. We are not going to work on a future story just because it fits.. we will antecipate the next story.. and for this we have to see the empty spaces.

We are evaluating portfolio and this behavior is a "problem" for us.. as we have to find all the antecipated stories and take some action to put them back to their places (manual work = bad).

Our scenario changes a lot, and for this reason the less manual work we do, the better..

Do you think it's possible for you to create this option?

Mike S

Hi there,

@Roi FineWe have the same problem in my team, we always prefer to use "leftover" capacity to start working on the next most important story instead of finishing a lower priority one. Since this affects only 20% of our work, it's ok for us SCRUM philosophy wise.

-> Without this feature Portfolio doesn't work for us, sorry!

Too sad that I found out only after paying the rather large license fee (we are a lather large corp)

Best regards - Mike

Roi Fine

Hey Mike,

Sorry to hear that. As a product manager of Portfolio I want to make things work for you. But as you may know, each company & teams have a different way of work. On top of that, each team often has a different way to work in Jira. This is a challenge for an app that sits on top of Jira.

Our thinking and approach for the future of Portfolio is to make the tool more flexible and simpler to how teams work. Now, this will have some cost to how automated and smart the solution will be.

We can schedule a call with you and other Portfolio users in your company to share our thinking and roadmap to get your feedback.

Cheers,

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-software

jira-software-cloud

advanced-roadmaps