Improve Automatic Story Point Distribution Across Sprints in Advanced Roadmaps

[Sander van Laarhoven]

Title:
Improve Automatic Story Point Distribution Across Sprints in Advanced Roadmaps

Description:
When planning capacity in Advanced Roadmaps, I assign story points to epics and set start and due dates. Currently, the automatic distribution of story points across sprints within this period tends to front-load the points into the earliest sprints, even if those sprints are already at or over capacity. This results in overloaded early sprints and underutilized later sprints, making the plan less realistic and requiring manual adjustments.

Suggested Improvement:
Enhance the auto-scheduling algorithm so that story points are distributed more evenly across all sprints within the epic’s date range, taking into account each sprint’s remaining capacity. Ideally, the system should fill sprints up to their capacity before allocating work to the next sprint, ensuring a balanced workload and more accurate capacity planning.

Use Case:
This improvement would help teams plan more effectively, avoid overloading early sprints, and reduce the need for manual redistribution of work. It would also make the capacity planning feature more intuitive and valuable for teams managing multiple sprints and large epics.

Benefits:

• More realistic sprint plans

• Better utilization of team capacity

• Reduced manual adjustments

• Improved planning accuracy

[Dave]

Hey @Sander van Laarhoven 

Although I work for Atlassian, I'm not directly involved in the development of Jira Plans / Advanced Roadmaps.

However, you might be interested in trying out my side-project - the Sprint Capacity Analysis as I think that this features some of the capabilities you're describing. This app is available for free on the Atlassian Marketplace: https://marketplace.atlassian.com/apps/1238160/sprint-capacity-analysis

I provide support on a best can do basis (it's not my day job at Atlassian!) but I'm keen to get feedback and make improvements and I can feed this back internally to the teams working on the product.

If you'd like to try it out then I'd be grateful for any feedback. The app allows you to set individual capacity (or just team capacity) as well as allocate skills to team members and then you can use the planning tool to organise the backlog into sprints.

It's focused on a single board and attempts to preserve rank as best it can, and although it's not yet looking at dependency ordering that's something I'd like to add in the future.

I just wanted to throw that out there as a suggestion

Thanks,

Dave

[Marc - Devoteam]

Hi @Sander van Laarhoven 

Atlassians product and philosophy follow the usage of Story Points on work items on the Story level, not on the Epic level.

As items on Story level are granted an Epic as a parten and if this Epic has multiple children, and these children are assigned to multiple sprints, the Story Point set on the Epic will be set to that sprint.

Thats way estimation should not be done on an Epic level.

Via automation a rollup of all story points set on the children of the Epic could be done, based on custom number field to be set on an Epic and place the output of the calculation of the sum of the story points in this field.

[Sander van Laarhoven]

Hi @Marc - Devoteam,

Thank you for your answer.

Off course the items on the story level get story points when the epics are fully worked out. Before that stage the Epic is estimated compared to reference Epics and rewarded a set of story points to plot in de roadmap of the product. Before the actual realisation of the Epic is planned the Epic is broken up in Stories and Tasks which are then estimated. The rolled up value of these items then replace the placeholder story points value on the Epic. This is part of the agile portfolio management process.

The story points on the epic should therefore properly spread over the available sprints and not overflow the sprint capacity that is set in the team settings within plans.

The roll-up is done in plans if you check the box in the settings so that is not the issue.

[Marc - Devoteam]

Hi @Sander van Laarhoven 

A Team is set a capacity.

How your PW/SM plans the sprint, this could overflow the Team capacity.

If there was auto-scheduling based on story point, this could lead to have an import Story be in the last sprint of the Epic time line

Based on the backlog items should be planned in a sprint not on auto-scheduling as this could leed the depended Stories could be planned in the wrong sprint based on the auto-scheduling.

Sprints should be planned based on the sprint backlog not automated on the amount of Story points.

Based on the rank of the Story on the backlog, the PM/SM need to decide the if an item can fit the sprint or not, not to overload the team.

[Sander van Laarhoven]

I am a SM/Agile coach so I know how planning works.

We are a premium customer and that is mainly because of Plans with capacity managent capabilities. My opinion is that if functionality exists in a product it should work properly. In this case:

Here you see that the planned sprints have room left to put items in:

When I put story points on the epic it spreads to the planned sprints:

But while it has room left it overcommits to the first sprints:

if I do the same with a story of 50 points it overflows the first sprint: