Cannot close a sprint with stories that are resolved that have tasks that are closed.

When I try and close a sprint some people have marked tasks as closed. 
This stops me finshing the sprint unless I move all the tasks to resolved.

I don't care if tasks are closed or resolved. How can I force the sprint to end? 

4 answers

1 accepted

1 vote
Accepted answer

This is described here: 

Any issues not completed at the end of the sprint will be moved to the next planned sprint, as they did not meet the team's definition of "Done". If you do not have a next planned sprint, they will be returned to the backlog and will be visible in the Backlog of the board.

  • If you have parent issues that are not 'Done' but have sub-tasks that are all 'Done', the parent issues will still be moved to the next sprint/backlog. If these parent issues are part of another active sprint, the previously completed sub-tasks will still be 'Done'.  


Sorry nope. The parent is resolved (ie done and should not be moved to the next sprint) just it has some subtasks that are marked "Closed" so jira throws a fit. I suppose jira is not recognising that Resolved and Closed are 'done'. How do I tell jira that resolved and closed are both 'done'

You have to check out your workflow; Resolved != Closed by Jira default settings. This is the standard comment for Jira's resolved: "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed." Change the workflow to suit your need, or have the team explicitly set the issues to closed when you're first at it.

But the problem is when things are marked as closed jira won't let the sprint complete... You are suggesting something has got misaligned from default jira install? We have done very little customisation

No, I'm saying that this is default Jira behavior. Resolved != Closed. If you want to get Resolved == Closed, you have to change the workflow.

Thank you very much for your attempts to help me. I find the internals of jira frustrating and confusing! Can you point me to where or how I need to change the workflow? I cannot see what jira looks at in the closing of a sprint to make its decisions.

You are now entering an area that can be confusing; I suggest you read up before you progress. Start with The look at Yes, the internals of Jira can be confusing. But the upside is the possibilities you have to configure it according to your needs.

(╯°□°)╯︵ ┻━┻

What was the answer to this question "I cannot see what jira looks at in the closing of a sprint to make its decisions." ?

I have this same problem, and can't understand what workflow has to do with this.

What transition is Sprint complete trying to execute for the tasks?

Btw. the statuses are Done and Closed.

This thread is over 3 years old and things have moved on.

The answer now is "an issue is done when it is in the far right-hand column of the board".

What? That depends on how you have configured your board.

Non the less, if one sub-task is closed (and all others, including parent) is in the far right-hand column of the board (status Done) Jira won't let you close the sprint.

What message is it giving you to tell you that you cannot close it?

Not sure I agree with this Jira functionality.

We manage common sprints across over 40 teams. So we have a special board we use to stop and start sprints.

