Integration Team in Multi-team Scrum

If one team in Scrum not enough, it’s advisable use Multi Team. But here you get one more problem – how to manage more than one team. And the answer: use the Integration team. With Multi Team your Scrum will look a little bit different.

Multi-team Sprint Planning

  • All the teams or at least representatives from each team get together
  • Product Owner gives the vision for the Sprint
  • Representatives figure out dependencies
  • Representatives figure out how to minimize cross-team dependencies
  • Then each team make their usual Sprint Planning meetings

Integration Team’s Daily Scrum

Not the same as a regular team’s Daily Scrum – not “3 Questions”
This meeting kann last less than 15 minutes
Goal: Is the integration on track?
– “Did we have any trouble integrating yesterday?”
– “Are there any likely integration troubles facing us today?”

Multi-team Sprint Review

Goal: Show off the done, working, integrated software and gather feedback

Multi-team Sprint Retrospectives

  • Representatives from the teams come together
  • Discuss and identify any cross-team problems
  • Representatives go into their regular Sprint Retrospectives

Scrum with Multiple Teams

Scrum says a team should be 3 to 9 people. But sometimes you want or need to go faster, so you add more teams. This process calls Multi-team Scrum or Scaled Scrum.

Challenges of Multi-team Scrum

  • Now you need to coordinate not only a single team anymore
  • Scrum Master need pay attention to dependencies in the Product Backlog
  • Manage also dependencies in the Sprint
  • New responsibility – integrate work from multiple teams

Done on One Team vs. Multiple Teams

In Single Team
– Goal: done, working software.
-If it doesn’t meet the DoD, it’s not done.

In Multiple Teams
– Goal: done, working, integrated software.
– If it doesn’t meet the DoD and if it isn’t integrated, it’s not done.

Multi-team PBI Recommendations

  • PBIs should done by one team in one Sprint
  • Manage dependencies between PBIs
  • Create a new integration team: Job is to make sure everything is integrated
  • One Product Owner for all the teams
    -One product – one Product Owner

How do you make Scrum under Waterfall?

Very often the Scrum under Waterfall exist in organisations. It might not exist formally, but it can be required by contract or by law. The Scrum can be part of the Agile experiment.
The Scrum under Waterfall be because it’s practically for the organisation.

What will be the same/different using Scrum under Waterfall?


Focus on ‘Definition of Done’
Daily Scrum
Sprint Planning
Sprint Review
Sprint Retrospective


Backlog = Project Plan
Less time on Backlog refinement
Less time on Sprint planning
Less negotiation during Sprint

But be aware, during Waterfall delivery: 

Waterfall has poor communication / misunderstandings
Lack of transparency
Detachment from reality
Slow feedback / No feedback
Nothing is Done

So you need to do following things:

1: Work in Sprints

The Waterfall can be scheduled for example 12 months. If one Sprint last 30 days, you will have 12 Sprints.

2: Avoid ‘Earned Value’

The task can’t be done for 85.6 or 98%. The task is done or not done!

3: Focus on Done

Create a Definition of Done (DoD), work with DoD

4: Testing, testing, testing

Test throughout Sprints, start to design your tests at the beginning of project. Test until the end

5: Get Frequent Feedback

Gather feedback early. Show the increment before it’s actually due

Waterfall vs. Scrum

What is “Waterfall”?

Waterfall is a plan-driven project management in software development. So normally you work with Gantt charts & Microsoft Project, you have Start & end dates and Project phases. In Waterfall, development phases have force defined order: first you write Requirements, than you Design and Develop your application and at the end coming Testing and Deployment phase.

Waterfall vs. Scrum


Requirements documents
Resistant to change
-Change is a bug
Poor “customer” involvement
Start-to-finish Project Plan
Large team size
Multiple phases
-eventual delivery
Contract driven
-Fixed feature set


Just-in-time requirements
Continuos change
-Change is a feature
Permanent “customer” involvement
Plan for the Sprint. Product Backlog
Small teams (3 to 9 people)
Increment every Sprint
Contract is closer to T&E
-Likely not a fixed feature set

Definition of DONE in Software Developent

Let’s imagine, that at the end of every iteration in SCRUM or any other Agile Software Development method, the developer is coming to you and saying: “I’m done with this functionality!” But you of course ask: “What do you mean done? Are you done or done done?”

What do I want to say here: Software developers think that software development begins and ends with them. It’s actually not really false, but…
The software development is much bigger than only writing the code. Code by itself isn’t that useful. When developing team is stating define Definition of Done (DoD), it will be much more than “just coding”.

Example Definition of Done

Development / Coding

  • Code is written with unit tests
  • Code has been merged to Main
  • Code reviewed by someone other than the author

Testing / Deployment

  • Written QA tests
  • Tested by QC
  • Tested by QA
  • Written UI tests
  • Accepted by Product Owner
  • Load tested Deployed to Production

As you can see, the real Done functionality contains much more steps, as just only code. And how to determine this Definition of Done (DoD)?

 Defining Definition of Done (DoD)

  • Get the team together before or just at the project beginning
  • Start to discus in which phase your functionality can be named as DONE
  • Try to avoid ambiguity and differences in definition
  • Write it down!
  • All team members should follow the DoD

So in next, when developer will come and say:”I’m done!”, all will know exactly what does it mean.

Who is actually the Scrum Master?

scrum master coach

The Scrum Master helps the team to be productive and use they creativity in order to deliver done, working software.

The main point here is that the Scrum master leads the team, but not command the team

The Scrum Master is a Coach. He is not a boss. The team members doesn’t need to report to the Scrum Master.
The Scrum Master is not a manager and doesn’t order to do anything. He is a leader and he need to figure out how to lead the team.