You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have a more elaborate set of status values. I do not, for example, have a "done" status as that seems vague...done by whom...dev, test, uat, BA analysis...etc. So when a ticket/issue has passed thru Dev and Systest, it gets a status of Sprint Complete. Then as Planning is conducted, the issues in Sprint Complete are moved to UAT Staging, ready to be moved to UAT but waiting on approval from the UAT owner.
At this point I want to close the sprint, but to do that, it seems to be looking for a status of "done"...the system wants to MOVE all of the issues w/o a "done" status to a new sprint, the current sprint, or the backlog....but I want to close the sprint because I have already reconciled all the tickets...if one was not finished and needed more input then the status was changed to "BA Analysis" for example...
HOW can I close my sprints if I do not end up with a "done" status for all the tickets?
Hello @Thane Carson
When you close a sprint in Jira it will consider the issues in the last column on the right to be "completed" in the sprint, regardless of the actual statuses mapped to that column.
So, for your issues to be considered "complete" in the sprint, they must be in the farthest right column for that scrum board.
The methodology of agile scrum is such that a work item has one definition of "done". All the work for that item must be "done" for the sprint to consider the work complete. The idea of "partial credit" for a single work item at various stages in its lifecycle doesn't align with the scrum methodology.
Note that if you have multiple stages of "done" for an issue, this can cause problems in managing the issue in scrum boards. If you need to be able to show completion in a sprint for dev work separately from test work, uat work, etc. then you really should have separate issues for each of those work items.
thank you...for clarification of "rightmost column", assume a Kanban board of 15 columns from Product Backlog to Released and NoTestingNeeded (spikes, etc). Each status matches the column. The Scrum board overlays the Kanban board and only includes about 6 of the columns in the middle from Dev Backlog thru to Sprint Complete. So at the end of the sprint, all of the tickets/issues are in the Sprint Complete column or moved to other status/columns outside of the Sprint...when the Review/demo is complete, all of the Sprint Complete tickets (rightmost column of the Scrum board) are moved to UAT Staging, so ALL of the Scrum columns are empty and ready for the Planning. At this point, if I close the sprint, will it "see" any of the tickets if there are none in the Scrum columns/status'? For example if there were 15 tickets in the Sprint, but now they are outside the visible columns of the Sprint, will any of those tickets get their status automatically changed...I dont want it to touch them because the status is already correct for all 15 tickets.
The "right-most column" relevant to the sprint would be that column only in the Scrum board. The right-most column in the Kanban board is not relevant to the sprint.
If the issues are in the right-most column of the Scrum board when you complete the sprint, then the sprint reports will show the issues as "completed" in the sprint. If the issues are in any other column within the scrum board, then the sprint reports will show the issues as "incomplete" in the sprint.
If you move the issues to a status that is not mapped to any column on the board, that could lead to some quirks in the reporting. I tried it with a sprint where I moved a mapped status to the Unmapped Statuses area in the Columns page, and then moved an issue to that Unmapped Status. When I looked at the Sprint Report for that active sprint, it showed the issue as "Removed from Sprint", but it didn't show a reduction in the burndown. Also, when I looked at the issue directly, it still showed that sprint in the Sprints field.
When I completed the sprint I told Jira to move the incomplete issues to the next inactive sprint. When I viewed the issue in the unmapped status I saw that its Sprint field had been updated to that inactive sprint, but I did not actually see the issue on the scrum board because the status was unmapped.
I did not do additional testing to see what would happen if the status was not simply Unmapped, but actually excluded from the board via the board's filter.
I would advise you to set up a test project in a similar fashion, with similar kanban and scrum boards, and thoroughly test out what happens under different circumstances.