At my company we are trying to use 3 different boards for one single project. A product owner board, a development board and a QA board. This board has columns that identify different states for each group, a lot of the states are the same though. It will also help us identify the velocity of each group since we all have states we are responsible for and there are states we could care less to see.
We believe that managing the states of all issues is important.
We want to know how story points are set to 'done' or completed. Is this based on the last column of the board and is it based on getting a Done status and resolution in that column?
The issue we are seeing is at the right most column in the Product owner board, the points get into a done state but then once its grabbed from that last column into QA's first column the completion of the points go back to 0 points completed, which is wrong because they completed the points.
Does anyone know why this happening?
The "done" column is the end state for the issues, and for story points to be considered done, yes, the cards need to be in the done column.
Your QA people are moving things out of "done" into a state where they are not done, so the story points cannot be complete any more, you're deliberately stating that they are no longer done.
I see, thanks for the reply.
The reason why we have it set up like this is because we consider 'done' to be when the PO has accepted it, but just because the PO accepted it doesnt mean QA has stopped testing it. Our PO accepts it after its been delivered by dev, yet however QA will still needs to run regression in a staging env against it once its been merged for a release candidate.
Dev-PO accept-merge-qa test RC in stage-release-finished!
We dont want 'done' to be in the qa flow because dev has already delivered and po has already accepted yet QA still needs to run more complex testing. I could see qa and dev being pulled into same state and then it delivers to PO for acceptance but after that how do you track the flow of items being merged, code reviewed, and released all the way through to Production?
You need to make a black-and-white decision about when an issue is "done". It's either done, or it is not, it can't be done at the same time as not done (unless you've got quantum computers and quantum human processes) It does sound like you might want to split this up - an issue is done when it reaches a certain point in the flow, but it has sub-tasks or linked issues that may still need to be completed independently.
That's similar to one of my candidates, although I think yours is better.
I suspect it would not be hard to code for "this column has green status in it, do not allow non-green status to be added", plus blocking changing colours from green to other in the status maintenance.
...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....
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