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

Team effort to develop a story

I don't understand the Jira logic with regards to Stories, sub-tasks, assignee and story points.

If I get it right:

  • A story shall represent a stakeholder/user value that we want to develop and deliver
    • In our case a typical story can be about creating a new visualization/graph in an existing dashboard
    • To complete the story we need to do work in the back end (data) and in the front end (dashboard, UI, visualization)
    • Typically at least two team members are involved in completing the story, a Data Engineer and a Data Analyst
    • To me it would make sense to create at least two sub-tasks, one for the Data Engineer and one for the Data Analyst
    • To be able to understand the capacity of the team members it would be great to see the story points the Data Engineer and the Data Analyst estimates for their part of the story to be completed
  • The Assignee of a Story is supposed to be the driver making sure the Story is completed, but does not have to do all the work her/himself, right?
  • So why is it only possible to get see story points per Assignee of a Story? And not for the assignees of sub-tasks.

I think this is counter productive and does not promote working as a team...

Since this the above does not work in Jira we have created Stories for both back end and front end work, but Stories shall not be used for this, since completing just one of them in a sprint does not bring production value to the stakeholder.

It has also made our sprint reviews in-efficient. Each team member tends to present all the stories he or she has finished and then the next and so on. In the beginning of a sprint review a Data Engineer might describe all his/her back end stories and at the a Data Analyst describes all his/her front end stories.

So one of the back end stories and one of the front end stories actually makes up the values the stakeholder wanted. Not so customer centric.

Ideally I would want only high value Stories in the Backlog and Sprint buckets and I would like to see all the story points per team member to understand if the sprint has a number of story points close to the learned team velocity. (No I don't want to use Tasks linked to Stories, it clutters the backlog/sprints and I want to have the nice swimlanes in the active sprint with the Story on top and the sub-tasks moving through the columns)

1 answer

1 vote
Scott Theus
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Mar 21, 2023

Hi @Peo Olsson

I think I may be able to help with a different way to look at this. At its very base level, Jira is just a tool to track work items. Whether those work items are front end, back end, or both doesn't matter to the tool; they are just things that need to be done by the team.

In an Agile framework like Scrum, those work items are user stories that deliver value to the customer. Again, at the basic level and using your example, a purely Agile user story needs to be complete with both front end and back end for the customer to realize the value. That does not mean that either the front or back end stories do not have value in themselves, but simply that the work item is not usable until both parts are completed. 

As an Agile Coach I recommend  keeping the front and back end work together in one story, especially if the team consist of both front and back end developers. That allows the product owner to know when the full value of the story is ready to be delivered to the customer and ensures that the two parts are delivered together within the sprint. (There are other benefits like cross training between front and back end developers, tracking work items as a whole, etc.)


Jira does not care if a story is front end or back end or both; as long as the team commits to doing the work in the sprint and they are delivered together the result to the customer is the same. 

Likewise, Agile does not proscribe exactly what "value" means; it could be argued that a front end story delivers value to the customer, but that value is not available until the back end story is also delivered. 

There are use cases where back end and front end work is written as two (or more) separate stories, depending upon the needs of the team, the product, and the org.   In these cases it would be a best practice to structure your sprints and the team so that the front end and back end stories can be completed together, but understanding that this is not always possible then the product owner should be setting the expectations with the customer and other stakeholders for the overall timing of when features are going to be available. After all, a feature is often made up of several stories developed over the course of several sprints and placed behind feature toggles until all the stories for the feature's MVP are ready for the customer to use. 

That is a very long way to say that if your organization needs to break a work item into front end and back end development stories there is nothing in Jira that prevents you from doing so.

Hope this helps, 


Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events