Only team members talk, i.e. the folks who committed to the work. The Product Owner and Management are welcome to attend, mostly to observe, and the Product Owner can chime in to add clarification if necessary.

The two main risks of the daily stand up are:

1. It becomes a status report session
2. The team reports status to the Scrum Master

The purpose of the meeting is to synchronize – to ensure there is a common understanding as to where everyone is at as a part of delivering the team’s commitment to the Product Owner for that Sprint. Meaning that it’s not about individual commitments, but how as a team are we going to get all this stuff to a potentially shippable state.

In a retrospective today we had this exact discussion, that although we know in theory stand ups are for synchronizing, how can the team increase the effectiveness of this? One of the takeaways was to view the stand up as a way to “create a plan for the day”.

Instead of developers merely picking off the next thing in the Sprint backlog that needs to be coded, and QA testers jumping on whatever is ready for testing… opening up more opportunity to leverage the “team is a team” concept where you’re not limited by title – if QA or Analysts are involved in heavy duty testing, but as a developer you’re wrapping up something relatively simple by 11am, and if another developer is able to do the testing on it to move it forward… that’s the kind of stuff you can talk about in your stand up where you’re coordinating what the day is going to look like for the team.