Why are stories in cancelled status pushing to next sprint?

[Natalie Cotela]

Hi there,

We noticed today several stories that were in cancelled status, but were pushed to the next sprint. How do I stop this?

The most activity on April 15, 2026 at 11:19am shows that when the previous sprint was closed and new sprint started during our sprint planning call, it pushed this cancelled story into the new sprint (even though it is in cancelled status). 

[Bill Sheboy]

Hi @Natalie Cotela 

In which column of your board is the "Cancelled" status mapped?

For a Jira Scrum board, only items in the far right column are considered completed regarding the Sprint.  If you have the "Cancelled" column somewhere else on the board mapping, Jira prompts to move the items to a new Sprint or the backlog.

Kind regards,
Bill

[John Funk]

This is most likely the culprit. The Cancelled status needs to be mapped to the column and not just sitting in the unmapped statuses area. 

[Shalini Pradhan]

Hello @Natalie Cotela ,

Good day! Welcome to Atlassian Community :)

When you close a sprint, Jira decides which issues are "complete" based on whether their status is mapped to the rightmost column of your board. If "Cancelled" is not present in that rightmost column (or is unmapped entirely), Jira treats those stories as incomplete and pushes them to the next sprint.

Steps to fix it:

1. Go to your board → Board settings → Columns

2. Find your rightmost column (where "Done" status is there)

3. Drag the Cancelled status into that rightmost column alongside Done

Thank you

[Mikael Sandberg]

The work items in canceled status are moved to the next sprint because you are not setting the resolution, either manually or via a workflow rule. If the resolution is set then Jira consider the work item as resolved.

[Adrian Woods]

This is the correct answer! Once the item is fully in a resolved state, it should stop moving beyond the current sprint. Hopeful this fixes it for you! Nice work, Mikael!

[Germán Morales]

EDIT: Thanks to John Funk for the correction below. Updated to reflect that the rightmost column mapping drives sprint close in both project types, and Resolution is a separate consideration in company-managed.

Quick clarifier that should save some back-and-forth: the mechanism for sprint close is actually the same in both project types.

Both project types (Company-managed and Team-managed): Jira looks at the board's rightmost column to decide what counts as "completed" at sprint close. Map your Cancelled status to the last column and sprint close will treat those issues as complete.

Additional consideration in Company-managed projects: the Resolution field also matters, but for other things: reports, JQL filters, workflow hygiene, and visual indicators in some views. It does not trigger sprint close on its own. Best practice is to set Resolution via a workflow post-function or an automation rule when status transitions to Cancelled, so Cancelled issues behave consistently in reporting.

To know which project type you are on: Project settings, then the bottom-left corner shows "Company-managed" or "Team-managed".

Belt-and-suspenders fix (recommended for both):

1. Move the Cancelled status to the rightmost column of the board.
2. For Company-managed, also add an automation so that when status transitions to Cancelled, Resolution is set to Cancelled.

That way sprint close is unambiguous and your reports and filters stay consistent.

Germán

[John Funk]

This is not correct. For Company-managed spaces, the status must also be mapped to the last (far right) column.

[Germán Morales]

Good catch John, thanks. You're right: the rightmost column mapping is the trigger for sprint close in both project types. Resolution matters in company-managed for reports, filters and workflow hygiene, but it's not what sprint close actually looks at. Editing my post to correct this so nobody gets the wrong info.