The Sprint Planning meeting is one of several Scrum events during which the team, Scrum Master and Product Owner roles plan work for the upcoming sprint.
The following report shows common situations that may occur during the Sprint Planning meeting and prove to be problems for the Scrum Master and Development team.
Most of the examples are based on BVOP.org’s definitions and recommendations for the Sprint Planning meeting. BVOP created the description and recommendations, but we expanded the sample situations and analyzed each one below. All reactions to the problems are described in terms of the Scrum Master role in the team.
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.
This is a practice initiated by Scrum Master, not Product Owner. And in this assessment participate all of the Scrum team – Product owner, Scrum Master, Development team. Reference: Professional Scrum Master vs Scrum developer Scrum guide says that the points are from 0 to 3, not from 1 to 4. (Question to the mentor – Is this a problem – after all, in both cases, the number of levels is 4?) Reference: https://www.scrumguides.org/
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.
Sprint Planning Objectives: The development team to plan how many tasks it can complete in the next sprint and how it will perform it. So what the Product owner wants is something that is done in the planning itself, not the next day. At the end of the planning, the Development team should be able to explain how it will work as a self-organized team to get the promised increment.
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.
According to the Scrum guide, a 3-week sprint takes 6 hours of planning. With this hour and a half, there are two possibilities for me: 1. The obscure User Stories have been discussed too hastily and not everyone who will be in the sprint has been discussed, because they think that the others are clear without the need to discuss. 2. The team is already quite experienced and the Product Owner has described User Stories quite well, so they are clear and easy to understand and no long discussions are needed to understand them. Reference: What makes a good Product Owner and what do they do? scrumtime.org 2020 As a coincidence: The discussion of User Stories for their clarification and scoring took place at the Grooming Meeting (zero sprint). And now on 1 sprint, planning is easier and shorter.
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.
In addition to the Development team, this assessment should involve Product owner and Scrum Master, ie. 15 points are from 8 people. There are 2 options: 1. Maybe 5 people gave a grade of 3 and the other 3 gave a “0”. Two groups at both extremes. It needs to be discussed to understand where the problems are and whether there is anything else that is not clear about the sprint and the tasks in it to have such a big difference of opinion. 2. 7 people for 2 points and 1 gave 1 point. In general, in this case the team has some doubts about the success, but at least they have the same assessment. Again, they need to discuss why they are not quite sure of success.
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. 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 is a beginner, which suggests that even in planning there is no attempt to estimate which task will take how long. And as a beginner, he has not encountered a number of problems that “come out” in the development of seemingly easy to read tasks, and therefore gives low cards because he thinks he will quickly and easily cope with the task. Discussions end quickly because he easily agrees with the opinion of his experienced colleagues and therefore begins to give 13. I will encourage him to give as much as he thinks and I will make the team discuss longer. It may turn out that the more inexperienced colleague gives an idea to quickly and easily cope with the task, an idea that experienced members have not thought of. And so, after the discussion, the experienced colleagues should change their cards.
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.
This senior member of the team has a higher self-confidence for his skills and for that he quickly throws cards with low numbers, because his experience met him with a number of problems and he would easily solve the upcoming ones. I would advise him not to hurry and to think more deeply about what card to put. If he is so sure that he should be 3 or 5 in the discussions to explain his views to colleagues – he can convince them to change their cards.
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.
This is a task in which the entire Development team must participate, because they are the people who plan the work they will do. The Product Owner has no right to say who will participate and who will not. Planning is part of the sprint and has a regulated time for which the Scrum Master monitors and the work that is evaluated is only for this sprint, not all Items in the Backlog.
Senior Development Team members suggest that the Planning Poker game be played with open cards and their numbers visible so that beginners can more easily choose their card selection.
This is against the rules. Open cards eliminate the opinion of the individual and beginners could easily be influenced by the cards of senior members. The evaluation could be distorted because it will be the real opinion of part of the team.
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.
This should not happen. There should be a second play after the discussion. And to him, if the participant with the highest value has given reasonable arguments and examples of why he thinks so, he may have changed the opinion of others and they should give his number.
During your Sprint Planning, a senior member of the Development team clearly 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.
Product Backlog is something that can be constantly changed – to be supplemented with new Items, to remove others, to change the priority. Commendable for Product Owner that all the information is available and well described. The senior team member should explain in detail why he thinks that this User Story would hurt if he is there in the Backlog – he may be right, but in the course of the discussion, the other members may give ideas that he does not like. it occurred to me. In all cases, a unanimous decision is made and things change so that the team works as efficiently as possible and produces the most valuable increment possible.
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
I would advise them to remove 2 tasks: with points 3 and 1 and so the velocity will become 103. But if they are convinced that these are very short and easy tasks and will not burden them too much, I will agree and support them. . It is their choice how much work to take.
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. Reference: User Stories Real Example. How to create user stories. Example of Acceptance Criteria and Definitions of Done, brightonbot.com 2019
There must first be a discussion between the members with 5 points and the one with 13. Why those with 5 points give so little and why the one with 13 – so much. And to follow a new play-off in order to get closer points and then to average.
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.
This averaging is miscalculated. In addition, there must be a discussion. The difference between points 3, 5 and 21 is too big. Then make a new play and then average.
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.
They are the people who decide what they can make and what will be the way to deal with the items taken. At the end of Sprint Planning, they must explain to Product Owner and Scrum Master how they will work as a self-organized team to achieve a Sprint goal. The Sprint Review will also receive feedback from stakeholders on this change.
Reference: The Product Owner role in Scrum, projectmanagement.cloudaccess.host 2020Your 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.
If the evaluation of all User Stories is not done at the Grooming Meeting at the beginning – there is no way to say anything to the director and it is true, because this evaluation will be done by the team of the next planning. But if Grooming is legal, this assumption of mine will be very conditional, because I do not decide which and how many will be the next User stories. What I can do: I see how much Velocity is on the team and from the Product Backlog I take User Stories which are at the top with a total of Velocity, approximately as much as before. But I emphasize that there is no guarantee that the team will choose the same Items.
The development team is discussing the idea of discontinuing work on 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.
Senior members do not have the authority to tell anyone what to do. Everyone together in the team must decide how to achieve their goals.
If we are going to test whether the product can be used and whether it will cause bugs, the designer could test, but only if this is a pre-arrangement in the team and everyone agrees and he has the necessary competencies.
If we consider whether and how many users use the product – then this is not the job of the designer at all and I will be strongly against. The designer, as part of the Development team, takes care to work only on product development. Its distribution and imposition on the market is the concern of others. Reference: Scrum Master related situations concerning Product Owner, Development team and managers, projectmanagement.jdevcloud.com 2020
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.
After so many business trips, it’s time to think about a new Product Owner. According to Product Owner, he may not have interesting information and may think that he has described everything in detail and clearly, but this is not the case for the Development team. I will insist that it is available even with an on-line planning connection, and even then if questions arise during the work.
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.
It would be appropriate for the Product Owner to have collected this information earlier. I have concerns that the client’s project manager may interfere with the team’s decisions, start unnecessary discussions and disputes, and create unnecessary tension for both parties.
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 seem clear and understandable. The team has no questions about them and offers to start a quick forecast of the time of the items for the next sprint.
It is commendable for Product Owner that all items are clear and understandable, but it is not his job to choose which ones will work. It prioritizes the Product Backlog and developers start from the top, and the layout may change a bit.
Project Management, Agile and Scrum 