Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage
Highlighted

change task state or create subtasks

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

1 comment

Rachel Wright Community Leader Apr 02, 2018

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

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  

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you