Directly assigning work to developers instead of letting them choose whatever they want to work on next (from the current iteration) may look like a good idea at first sight.
You know that Jessy is the perfect girl to take on a story about accounting and you know she will be able to work through the missing parts on her own because she has a good domain knowledge about how accountants work. On the other hand, if you let Kevin take it, it may take twice as long and he will probably interrupt the whole team in order for him to understand all the parts of that story.
Assigning stories to developers may save the team a few hours at first, but this is borrowed time. In essence, you are building a knowledge debt and this debt comes with high interest rates.
By directly assigning stories to developers, you are creating bottlenecks. Jessy is slowly becoming an expert at working on accounting stuff while the rest of the team is stagnating.
Imagine that, at some point in time, the ten next important stories are about accounting. Jessy won't be able to do everything and you will now have to assign most of that work to the rest of the team.
At that point, every mistake that the team should have made over a long period of time will occur and you will think the team is incompetent. When in fact, they never got the chance to make those mistakes over a longer period.
A manager could then decide to assign the accounting work more equitably, but he would now have to keep track of who needs experience in what. The manager also becomes a bottleneck since everyone depends on him to figure out what they should work on next.
Jessy may not want to work on the accounting part of this app, she may want to explore some other parts. By being allowed to explore on her own she is slowly building ownership of the whole software — not just the accounting features — but the software as a whole.
Kevin may want to work on some accounting features even if he is not the best man for the job and he should be able to ask around for help. As Kevin becomes better with accounting stories, he may challenge Jessy on some specific pieces of code and bring some fresh ideas to the table.
If you treat your developers like components of an assembly line who are just there to execute tasks assigned to them, they may become just that or even quit. Instead, take advantage of their brain power, their creativity and their passion. Allow them to accomplish the best work of their life.
If Jessy gets to explore as many parts of the software as she wants, she will become curious, ask questions, come up with ideas and this is where she will cultivate a sense of ownership.
When you encourage discussions and empower the team, you are not only allowing your team to innovate, but you are also creating a great work environment, thus increasing employee retention.
Not only should you not assign stories to developers, you should be encouraging them to experiment and look outside their comfort zone. Everyone wins in this kind of environment as you gain multiple domain experts, you encourage innovative and creative ideas. Developers will feel that they are growing and that they are making a bigger impact to the business — and they really will be.