If a team works on different things, how can they run sprint planning effectively?
I'm a Scrum Master for a team who are working on different features for different products, but all for the same company. As we're a small team, we've kept it to 1 team and have been sprint planning that way.
We're slowly moving to a 1-team approach where they start to work on the same thing, but until then, I'm not sure if we're running sprint planning effectively.
For example, I'm keen on them thinking through and identifying the likely developer tasks for each story within the sprint planning session. However, as we have 3 developers (1 developer being highly specialised in data visualisations) and 1 designer, they feel self-conscious that they're wasting everyone else's time when they're discussing and elaborating on their tasks.
- we end up with multiple sprint goals, which is probably a necessary evil considering we are working on different things
- we've started tracking velocity as a whole team instead of as individuals, but I'm not sure if this will be an issue considering the team set-up
What can I do to help the team run their sprint planning better despite being a 'mercenary'-type team?
With a team of four working on several different products you could consider using a Kanban-based approach instead of Scrum. Scrum works best if you have a cross-functional team with a quantity of work for a single product that makes it necessary to plan a co-ordinated sprint a week or two in advance.
With your team however, prioritisation is presumably much more important than sprint planning. When you have one or two team members who are critical for certain pieces of work it possibly isn't helpful to define a whole sprint in advance around those key-person dependencies. Suggest to the team that they do without sprint planning. Set WIP limits, have daily stand-ups to keep everyone up-to-date and then just monitor progress.