One of the trickiest things to do when working in bigger teams is ensuring that it is possible to parallelise the work we have across the number of pairs that we have available.

From my experience this problem happens much less frequently in smaller teams. Perhaps inevitably it’s much easier to find 2 or 3 things that can be worked on in parallel than it is to find 6 or 7 or more.

As a result we can sometimes end up with the situation where 2 stories are played in parallel with a slight dependency between them.

It may be possible to start those two stories at the same time but one may rely on an implementation of the other in order for it to be considered complete.

It’s not an ideal situation but it still seems doable if we ensure that the two pairs work closely together both metaphorically and in terms of their physical proximity.

I think a more useful strategy is to look at how many things can be worked on in parallel and then deciding the team size rather than choosing the team size and then trying to find a way to make the way the stories are written/played fit around this decision.

This is rarely what happens since budgets/need to get to market quickly often take precedence so we end up working in a sub optimal way.

While this is a trade off that the business may be happy to make I still think it’s useful to identify the risk we’re assuming by taking this approach as well as recognising that the amount of work we can flow through the system is limited by how much we can process in parallel.