How do story points get completed/ done?

[Quoc Nguyen]

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?

Thanks

[Tina Rusnak]

But is it the last column or the Done Status or the Accepted Status that earns the point/burndown? If you map the status of IN PROGRESS to the last column are points awarded? I've heard rumors of this :)

[Nic Brough -Adaptavist-]

Yes.  As we've said above.

[Ming Chen]

We need to give credit for velocity and burndown for stories that are in ready for testing. When ending a sprint, is there a way to give credit even though stories are not in the done column? 

[Deb Barker]

Did you find any resolution to this?

[Nic Brough -Adaptavist-]

I suspect they did - they started using the last column as "done".

[Deb Barker]

While I apprecaite that this "shouldn't" be how things are done, I've seen a bunch of people asking for this feature.

Can Atlassian come to the party on this, rather than playing the Agile idealists?

[Nic Brough -Adaptavist-]

They'll need a different definition of done that remains clear to the end user (I've got a couple of candidates, but I'm uncertain of them.  Most suggestions fail the simplicity test though, including one of mine)

[Deb Barker]

Making green vs yellow configurable per column seems like an easy way forward for this.

Green indicates done, however I understand that it can't be the status green as multiple statuses could exist in one column whose colours don't match.

[Nic Brough -Adaptavist-]

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.

[Deb Barker]

Or you could ignore the status colours entirely, as they don't actually provide any help in this context and just leave the colour as the column attribute.

In which case either drop the colours on status entirely, or don't show them in this UI.

[Nic Brough -Adaptavist-]

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.

[Quoc Nguyen]

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?

Thanks!

[Nic Brough -Adaptavist-]

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.

[Quoc Nguyen]

Thanks Nic, We will look into that.