Task Structure in Jira

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?

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.

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?

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.  

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.