Should all team members be assigned user stories?

Question

This is a very basic question but I don't see any answers on it yet.

Scenario: We did sprint planning and I noticed some one saying

Not all developers have a task to do. We need to add more tasks so that everybody has work.

I have a problem with that for the following reasons:

1. If our velocity is 60 and you add tasks so that everybody has work you may end up with going way over your average velocity, you are setting yourself up for failure.
2. With agile I would rather promote peer programming instead of everybody doing a task and when the sprint ends we have more tasks that is in development than those that are closed.

Idea Maybe stories should be split so that each team member has a task but in all they are working towards the same goal.

Question: Do you give each team member a user story or do you plan according to the velocity and then the team should work together to deliver a potentially releasable sprint rather than a half completed sprint?

Do you have experience in this and how did you deal with it?

Answer 1

Question: Do you give each team member a user story

A see an anti-pattern here. As a Scrum Master, you don't have to assign stories & tasks to team members. It's their job (under your servant leadership) to self organize and pick sprint backlog items. They can use swarming techniques, they can pair program, they can breakdown technical tasks into granular level to work as a team and deliver their commitment - the Sprint.

plan according to the velocity and then the team should work together to deliver a potentially releasable sprint rather than a half completed sprint?

This is better. Remember that the estimates are a guess after all. So velocity is a more accurate measure against which you can plan your upcoming sprint. Don't fall into the trap of ensuring that everyone is 100% utilized. Instead focus on 100% optimization. In team retrospective meetings, the current velocity can also come under discussion. Does the team think that their velocity is low? Maybe they have become efficient enough so that the velocity can be go up by planning for more stories in the next sprint.

---

On a related note, there are two views on assigning tasks to individual team members during the sprint planning meeting. One argument is to have names against all sprint tasks when you end the sprint planning meeting. The second point of view is, task assignment should not be done in the sprint planning meeting. Let the team pick tasks as they go, with sprint completion as a common objective.

Mike Cohn mentions in his blog post:

If a team walks out of sprint planning with a name next to every task, individual accountability will definitely be increased. I will feel more responsibility to finish the tasks with my name or initials next to them. And you will feel the same for those with yours. But, this will come at the expense of team accountability.

My recommendation is that a team should leave sprint planning without having put names on tasks. Following a real-time sign-up strategy will allow more flexibility during the sprint.

More on this:

• https://blog.backlogapp.io/why-not-to-assign-backlog-items-during-sprint-planning-7b5bdb7a047
• https://www.planningpoker.com/blog/should-your-team-claim-tasks-in-sprint-planning/
• https://softwareengineering.stackexchange.com/questions/97535/who-should-define-assign-implement-and-follow-the-tasks-in-scrum

Answer 2

Firstly we don't give or assign a story to team member. They should pick it as they are self organized.

Commitment for the sprint (how much can we do) is decided based on team's velocity.

It is the team's responsibility to ensure that what is committed for the sprint is met collectively. That does not mean that one story is worked by all, but if a team member is stuck, this is made transparent in the daily scrum or even earlier. The team pips in as required and ensures that the problem is resolved and story completed.