Can Kanban Board columns be based on Resolution status?

[Dan Peters]

My project includes 5 sprints.  Sprints 1-4 are "development" sprints (each 3 weeks), where all config, dev, and QA occurs for a given story.  The objective is to close each story in a single sprint.  

However, we perform all User Testing on stories during sprint 5 (which is 5 weeks).  So, while the story is officially "Closed" in JIRA after the "development/QA" sprint (and the story points have been allocated and velocity calculated), we still have activities/statuses related to the story that I'd like to track ... statuses such as Ready for User Testing, In User Testing, Ready For Delivery, then finally closing (again) as Delivered.

First, what are some thoughts on how best to approach this? I HAVE to close the stories at the end of each sprint in order to calculate velocity early (i.e., not wait until after sprint 5).  BUT I want to track these other statuses.

I was thinking about using resolution statuses to track the status of a story after it's closed ... in other words, "re-close" each story as it moves from Ready for User Testing to In User Testing, etc.  While that seems feasible, it seems a little awkward.  Plus, If I do that, I'd like my Kanban Board to show those Resolution statuses as separate columns ... can that be done?

I'm really curious to know how others have solved the problem of stories that really should remain open until a Release occurs ... but have to be closed in order to get an early velocity determination.  Thank you!

[Randy]

To answer your question literally, no you cannot set columns based on resolution status.

You can just setup your workflow as follows (simplified status's for the example):

TODO -> Dev -> QA -> QA Done -> Done

Then you setup two boards.  Dev board will track only the columns TODO, Dev, Done

The QA board will track Done, QA, QA Done

Use the Dev board for your first 4 sprints.  Then use the QA board for your 5th sprint.

--

Now with all of that said, one has to wonder how you're using velocity and how accurate it is in your uses if it doesnt include the QA effort in the calculation.

How do you track dev work that was discovered to be incomplete or incorrect once QA is performed in sprint 5?

How do you track velocity and LOE to project when you will reach your goal for release in sprint 5?

What you are doing is essentially "Iterative Waterfall".

[Dan Peters]

Thanks for your response, Randy.  

To clarify, QA IS contained within our Dev/Config/QA sprints.  It's User Testing (UT or UAT) that we've chosen to hold off on until Sprint 5, so that that effort can be conducted as a single body of work by our business partners rather than performed incrementally.

Our UT work has different resources involved, and will not be counted in velocity.  Only Dev, Config, and QA work stories will be pointed and counted toward velocity.

So, considering that Sprint 5 is UT (and not QA), I assume you're answer still holds:

"Then you setup two boards.  Dev board will track only the columns TODO, Dev, Done

The UT board will track Done, UT, UT Done".

Under that model though, I still have the problem that I'd like to be able to track the status of a story as it goes through UT .... BUT ... the story has already been closed in one of the prior Config/Dev/QA sprints.  Since the story was already closed (it HAD to be so that we could calculate velocity), I can't push it through additional UT statuses.  Which I was considering changing the Resolution from one to the other while the story is closed. (Which like I said seems awkward.)

[Randy]

This is an incorrect assumption:

>  Since the story was already closed (it HAD to be so that we could calculate velocity), I can't push it through additional UT statuses. 

Set resolution and status to your Done state in sprints 1-4.

Then with Sprint 5, leave the resolution and transition starting from "Done" through the UAT steps. 

Are the UAT agents going to be working directly in JIRA with the user stories and transitioning them individually?  If so, then a board makes sense. 

If not, i would just send them a version report of all the stories you completed in sprints 1-4 and address any feedback from sprint 5 as a new issue entirely.  I assume any work discovered in sprint 5 will be going back into a new dev/qa cycle somewhere?

[Dan Peters]

I didn't know about the option of setting the resolution and status to Done then iterating the status through the UAT steps (while still holding the resolution status constant) so that I can see them on a board.

Yes, we would like to track all stories in JIRA right up to Delivery.  So this approach may be exactly what I need. I'll have to play with that. 

Any work discovered in Sprint 5 will be completed in Sprint 5.  For example, if a UAT bug is found, then dev will correct the bug, and re-testing will occur.  But we are not intending to story-point the UAT and bug fix work or use it in our velocity calculations.  We actually lengthened Sprint 5 to account for that additional work.

Just to confirm ... JIRA will allocate the story's points to the sprint at the time when I do what? Move the story to the first workflow status that I have defined as Done?  (In this case, see test story 2 in the first screen shot below.)  

image2016-12-9 19:39:28.png

Or ... are the points allocated the first time the story is closed (in this case, when I move the story to the Closed column).

When I tested the above scenario and moved the story to Development Complete, I wasn't prompted to set a resolution, even though the status was appropriately changed to Done.

[Randy]

Points are allocated to your velocity calculations and sprint report when you "Complete" the sprint.  If you change the story after the sprint closes, the sprint report doesnt update so you'll maintain the velocity calculations you had from sprint 1-4.

What you need to do i believe ( i havent tested this but assume it'll work ) is make sure the final status of stories in sprints 1-4 are marked as a "Done" issue status type (Green in color) and is assigned to the right most column of your sprint board.  Setting the resolution field does not matter but is encouraged to let you use all the other features tied to resolution.

Your burndown charts pull realtime from the current state of the issue so that will change as you reopen tickets in sprint 5 but it shouldnt have an affect on your logged velocity in sprints 1-4.