How to deal with team members with limited skill sets?

What about how to deal with team members with abundant skill sets?

My first reaction to your description was "there are a lot of things here that have nothing to do with the Development Team so why is all that stuff in the Product Backlog?".  But won't go into that one at this point. 

The way I have approached this scenario in the past is to coach the team on the benefit of expanding their skill sets by pairing with someone working on something outside of their specialty.  It doesn't always help to frame it in the "it will benefit the team" message.  Sometimes you have to resort to "it will make you much more marketable should you choose to leave".  That last message is usually delivered in private but I have resorted to it.  If they see this as a benefit, they will be much more likely to find "work" to do when they have nothing specific to their silo of skills. 

You might also introduce them to the "medical emergency theory".  "What happens if Bob's appendix bursts on his way home? Is there any way that his work can be picked up and finished while he recovers in the hospital?" Yeah, it is morbid but believe it or not, something very similar happened at a company where a friend of mine works and they actually found themselves in a very bad situation because Bob had all of the knowledge on something that was critical to their success. 

This leads to a situation where some (usually developers) are running out of things to do. Not every developer gets a dedicated work item for a sprint. 

In Scrum reality (and for that matter a lot of the Agile frameworks) that statement is true by design.  This isn't about a group of individuals doing work, it is about a team of people working together in order to reach a goal. In your scenario each individual is saying "I have nothing to do so I'm going to let the rest of the team try to complete our goal while I find something else to do."  In that example the single individual is making the entire team responsible for finishing that piece of work the individual pulls in while they are also trying to finish everything else that they had already forecast. Focus on that with the team and help them understand that while individual effort is usually needed it should only be done in relation to the work being done by the entire team with the intention being to help the team accomplish the goals that have already set. 

Some are non-developers working with the customer and grooming the requirements for the team.

Are they actually members of the Development Team then? In other words, is their work required not just for refinement, but for a feature-complete increment to be created by the end of the Sprint?

Not everyone is even capable of working with every item in the backlog.

Would that truly be necessary, in order to avoid the bottlenecks which are evident, and to smooth flow? Might the situation be improved if each Development Team member cross-skilled in just one other discipline, and assisted when needed?

This leads to a situation where some (usually developers) are running out of things to do. 

Just my opinion, but such situations scream out to me as opportunities for learning and observing.

@Antti, I feel your pain. I've inherited a team similar to that which you describe. In fact, this actually gets at the root of the other post I have recently started: https://www.scrum.org/forum/scrum-forum/30361/what-do-when-sprint-goal-doesnt-demand-skills-all-team-members. You may want to see some discussion in there as it relates. I like the suggestions made above here as well. I myself promote pairing & swarming on stories for sake of knowledge transfer, while acknowledging that this tends to slow things down in the near term in order to speed things up in the long term. This relates to another outstanding question I have out to @Ian in the thread linked above, but perhaps it's better answered in this context because it may shine light on your question "How do you plan sprints with this combination of different work types?" I'm trying to figure out the answer to that question myself. When working with infant Scrum teams composed entirely of specialists, I've found it very difficult to define a common goal that the team can achieve in a single sprint, let alone one of value. I'd also like to hear more from others on whether they have shared the same experiences or not. And if so, does it change the nature of your sprints when your team is in the forming and storming stages? 

I can understand that Daniel's suggestion would probably be the best option but somehow I don't like it anyway (sorry Daniel). I have a developer background and it would not be ok if I would have to start doing more refinement with the customer and less of actual developing. Well, that's more what I'm currently doing (and hate it) but let's not go there either...

One other idea came to my mind from something that Daniel said in the beginning. How about separating these two types as separate teams? Actually, there are even more types as there is also UX stuff which is currently only done by UX designer. I would like to see the UX designer together with the dev team since they have more constant interaction than with the dev and refinement persons. 

In this case, there would be two teams, one for refinements and one for developing stuff based on the stuff from the other team. I think this would work better. Not perhaps an optimal solution, but still better? What do you think?

