Ideally the commitment made each sprint is by the entire team to complete all of the committed work as a team, not simply to complete specific tasks as individuals.
When the commitment is to the entirety of the sprint a team member’s work is not done until all of the committed work is done, not just their individual tasks.
When a person is working on two teams they are forced to look at the work they are doing as an individual commitment instead of as part of the team commitment. Once their committed tasks are complete for one team they focus on their committed tasks for the other team. This forces them to be less than a fully committed member of either team.
Accountability and transparency are two important aspects of any team based system such as Agile SCRUM.
Working on two teams also provides opportunity for someone to hide work done outside of teams by pointing to work being done on one team or the other. This reduces accountability and transparency. The person often won’t even be aware that they are doing this. Interruptions and other unplanned work tend to take up a lot of time and are simply not noticed as impediments. The person will feel very busy but won’t be bringing much too either team.
There is always more work that can be getting done on a team so any argument that there isn’t enough work for a full time employee in a role on a team is invalid.
Often teams limit themselves to specific work items handed to them by their product owner. In many ways this is correct as the product owner sets priority. The problem with limiting the team in this way is that there are always items that need addressing and investigation that will not be on a product owner’s radar until it is discovered as an issue in production.
A team should always put the work brought to them by their product owner first but in the rare cases where a person on the team doesn’t have enough to fill their time with the stories brought by product management it is a great time to do those extra things that will never make it into a product owner’s plan.
What kinds of things are these? How about looking for bottlenecks and system performance improvement opportunities? How about looking at system capacity and usage?
Often the person who finds themselves without enough work on their plate is limiting themselves to a very specific role such as a database engineer. How about taking some of that time to learn some new skills that can benefit the team? Expand your role and become more cross functional. Become an expert on more than just the one area you already have expertise. Use the opportunity to increase what you know and in the long run the team will find itself with a better system and higher velocity of work getting completed.
Does this apply to the Product Owner and Scrum Master as well?
The short answer is yes. With that said- if there is a shortage of resources, the scrum master and product owner are the first two positions I would share between teams. There WILL be time conflicts between things needed for both teams. This requires a scrum master and product owner with strong abilities to prioritize and a willingness to let the teams members act in their place when needed.
Sharing someone between multiple teams is far from ideal and should be avoided whenever possible.