Defining Objectives for Your Scrum-of-Scrums
During the Scrum of Scrums, what should be captured in writing and disseminated to the participants afterwards?
The first step in answering your question is to figure out what your objectives are for the Scrum-of-Scrums. In a related post, I defined the purpose of the Scrum-of-Scrums as a dependency-coordination meeting between Scrum teams and not a status pull.
My goal is to...provide the program manager with a view to effectiveness in each team.
If you're (mis)using the Scrum-of-Scrums this way, then your project may lack:
- proper visibility and transparency,
- appropriate stakeholder participation in Sprint Reviews,
- active engagement by the Product Owner, or
- a culture that values effective team process over "accountability."
The types of artifacts you need for a healthy Scrum-of-Scrums will be quite different from the artifacts you need from a "Scrum, but..." meeting that is really a status-pull in disguise.
Useful Scrum-of-Scrums Artifacts
So, what meeting artifacts will help you capture the essence of a healthy Scrum-of-Scrums and assist you in coordinating your inter-team dependencies? Again, that depends, but I have often found the following items useful in my own work.
- A list of pull-queue items. Analogous to the "what I did yesterday" stand-up item, this is a short list of what each team has finished and has ready for other teams to pull into their workflow.
- A list of impediments. The Scrum-of-Scrums isn't the place to hash out how to solve all the project's problems; it's a meeting to identify specific problems so that the people best-suited to address it know they need to sync up after the meeting.
- A list of noteworthy process changes identified during the meeting. Sometimes problems do get solved in a Scrum-of-Scrums, often through the simple act of identifying dependencies or recent milestones, or by transferring tasks between teams. For example, Team 1 says they don't have capacity to QA some new feature, and Team 2 says they have a new continuous integration server and will take on the QA task. This information would definitely be worth capturing in a meeting artifact!
I often find that summarizing a healthy Scrum-of-Scrums really only requires a few bullet points, and almost never exceeds a single-sided piece of paper when printed. If more detail is needed, an appropriate team- or project-level user story can be generated to capture the essence. Such user stories convey actionable information, and provide organizational visibility when added to the appropriate backlog.