In your opinion, is the Product Owner a member of the team? Usually, the team’s answer during agile mentoring is that they are not. Although the Product Owner is not familiar with the technical development, their presence on daily stand-ups is very important. However, since they do not participate in the implementation itself, the team can consider them as a foreign element and have a problem performing in front of them. How can this be prevented?
Product Owners should not engage in daily stand-ups…
Most agile teams are confused about whether the product owner should be on daily stand-ups or even why they should be there. While it’s true that the product owner should not be involved in the Scrum handbooks, the vital word here is involved, meaning that he should not be the one performing.
The presence of the Product Owner in the room is, however, important. Not so they can find out what the team is doing or check if everything is going according to the plan. The role of a Product Owner on daily stand-ups is to help the team.
The Product Owner is an important part of the team. Like the Scrum Master, they should attend the daily stand-ups.
If there are minor uncertainties about the user story, the Product Owner can clarify them immediately to prevent delays caused by blocking the tasks.
If the team finds out that they’re falling behind the schedule, the Product Owner determines which user stories to omit in the sprint and which ones to prioritize. Participation in daily stand-ups lets you be aligned and will not start from ground zero with every planning.
Product Owner or a Product Manager: warning signs
Has it happened to you that the team gets a little more nervous when you’re around on the daily stand-up?
Maybe it’s because they think of you as their manager! Though it may not seem like it, small things that seem to be insignificant may affect how the team perceives you.
While working with one team, we noticed an interesting phenomenon. On the stand-up, the Product Owner always stood opposite the team so everyone could see him. It was not intentional, but the team was afraid to stand next to him. This was also reflected in the communication between the team and the Product Owner. It was more aggressive, and people were always defending their positions in the team. They also did not want to have the Product Owner with them during the retrospective. This is an indication that the Product Owner was a Product Manager to them.
This is wrong for the Agile mindset. What did we do? We let the Product Owner come to the team a little later and blend with them. The team did not know where the Product Owner would stand, and after a few meetings, they did not care. He became a natural part of the team just by that. Unbelievable, isn’t it?
More things can lead to the same situation. If a Product Owner considers daily stand-ups as status update meetings and wants to attend them to control the team, it is clear that the team won’t be thrilled with his presence. Daily questions like ‘When is it gonna be?’ and ‘It’s not done yet?’ would discourage even the most persistent ones. Micromanaging of daily stand-ups has the same effect.
Another negative factor might be if the Product Owner does not attend daily stand-ups regularly or does not arrive on time. If you come only from time to time, the team may perceive your absence as disinterest and all the more think that when you eventually arrive, it is only so you can control them.
Equally important is how you behave in stand-ups. Are you asking questions or often interrupting someone? By doing this, a 15-minute stand-up easily becomes a 40-minute daily meeting. If you always stand in the way so you can see everyone and watch intently, it can give the impression of authoritarianism and not an equal member of the team who is there to help.
How should the Product Owner support a daily stand-up
To really help your team with your presence, you’re not just a manager to them; first of all, you need to realize what the purpose of the daily stand-up is.
The daily standup serves as a team synchronization and improves the transparency of development.
The Product Owner is supposed to participate in the stand-up, not perform in it. Try to sit down next to the Scrum Master and listen to the team or even make notes. Or join them, blend in and listen as the rest of the team. Focus and do not intervene unless someone has asked you a question.
The Product Owner should respect the team and, therefore, always be on time and do not miss stand-ups for other meetings. They are essential for product development, more important than anything. You have ten people who agree on further steps on strategy and execution, like an army unit. They fight then.
Communicate with the Scrum Master. Make sure that the team knows why you’re there. If they start thinking, ‘Why even is the Product Owner there?’ He knows nothing about Java, we don’t need him there!’, they will not want you to be there. The team should understand that your presence is beneficial to them and is important for a smooth and transparent development process. The Product Owner is a member of the team that represents it in front of the clients or the management of the company, and so he must be informed.
The Product Owner contributes to the end product in a similar way team members do. He contributes from a different perspective, though. That’s why the Product Owner is a member of the team.
If you feel like there is a problem between you and the team, solve it with the help of Scrum Master. You are a team member, and Scrum Master should help integrate you. Don’t miss out on team activities; they’ll only bring you closer. For example, does your team create personal maps? Be sure to join the team in their creation!
Ten tips for Product Owners to remember
The team performs the daily stand-up, so you should participate in it. If there’s a problem, the team can ask you to help right away, not during the sprint review. Therefore, make sure that the team wants to see you on the stand-up so you do not disturb them by your presence.
Remember:
- Stand-up is not a status update,
- you are not its manager,
- stand-up should ideally be no longer than 15 minutes, so don’t extend it from your position,
- talk last on the stand-up. Otherwise, people will switch the context to your problems, which are often about preparing additional requests, not about the status of the issues currently being addressed,
- don’t tell them what other user stories you’re preparing; there’s still plenty of time for that,
- sit down or shuffle between the team and listen to them,
- answer questions and direct the team to the goal,
- don’t worry too much about the details of implementations; give the team members space for self-realization,
- don’t skip stand-ups, and don’t be late,
- if there’s a problem, work on it with Scrum Master.