Another idea I got was more or less about giving up and going more with Kanban style board. The situation is not ideal for that either and it doesn't solve the issue but I think it works around the issue of planning an iteration and problems with capacity and velocity. We could just have different swimlanes for a different type of work and go with that. How do you feel about this solution?

I've found it very difficult to define a common goal that the team can achieve in a single sprint

Just a question, but does your Scrum Team begin their Sprint Goal discussion with what the Product Owner would like to achieve/deliver in the upcoming sprint (from a business value perspective)?

In my opinion, the PO objective should be the focal point of the discussion (Focus), despite any specialized skill sets within the Development Team.

We have a theme for the sprint, but usually, the theme describes only parts of the sprint content. And usually, it's the dev part. It is just because of the nature of the work that is in the sprint. We are now considering to separate these two types to individual teams which might be the best option. 

How about separating these two types as separate teams?

I can understand your temptation, but be careful about exploding a cross-functional team into functional silos. Personally I (and my teams) have seen enough disconnects and failed handoffs in the waterfall world to understand the reason the industry has embraced more cross-functional teams. If your team / company hasn't felt that pain I guess I can see how it could be a less inviting proposition. If you do experiment with that two team approach, you may want to track the number of defects resulting from misunderstandings of requirements / customer needs, and how long it takes to resolve them. 

Another idea I got was more or less about giving up and going more with Kanban style board.

Again I can understand the temptation. In fact, I'm tempted to go this approach with my team right now. I feel like there may be some hybrid of Kanban and Scrum that could work optimally when teams are forming/storming, but I haven't come to any conclusions. For what it's worth, I do think there is a lot of benefit (i.e. increased team performance) that *ultimately* comes from cross-training. I've been fortunate to see it on a couple of my past teams. And I do think common team goals (regardless of sprint boundaries) help drive that. What about asking the team what their secondary interests (and maybe even tertiary) are, and go from there? Also, do you have a "Product Owner"? If not, are any of the non-developers able to assume that role?

@Timothy, I just realized I missed your question that was in response to my comment. More often than not, we do start out with the PO's priorities (shaved down to the smallest common goal we can think of). And the team has a tendency to try for it, only to come up short each time. And it is beginning to wear on morale. Usually the work is weighted heavily toward the skillsets of a couple specialists. They are well intending and pair/swarm with folks for the purpose of cross-training at the start of the sprint. And then halfway through the sprint the team recognizes they are behind, and in order to achieve the sprint goal the specialists need to be left alone so they can carry the team past the finish line. It's not like @Daniel's example with folks in effect saying "I have nothing to do so I'm going to let the rest of the team try to complete our goal while I find something else to do." It's just that the team recognizes that the pairing/swarming is counter-productive toward meeting the sprint goal (albeit productive toward increasing team performance in the long run), and the specialists ask kindly for the others to get out of the way (and perhaps focus on technical debt relevant to their specialty, or operational support, or just learn on their own). I've seen this many times on different teams. Can anyone else here relate? If so, how do you approach this situation?

I see that often and in reality it is correct.  There are times that more than one person working on a problem is inefficient.  But that is not a reason to not swarm.  Swarming does not mean a bunch of people work on a problem.  It means a bunch of people get together to discuss the problem and come up with a way to address it.  If the swarm determines that the most efficient way to address the problem is to let one person go away, ignore everyone else and fix it then the swarm was successful.  However, I coach that even if the swarm results in that situation, there is still benefit to do a "retrospective" with individuals on what happened so that knowledge can be shared.  I will always suggest it occurs after the situation is resolved so that the next time it occurs there is a wider knowledge base to serve the discussions.

One thing I see from your narrative is that if this situation occurs frequently, it seems to me that the knowledge transfer that is occurring isn't being effective.  There should be some level of relief for the specialists where the dependency on them lessens due to more people learning about their specialty.  That would be something I discussed with the team to identify if there is anything that could be done to improve that practice.