Outline: A short post presenting the 5 Scrum events and the importance of having (or not) the Product Owner attending those events.
- The 5 Scrum events
- The Product Owner and the Sprint Planning
- The Product Owner and the daily Scrum
- The Product Owner and the Sprint Review
- The Product Owner and the Sprint Retrospective
- The Product Owner and the Scrum events
As per the Scrum Guide 2020 a.k.a. the Bible of Scrum, the 5 Scrum events are:
- The Sprint – which is a container event for all other Scrum events. It is timeboxed to a month or less
- The Sprint Planning – where the Scrum Team decides what should be done in the Sprint, why it should be done and how it should be done (at least the first few days)
- The Daily Scrum – where progress towards the Sprint Goal is inspected and adaptation towards work planned is taking place. This event is meant for developers to collaborate and organize their work for the day and is therefore optional for a product owner to join
- The Sprint Review – where results of the work are demonstrated to key stakeholders, feedback is sought after and decisions take place on what to do next
- The Sprint Retrospective – where the team members inspect what went well, what went not so well and what they can improve
So what would be SOME of the consequences of not having the Product Owner in one of those events?
Sprint Planning. Not having the PO in the planning phase means that the Scrum team may not be able to set up a meaningful and/or valuable Sprint goal and would not select the most valuable backlog items to work on for the Sprint.
Anti-pattern example: Product Owner cannot join the Sprint Planning on a regular basis mentioning important issues he/she has to attend do. Developers are told that they know what to choose best given that they know the product well and to go ahead with the planning fully empowered. On the next days or so, the Product owner review the outcome of the planning and decides to change the selected items with others as it does not align with his/her views and “new” priorities. Due to frequent changes and reprioritization, team members become disengaged and demotivated.
Daily Scrum. Not having the PO in daily Scrum can lead to a loss of information and synchronization between the developers and the PO, requiring the PO to ask for status update separately to the developers or Scrum Master. However, this is the sole Scrum event which is not mandatory for the PO to join. Actually, having the PO in the daily Scrum can lead to unexpected consequences as he/she can disrupt the flow of the conversation between the developers themselves. The goal of this short meeting being an alignment and collaboration between developers on what to do for the day and progress towards the Sprint goal. It is therefore of utmost importance that this event does not turn into a status update or project report towards the product owner which is often considered (incorrectly) as a manager by various team members. If he/she participate in the event, the Scrum Master has to watch out for such anti-pattern.
Anti-pattern example: The developers consider the daily Scrum as a status update call and report their progress to the product owner in similar fashion to what would be done with a project manager. The developers are not collaborating among themselves to decide what to do next and how to tackle challenges as a team but instead ask the product owner what it is the next course of action and/or tasks that they should take.
Sprint Review. Not having the PO in the review means that the team is not united in front of its stakeholders. The PO is the flagship of the product and should “stand in front of the crowd” to promote the tool and have the developer’s backs when they are being challenged while presenting increments to stakeholders. Prioritization decisions need to be justified by the product owner and feedback from stakeholders need to be taken into account .
Anti-pattern example: The PO is not joining the review or treat the review as a stage gate where he/she inspects the results of the work of the team, giving the developers good and bad points. This creates a split between the developers and the product owner ( the development team vs the PO instead of the Scrum team) where the product owner is considered a manager who does not have skin in the game but only act in pursuit of his/her own interest. Such pattern eventually lead to disengaged developers and misalignment on the product goal and what to do next.
Sprint Retrospective. Not having the PO in the retrospective means missing a key part for improvement. The PO brings different perspectives, information and views to the table. He/she is generally a key to solve prioritization, stakeholder management or organizational issues with or without support from the Scrum Master. Without his/her involvement, many improvements devised by the developers cannot take place.
Anti-pattern example: The PO is not joining the retrospective as it is “meant for developers” or he/she has more important priorities. Issues with the product are centered around its value, the way requirements are expressed, stakeholder management and prioritization. The developers and the Scrum Master discuss about how to address those issues which all require the PO involvement. Yet after the retrospective, those issues are never brought up to the PO nor addressed properly and the issues linger till the developers become again totally disengaged and delusional.
That is it for this short article – there are actually many other anti-pattern examples and reasons on why the product owner should join all the Scrum events but above are among the most commons. If you are a PO, think about the impact you are having on the developer’s morale when you are not joining the Scrum events. If you are a developer or Scrum Master, we appreciate your comments on other reasons and anti patterns regarding the PO (non) participation in those events.
We hope you enjoyed this article and please reach out to us for any question or comment you may have!
Your Value Insights team