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"?
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.
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.
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,
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.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot