nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Accepted answers

All comments

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.

Ming Chen_ro2o97

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?

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software