The certified Scrum Master must have an excellent performance during the Sprint Planning meeting in Scrum. Otherwise, the Development Team and the Product Owner role may waste time and fail to plan work productively.
The certified Scrum Master must pay attention to every detail and stop unregulated actions. Reference: BVOP Certified Scrum Master, https://bvop.org/scrummaster/ Also, the Certified Scrum Master must monitor the reactions of all participants in the Scrum team. The team defender must break any negative attitude from both the Product Owner role to the programmers and between the individual developers.
A Certified Scrum Master shares best practices
Certified Scrum Master Robert Smith sent his collection of good practices to follow during the Sprint Planning meeting. Here they are.
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. Reference: A certified Scrum Master shares the Daily Scrum event, https://projectmanagement.freesite.host/a-certified-scrum-master-shares-the-daily-scrum-event/
The certified Scrum Master responds
This type of assessment of the expected result is part of the role of the Scrum Master. The product owner has other commitments, but this practice has to be offered and initiated by the Scrum Master. The numbers for expected success are from 0 to 3, not from 1 to 4. (Actually, I don’t know if they have to be from 0 to 3 and if they can’t be used from 1 to 4. For me, the logic is this – 0 means nothing, no success.) Please for a little clarification here. As a Scrum Master, I will remind my fellow Product Owner of my role.
At the end of the Sprint Planning meeting, your Product Owner states: Colleagues, it was exhausting sprint planning and we all worked hard all day. Would you be so kind as to 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.
Certified Scrum Master Response:
And in this situation, the Product Owner takes on the role of Scrum Master. The scrum master is the one who has to keep track of the duration of the sprint planning and everything that is within the sprint planning. Reference: What is it like to be a Scrum Master, https://projectmanagers.edublogs.org/2020/09/14/what-is-it-like-to-be-a-scrum-master/
The Scrum Master role ensures that the Scrum team adheres to the time limit of the meeting, as well as keeps all participants focused and monitors for violations of Scrum principles and rules. The meeting should include 2 essential points – WHAT will be fulfilled and HOW will be fulfilled. So it should not end, despite the fatigue of the team and its duration, only with the first point WHAT. At the end of the planning, you need to know HOW. It is very important in the presence of all to debate the ways of implementation and to be understood and accepted by all. The discussion should be live, with the participation of each of the Development Team. If there are any disputes or debates, they should clear the final decision on which the team rests. Reference: Responsibilities of the Scrum Master role, https://projectmanagers.joomla.com/11-responsibilities-of-the-scrum-master-role.html
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.
Good practice
For a 3-week sprint, the optimal duration of Sprint Planning should be 6 hours. If 1.5 hours have been missed and unclear stories have already been discussed, I will direct the team’s work to a relative assessment of each story’s time, breaking down smaller tasks into each story, and setting a time estimate for those tasks as well. I will make sure that the work of the team goes smoothly because there must be time left to decide on the tools HOW to do what is necessary to obtain the increment at the end of the sprint.
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
Since so far only the Development team has given their numbers, both the Product Owner and the Scrum Master should give numbers. After adding their numbers, the expected success of the sprint will be calculated. Otherwise, the number of the development team is close to the maximum – 18 (6 developers with 3 maximum points, if everyone gave, means that 18 is the maximum number of expected success). If the addition of the numbers from the Product Owner and the Scrum Master does not result in a number close to the maximum, we will conduct a short discussion for possible pressures. If by adding their numbers the final result is close to the max, I will thank everyone and close the sprint planning meeting. Reference: How to become a Scrum Master? https://brightonbot.com/how-to-become-a-scrum-master/
During your planning meeting, you notice that a novice member of the Development team systematically throws cards that have the numbers 1 or 3 and always puts his card last.
The other members choose much larger cards. This provokes a discussion every time, which ends quickly. Then this colleague of yours plays card 13 every time. Why do you think he does it? What exactly would you do?
He does it because he is a new member of the team – he may be worried about his inexperience as a young professional or he may not have been in a Scrum team before and may not understand the importance of planning meetings.
Low numbers mean an estimated low difficulty of the task and therefore requiring little time and effort from the team. I will explain to him the meaning of evaluating the relative value of time (he may not have heard of it and does not know what it is). Placing the lattice 13 each time after the explanation may mean that he either did not understand how to assess relative value and need re-explanation, or fear as an inexperienced new person to reinsure and therefore gives a middle card environment ”).
We will talk again about the meaning and significance of this type of assessment through play and I will ask the next sprint planner to be the first – to put his card first. I will ask him to explain to the team why he thinks that each story is of average sadness for him – he may need a professional discussion with other Scrum developers. Reference: Professional Scrum Master vs Professional Scrum Developer, https://stc-montreal.org/professional-scrum-master-vs-professional-scrum-developer/
During your planning meeting, you notice that a senior member of the Development team systematically throws 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.
RESPONSE FROM THE SCRUM MASTER
Being a senior member, he is supposed to be experienced and knowledgeable. This gives him confidence in his judgments and therefore he can put low cards – the tasks for him do not seem so difficult and do not require much time. Putting your card first can mean that he makes a decision faster and evaluates things faster. At the end of the evaluation by everyone, I will ask him to explain his motives and the reasons that lead him to these evaluations. He may know methods and methodologies that other members know. Getting to know them will benefit everyone. But, although he is experienced, as we all know – there are no sinless people. In the debates with the other members, his mistakes may be found or it may turn out that a given assumption of his completion of a task / s hides a difficulty that will require more time to overcome. I will suggest, after such a situation and the debates, at least to play again.
Just before your planning meeting, your Product Owner informs the others that the beginners will not throw cards because there is a lot of work to be done, and in his opinion, the time will not be enough.
Product Owner cannot take over the Scrum Master function. If there are any concerns about the judgment of the novice team members, you should discuss them in advance with Scrum Master. Scrum Master, for his part, will remind the Product Author that absolutely everyone on the team must give their assessment. Regardless of everyone’s experience, the cards are thrown by everyone.
The assessment of the sufficiency of the time for sprint planning is in the hands of the Scrum Master and he leads the meeting and monitors its duration. The participation of everyone, in addition to being mandatory, provides experience and opens debates that are important and necessary for the success of the sprint and each subsequent sprint thereafter.
The role of the Scrum Master monitors the honesty and equality of the members of the team, as well as for everyone to be satisfied with their participation in the scrum. Reference: Scrum example team and projects scenarios, https://phron.org/scrum-example-team-and-projects-scenarios/
Senior members of the Development team suggest that a planning meeting be held with open cards and their numbers visible so that novice participants can more easily choose their choice of cards.
I will add that this should not be accepted because it deprives novice team members of the process of thinking and forming their judgment. The rule is that everyone gives a card and the cards are upside down. Beginners will adjust their assessment, if necessary, during the debate. This way they will gain much more lasting knowledge and will be able to do it much faster in the next sprints. This situation also violates the principle of scrum because it divides members into leading roles. I will also point out that there is no leadership or leader in the scrum. In scrum, everyone is equal to everyone. The role of the Scrum Master is to ensure that this is not violated. I will suggest to the team to encourage beginner members by giving them the option to discard their cards first.
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.
During scheduling, the Story Points of each User Story are taken as the average value between all given numbers by the members. I will remind that of the team. It is not right for the team to take the highest number, because this will disrupt the time of the sprint and it will turn out in practice that the team will be ready with the increment earlier than the end of the sprint. If the Scrum Master was a traditional project manager, they would take care of all estimation mistakes again. This is what makes a manager a true professional. Reference: Qualities of the certified project manager, https://projectmanagement.over-blog.com/qualities-of-the-certified-project-manager.html
During your Sprint Planning, a senior member of the Development team complained about 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 states 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 development team is self-organizing and this is a leader in the work under Scrum. Only its members can choose and decide how much work they can take in a sprint. Although the Product Owner has prioritized Product Backlog Items and given a maximum explanation in User Stories, developers will decide whether to take the next priority task or the next.
If there are any pressures on the item on the agenda regarding its implementation in the product, developers can leave it waiting. And the product owner should not interfere in this. He may be asked to take more information from the stakeholder or the team to give an idea later to solve the problem item. The number of replacement items must cover the velocity value of the development team.
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
THE CERTIFIED SCRUM MASTER RESPONDS
The selected user stories exceed the speed of the team (their total is 107). The cant is 4 points. I will suggest to the team to reconsider their choice and remove two (3 and 1) with a value of up to 4. To leave them as an additional task that can be done if they deal with Sprint Backlog earlier. We can also test the following situation – Since the cant is not with many points, they may think and leave it like that, but I will increase the attention around the fact that the sprint must be completed on time and the team must leave nothing for the next sprint. Just choose what to do.
In the middle of a Sprint planning meeting, you are on your 5th sprint.
The development team takes their seats and you hear them talking that they are considering changing some of the technology they use for the product.
The team chooses the tools and technology it works with. If this is said officially during the sprint planning and discussed, it can be accepted as an official proposal by the team, not just a comment. I will emphasize that new things in the middle of the project or an already advanced project should be considered whether they will not affect the speed of work and instead of helping, slow down the project. If the team decides to do so, I will make sure that this is foreseen by them during the time assessments. The implementation of the new technology should be included as a separate task/s.
Your director is calling you. He wants to hear as a guide on how many User Stories and who specifically your team can do in the next sprint.
I will explain to him that I can not give specifics in advance in the choice of user stories, because the team decides which and how much to choose. Self-organization is part of working at Scrum. I can give the director’s answer after the sprint planning meeting is over.
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 to the new designer in the team to stop the design work and start checking the usability of the product.
The decision to do so should be made by everyone, not senior team members. Moreover, this is the task of the designer. He must decide for himself what exactly to do and discuss this with everyone. Team members are equal to each other and this cannot define seniority roles. The designer may have looked at the components already developed and give his suggestion or ideas that the client will like much more. The advice to him for checking the usability of the product can interfere with the work of testers, who do not need such a thing at all.
Your Product Owner is missing
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.
I will take on his role. As part of the Scrum Team, I am familiar with the course of the project, details, comments, what has been done so far …. If necessary and ambiguities, despite his opinion that everything is clear and there is no interesting information, I will communicate with him or the client. The development team may have questions, may need clarifications, clarifications, and more details. (Reference: https://agileprojectmanagers.blogspot.com/2020/10/scrum-master-answers-questions-of-their.html)
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 your Sprint planning meeting because he expects some information from him.
ATTENDEES AT THE SPRINT PLANNING ARE THE ENTIRE SCRUM TEAM (DEVELOPMENT TEAM, SCRUM MASTER, AND PRODUCT OWNER ROLE).
Interested parties may be invited to provide additional information, although this is rare and it is the responsibility of the Product Owner to provide all available information.
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 items look clear and understandable. The team has no questions about them and offers to start a quick prediction of the time of the items for the next sprint.
Product Owner cannot select items. The choice is made by Scrum developers. Only they can decide and select those items that will end up in a sprint. I will recall this in the Product Owner role.