We are starting a new project that spans multiple teams (squads). I don't really know how to handle this situation.

Do you create a new team for this project ? Do you split user stories on both existing teams ?

I do not think the first approach is the right one, but I worry about adding dependencies between teams with the second approach. Is there a better alternative ?


2 Answers 2


The correct way to handle it is to have a common product backlog as both teams are working in the same product. Also both teams should have the same definition of done or at least close enough to make sure it's compatible. In order to adapt your DoD to this new scenario, you will need to change to "done, working and integrated".

There will always be dependencies between teams no mater how you manage it. So a good way to manage it is by making one of the teams responsible for the dependencies management. This doesn't mean that the other team do not care, it just means that one of them will be actively looking for issues and solutions.

For sprint planning, a good practice may be to have a first common sprint planning where the PO share the vision of the sprint and defines goals for all the teams. Once done, each team may go for a separated sprint planning where they do the normal story pointing and estimation of work to be done in the print.

On the daily standup, the integration team may change a bit the 3 questions to answer to include information about what happened with integration yesterday and the day to come.

On the sprint review, all teams may be together showing the work done, working and integrated. On the other hand, the sprint retrospective may be done within each separate team.

Hope it helps

  • What about your boards? You create a new one for the project or use the existing ones ?
    – benjamin.d
    Jan 12, 2016 at 16:52
  • You should have only one backlog and one board. However, you can have a board per team in order to reduce the amount of items being on it.
    – ZanattMan
    Jan 18, 2016 at 16:54

Sound like you need the scrum of scrums here. Each team works on clusters of user stories. More information about this can be found at: https://www.mountaingoatsoftware.com/agile/scrum/team

Rather than scaling large teams, Scrum projects scale through having teams of teams. The concept is explained very well in the link. It formed the basis of my understanding as a scrum-master and this technique works really well. The concept may seem complex and daunting, but once you see it in action and come to terms with it you will definitely realise the benefits of it.

Hope this helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.