I have a problem with stories that never dissapear from the sprints even if they are closed (in fact, these stories appear as "closed in sprint1", "closed in sprint 2", etc.) I'm using two different boards to manage a scrum team:
1.- Dev team board (includes only the needed columns/status for developers)
2.- Complete team board (includes status for both development and qa people)
The DevTeamBoard does not contain CLOSED status (in the columns configuration), but the CompleteTeamBoard does contain CLOSED status and some other additional status used for QA, which are not visible in DevTeamBoard.
Problem description: it seems that, when I finish a sprint using the DevTeamBoard, stories are being moved to the next sprint, even if the status of the issues is CLOSED (you only see it after you start the next/new sprint) Also, when closing the sprint, the pop-up states "XX issues were not closed and will be moved to the top of the backlog" (which is not true, as stories are closed, but they are not visible because CLOSED status is not assigned to any column)
My hypothesis is that, as CLOSED status does not exist in DevTeamBoard, even if the stories are CLOSED, they are not "completely marked as CLOSED" and hence, they appear in the next sprint again and again.
The problem dissapears if I add CLOSED status to DevTeamBoard, or if I use CompleteTeamBoard to close sprints, but this behaviour is completely crazy. It does not matter if you can see stories or not, if they are closed they should be not visible any more no matter the board, and for sure not visible in next sprints. The board using for finishing the sprint should not change the result, but it does.
I'm using JIRA v6.1.6
Any help will be much appreciated,
Thanks for the fuller explanation.
You are correct the method for restricting the permissions can be solved as follows.
You may be wondering why I am suggesting that the boards get extra columns - this is because I believe all members of the team should be aware of what is committed for the sprint and its likely impact on them. So for example the QA board need to have visibility of what is with both the Product and Development Teams so they can recognise when something is going to be a blocker. Not having visibility of what is with the other teams may lead to starvation if a team at a particular point in the development process.
Be aware this is just one approach to working with multiple teams across a sprint and it fails fairly spectacularly when issues are not completed for the whole process. An alternative to consider breaking the team tasks down into the deliverables of the Sprint. Again there are different options on how to do this but it gives you a more granular view of the process and can often be simplified to
"To do" - "In Progress" - "Done"
with each team having visibility of their queue of actions. The challenge is how to represent the dependencies between the tasks so that development does not start till Product is complete and QA after Dev...
I hope this helps with options for your team.
You are right in your assumption that it relates to the Closed column not being visible on the Dev Team board. Which raises the question of how do you indicate an issue is Closed when working on the Dev Team board. Remember that JIRA assumes the right-most column is your Definition of Done and so when you close a sprint on the Dev Team Board what resolution do these issues have that are carried over - I am expecting it to be unresolved as it has not been through a resolve issue transition.
I would map all your later stages to a right most column (Dev Complete) and set conditions for the transition to only allow developers to indicate that their work is done. What is the next step after a developer completes?
Remember that the status of the ticket behind the Agile board will drive the behaviour of the sprint closure. So whilst something may have completed the Developer work if it does not have a resolution it will not be considered complete and this is where I suspect you are seeing the behaviour issues that you are reporting.
A quick check would be to look at what happens if you close the Sprint in the Complete Team Board in advance of closing the Sprint in the Dev Team Board? Do any items come across in to the next sprint that you did not expect?
Hope this helps.
Hi Phill, thanks a lot for your quick response.
Here's some additional information: in current scenario Developers set stories to "Development DONE" (the right column of DevTeamBoard), wich is the status used for "Ready for QA" column in the CompleteTeamBoard, then QA team transitions the issues to the CLOSED status (in the CompleteBoard only)
I can include all final statuses in the right column of DevTeamBoard, but selecting the right status when dragging&droppnig an issue becomes more complicated when there are so many choices (I'm not able to configure/restrict those options, I guess it's a problem of permissions)
Closing the sprint in the CompleteTeamBoard solves the issue (once it's colsed in that board, it's closed in all other boards), but it makes no sense to me to inherit CLOSED issues even if the status is not visible in the DevTeamBoard. Also, those CLOSED issues are shown only after the new ActiveSprint is started, not after finishing the sprint, which is quite a strange behaviour.
My idea behind this boards distribution is to have each team only with the needed columns&status, working as a waterfall mechanism where previous team feeds the first column of next team and so on. This way each team focuses in its columns/status, and does not have to see the full panel (or all the other statuses concentrated in the right column)
With current behaviour I'm oblied to use the CompleteBoard to finish sprints, which is not such a big problem now that I know where the problem is (I did report only a simplified view of my real problem)
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
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