Question: Let's suppose the development team is planning the next Sprint. What does it technically mean that a User Story is added to the Sprint Backlog? Is it assigned to a developer or to the whole team? (If it's assigned to the whole development team, then how do we do this in Jira?)

Answer: 
When the team plans a sprint, they pull product backlog items or user stories from the top of the backlog and into their sprint. The stories they selected to do that sprint now form the "[sprint backlog](https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)".

Now, **concerning assignment of these stories... it depends**.

As part of the planning, developers also can decide who does what. Jake could assign himself Story 1, Jane could assign herself Story 2, and so on. That's a visual indicator of who does what work, but it's not actually mandatory. **The team owns all of the stories, no matter the individual who works on them**.

For example, I worked in a team where we didn't assign the stories. Almost all of us were full stack developers so we just took stories and worked on them as we became available. We knew who was working on what because we were in the same office, we communicated when taking new stuff to work on, and we synchronized and planned our work during the daily. So stories were moving from TODO to IN PROGRESS without being assigned to anyone. Jira has no problem doing that. The story just shows up as UNASSIGNED in Jira.

So it depends on what you want to do. If you find the information useful to see, you can assign a story. If not, the team will still know how to organize themselves and do the work.
The November 2020 Scrum Guide says:

> 
> The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
> 
> 
> 

In this definition, the unit of work is not defined. That is, the Product Backlog Item may not be the unit of work that is Done by one or more members of the Development Team.

In my experience, most teams do one of two things. One common approach is for the Product Backlog Items to be allocated to one or more members of the Development Team. The team itself decides how this work is allocated, but the sign of a self-organizing team is frequently self-assignment and a pull-based approach. Another approach is that a team decomposes the Product Backlog Items into subtasks and those subtasks are allocated to members of the Development Team. Again, self-assignment and pulling work indicate a self-organizing team.

The exact "assignment" depends on the practices of the team and the tooling. Practices such as pair programming and mob programming have two or more people working on a single unit of work, so there isn't a single assignee. However, even in these cases, a team may opt to decide on a single person to "own" the work and they would be identified as the assignee. The tooling also matters since tools may have limitations on who is allowed to be an assignee. For example, Jira only allows one person in the assignee field, so teams may leave this blank, create team accounts, or use custom fields as a workaround.

Specifically, in Jira, you have several options:

* Add a "Team" custom field. This is generally helpful in an environment with multiple teams working on one Product Backlog but can be useful to help identify which team has taken on responsibility for the work.
* Add a "Paired" custom field. The default Assignee field can be used if there is a single owner while the new custom field can be a list of users who are pairing or mobbing on the work.
* Do nothing. If you're using the Scrum configuration with Sprints, you don't need an assignee to bring items into Sprints or move things along a Sprint Board.