Abstract: In Scrum, the Sprint planning meeting (abbreviated as the planning meeting) is the beginning of a Sprint. The product owner (ABBREVIATED as the PO) and the development team establish goals for the Sprint, otherwise the development team may not know what to do and therefore cannot carry out the activities in the Sprint.
This post is from huawei cloud community “Sprint planning meeting starts, product owner is Not there”, by Xiaozhi Agile.
background
In Scrum, the Sprint planning meeting (abbreviated as the planning meeting) is the beginning of a Sprint, and the product owner (abbreviated as the PO) and the development team establish the goals for the Sprint, otherwise the development team may not know what to do and therefore cannot carry out the activities in the Sprint.
So what happens if the product owner doesn’t attend the planning council?
In order to avoid ambiguity, it should be clarified before the analysis that the product owner mentioned in the article mainly refers to the PO in the independent research and development project or the agent PO (non-customer personnel) under the independent research and development. Although the Scrum guide does not specify who the product owner should be (customer or supplier), it is generally accepted that the product owner is a “customer representative”, that is, your own person as the product owner is not mentioned in detail due to limited space.
Problem analysis
As more and more enterprises in China start to use Scrum as an agile transformation method, for such enterprises, there may be a certain degree of misunderstanding of the responsibilities of the product owner in Scrum. In principle, the product owner is expected to be present and punctual for planning meetings, both in the Scrum guide and other references (e.g. ** The Essence of Scrum **). As a project grows, requirements analysis, number of stakeholders, and complexity increase, resulting in an exponential increase in the product owner’s workload. The product owner’s absence from planning meetings may not only be subjective but may also be influenced by objective factors.
Generally speaking, the main reasons for product owners not attending planning meetings are:
1. ** Product owner does not clearly define his/her responsibilities: ** Mainly reflects that the product owner does not clearly understand or pay no attention to his/her responsibilities in the planning meeting and does not attend.
2. The convening of ** planning meeting is not fixed: ** Mainly manifested in the unfixed time of the planning meeting, which may conflict with the work plan of the product owner and not attend the meeting.
3. Low efficiency and long time of ** planning meeting: ** Mainly reflected in the product owner’s heavy and complicated workload, long time and low efficiency of planning meeting, resulting in subjective resistance of product owner unwilling to attend.
4. ** fails to deal with emergencies: ** mainly reflects that the product owner cannot attend the planning meeting due to external uncertainties such as market changes and customer requirements.
To sum up, the following will give solutions to the four aspects of the above analysis.
The measures
The product owner does not define his responsibilities
The Scrum Master is the “political commissar” in his daily work, instilling Scrum ideas into everyone on the Scrum team. In terms of the product owner, the role and responsibility of the product owner in the Scrum framework and the importance of event participation should be clearly understood. For planning meetings, in principle, the product owner is required to be present and on time for planning meetings, because the product owner needs to work with the team to establish Sprint goals and scope, otherwise it may lead to a Sprint that is not targeted or deviated from the goal without achieving the desired results.
There is no certainty that the planning meeting will take place
As a saying goes, “nothing can be accomplished without rules and standards”, we must first make rules (plans). For example, when a team is preparing for an Agile transition, at its launch meeting (or other pre-Agile event), it is important to establish rules. This should include the cycle of sprints, and who needs to attend which Scrum events at what time. Of course, agile teams that have been around for a while can re-establish rules if they don’t. For planning meetings, you need to define when each iteration will take place, for how long, and who will attend.
On a daily basis, the Scrum Master is expected to be the “babysitter” and can “shout” just before a meeting. However, we suggest meeting reminder email. Mainstream email management systems (Outlook and Foxmail) can set “repeat cycle” to remind members of Scrum team in a simple and convenient way.
Both of these, in plain English, are rigid in thought and process, so that everyone (the Scrum team) knows what to do at what time, and keep the team pace so that no one on the team knows when the meeting is going to take place.
Not doing a good job of responding to emergencies
If the product owner is unable to attend the meeting due to unexpected circumstances, such as the need to deal with relevant problems at the customer site. This requires the product owner to ensure that the number of stories in the product backlog is adequate for the development team’s work for the next one or two sprints (including priority). In addition to quantity, there should be quality requirements for user stories, not only with clear descriptions, but also with acceptance criteria (AC). This makes it much easier for the product owner to be absent, because the development team knows what to do and how to do it even when the product owner is not there. Of course, what is mentioned here is the problem that the product owner is not in two places. If the product owner is only in different places and the time is OK, the team needs to have the ability and tools of video meeting, and the team must prepare in advance.
In addition, the development team should be empowered to manage the product backlog as well as the product owner, as the Scrum guide points out. This requires the development team to have the ability of self-organization (for the construction of self-organization ability, please pay attention to the FAQ of our expert team later). In Huawei Cloud DevCloud, the concept that everyone is a product manager has always been implemented, so that every member of the team can become the backup of the product owner.
Another important point to note, and one that is easy to overlook, is that product owners are also people. Product owners also have to pick up children, attend parent-teacher conferences, and take vacations outside of work. These are also known as “weekend events”, so schedule Scrum events to avoid the end of the week and the beginning of the week (Monday and Friday) to reduce the probability that critical events will be interrupted by daily life. So many teams start their sprints on Tuesday and Wednesday. If there is an effect of “weekend events” (which happen more often), then this corresponds to the “rules” mentioned at the beginning, if necessary.
Finally, consider the extreme case where the product manager must attend planning meetings, which are often triggered by a sudden change in future work or other important value. In this case, you may have to postpone the meeting until the product owner is ready. If it’s just a few hours late, it doesn’t really matter. Just start the meeting later in the day, and the rest of the meeting won’t be affected. If the meeting is too late, however, it could be a major change in the schedule, which could be tailored to the situation or even canceled.
Planning meetings are inefficient and long
On average, planning meetings can last anywhere from four to eight hours. For product managers, this undoubtedly increases their work burden. To some extent, they are unwilling to accept such a long meeting, so they need to improve their efficiency in the meeting.
When we actually have planning meetings, we usually split them up into half and half sessions. The outline (which may vary from team to team) is as follows:
As you can clearly see, a planning meeting is divided into two “meetings” for the product owner and the team, and for the development team itself. So the product owner doesn’t actually have to attend the full planning meeting, which saves the product owner time during the meeting. The Scrum Master should be able to keep the product owner out of the details and technical implementation discussions.
It should also be noted that an important input to the planning meeting, a backlog of prioritized and appropriately granular user stories, is already known to the development team at the grooming meeting. This also requires product managers to pay attention to the quality of user stories, which in fact helps them reduce the burden of communication and improve efficiency. For more on writing user stories, see “User Stories equals Requirements Specification” — You Can’t Write a Good User Story.
For the product owner who only attends the half-time meeting, if the process is well controlled, the result will be to increase the likelihood and willingness of the product owner to attend the meeting. Of course, this first and second half is not completely without problems. If the development team finds that the Sprint goal may change in the second half, it can be adjusted with the product owner in a light way, and the problem is generally fine.
conclusion
More about the product owner did not take part in the analysis of the planning meeting is according to what is said in the common case, but certainly not only hereat, because the real situation is always changeable, we need to have been around the core of the agile and deal with problem solving activities, in the process of practice, take is “rigid, after optimization, and then curing” policy, Continuously refine and improve our processes and ideas to increase efficiency and competitiveness.
The resources
The Scrum Guide
The Essence of Scrum
Click to follow, the first time to learn about Huawei cloud fresh technology ~