Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Closing a sprint that does not have any work assigned but it is linked to a program board?

melissa_barton
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 18, 2026

On our program board that uses several spaces to link dependencies, when one of the spaces does not have any work planned for the sprint and the sprint is 'deleted', the program board will then show an error- Screenshot 2026-05-18 094849.png

What can be done to alleviate this error without putting fake work into a sprint to 'close' it? 

2 answers

0 votes
Joshua Brock _ Seibert Group_ GmbH
Community Champion
May 28, 2026

@melissa_barton welcome and great question!

This is a known friction point in multi-project Jira setups, and the root cause is worth understanding so you can pick the right fix.

When your program board links dependencies across multiple Jira spaces, it relies on active sprint references in each of those projects. When a sprint is deleted (rather than completed), those references become orphaned, or rather, the board loses its anchor point for that space and throws an error. Completing a sprint, even an empty one, closes it cleanly without breaking the dependency graph. Deleting it does not.

A few practical options that don't require fake work items:

1. Complete instead of delete. If a team has nothing planned for a sprint, just complete it as-is. An empty completed sprint is harmless and keeps your board clean. This is the lowest-friction fix.

2. Remove dependencies before deleting. If you do need to delete a sprint, first unlink any cross-team dependencies that reference it. This prevents the orphaned reference issue, though it adds manual overhead.

3. Reconsider the sprint-per-space model. If several spaces routinely end up with empty sprints, it may be worth reviewing whether your ART structure maps cleanly to your Jira project setup — this kind of error is often a symptom of the underlying hierarchy not quite fitting Jira's native model.

That last point is one I just wanted to touch on a bit more. Native Jira's program board wasn't designed with SAFe's multi-team dependency model in mind, which is why these structural edge cases surface. If you're running SAFe at scale and finding these workarounds are becoming routine, it might be worth looking at our product, Agile HiveIt's purpose-built for Scaled Agile Framework (SAFe) in Jira and maintains the program board at the PI level rather than the sprint level, so empty or closed sprints in individual spaces don't cascade errors to the board.

In the meantime, the complete-instead-of-delete approach should solve your immediate issue.

And just in full disclosure, I work for Agile Hive which is a product of Seibert Group, GmbH.


Best of luck and again, welcome to the Community!

Joshua
Content Writer and US Representative
Agile Hive & Aura Apps (products of Seibert Group GmbH)

0 votes
Arkadiusz Wroblewski
Community Champion
May 22, 2026

Hello and welcome to the Community @melissa_barton 

The error message is quite clear here.

The Program board requires every column for the E-Platform team to be mapped to a sprint, which is why deleting one broke the board's configuration. You don't need to create dummy work items to fix this, the board just needs the underlying sprint mapping resolved.

You can either create a new sprint in the E-Platform backlog and link it to that empty column, or remove the sprint mappings for that team entirely so the board defaults back to date-based planning.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events