Daily Standup and Scrum of Scrums - what should be the order of meetings?

Hi Andrze,

You can have the additional stand-up meeting after your team standup meeting is done. This will enable to discuss the status of the different team's as per the agenda of a daily stand-up meeting
1. What was done from previous day to now?
2. What is the plan for the next one day?
3. Any issues

The discussions held in the additional stand-up meeting can be shared with the respective teams in your subsequent stand-up meeting.

Hope this clarifies your question.

thanks and regards,
K.B. Sasi Prasad

1. The idea of doing SoS is not to share the status but to communicate the dependency and sharing the info on items which can impact other teams

2. Do the SoS after team's daily standup so that all dependencies are noted down

3. Leadership can use it for sharing the stakeholder's comments

4. Based upon the level of dependency, it is not necessary to do the daily SoS, it can be done on alternate days or twice in a week.

Cheers
Sanjay

In my experience an SoS should be held at least twice a week in order to preserve momentum. The focus should be clearly and squarely on how teams need to collaborate in order to meet their release goals. The best time is as soon as possible after the teams' daily scrums, because impediments that are raised in the SoS may require replanning to be done by one or more teams in order to unblock them. These dependencies therefore need to be surfaced as quickly as possible in order to reduce waste.

Yes After the Scrum is a good time for Scurm of Scrum. If your scrum team is large then you will need some time to arrange the information to be reported at SoS.
One followup question, Scrum has some recommendations on who should attend and who should not attend. Do you recommend any such rule for SoS ?
Good suggestion on the frequency ideally twice a week.

One representative is needed from each team. Attending the SoS could be seen as an impediment that stops or interrupts Development Team members, in which case the Scrum Master should attend.

On the other hand, some team members take turns in attending the SoS, so as to improve everyone's understanding of the wider release picture. However this can compromise continuity and efficiency, as attendees *who don't* know the big picture may fail to pick up on impediments which their team or SM could help resolve.

Andrzej,

It's important that you understand a couple of things first.

1. The SoS, or similar coordination practices, are not part of Scrum. They are what we call "complementary practices" -- in short, optional practices that may or may not be useful for all product groups. There is no standard way to execute coordination among multiple teams on the same product.

2. The SoS is a "scaled" version of the Daily Scrum. As such, it should be owned and executed by the Development Team, just like the Daily Scrum is.

3. Like the Daily Scrum, it is not a status meeting, but a coordination and re-planning meeting for the Dev Team.

So, with all of that said, here is something to think about:

With only two teams on a product, I'd be very wary of creating a SoS. Instead, I'd encourage each team to send 1-2 Dev Team members to the other team's Daily Scrum. I call this the "visitor pattern"(another complementary practice). In this way, the "visiting development team member(s)" does not participate in the other team's Daily Scrum, but *may* participate and ask questions immediately *after* the Daily Scrum if needed. Usually, this is plenty enough coordination for just 2 teams. In my experience, with only two teams, a SoS is rarely needed.

I can also add that I'm currently working on article on the Scrum of Scrums practice and I'll try to remember to come back here and link to it once it's published.

Thanks Charles and others. Will look forward to your article. You mentioned SOS as a complimentary practice. What are the other areas under this "Complimentary Practices" category. I know the Scrum guide deliberately leaves them out to focus on just the core principle and that is good. Would be great to have a "Scrum Guide Complimentary" from scrum.org which list these practices.

The Agile Atlas separates "Core Scrum" from "Common Practices". This isn't a scrum.org resource but it may nonetheless prove helpful:

http://agileatlas.org/common-practices

Per my previous statement, the article I on SoS that I wrote has now been posted:

https://www.scrum.org/Blog/ArtMID/1765/ArticleID/12/Resurrecting-the-Mu…