Having MORE than one COLUMN in KANBAN as DONE Edited

[Diogo SPDO]

Having MORE than one COLUMN in KANBAN as DONE

I am trying to have as "DONE" (for sprint metrics) all issues that are in any of the 3 last columns in Kanban.

I am having challenge here because it only allows me to have one column with Status: done, like in image below

Is there any other way I could accomplish this ?

[Jack]

this is not possible. only the last column is consider Done for scrum

[Bill Sheboy]

Hi @Diogo SPDO  -- Welcome to the Atlassian Community!

What problem are you trying to solve by having multiple columns (workflow steps) mean "done" on a board?

As Jack noted, Scrum teams have one meaning for "done"; otherwise teams and stakeholders have confusion and less transparency about the completion/readiness of features.

Best  regards,

Bill

[Diogo SPDO]

Thanks for the responses Bill and Jack,

Let me explain my challenge so maybe you could point me in the right direction with other solution:

In my KANBAN, the first 3 columns stages for development, and the last 3 are for testing stages. I don't want the dev team to be penalised on burndown chart because the test team took long on their tasks. Get it ?

I would like to cont in burndown chart as "DONE", after the third column (in any other after the third column)

Let me know if I got you more confused or clear ? lol

[Bill Sheboy]

Hi @Diogo SPDO 

Of note, please try to respond in the same thread rather than creating a new answer.  That will help others in the community when trying to use this post as a source in the future.

Thanks for your clarification about what you are trying to do.  One of the reasons teams use Kanban is to make workflow visible, and thus find opportunities to improve delivering value.  Delivering value requires development and testing with your workflow, so just improving development doesn't necessarily help.  It is a good thing to see when you believe work is piling up ahead of testing, or testing is taking longer than expected.  This can lead to team conversations about how to resolve the mismatch between dev/test capacity, or perhaps dev quality, or... lots of possibilities.

One way to see such issues is using a Cumulative Flow Diagram, rather than a burn chart.  The team can then see:

• the rate of work arrival and completion
• stalls or pile-ups in workflow steps
• the amount of work in progress (WIP) 
• the duration to move work from start to delivery

Please consider having a discussion with your team about how to make the workflow visible and what to track in order to improve.  Thanks!

Best regards,

Bill

[Diogo SPDO]

Sorry Bill, I didn´t intend to create a new question.

Thanks for the clarification, I sure will test those methods of reporting.