Skip to main content

Task Structure in Jira

Last post 04:14 pm June 22, 2023 by Ian Mitchell
5 replies
09:44 am June 21, 2023

Hello everyone, 

I have a very rookie question regarding the structure of tasks in Jira. 

Currently, in our company:

1) we create an Epic (for example : Login)

2) We create user stories: "[Backend] Create Login" and " [Frontend] Create Login"

3) Inside these user stories we create subtasks for 1. Development , 2. Code Review , 3 Deploy & Merge & QA Testing 

How do you structure your tasks in our company? Do you create subtasks or do you create user stories for development, code review, QA testing and etc.? 


11:36 am June 22, 2023

Scrum is all about delivering Value from each Sprint. 

When structuring the Product Backlog it is important to have transparency about the Value the PBIs are bearing.

In your example, it looks like the Value is on the Epics level since the User Stories do not carry the Value by themselves. There is no value to the user/customer in delivering the Backend without the Frontend.

Thus there is a risk that the stakeholder will be misled about the value delivered.

So, your structure of the Backlog might be OK, but it has to be very clear to everybody where is the Value and what actually needs to be measured in terms of delivered value.

Another approach would be to have User Stories representing the Value by themselves, so both Backend and Frontend are included. Further, the developers might plan the work in sub-task such as backend development, frontend development, integration, testing etc...

Any particular reason why you split User Stories for the Backend and Frontend?





12:28 pm June 22, 2023

I agree with Jacek, Login would be the user story because there is no value in a front end or backend story by themselves. In addition, if all your subtasks are the same for every story, I would get rid of subtasks and make them workflow columns instead (Dev, Code Review, etc.). Then the story would flow through the columns to Done.

01:10 pm June 22, 2023

Hi Peter. One question to clarify-are you asking the advice about how to organize Product backlog and Sprint backlog in the best way, or you are simply having trouble with often stubborn Jira interface and are not sure how to set up PBI files(which are called issues in some version of Jira) in the file so they would accurately represent your established vision of the Product backlog?


04:06 pm June 22, 2023

I'm in agreement with everyone, including @Nicholas because Jira is not the most intuitive product at times. It started as a ticketing system for help desks and is still used for that in many places so the structures it provides can be somewhat rigid. 

In any tool I suggest simplicity is best.  Tools that have the ability to generate views with workflows are great for showing the transition of items from idea to delivery.  The subtasks you listed are actually workflow and not tasks.  I also advocate that the item that is transitioned across the workflow be related to either specific work or value with preference towards the value.  Most people outside of the Developers will not understand something like "build structure to pass user credentials" and "hash password using 128-bit encryption key" so they won't understand the value.  However they would understand "encrypt user credentials for secure transmission" and that would need to pass through the workflow of "development", "code review", "test", etc. This method would also give outsiders the ability to see how far it has progressed through the workflow. 

You didn't ask this but I'll give it to you for free.  Do not distinguish between Bugs, Stories, Tasks at the highest level.  Pick one item type and use it for everything.  Why?  Because if you have bug and story items in your Product Backlog there will be a tendency to treat them differently. It's human nature to want to treat different types in the same list in different ways.  But if everything in the list is the same type, it is easier to treat them all in the same manner.  This will prevent you from trying to decide the workflow for a bug/defect versus the workflow for a new feature versus the workflow for an enhancement.  Make everything the same item type, use the same workflow and rules on all of it.  After all, all of it is something that needs to be done in order to improve the product.  

04:14 pm June 22, 2023

How do you structure your tasks in our company? Do you create subtasks or do you create user stories for development, code review, QA testing and etc.? 

A user story is a placeholder for a conversation about a potential requirement, so it is unlikely to be a task at such a technical level.

The Developers'  technical plan ought to ensure that the Sprint Goal is met by providing at least one Done Increment of work that Sprint. It does not necessarily relate to, or further decompose, any user stories at all.

Whether Jira plays nicely with this is another matter. The tools which teams use often constrain their thinking.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.