Photo courtesy of Rawpixel

4 Daily Scrum Tips for Product Owners

Published on 20th June 2017

The Daily Scrum is an important meeting for agile development teams: It facilitates self-organisation and helps maximise the chances of reaching the sprint goal. Despite its importance, the meeting is not always effective. This articles share my recommendations on how you as the product owner can help make the Daily Scrum a success.

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:

  1. The progress made by the team members;
  2. What people intend to work on next, and
  3. 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. [1] 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. [2]

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.


[1] 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.

[2] 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.

Post a Comment or Ask a Question


  • Paul L. says:

    In Tip#2 that’s great advice not to turn the stand-up into a workshop. In my “daily scrum” experience, we allowed the PO to attend (because our PO’s typical “available in listening mode” presence was not perceived as harmful, disruptive, or distracting) and after the team members shared with each other the answers to the 3 Qs, the team was generally ok with a quick request or announcement from the PO. Using your examples of a request for product backlog refinement or updating the product roadmap we generally handled those via recurring team sessions set up expressly for those activities, and occasionally in an ad hoc manner when members’ capacity permitted. And this practice seems consistent with the Scrum Guide’s guidance that…“The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”

    • Roman Pichler Roman Pichler says:

      Thank you for your feedback Paul and sharing your experience. Great to hear that having the product owner attend the Daily Scrum was helpful for you and that you managed to establish an effective product backlog refinement process. I’ve shared my thoughts on the latter in the post “When should Product Backlog Grooming Take Place?” btw.

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.