The Sprint Planning meeting in the Scrum framework is an important event during which the work of the entire Scrum team for the upcoming sprint is defined and planned.
The Scrum Master and Product Owner roles as well as the entire Development Team participate together in this meeting to raise issues on Product Backlog items that the Product Owner role has previously prioritized. The Scrum Master role monitors for problems, and the Development team shares their predictions. Reference Sprint Planning, BVOP.org
The Sprint Planning meeting may seem like simple planning, but in a real environment, many Scrum teams have difficulty.
The article describes sample situations with problems and reactions from the Scrum Master role.
At the end of the Sprint Planning meeting, your Product Owner states: Colleagues, please all of you now assume the success of the sprint by giving a score from 1 to 4 as one will mean that we will fail to achieve our goal, and 4 means that you assume high success for the sprint.
The Scrum Master’s response: I would add, “Colleagues, let’s all make this assumption,” and he and I are part of the Scrum team. The numbering is mentioned, it is good to be from 0-3, but I think that this approach will give us a clear idea of the opinion of the team. The success of the Scrum Sprint often depends on optimized processes, waste management, and productivity as the Agile Kaizen principles tach. Reference: Every Scrum Master must know the Kaizen principles, wikipedia-lab.org
There are many rules (advice) designed by the Kaizen creator that can be applied to every business and work process. These rules are often referred to as the 20 keys of workplace improvement. Reference: 20 Agile Kaizen keys to workplace improvement, libraryofmu.org 2020
At the end of the Sprint Planning meeting, your Product Owner states: Colleagues, it was exhausting to plan the sprint and we all worked hard all day. Would you be so kind tomorrow morning to send me and our Scrum Master your presentation on how you would complete your sprint tasks and what your self-organization plan is? Thanks in advance.
The good Product Owner does not say such a statement. Reference: What makes a good Product Owner and what do they do, scrumtime.org The answer of the Scrum Master:
Let’s assume that we are already a good team, everyone knows their place and works professionally. I would not welcome such an additional request for written explanations and plans. This would put extra strain on the team and affect its motivation and morale. I would rather end with:
Colleagues, the fact is that we went through a difficult day today. I am very glad that we reached a unanimous opinion about the length of our sprint, as well as what we will use as know-how from the previous product backlog. Reference: Atlassian.com
We have a lot of interesting work ahead of us, we will do our best, but there is a reason. After today, I am sure that you understand the visibility of the management and you will make the necessary efforts are self-organization and motivation, as before. Thanks to everyone and see you tomorrow.
A sprint of three weeks awaits you, the team and the product owner have discussed the necessary details on unclear User Stories. It’s been an hour and a half.
The answer of the Scrum Master: Colleagues, these details definitely had to be discussed so that there would be no ambiguities. But please, let’s focus now on our remaining 4:30 minutes and discuss what we can use from the product backlog, how the work will be performed, and distributed on an appropriate increment.
Which ones to actually include in which period of the sprint in order to be as productive as possible. After our meeting, I will talk to the Product Owner about the possibilities for us to receive a little clearer US from the client so that we do not waste a lot of time in their interpretation. Reference: Product Owner role in Scrum and real problem situations, www.vbprojects.org 2020
At the sprint planning meeting, you have 6 members of the Development team. Everyone guesses with a number about the success of your sprint. You count the result and the total number is 15
The answer of the Scrum Master: Following the unwritten rules of the team, most voted with 2 and 3, which gives a very good chance of success. We continue to work on our sprint with full force, it is obvious that they are confident in its success. Only if there is one – 0 I would ask for the opinion of the person who posted it (if the voting is visible or roll call, in which I see no problem) Reference: Scrum problems with questions, answers and explanations from the point of view of Scrum Master, https://ossalumni.org 2020
During your Planning Poker, you notice that a novice member of the Development team systematically discards cards that have the numbers 1 or 3 and always puts his card last. The other members choose much larger cards.
Answer by the Scrum Master: This provokes a discussion every time that ends quickly. Then this colleague of yours plays card 13 every time. Why do you think he does it? What exactly would you do? I would remind him very briefly, without discrediting him … “Ivan, I know that you come from a very good company and I know how experienced you really are, but I guess you used a method for the successful sprint with numbers from 0-3 if not please correct me. In our team we borrow the advantages of Poker Planning, namely, this gives us a wide field for visualization of the given story. A range of 1-21 can describe the approximate relative time we look for by summing them afterward. ”
During your Planning Poker, you notice that a senior member of the Development team systematically discards cards that have the numbers 3 or 5 and always puts his card first. The other members choose much larger cards. Explain the possible cause and actions.
Answer of the Scrum Master: I will definitely open a discussion before I just summarize and move on. I will ask for more details and why he has such an opinion. His experience may suggest obstacles, delays that more inexperienced colleagues have not encountered.
Just before your Planning Poker, your Product Owner informs the others that beginners will not throw cards because there is a lot of evaluation work to be done, and in his opinion, the time will not be enough.
Answer of the Scrum Master: I will be against such an initiative. The Product Owner should not interfere with development team members and tell them what to do. Many people believe the Product Owner is the manager in Scrum but he is not. Reference: Product Owner is king www.cio.com
Each member of the Scrum team has the same “rights and obligations”. The inexperienced of the team can definitely have a different side view of the performance of a story, which can be very valuable and help save time.
Senior members of the Development team suggest that the Planning Poker game be played with open cards and their numbers visible so that beginners can more easily choose their choice of cards.
Answer of the Scrum Master: I would not welcome such an approach, as they will not express a personal opinion, but will be guided by the opinion of their more experienced colleagues. Therefore, they will not contribute to our predictable calculations and if we say they are responsible for the product design that requires 15 points of time but sees a colleague voting with 3 (who is not fully acquainted) then this will distort the end result and make the method illegitimate and meaningless.
After each “play” to select Story Points on each User Story, the team discusses the differences in card numbers. After the discussion, they take the assumption of the participant with the highest value on the card.
The Scrum Master’s answer: It would not be the most appropriate approach. The average values would give us the most realistic time picture. With the highest, we risk procrastinating too much in time, with the lowest it will not reach us. This is the idea of ”playing” to give us the most realistic average.
During your Sprint Planning, a senior member of the Development team openly complained about the User Story, prioritized at the top of the backlog, and carefully prepared for the Development team. All information is available and well described. A senior member of the Development team says that if they develop this in this sprint, they are likely to damage important architectural decisions. Your Product Owner emphasizes that it is his responsibility to take care of the backlog, and the development team to develop the product.
The Scrum Master’s answer: I would definitely take this opinion of the senior member of the team into account. He has probably encountered a similar problem already and is aware that it will have a negative impact.
I will ask for more details and discuss them with the team, we will also discuss the possibility of changing the location of this particular story (say the middle of the story after most of the basic code has already been written).
I will also start a conversation with the Product Owner and I will share with him and remind him that there are no clear roles in Scrum and each of them is possible to complement each other, this is the valuable thing in our way of working, namely that our team members have the necessary freedom and broad vision, as in this case saves and “saves” a whole sprint from failure.
The development team has a Velocity of 103 points. For Sprint Backlog they choose User Stories with Story Points from 3, 5, 1, 8, 21, 13, 1, 21, 8, 8, 13, 5.
Answer of the Scrum Master: I would specify for them that this time sample cycle is a little longer for the stories they have performed in previous sprints and exceeds the approximate time value by a little. I would give them options for action, to stay with it, as if to be done properly, they had to work a little more than before (which is not recommended in general and still has a lot of dependencies). Another option is to choose a story as close as possible to Velocity 103 so as not to cross any “border”.
At the Planning Poker meeting, the team rolls cards 8, 8, 13, 5, 5, 8. They average the points and score Story Points for that User Story of 8 points time.
Answer of the Scrum Master: I would look for a little more detailed information why according to some of them we will need 13 and according to others 5, the difference is serious and good, and let’s discuss what exactly are the differences in their views.
At the Planning Poker meeting, the team rolls cards 3, 5, 5, 13, 21, 8. They average the points and score Story Points for that User Story of 13 points time.
Answer of the Scrum Master: Here we encounter even more serious differences of opinion. It will definitely be necessary to clarify what makes the particular technician assume 3 and what 21, in general, it has all kinds of values …. which would dictate many questions. It may be something completely unknown if the differences are such. Separately, I will ask why they averaged value of 13 after the model tells us a value of 9, I will ask about the method by which they considered 13 to be the better choice.
In the middle of a Sprint planning meeting, you are on your 5th sprint. The development team is taking their seats and you hear them talking that they are considering changing some of the technology they use for the product.
Answer of the Scrum Master: I would not interfere in their work if they considered it good to change the technology, they probably thought that this would not create delays or other obstacles in the current and upcoming sprints. The 5th sprint can really only be the beginning of this increment and this can be a big plus for our further actions.
Your director is calling you. He wants to hear as a guide how many User Stories and who specifically your team can do in the next sprint.
Answer of the Scrum Master: I would tell him that we do not usually make such sample predictions, as it almost always arises from something unforeseen by third parties or from customer additional priority services that need to be quickly inserted into the increment.
However, you can safely rely on the time frame that we have set for the whole sprint, it is something that the team pays close attention to. If it is of great importance, we can form regular informal meetings, which we can devote only to time planning.
The development team is discussing the idea of discontinuing work on the preliminary graphic design of project elements because they already have a known collection of developed components. Senior team members suggest that the new designer in the team stop designing his work and start checking the usability of the product.
The answer of the Scrum Master: The team solution sounds completely logical and necessary to me. However, the proposal of the seniors in the team will want to be directed to all of us, including the Product Owner, the junior designer and together we will decide whether it is necessary for him to stop or start QA. from him and whatever they share will be taken as pure coin and will not be communicated with us and with himself most of all.
Your Product Owner goes on a business trip again. He will not attend the Sprint Planning meeting. He tells the team to calmly choose a job for their Sprint Backlog list and set their Story Points. According to him, there is no interesting information that can provide them and his departure will not negatively affect anyone.
The Scrum Master’s answer: The Product Owner role should be maximally available to the Scrum team, as many of its functions and activities help to avoid ambiguities in the project.
Separately, with his approach, he should not give tasks, state, but rather ask what the team would need as details, given that he is not there. Sprint planning is a very important moment in the work of the team, in which to determine many of the time values that it should convey to our client. If you have no idea what we have predicted and set as sprint intervals, this would definitely have a negative impact on our team and client.
After 5 minutes, your Sprint Planning meeting begins. Your Product Owner tells you at the last minute that your client’s project manager will be present at the Sprint planning meeting because he expects some information from him.
The answer of the Scrum Master: I would initiate if it is possible for them to make the meeting with the project manager now (and to postpone the Sprint planning a bit) to gather all the necessary details that we will really need when planning with the team after that.
It would not be professional, but it would be more of a process to have an outsider in sprint planning. For some people on the team, it may seem inappropriate and worrying about such a visit, in general, I would consider it an attempt at “external influence” and I would divide the meetings tactically.
You have a sprint of 1 week. You settle in comfortably for your sprint planning and the product owner presents the Product backlog items he has chosen for the Development team to develop during the sprint. All product backlog items look clear and understandable.
Answer by the Scrum Master: The team has no questions about them and offers to start a quick prediction of the time of the items for the next sprint. I would ask the Dev team if these items (easy to implement) are really well and correctly selected and according to their expert opinion, whether given the previous backlog will not accumulate a large number of difficult and time-consuming to implement such further.
I will remind them that our sprints are only 1 week long and it is very important that we think carefully about the combination of items so that it does not turn out that we will have to extend sprints because we started with the clearest and most understandable ones.
It will also be good to plan a sprint for a sprint so that information does not mix and overlap, separately if we are planning another one, then this plan will not start a week in which everything can change.