Skip to main content

Having two daily standups for large teams

Last post 02:55 pm April 18, 2015 by Ian Mitchell
2 replies
08:46 pm April 16, 2015

Our team, including development and test comprises 1 system architect, 10 devs and about 10 testers. Every member of this 21 person team participates in the same daily standup. Even though we complete the standup in about 20 minutes, I am starting to wonder if this is too big a group to be engaging in a single standup.

What I am actually noticing as one of the scrum masters, is that some members of the group take this opportunity to engage in personal egotistical battles and this typically ruins the moral, making standup go longer.

I will like to propose to my manager and partner scrum master on splitting the daily standups into two separate groups, with a mix of dev and testers or some other reasonable composition. I usually though that when scrum teams exceed a certain number such as 10, they need to be split.

What are your thoughts or experiences?

Thanks,

Klaus


11:03 am April 18, 2015

An interesting experiment after a daily stand would be to ask some random team members if they could comment on the progress toward the Sprint Goal, done by an individual team member or for the team as a whole.

My bet would be that nobody has any glue for nobody shares or receives any useful information about how you are doing as a team. Maybe except these guys that are going into battle for they are at least frank and open in communicating something is dead wrong.

It is your responsibility as a Scrum Master to resolve impediments, and one of the simplest impediments to recognize is a violation of the basic Scrum rules, in this case team size and number of Scrum masters per team.


02:55 pm April 18, 2015

The Scrum Guide will tell you about optimal team size, and the roles and responsibilities of a Scrum Team.

When splitting a large team, think about:

- how the dependencies between teams can be minimized
- how each Development Team can provide feature-complete deliverables
- how these deliverables will be integrated into a potentially releasable increment at the end of each Sprint
- how the teams will self-organize when drawing work from the same Product Backlog
- how Sprint Planning, Reviews, and Retrospectives will be co-ordinated
- how the Development Teams will self-organize and replan during the Sprint to ensure the Sprint Goal is met
- how the Definition of Done will be improved and jointly observed by the teams


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.