The Daily Scrum is a common meeting for agile teams. But I still find that some product managers and owners aren't sure if and when they should attend it. This post shares my recommendations on if, how often, and how you should participate in the Daily Scrum.
Tip #1: Know what it’s all about
The Daily Scrum meeting, sometimes also referred to as stand-up meeting, wants to help the development team manage its work. In Scrum, the team collectively agrees to a sprint goal and is responsible for meeting it. This includes tracking progress of the work on a daily basis and discussing any changes that may be required. The Daily Scrum supports self-organisation by encouraging the team members to talk about:
- The progress made by the team members;
- What people intend to work on next, and
- If anybody needs help—if there are any impediments or blockers.
The Daily Scrum is meant to be a quick meeting that lasts no more than 15 minutes. It should be held at the same place and time every day; I find it’s best to have the meeting in the morning.
Tip #2: Should you attend?
I recommend that you participate in the Daily Scrum at least twice a week as the person in charge of the product.  This allows you to understand what’s happening in the current sprint, and if and how you can help. You may find, for example, that some user stories are done and can be reviewed; or you may discover that the team is struggling with some acceptance criteria and requires your input. Additionally, you may want to ask the team to help refine product backlog items or update the product roadmap, for instance. 
Be aware that the meeting is not intended to solve any problems. Therefore, don’t turn it into a product backlog or roadmapping workshop. If you hear that the team members have questions about acceptance criteria, for example, then answer them after the meeting. Similarly, if you require the help of the team to work on the product roadmap, then hold a separate workshop.
Additionally, don’t forget to balance your various duties. These include not only working with the development team, but also meeting users and customers, and engaging with the stakeholders. If you religiously attend the Daily Scrum, then check if the balance is still right.
Tip #3: Don’t interfere
Recognise that the meeting is not for you, but for the development team. Refrain from interfering with the team’s self-organisation and do not assign tasks or criticise individuals, as this would damage the team’s autonomy and weaken the commitment. If you are concerned about the sprint progress, then say so in a honest but constructive way. Do not tell the team what to do. It’s up to the team members to manage the sprint and meet the sprint goal, and it’s up to you to manage the product and the entire release (made up of several sprints).
If you find that the team members look at you and tell you what they have done, you know something is wrong: People report the project status to you instead of taking charge of their work. Therefore, share with the team what you see happening and ask people not to address you but each other. Alternatively, stop attending the meeting until you’ve discussed the issue in the next sprint retrospective where process improvements should be agreed (see below).
Similarly, if it’s hard for you not to suggest who should do what or what should be done next, then stop attending the meeting in order to give the team the necessary autonomy to self-organise and take full control of their work. You should also investigate why you find it hard to let go and trust the team to do a good job: Are you anxious to meet an ambitious product goal? Do you doubt the team’s ability to meet the sprint goal? And what can you do to feel more at ease?
Tip #4: Let the ScrumMaster do their job
Know that it’s the ScrumMaster’s job to ensure that the Daily Scrum takes place and that it is effective. If you feel that something is wrong, however, that the team members don’t track their work well, that people don’t attend the meeting or arrive late, or that the Daily Scrum often overruns, for instance, then discuss your concerns with the development team and ScrumMaster in the next sprint retrospective. But don’t take on ScrumMaster duties.
Remember that your job is to manage the product—not the team or process. If you don’t have a ScrumMaster or if the individual is not available or qualified, then recognise this is as an impediment to achieving product success that needs to be resolved—by hiring a qualified ScrumMaster or helping the current one develop and grow.
 If you are in charge of a larger product and work together with other product people like feature or component owners, then you usually don’t attend Daily Scrums. Instead, participate in the Scrum of Scrums (SoS) meeting, a variant of the Daily Scrum, which is often used to facilitate multi-team development efforts. I like to work with daily SoS meetings that take place immediately after the teams’ Daily Scrums and involve a representative from each development team.
 Please note that this recommendation is not in line with the 2017 edition of the Scrum Guide. Over the years, the definition of the meeting has changed. Initially, it was an open meeting, but only development team members and ScrumMaster were allowed to talk (see Agile Software Development with Scrum). In the book Agile Project Management with Scrum, the meeting is changed to allow product owners to contribute (see pp. 135 and 141). No matter what the current official definition is, the key to a successful Daily Scrum is letting the development team take full control of the work in the sprint.