Complications of having multiple transitions back to To Do?

Alexandra Doyle June 8, 2017

We run dev work, deployments and two rounds of QA in a single project. Each user story has a single ticket that moves thru statuses for each "phase" (Dev, Merge QA1 Environment, QA Round 1, Merge QA2 Environment, QA Round 2, Merge UAT). I know, subtasks would be the most efficent way to do this, but long story short, politics and pushback. 

The newest issue is time tracking. Now automatic time tracking is required because manually posting hours spent on tickets is too much wasted time/effort. Addon installed. Time tracking auto starts when a user is assigned and then auto stops when the assignee changes OR the ticket moves out of an In Progress status. 

Because of the merge statuses where work is not really being done, the ticket is just pending a deployment, and because of assignment buckets (ready for QA) when moving from one phase to the next, there are some areas where we need the time tracking to stop automatically. The easiest way to do this is to change those transitional statuses to have a "To Do" status type.

What are the risks (both reporting for spring planning and monitoring) to having the ticket transition into a To Do status for these sections? 

For example, workflow would be as follows: To Do-->In Progress-->Review (In Progress status type)-->Merge QA1(To Do status type)-->QA Ready(To Do status type)-->QA1 In Progress (In Progress status type)-->Merge QA2(To Do status type)-->QA2 Ready (To Do status type)-->QA2 In Progress (In Progress status type)-->Merge Prod(To Do status type)-->Done

0 answers

Suggest an answer

Log in or Sign up to answer