What's best approach to breaking up stories that span sprints: separate stories or sub-tasks?

[Cash Coyne]

I have a question that one of you may give me guidance on.

We're discussing weather it's better to have a story with sub-tasks like this:
Story: As a user I want to login to the app
Sub-Task 1: Design a login screen (US person does this)
Sub-Task 2: Write the code for a login screen (Python Dev does this)
Sub-Task 3: Test the login screen (QA person does this)

This way the story isn't "done" until all sub-tasks are done, but that could cause the story to take more than one sprint, particularly when there is limited availability for one type of resource (ie: Python Dev in this example)

And then how to handle it thru multiple sprints?

Or to have 3 separate stories:
Story 1: Login Screen - Design a login screen (US person does this)
Story 2: Login Screen - Write the code for a login screen (Python Dev does this)
Story 3: Login Screen - Test the login screen (QA person does this)

This way each story can be done in a sprint, but the stories could be in different sprints.  And I can't use Epics because there is already a parent epic for this, and Jira has only so many levels.

[Bill Sheboy]

Hi @Cash Coyne 

I would not recommend splitting down the request in either of those ways, particularly with the intention of work spanning multiple sprints.

Instead I recommend the product owner and team meet with your scrum master / agile coach and learn ways to split requests down into smaller, valuable, releasable chunks that can be completed in a single sprint.  And perhaps to learn if there are opportunities to have fewer silos in work type / skill areas, leading the team to swarm and complete the smaller items together.

Kind regards,
Bill

[Charlie Misonne]

In theory epics are for multiple user stories. So you shouldn't use this to group design, development and testing of a single US.

Personally I think design and testing should be part of the US (especially testing). Testing a new feature is often part of the definition of done.
Sub-tasks will be annoying because they are expected to be completed within the same sprint. If you already know you can't achieve that you can either think about resource availability and how to improve on that. It won't be easy of course.
Maybe you need longer sprints?

But if you just want to solve your issue "Jira-wise" and keep a connection between the 3 items I would just link them together. Logically the design comes before coding and coding before testing so you can use an issue type link indicating this order.

You can also look at Jira's Advanced Roadmaps where you are allowed to create extra levels in the hierarchy.