It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How do story points get completed/ done?

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

 

2 answers

0 votes
nic Community Leader Apr 18, 2015

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?

Thanks!

 

nic Community Leader Apr 19, 2015

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.

Thanks Nic, We will look into that.

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? 

Did you find any resolution to this?

nic Community Leader Aug 22, 2017

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

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 Community Leader Aug 22, 2017

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)

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 Community Leader Aug 22, 2017 • edited

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.

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.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Software

Early Access: If you use Jenkins and Jira Software Cloud, you need to read this!

The Jira Software Cloud Team has been busy working on a simple, secure, and reliable way to integrate your build and deployment information from Jenkins with Jira Software Cloud. This means you don’t...

704 views 0 11
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you