Should meeting minutes be captured during Scrums of Scrums?

Question

We hold daily Scrum of Scrums meetings on our project. The participants (i.e. non-technical managers) each manage several smaller projects and provide updates on their projects (from their daily scrums the day before). During the Scrum of Scrums, what should be captured in writing and disseminated to the participants afterwards?

Capturing a daily agenda seems overkill. But what about minutes to be sent to the participants after the meeting? Is there real value in capturing what was done and planned in each day? Maybe just capturing the impediments (and their resolution) is the best balance between effort and value.

How can How to take minutes of meeting effectively? (which talks about meetings generally) be applied to Scrums of Scrums?

My goal is to have something that the individual managers can use to reflect their status accurately with some historical view; and to provide the program manager with a view to effectiveness in each team.

Answer 1

We have found it most useful to track the following:

1. Impediments - who owns them.
2. Cross-team dependencies - when to expect.
3. Resource contention - how it was agreed to be resolved.

In addition, you may find this detailed write-up from Mike Cohn of Mountain Goat Software helpful: http://www.mountaingoatsoftware.com/articles/advice-on-conducting-the-scrum-of-scrums-meeting

Answer 2

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.

1. 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.
2. 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.
3. 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.