Can Kanban Board columns be based on Resolution status?

Question

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!

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

Randy_dyxb6i · Answer

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.

Dan Peters · Answer

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_dyxb6i · Answer

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?