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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
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  


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events