planning

This builds on Scaling Scrum (3-4 teams) (Part 1) Part 1 looked at the situation where there were multiple teams working on a single product. This will look at instances where there are multiple teams working on different projects/products in the same organisation. i.e. each team has a different backlog. Remember the rule though 1 product = 1 backlog!
What we are going to do here is to make sure that separate products/projects are in sync with each other and dependencies are made visible and met with minimal delay.

Some examples may be:

Scaling Scrum is easy, have a look at the Scrum guide at http://www.scrumguides.org . You have a number of teams that each operate as normal and a member from each of the team attends an additional daily scrum. Yes, it all makes sense, but it is a lot easier to say than do, even on a small scale. There are a few practical things that newer teams and organisations need to think about and do other things will descend into a state of anarchy.

By and large there are two sets of circumstances where you need to scale.

An issue that often arises during the sprint retrospective (the most important Scrum event), for new teams is the fact that not enough is known about very new high priority stories to be able to estimate them. This leads to wildly varying estimations, arguments about how or what should be done, committed work not being completed during the iteration and a whole host more problems. It also make the negotiation between the Product owner and the team very 'interesting' during the planning session.

Reasons for these late arrivals could be: