Are User Stories from Sprint Backlog assigned to individual developers?

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 1

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".

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.

Answer 2

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.

Answer 3

It's up to the team to create the sprint backlog based on the backlog items chosen by the Product Owner. Some teams do use sprint planning to allocate at least some items to individual developers, other teams adopt a "pull system", meaning items are not pre-allocated and it's up to each individual to pick up items off the backlog when they have the capacity to do so.

In Jira, if you want an issue to be worked on by more than one person then the easiest way is to have each developer create their own separate sub-tasks assigned to themselves.

Answer 4

A "story" does not necessarily correspond 1:1 with a development task. You need to determine from the story what needs to be done, and by whom, in order to complete it.

Answer 5

Since you're asking about user stories, not tasks: A user story usually consists of several tasks that can be tackled by different team members, sometimes even different crafts. That means that, while you can certainly assign team members to any of the story's tasks (though you don't have to do that, either), the story is more likely to be owned by the team as a whole.

There can be exceptions, of course. For example, you could have a user story entirely made up of tasks that can only be solved by a specialist in the team, so it might make sense to assign the story to this person to make that visible.

Answer 6

We have component ownership (there is a business lead and development lead for each).

We personally didn't automate the assignment of the ticket to DEV lead, but automated to assign to business lead according to the component (first component mentioned in the ticket - responsible assignee - it's set up in the Project's settings on JIRA).

Once the story is ready for development, business lead/ regular analyst re-assigns it to the proper DEV lead (in order to get rid of code ownership there is a rotation of DEV leads, so we refer to a specific table on confluence - it's updated by project manager).

It's more relevant for us, because business lead always knows the proper person, as business lead does usually collaborate with DEV lead of the component on LOE estimation, proposals to the Customer, etc.

Seems like a little overhead, but irl it's not.

Answer 7

As Bogdan already mentioned: "the team owns all of the stories", & the team should also owns the way to get those stories done. I mean pre-assigning to individual member or pulling when sprint progress are both fine.

One practice in my team is we always have individual owner at story level even when multiple members involve. The owner will be in charge (in front of the team) to facilitate all sub-tasks & relevant members to get the whole story done.