Question: In the beginning of the Sprint we assign various items to each developers. Some developers may work on more than one item at a time, however when they work on the item they typically `Start Progress` which puts the item in the `In Progress` state.

In the concept of Scrum or Kanban, does anyone know negative consequences of having more than one item in `In Progress` state per developer?

Answer: 
Having more than 1 item In Progress for a single person will *kill* productivity. Multitasking is horrible for getting things done quickly and/or well. See [Agile team full of part time developers](https://pm.stackexchange.com/questions/21286/agile-team-full-of-part-time-developers/21287#21287) for more details.

It might seem like a good idea to pull in new work if something gets roadblocked, however this is, in essence, optimizing for utilization (making sure everyone always has work to do) rather than for flow (making sure lead time, the amount of time issues spend 'In Progress', is as low as possible). Which is not efficient. See the [100% Utilization Myth](https://dzone.com/articles/100-utilization-myth) for more information. In this situation, it's better for the Team to focus on removing roadblocks as quickly as possible, rather than leaving multiple tasks partially-finished and bringing about inefficiencies from multi-tasking and busy dependencies.

Also of note:

> 
> In the beginning of the Sprint we assign various JIRA items to each developers.
> 
> 
> 

Scrum works best as a *pull* model, rather than as a push model. Meaning management (whether Scrum Master, Product Owner, or others) leave tasks in the 'TODO' column, and developers assign tasks to *themselves* once they finish what they're currently working on.
The main downside of having more than one issue in progress is a loss of focus (which results in loss of quality and efficiency). Another problem is that when people start to claim 'their' stories, the sense of collective ownership and team responsibility can get lost. From there it's just a small step to a team where Person X always does task Y, and that's not what you'd want in Scrum.

In general we strive for one story per person (and nobody is allowed to claim stories in ToDo until he can actually start), but there are circumstances when we allow (and even stimulate) someone to take up a few stories at the same time. Most of the time this happens when various stories share a common piece of code; from a technical perspective it makes sense to handle that part all at once.