A Serial Scrum Team

The simplest situation of doing product development with Scrum is to have one Product Backlog capturing the desirements for that Product, and having one Scrum Team implementing that Product Backlog in Sprints. The Development Team has all skills to turn several Product Backlog items into Done per Sprint upon the definition of Done. The Development Team manages its work in the Sprint Backlog and has a daily inspection to safeguard direction and alignment via the Daily Scrum. The Product Owner provides right-time functional and business clarifications. The Scrum Master coaches, facilitates and serves the team and the organization. Find more of the basic rules of the game of Scrum in a previous blog note, The Scrum Perspective To Agile.

The Sprint Review is easily guaranteed to be fully transparent, an important prerequisite to make the empirical approach of Scrum work.

Multiple Scrum Teams

For larger products, the need to build a product with multiple Scrum Teams will arise. The multiple Scrum Teams build one Product, i.e. work on the same Product Backlog. Each Scrum Team (Product Owner + Development Team + Scrum Master) derives its Sprint Backlog from selected Product Backlog items, does its Sprints and has its Daily Scrum. The need for a transparent ‘inspect’ at the Sprint Review remains. The Increment presented for collaborative inspection should still live up to the definition of Done, i.e. have no undone, hidden work left, and it should represent the complete product that the Multiple Scrum Teams are jointly building. It is expected to be an integrated Increment.

To have an integrated Increment by the end of every Sprint implies at least regular communication and information sharing across the multiple Scrum Teams within the Sprint. The Scrum Teams have regular Scrum-of-Scrums meetings besides the Daily Scrum that they have per Scrum Team. In the Scrum-of-Scrums, the best placed Development Team members of the Multiple Scrum Teams gather to exchange integration information, so that each Scrum Team can optimally plan and re-plan its Sprint Backlog.

When working as multiple Scrum Teams, the Sprint Backlog of each individual Scrum Team will obviously need to hold integration tasks to live up to the quality expectation of integrated Increments, upon a shared Definition of Done. The multiple Scrum Teams will most likely work upon the same Sprint Length to simplify planning of an integrated Sprint Review. Depending on the number of multiple Scrum Teams, a common Sprint Planning meeting part 1 may be considered, but probably a separate Sprint Planning meeting part 2. They might want to consider to do (part of) the Sprint Retrospective together. What works best for them to build integrated Increments.

Platform Level Scrum

In more complex situations, a mere Scrum-of-Scrums meeting, although being performed, might not be enough to keep the multiple Scrum Teams’ work fully integrated. Maybe there are too much Scrum Teams building the same product. Maybe multiple products are closely connected or technically linked, while each has its own Product Backlog and one Scrum Team or multiple Scrum Teams implementing it.

For clear empirical reasons, Increments are expected to be technically complete, no undone work, integrations included. No unknown remaining work should impede the Product Owner in the decision to ship upon the assessment whether the Increment is functionally complete or coherent enough.

This situation might reveal the need for a team that doesn’t works as a feature team. A feature team typically is a vertically sliced Development Team having the skills and authorization to work on all components and layers needed to build features that are actually usable by end-users. This specific team does not implement functional desirements from this end-user perspective but has the other Scrum Teams as ‘customer’. Key is that this is a full-time team that performs its work for the other Scrum Teams on a daily base. It is essential that work is not postponed, as it will accumulate and result in unpredictable and uncontrollable efforts. The specific team performs inspections that enable the other Scrum Teams within the Sprints to adapt their Sprint Backlog plan for producing integrated software by the end of each Sprint.

A common purpose for such a team is technical integration. An “Integration Team” in this setup regularly collects checked-in code of the multiple Scrum Teams, merges, runs and tests it on specific systems in order to feed back the results to the multiple Scrum Teams. This inspection reveals important development information that needs to be taken care of during the Sprint, not be postponed to some later phase. However, the model is also applicable on highly specialized skills that cannot be injected in every Scrum Team. E.g. think of highly specific performance or security testing in large financial institutions.