Should all user stories must be completed within one sprint?

[hee]

Hi, I'm a scrum master on a team using Scrum.

I've been studying Agile recently, and since our team uses Scrum, I'm interested in how to make user stories.

Our team is divided into server engineers and client engineers.

Although the API details are determined first, since client development is largely dependent on the server, server development tasks are performed first (in previous sprint) to avoid bottlenecks.

e.g. (User Story) Customer can login into our service.

In this case, we separate user story into 2 user stories - because Jira doesn't allow user stories to be in 2 sprints.
- [TICKET-1] [for BE] Customer can login into our service -> Will be proceed in Sprint#1
- [TICKET-2] [for FE] Customer can login into our service -> Will be proceed in Sprint#2

I know that user story must be completed within one sprint.
But in this case, 1 User Story spans two sprints.

We cannot increate the length of each sprint, and to accelerate backend engineer's performance is too difficult for us.

So I thought divide one user story into two user stories can solve this problem.
Now "Target" are divided into external and internal customers, like this:
- [TICKET-1] Client Engineers can use login API -> Will be proceed in Sprint#1
- [TICKET-2] Customer can login into our service -> Will be proceed in Sprint#2

But this still have several problems:

1. TICKET-1 does not appear to be a user story; I think this seems to be "Task", not "User story".

2. I heard that definition of user story should be written solely for external customers, not internal customers.

3. It is difficult to clearly define that TICKET-1 and TICKET-2 has same goal "Customer can login into our service".

...I couldn't find any further improvements here, so I'm asking here.

Can't we write user stories if we are not a full-stack engineer?
Is any good way to use user stories in this case?

I've been thinking about it for almost a year, and I still don't know the answer.
I would really appreciate it if you could tell us about your experience. Thank you.

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

The short and simple answer is that if you've got two teams dealing with an issue, then you are not doing Scrum.  A broad and simplistic view of a scrum is that an issue goes into a sprint, the multifunctional team deals with it and hence delivers something the end-user can see as a new thing that does more than the previous iteration.  If a story is not complete in a sprint, your team has failed to deliver and needs to examine why.

For your way of working though, I would stop concentrating on the individual issues and look more at the teams.  This is a bit easier to explain with an example.

Imagine you have a workflow that describes an ideal process for any new issues (don't worry about the "no, go back a step" stuff here):

New -> server engineering -> ready for client dev -> client engineering -> done

Create boards for each team.  Boards are supposed to represent a team's work, although there's no harm in creating extra ones to get a different viewpoint.

Your server engineers team should have a board with columns mapped to status:

• To-do: New
• In progress: server engineering
• Done: ready for client dev,  client engineering and done

Your client engineers then need a board with:

• To-do: ready for client dev
• In progress: client engineering 
• Done: done

This decouples your two teams and allows them to run their own sprints and work with one single issue, with the same goal and story.

[hee]

@Nic Brough -Adaptavist-Thank you for answering my question!

I did not understand this part of your answer:
This decouples your two teams and allows them to run their own sprints and work with one single issue, with the same goal and story.

Does "goal and story" in your answer means Sprint goal and User story?
I heard sprint goals and user stories does not shared within other teams.

And I'm really sorry that I left out an important things,
since our team is a squad, so server engineer and client engineers are working in same team.
(1 Product Owner, 1 Designer, 1 Data analyst, 1 Server engineer, 1 Quality tester and 2 Client engineers in our squad)

Is your suggestion(create boards for server engineer and client engineers) still valid?

And will it be difficult for my team to use user stories?

I have a lot of questions, but I would appreciate your answers :)

[Nic Brough -Adaptavist-]

Sorry, I should have said "same issue goal and story".

But you've explained that you are one team now, so having two boards is not the answer.  A board is supposed to be for a single team.

Your problem is that you cannot complete a story within a sprint, so yes, absolutely the right thing to do is to break it up into smaller stories.

The best thing to do would be to take the main story as described by the requestor as the last story that needs to be done on the task, and create one or more new stories that are linked to it as blockers or dependencies.  The smaller new stories should be do-able within a sprint, and that enables you to take the main story into the next sprint after they are all complete.  On the main story, reduce the estimate by the estimates you put on the new dependent issues.

[hee]

I understand thank you!
Shall I ask just one more question?

Does this match your stated intentions?
-> Break one story into 2 stories, and one of the "target user" of user story is Client engineer.

e.g)

original ticket:
[TICKET-1] Customer can login into our service

separated tickets:
[TICKET-2] Client Engineers can use login API
[TICKET-3] Customer can login into our service (is blocked by TICKET-2)

The reason I ask this question is because I've heard that user stories should deliver value to 'customers', but I don't know if it's okay to treat 'client engineers' as 'customers' too.

[TICKET-2] independent and technically deployable, but I wonder if it can be treated as a 'user story' because it doesn't feel like it delivers value to the 'customer'.
In this case, should [TICKET-2] be treated as a 'task' rather than a 'user story'?

[Nic Brough -Adaptavist-]

Yes, you are absolutely right.

The ideal in Scrum is that every sprint delivers value to customers, not each story.  In real life, you are going to end up with issues that do not deliver anything to the customer.  

The main reason for that is exactly what you have described - you have a story which you have broken down so that it can be planned into sprints properly.

I would indeed raise the dependencies 2 and 3 as tasks rather than stories, and flag them as dependencies for ticket-1, it is a better word to describe what they are.  I think "task" is a better word for "stuff we need to do that the customer has not described, but needs doing so we can complete something that they have asked for"

I would also do what you suggest with your client engineers: treat them as customers, too.  They need your team to do some work before they can do their piece of work, even if they're part of the team, they're acting as customers here.

The only thing I would add is that it is important to make all of this clear to the customer.  Sometimes, you're going to have sprints that deliver nothing of any visible change to the original customer, but it's important that you can explain to them that "sprint 7 is going to deliver the ability for client engineers to use the login API, so that they can build you the login in sprint 8"