Should all user stories must be completed within one sprint?

Question

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- · Answer

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"

hee_hg9aqj · Answer

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- · Answer

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.