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!


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
Community Members
Community Events
Community Groups

Subtasks or Statuses?

I'm a new Jira project manager of team managed project using a scrum board. The team develops code to be used for dashboard report content and there are multiple tasks performed by different team members throughout the process .  I'm new to Jira and trying to determine the best way to manage our workflow: 1) move the issue through statuses representing the various steps of the process - I.e. Requirements, logic, Review, Code, UAT, Deploy, etc.  or 2) use a subtask for every step and move those through basic statuses I.e. Pending, In progress, Deploy to Prod, Complete.    This sounds like it would have the best functionality for customizing the workflows and handing off the tasks from one person to the next, reassigning ownership, etc. I'm leaning towards the latter and considering creating issues by cloning from an issue designed to work like a template. 

Does this sound like the best option or would anyone have advice or input to offer?

2 answers


This is a concept that depends heavily on how the team's business rules work.

When we talk about issue statuses, we talk about phases that the issue goes through until it reaches its end point. Changing the statuses to use sub-tasks can generate a huge wave of sub-tasks that where using by status, the action would just be to move or change a value.

See the subtask concept as:

I need to create a template for a website;
In my issue, I'm in the template creation phase;
Then I can create sub-tasks to map the creation of this template.
Issue status: In template creation
Sub-task: program template css;
Sub-task: template html program;

After the sub-tasks are completed, you can move the issue to "In template validation", for example.

You can control your development by general phases and distribute sub-tasks into small tasks.

It is a better way to manage than changing the status issue and assigning another person to each new phase of it. It becomes a very manual management that sometimes deprives you of an action value that someone else did, because everything is in the same issue and not aligned in sub-tasks

0 votes

Status is definitely the way to do this.

"move the issue through statuses representing the various steps of the process " is exactly what workflows are for!

Sub-tasks are a way to break up a story into pieces, either for simplicity, or to represent distinct parts of a story, or to allocate bits of it to different people.  They can have their own workflow and fields, separate from the story, but they are still just a part of their owning story.  They don't represent your development process.

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events