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?
This is described here: https://confluence.atlassian.com/display/AGILE/Ending+a+Sprint
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.
You are now entering an area that can be confusing; I suggest you read up before you progress. Start with https://confluence.atlassian.com/display/JIRA/Configure+workflows+and+screens. The look at https://confluence.atlassian.com/display/JIRA/Configuring+Workflow. 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.
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?
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).
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"
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 had exactly the same problem. If you haven't already found the solution, take a look at https://answers.atlassian.com/questions/9867148/jira-wants-to-move-completed-stories-to-the-backlog-upon-sprint-completion.
Simple solution in the end (but oh so infuriating to track down)
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...
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!
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