You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
I don't understand the Jira logic with regards to Stories, sub-tasks, assignee and story points.
If I get it right:
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)
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,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.