The lifecycle of a Story for example will go through pre-sprint, sprint, and post-sprint to get into production. E.g. from an idea, to getting ready, to being ready (for sprint), in progress, Ready for UAT (let's say this is Sprint Done), and then some post-sprint steps before going into Prod.

There can be sub-tasks for some pre-sprint work, such as analysis/design, then some sub-tasks for sprint work (dev type sub-tasks, test type sub-tasks), and then a number of post-sprint sub-tasks.

So I should be able to close the sprint, with some Stories in "Ready for UAT" (last column, a sprint done status), and for it to still have some sub-tasks to be done after the sprint.

But if my sub-tasks have a "todo", "in progress", "done" status for example, and the Stories also use the "in progress" status, then I can't map that status to the last column, or else these stories will be considered done and won't get carried over to the next sprint. But as I understand it, the only way Jira will let me close the sprint is if all the statuses of sub-tasks are mapped to the last column (or at least the statuses any of the "Done-status" stories's sub-tasks).

The only "hack" around this I can see is to have a special set of sub-tasks statuses (e.g. sub-task-todo, sub-task-in-progress, sub-task-done) and, on our special sprint-stop-start board, have all those statuses mapped to the last column.

This will be a pain to implement as currently our sub-tasks have common statuses as several of our issue types.

I'd just prefer it let us close a sprint regardless of the sub-tasks' statuses (as some of the sub-tasks are often about post-sprint activities).

That make sense?

Anyone agree?

No, that defeats the whole purpose of sprints with subtasks.

The point of a sprint is you commit to doing a set of stories.  If you break up a story into sub-tasks to help you manage it, allocate different bits out, differentiate between types of work, or teams, and so-on, that's fine.  But a story, by definition, cannot be complete until all of it is done.

In a sprint, there is no try, no partially complete, there is "done" or "not done".  If your sub-tasks are not all complete, then the story can't be.

If you have a need to carry sub-tasks over into the next sprint, then they are not sub-tasks (and you should not have said you would do them in this sprint).

As far as I know you can't exclude a sub-task from a sprint, so I find Mr. Smiths position legit.

That's correct, a sub-task is part of a story and hence goes into a sprint with its story.  A story, logically, cannot be complete if it has open sub-tasks.  So, it's nonsense to have open sub-tasks on a complete story.

If you do find yourself wanting to do this, then either move off Scrum (because you're not doing Scrum), or accept that you're breaking up stories incorrectly, and move the sub-tasks to the right place (or create them initially in the right place)

Seriously... you really think that an organisation cannot do sprints unless the story gets pushed into production by sprint-end?  It’s that sort of purest scrum talk that gives scrum a bad name.  We are a decent sized enterprise on a journey towards CI/CD etc, but that does not happen overnight.  Meanwhile, like it or not, we have work on a story “post-sprint”, mostly related to final integration testing.  Ideally that would not be needed, but it is.  For Jira to enforce such a rule I suspect is not some devotion to scrum purest thinking otherwise it wouldn’t let us close a sprint on a different board (enterprise sprint stop/start scrum board) that has the sub-task statuses all mapped to the last column... which is different to how the individual team boards are mapped.

So that’s our workaround we adopting... we have created specific statuses only used by sub-task issue types (sub-task-to-do, sub-task-in-progress).  Each team has their own scrum board, but we centrally stop/start sprints (common enterprise-wide sprints) from an uber-sprint-scrum board. This board has similar status mapping to most of the teams (I.e. we mapped all “Sprint-done” status from “ready for Demo” and “ready for Integrated UAT” to the last column, whilst “in dev”, “test automation” and other “sprint” activities are in the prior columns.  Except we have ALL the sub-task-specific statuses on this board mapped to the last column.  So when we close the sprint (on this board), it doesn’t see any of the sub-tasks as not-done, so it happily let’s the sprint close.  In reality, a story that got to “ready for integrated UAT” is considered sprint-done by the team, but they may still have, for example, a final sub-task on it to “final test” the story again in the fully integrated environment.

So if we are not doing scrum (pure) then I don’t think anyone in our organisation is losing sleep over it. But we certainly are running in sprints/iterations, and we don’t expect to have to hack around in this way just because some scrum rule-book says “a story ain’t done until everything is done” (i.e. in prod or ready to be pushed out automatically)... which I don’t think is the reality with many teams and complex organisations that have a long journey of transformation to CI/CD.


PS:  Thanks @Frode Nilsen

That is not what I said at all.  I simply pointed out that your current setup is not scrum and is useless for measuring things in sprints.

I suspect you've simply stumbled into a common misunderstanding about how it can be done.  The point is committing to sprints and completing them and measuring success.

Here's where you're going wrong:

> an organisation cannot do sprints unless the story gets pushed into production by sprint-end

No, of course not, it really doesn't work like that.   That is an incredibly rare way of working.  The output of a development sprint is a pile of code that meets the requirements (or at least the developers think it meets it).  Trying to run a spring from Story to Production is a waterfall way of thinking and totally wrong in most cases.

> we have work on a story “post-sprint”, mostly related to final integration testing

Yep, that's fine and definitely worth doing.  But is it really part of a development sprint?  No.  It might generate more work for the developers if it fails tests, but it's not part of the development sprint.  Similarly with the deployment activity - it's not development work.


"It's part done" simply does not work.  It's either done or it is not.  What you've got wrong is trying to break that, which, while you can do it in Jira, simply negates most of the benefits of doing scrum.  The problem is that you're still thinking in the waterfall end-to-end pattern.   Either embrace it (do Kanban instead because your numbers can't work with scrum), or move towards doing it properly - break up your processes into dedicated sprints for the teams doing the different parts.  A developer's "done" story is a tester's "to do"

'A developer's "done" story is a tester's "to do"' - yes.

It would be nice if you could describe another way to do that effectively in Jira, that meets your demands for "Scrum".

Create boards for each team, as intended.  Imagine a simple workflow:

To-do -> Developing -> Ready to Test -> Testing -> Done

The developer's board has || To-do || Developing || Ready to Test ||,so that they consider "ready to test" as "done"

Then the testers get a board with ||Ready to Test || Testing || Done ||

I'd usually have an overall Kanban board for an overview as well.

Well, this suggestion has it problems too.

Ready to Test must be two stages, where the first is Ready for Review (in Scrum team 1). That implies you have to do a manual transition to Ready to Test after the sprint is closed.

If a tester takes a Ready to Test issue and move it to Testing, Scrum team 1 won't be able to close its sprint. Because the issue is not mapped to their board anymore.

It all come down to a problem in Jira, not a problem in the workflow.

No, you've not understood what it is doing.  Developers see three columns, effectively to-do, in-progress and done.   There's no extra status or manual transitions, you don't need them.  Developers sprint as normal.

The quirk in what I've done there is because I have over-simplified, and assumed that testers will not pick up from "ready to test" until the sprint is ended.

If they are going to do that, then on the developer board, add Testing and Done into the column (but protect the transitions with "only tester can do this" conditions).  Then the sprints work for the developers, no matter what the testers are up to.

It comes down to a problem in your perceived process, not Jira.

I found out that, you can complete sprint from "Active sprint" section

select desired sprint and in top right corner is button complete sprint

Another question si why it can not be done this form backlog view

Tom I'm New Here Jun 14, 2018

I agree - this should be possible from the backlog view, I've been battling with this for ages!

Thanks for the (unfortunately necessary!! tip)

Hi AW,

I had exactly the same problem. If you haven't already found the solution, take a look at

Simple solution in the end (but oh so infuriating to track down)

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 27, 2018 in Portfolio for Jira

Introducing a new planning experience in Portfolio for Jira (Server/DC)

In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to   have–in   order to produce a reliable long-term roadmap. We're tur...

2,506 views 15 20
Read article

Atlassian User Groups

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!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you