If a team works on different things, how can they run sprint planning effectively?

Question

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.

Also:

• 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?

Answer 1

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.

Answer 2

One thing you might do is get the team members to refine the backlog on their own in advance of sprint planning. They can add sub-tasks and estimate before the meeting.

This is obviously not something you would want from a team collaborating on the same bit of work, but in your circumstances it might make sense.

Even doing this, I would still encourage the team to share their thoughts during sprint planning. Part of the value of working in a team is gaining understanding of how others work (even if they have a different specialism).

Answer 3

Something that I think would be key to understand is: do each member of the scrum team work only on a single product? And if so, why is that?

Right now, I don't think you can call yourselves a scrum team, because you are not collaborating beyond sharing meetings and a bucket of tasks. You look more like @Bart van Ingen Schenau's comment: a group of people thrown together with their own backlog. Therefore I don't think trying to have compelling sprint planning events is the right focus as it is not the right problem to solve.

However, you have a great opportunity of changing things if the organization is open to it. As you said, you are slowly moving to a scenario where you all work on the same thing, and I believe that should be sped up. Notice that -in my experience- this doesn't mean that all the team needs to work on just one application/product/feature, they can in fact work on different things and that as a whole would be your product. Let's say: if you all work on one application at a time, you can consider that your product, but an application has different modules and dependencies to work on; under that logic a set of applications could also be considered a product with each one being just a module of a bigger one.

Hence, if you as a team are allowed to share the different portions of work (this means dev 1 needs to start working on what dev 2 is expert, and so on), then you will naturally evolve to a model where work is shared -Product Backlog- and Sprints can have a common goal upon a shared Sprint Backlog. That would make Scrum events of use to everyone and the conversation will flow on its own as now the "problem" is everyone's.

Hope this helps, remember that Scrum is just a framework, so as long as you adhere to its core you can apply it to all sorts of situations with an open mind!

Answer 4

It sounds to me like your very-small team also consists of, shall we say, "subject-matter specialists." And this might in the short run simply "be the hand that you've been dealt." But I think that you want to take every opportunity to emphasize that "we are all one team," and so, to the greatest extent possible, "we all are aware of what everyone else is doing, and we can be and are expected to help out with anything."

(Of course, it should be obvious enough that I don't mean to say that one employee's going to start "teaching data-visualization classes ..." Instead: "many hands make light work.")

You refer to them as "mercenaries." My term for it is "lone wolf," and in either case this is a purely-social dynamic that you need to diplomatically counter. Because, whether the practitioners realize it or not (and they very likely don't, having never actually encountered anything else), this is a very inefficient way to work which leads to a lot of unnecessary pressure. Pressure that they might right-now be accustomed to, and secretly resent. They need to be shown that project management can lead them to "a more-desirable lifestyle situation."

I've crossed paths with plenty of software developers who speak of "lone wolf" in this way – "I'll never go back there again!" And I myself agree.

Answer 5

It might help to separate backlog refinement and sprint planning. Backlog refinement might be attended only by people working on the product concerned.

If developers can work on multiple products, it might help to roughly define in advance how much (e.g. 30%) time/work should be spent for one product.

Talk about this problem in a Sprint Retrospective.

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

As long as it works, I'd keep this if you want to be a team. Tracking the velocity of single developers might not help nor making them happy.

Edit: Typos and what I want to add: This situation is not good but I understand that sometimes there is no choice and one has to find a solution :-)