Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Jira Portfolio capacity warning

I read where if a team exceed its capacity (velocity) for a sprint the issue is only partially scheduled.  Does this mean that Portfolio only schedules to the teams capacity and the rest is unscheduled?  I can see where this makes sense for future sprints, but the active sprint means the team has committed to completing this work.  Can you clarify how this works and the rationale for it.   It may just be that this is the most conservative view, but I want to make sure I understand what my plan is representing.

1 answer

1 accepted

That text you are referring to is related to how the scheduling algorithm works.

The scheduling algorithm does this, it's useful to predict how long the epics and stories associated with a team will take to complete  beyond the team's sprint to sprint commitments. As you indicated: it's useful for future sprints.

Your team configuration (in your plan) should indicate which scrum board the team is using. This allows the plan to see the explicit sprint commitments the teams make.

Any commitments the teams make in their scrum board will not be disrupted by the scheduling algorithm. There will be a warning in the capacity view to call attention to the fact that the team is committing more than their planned velocity. But it's not an error, it's a warning.

You'll also notice (when you connect each Team to their Scrum board) that the names they (the team) uses for each of their sprints in their board appear on the plan. The predicted future sprints follow a generic naming convention of Sprint <number>. This makes it easy to tell where the algorithm has started populating stories into predicted future sprints that the team doesn't even have on their board (yet).

Thanks that was helpful.  One clarification, I understand that the committed sprint is what the team has committed to and not disrupted by Jira; and that generic sprints are only planned to the capacity defined by velocity.   That makes sense. 

Does the committed only include the active sprint, or does it also include all named sprints?  Our teams commit to the active sprint, but POs will start to align the next sprint by naming the sprint and filling it with ~2 sprints worth of the teams capacity.  Ideally, these defined, but uncommitted, sprints would only be planned to the teams capacity.

Great, glad to help :)

Active and Future sprints on the team's scrum board appear in the roadmap/timeline capacity view.

Prior closed sprints do not.

Story level items the team adds to future sprints on their scrum board are also not disrupted. The PO can also add stories to these future sprints in the Plan, either explicitly or using the scheduler. If sprint assignments are done in the Plan, these changes need to be Reviewed and Committed to the Jira boards (from the plan) before plan based sprint assignments will be visible on the teams board.

This "sandbox" planning context helps with "what if" analysis.

Any changes in sprint assignments, done on the team's board, are reflected in the plan as soon as they are done. You may need to refresh the plan page if you want to see it as soon as it happens

This has been working for me - thanks, but I have started noticed a related behavior that is causing concern.   

You indicated that Portfolio will not disrupt stories a PO has put into a sprint.  We have adopted a practice of communicating a 3 sprint window on our planning horizon to give leadership a near-term plan, while beyond that is still in flux.  This allows us to adjust our plans where necessary, but provide leadership with what we plan to complete in the next 3 sprints.  The near-term Portfolio plan becomes our plan of record.

The problem is I took your term "not disrupt" to mean that POs took ownership/control of a named sprint, and Portfolio left it alone.  It appears that is not exactly the case.  We are seeing when a sprint is under committed, Portfolio is pulling stories from the backlog to use the remaining capacity in the sprint.   This is disrupting our plan of record and our next delivery window that is in planning. 

I am assuming I am correct on how Portfolio works based on what I am observing.  Do you know if there anyway to force it not plan additional work into a sprint?  Do you use Portfolio as the plan of record, and if so, how do you address this?


Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you