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

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

Avatar

1 badge earned

Collect

Participate in fun challenges

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

Challenges
Coins

Gift kudos to your peers

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

Recognition
Ribbon

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!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,458,136
Community Members
 
Community Events
176
Community Groups

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