change task state or create subtasks

[Nour Eldin Arafa]

I manage a scrum project and want to put a methodology for the path that the task move on it from development to code review then test then bug fixing then retest then ready for deployment and then deployment . I have two choices the first is to make one task and change the workflow to be suitable to manage it by adding code review and retest transitions and states to the default work flow of jira , the second choice is to create subtasks from the parent task such as development subtask , test subtask and so on and make dependences between subtasks so for example test can't begins before development subtask state be (done) and when task is on testing if there are bugs descovered and will be fixed the sub task of development will reopened and the subtask of test will be stop while the parent task state still (test) . what's is the best choice to trace work and to manage the task so I can know the source of delay in task and in the same time faceliftes the workflow between team members

[Nour Eldin Arafa]

Hi @Rachel Wright

Thanks very much for your opinion . it is actually the right choice that i used and it provides a flexibility  between all state of task because some times we do some states in parallel as create test cases and development so subtasks is more suitable in the real life . thanks very much again and wish you all the best  

[Rachel Wright]

Hi @Nour Eldin Arafa,

I'm sure you'll get a lot of opinions here on which is method is "best."  My personal opinion is that the method that facilitates the simplest workflow (your idea #2, with sub-tasks representing all the "stuff" to do) is best because it allows the workflow to remain flexible.  It will let the workflow be used by other teams (even non-dev teams) that maybe don't have a code review step, for example.  

We made the mistake of trying to add every possible "step" to a workflow and in order to accommodate everyone and every possible path, it ballooned to over 20 statuses.  I can't say enough just how much I regret that we built this!  It was such a bad user experience.  Hopefully you can avoid it!

Also, I always recommend only adding statuses to a workflow that you'll actually query for and report on!  Had we followed this rule, we would have seen that about 15 of the statuses were not valuable.

Hope this helps,

Rachel Wright