Sample questions for Certified Scrum Master Preparation

Preparing for the Certified Scrum Master certification exam takes time and energy.

To successfully pass your CSM, PSM, or BVOP exam, you need to not only know the Scrum Guide but also have a lot of additional knowledge.

Table of Contents

Preparation for the Certified Scrum Master certification exam with sample questions and answers

To easily and successfully take your ScrumMaster certification exam, we are sharing with you quite a few sample questions and their appropriate answers.

Product Owner states: Colleagues, I ask all of you to now predict the success of the sprint by giving a score from 1 to 4 where one would mean that we will fail to achieve our goal and 4 would mean that you predict a high success for the sprint.

I find the idea of ​​putting estimates on the perceived success of the sprint interesting, effective, and potentially productive for better planning.

In this situation, the only thing that bothers me is the clarification “at the end”. It is possible that the entire meeting went well and that reasonable planning was done, but it would still be good to keep in mind that additional questions for discussion may arise as a result of this group assessment initiative. Reference: “Scrum Master certification exam preparation with sample questions“, It is not excluded that everything went smoothly and yet when determining the final assessment, a discrepancy appeared between the colleagues, which would signal that some of them still had certain reservations that should be clarified. Therefore, it may be a good practice to allow a reasonable amount of time (albeit towards the end of the sprint) to allow the Development team to discuss any differences.

Another thing that seems essential to me is that the person who judges whether there is enough time for each “game” should be the Scrum Master. It is not a problem for the prompt to be voiced by the Product Owner, but it is still the Scrum Master who is responsible for the meetings starting, ending on time, and being as focused as possible. If in a specific situation, the actions of the Product Owner are coordinated with the Scrum Master, everything is fine. Reference: “Preparation for the Certified Scrum Master certification exam for PSM, CSM or BVOSM“,

At the end of the Sprint Planning meeting, your Product Owner stated Colleagues, it was an exhausting sprint planning and we all worked hard all day.

Would you be so kind as to send me and our Scrum Master tomorrow morning your presentation of how you would accomplish your tasks for the sprint and what your self-organization plan is? Thanks in advance.

I don’t find such an approach productive, I even suspect it would annoy colleagues, besides taking up their time. The meeting itself was held to clarify precisely the questions “what” and “how” will be delivered at the end of the sprint. The best way to do this is through discussion and using games like planning poker to focus the discussion on the essential issues. After the meeting has ended successfully, I don’t see the benefit of such a “report” from colleagues on the work done at the meeting. Source: “Preparation for PSM, CSM, and BVOSM Scrum Master certification exam with sample questions“, The Scrum Master can take notes with all the important moments of the meeting if he needs a memory stick or something like that… At the same time, the self-organization of the team happens… in a team spirit, therefore such a general presentation seems to require more additional time or a meeting and after the end of the planning… On the contrary, if everyone is expected to inform the SM and PO separately how they intend to organize and fulfill their tasks, the team spirit is completely lost and it resembles an unnecessary report/interrogation. Read more: “Preparation for Certified Scrum Master certification exam with sample questions”,
If the initiative of the Scrum Master and Product Owner is inspired by this quote from the Scrum Guide “By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.”, I do not consider it necessary to be literalists. This can easily be achieved through the good organization of the Planning meeting itself and within its framework. Source: “Preparation for Certified Scrum Master certification exam with sample questions“,

A three-week sprint awaits you, the team and the product owner have discussed the necessary details on vague User Stories. An hour and a half have already passed.

In a 3 week sprint, an hour and a half mean roughly 1/3 of our available time is running out. There is no way the team will work well in the future if there are unclear user stories and their clarification is key, including for prioritization. More on the topic: “Example questions for the Scrum Master certification exam“,
However, the important question here is how much of the specific sprint planning should be occupied by such activity. If the Product Owner has prepared well by prioritizing the backlog, the team should focus mainly on those stories and tasks that are the subject of the particular sprint. If this work has not been done and the team is still working on it, the allotted time of 6 hours may not be enough. As a Scrum Master, after the meeting, I would discuss this matter with the Product Owner to find a way together to improve the work for the future. At the meeting itself, I would also take measures by trying to focus the colleagues with questions about the current sprint and the specific tasks. Check original idea: “Preparation for the certification exam for CSM and PSM I (BVOSM) Scrum Master“,

During your Sprint Planning, you notice that a junior member of the Development team systematically throws cards that have the numbers 1 or 3 and always places his card last.

Other members choose much larger cards. This sparks a discussion every time, which ends quickly. Then that colleague of yours plays card 13 each time. Why do you think he does it? What exactly would you do?

Putting his card last is a sure sign of insecurity on the part of the more novice colleague. The fact that the ensuing discussion “quickly ends” is a further signal that he probably does not fully understand the complexity of the task at hand and finds it difficult to make an adequate (if we accept general opinion as a criterion of adequacy) prediction. Reference: “Certified Scrum Master exam preparation with sample questions“, The subsequent selection of cards with a higher value indicates the colleague’s attempt to adapt to the situation and possibly avoid uncomfortable discussions in which he probably feels unprepared and not particularly comfortable. If he had a solid reason behind his choice, he would defend it. I think that in this case, it is more about timidity, lack of confidence, lack of experience, and possibly knowledge. Another idea: “Preparation for the Certified Scrum Master exam (PSM, CSM, BVOSM)“,
I believe that in this case, the most favorable environment should be created for the colleague to adapt and gain the necessary experience. This doesn’t have to be done by putting the spotlight on him too intensely, but he shouldn’t stay in the shadows either, as he won’t be able to gain experience that way. Balance is important here. Perhaps I would have conversations with more experienced colleagues who can help him adapt more quickly. Read original article: “Preparation for Scrum Master certification exam on Sprint event“, On the other hand, I would also have a conversation with the colleague himself, if it is appropriate for his case, I would encourage him not to be embarrassed by discrepancies, even to ask questions to his colleagues when there is a discrepancy because this is the only way to his professional success and confirming him as part of the team. If it is appropriate for the particular team and the type of characters in it, even in a public discussion in front of everyone, the question of tolerance, team spirit, and mutual assistance between its members can be raised (either in open conversation, through a game or some other form). Read more: “Professional Scrum Master Certification Online“, (Visit the website here)

During your Sprint Planning event, you notice that a senior member of the Development team systematically throws cards that have the numbers 3 or 5 and always places his card first.

Other members choose much larger cards. Explain the possible cause and your actions.

Quick decision-making by the “senior” team member is probably due to more solid experience and knowledge. Perhaps he has worked on such projects and has a good idea of ​​how long the task would take to complete. The only thing to be careful with is whether he does not appreciate his capabilities.., in this particular case planning poker is a game for general determination of performance – by the team. If some of the members do not feel at home, the same tasks will likely take more time for them. Reference: “Preparation for Scrum Master certification and tips for Scrum professionals”, (Visit original website) Here, a discussion of the moment must be held and the reason for the discrepancy must be clarified for both parties to adapt (the experienced colleague to the possibly less experienced and vice versa). If the senior colleague knows ways to effectively speed up the work, he can share them with the others and thus achieve the most accurate possible estimate of the execution time. Original source: “Preparation with sample questions for Scrum Master certification exam CSM & PSMI”, (Check reference)

Right before your Sprint Planning event, your Product Owner informs the others that the beginners will not throw cards because there is a lot of work to evaluate, and in his judgment, there will not be enough time.

I will explain to the Product Owner that such a practice can be allowed under one extreme exception, as it is completely contrary to the idea of ​​a scrum. All participants in scrum teams should work as a team, like a well-oiled machine. Ignoring the opinion of some of them is belittling their participation, demotivating them, and at the same time taking away the opportunity to develop and adapt to the situation. If we destroy teamwork, it will have severe consequences for all our work, incomparable in scale to missing the specific deadline. Reference: “Free preparation for the Scrum Master certification exam (CSM, PSMI, PSMII, BVOP)”, (Visit the website here) The seniors will likely gain courage at the expense of the younger ones, this will give them the feeling that they are doing more and more important work. The rest will be united by a common feeling of being undervalued and neglected. And we have already created fertile ground for intrigue and conflict. Moreover, it is doubtful how the seniors will evaluate the skills and potential work of the junior experts – and that without taking their opinion into account. I wouldn’t like that kind of situation at all. I will do everything in my power to eliminate such practices – with diplomacy, with firmness, with patience – whatever will work for the particular team and situation. Read more: “Free training to prepare for the Scrum Master Certification exam”,

Senior members of the Development team suggest that the Sprint Planning event be held with cards open and their numbers visible so that novice participants can more easily select their card choices.

Here I would immediately take an attitude and support/praise/motivate the concern of senior colleagues towards the less experienced. Then I would concentrate a little more on the idea and meaning of this planning.  Original article is published on EduWiki: “Best Scrum Master Certifications for 2022 and 2023“, At its core is the idea that everyone independently determines the number they think corresponds to each task. I will note that it is especially important to be patient and attentive to more novice colleagues, who will take more time to achieve accurate forecasting. In the beginning, our collective effort to explain to them why an agreed-upon number should be of a different value than theirs will be key, but it is the only path to their successful adaptation and growth. Read more: “Best Scrum Master certification online”, If we allow them to “rewrite” instead of learning how to do it themselves, we will significantly slow their progress. I would use such an opportunity to create the most comfortable environment for beginners in the future, incl. and to avoid situations like #5 above.

This method proposed by colleagues will not clarify the depth of misunderstanding among inexperienced colleagues, and if we do not know the problem, we cannot solve it. I mean, if the novice X “rewrites” instead of showing the number that will give away how far from the truth it may be, no one will pay attention to it and get a mediocre explanation… Author’s original website: “Preparation for the Scrum Master certification exam (BVOSM, CSM, PSM)“, The opposite will cause a serious discrepancy to be registered, which will clear ambiguities and can enrich it with additional information. After all, in the scrum team, the capacity and knowledge of each team member are common assets, resp. general passive when absent. Everyone has an interest in everyone being as well prepared and useful as possible. Read more here: “Quick and easy preparation for the Scrum Master certification exam“,

After each “play” to select the Story Points of each User Story, the team discusses the differences in the numbers on the cards.

After the discussion, they guess the participant with the highest card value.

If this highest value participant is the same, it is probably quite persuasive or experienced. In any case, this phenomenon of divergence is desired and purposeful, that is why we play this game – so that by identifying the differences we can improve our work and find the most suitable approach. Reference: “Lessons for Scrum Master certification and practicing professionals“, However, the decisions of the team are always an indication of the attitude among them. If they massively choose the highest value, it shows that they are cautious or timid… If I have reasonable doubts that they will overestimate the tasks and end up with time left in the sprint, for insurance, I would consider the option to estimate more items to use, if the team finishes work earlier.
It is also possible that this trend is not something to worry about. If we have new technology, an unfamiliar product, or any other such factor, it’s normal for colleagues to have doubts and want to give themselves more time in case something goes wrong or needs additional testing. I will motivate them to argue more solidly for their choice and if I find a worrying/unconvincing argumentation, I will provoke further discussion on this issue.
(In any case, the selection of the final value of the task should not be made immediately after the discussion, but after a replay. The above applies if, despite the replay, they still chose the highest value).

During your Sprint Planning, a senior member of the Development team openly resents 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 states that if they develop this story in this sprint, they are likely to damage important architectural decisions. Your Product Owner emphasizes that his duties are to take care of the backlog and the development team to develop the product.

This is a particularly troubling situation in which I would immediately take action. The Product Owner cannot exceed his duties and disrupt the self-organization and freedom of work of the Development team. His role boils down to providing a backlog with well-prioritized and clear items. From there, the technology dependencies are defined by the team, they have the option to de-prioritize work on a certain item if it will create complications/double work/significant delay in the future. Only the development team can judge what they can complete during the sprint, without pressure or influence from other roles. In such a situation, I would tactfully explain what Scrum’s concept of role distribution is for the backlog, reminding all colleagues that teamwork is the most productive. Yes, it is the Development team who chooses how many items they can complete, but this work can be done as efficiently as possible with the help/advice/guidance of the Product Owner, as he communicates with the business people and knows the desired look best of the product the team is working on.
In the specific case, it is good to ask the question about the sprint goal and to track whether this goal is well defined, whether the selected items correspond to it and how the User story in question, which the Product Owner insists on, is included in this framework. In a spirit of understanding and constructive dialogue, we will find out exactly where the problem is and how we can solve it together.

The Development team has a Velocity of 103 points. For the Sprint Backlog choose User Stories with Story Points of 3, 5, 1, 8, 21, 13, 1, 21, 8, 8, 13, 5

The total of all User stories is 107, more than the team pace by 4 points. This is a stand-alone reason to drop one or more stories from the “must” list for the sprint so that the number is close to or equal to the team’s defined velocity.

On the other hand, the diverse nature of the tasks included in the backlog is impressive. A task with Story points: 21 carries the risk of complications and a theoretical increase in development time. Although tasks with fewer story points may offset larger ones, it is good to have a buffer when there are more complex tasks for which the team has determined more story points.

At the Sprint Planning event meeting, the team rolls 8, 8, 13, 5, 5, and 8. They average the scores and score Story Points for that User Story of 8 points of time.

Here, averaging can “hide” a potential problem to be found at a later stage. It is good that there is unanimity between three of the members, but for sprint planning to fulfill its function, it is good to provoke a discussion between those who threw cards 5 and 13. After they have presented their arguments, the floor can also be taken by other team members. This will ensure that there is no legitimate concern of the colleague who chose card 13, which will be ignored, or that a good optimization idea will be missed by those who chose card 5.
Such a vote may not always be a signal of a real problem, but all signals should be checked in time to avoid unnecessary crises later.

At the Sprint Planning meeting, the team rolls cards 3, 5, 5, 13, 21, and 8. They average the scores and score Story Points for this User Story of 13 points of time.

The idea of ​​averaging is to choose the most accurate value that reflects everyone’s assumptions simultaneously and as closely as possible. However, this is only possible if the selected values ​​are relatively close. This is not the case, and in practice, a result is obtained that approximates the guess of a single team member. I believe that here the team should hold discussions until the values ​​are close to each other with a difference of about 2-3 (maximum 4) points on average. More than 10 is too many and starts to look like lotto chance voting. I realize that complete agreement cannot always be reached, but perhaps stimulating a dialogue mainly between those who chose cards 3 and 21 would go a long way. Once they are the ones who present their views as a starting point for discussion, the others will chime in, bringing even more clarity.

For me, 13 points in this situation is not a workable solution, if there are too many unknowns or it is not on the agenda, this is exactly what we could do and at a later stage, we could hold a vote again. If not, repeat discussions until the values ​​converge or at least discover the unknown.

In the middle of the Sprint planning meeting, you are on your 5th Sprint.

The Development team takes their seats and you hear your colleagues talking to each other that they are considering changing some of the technology they are using for the product.

This sounds like a very risky move that should be carefully considered and widely discussed by all members of the team. As a rule, the choice of technology is made at the very beginning of the work, not at such a late stage. Such a choice must be very well justified, be following the requests of the customers and the indicative terms and appearance of the product set by them (and not a risky self-initiative of our head). At the same time, even if the request comes from the business persons, it is still possible that it is not appropriate and it is necessary to explain to them in detail all the risks that such a move entails.

A technology change can send us back to square one, undoing all the progress we’ve made so far. It is precisely for this reason that we will discuss this issue as soon as possible. Already at this meeting, it should be clear where this idea comes from, including the opinion of the Scrum Master and each member of the Development team.

Your director is calling you. He wants to hear as a guide how many User Stories and which ones specifically your team can do the next sprint.

I cannot refuse to provide the director with information, but I will certainly clarify that what we have is always indicative. Working in scrum conditions provides flexibility and adaptability that would be impossible if we had the tasks for all sprints scheduled in advance. The tasks for each sprint are selected by the team itself from a prioritized list for the purpose. I will make sure to get information from the Product Owner about which stories from the backlog we expect to be included in the next sprint (more like a general material scope – “work on some functionality” than a breakdown of a specific number and type of tasks). Of course, these follow-up tasks must be estimated and at least tentatively prioritized.

Even if I get relatively accurate information, I will again remind you that the work is dynamic and change is possible (because of new requests from business people, because of technological reasons/problems/considerations, and the outcome of even the current sprint).

The Development team is discussing the idea of ​​suspending work on the preliminary graphic design of elements of the project because they already have a known collection of developed components. Senior members of the team suggest that the new designer on the team stop his design work and start doing usability tests of the product.

Choosing at what point to stop developing a component and start testing is a decision that should be made by the Development team. In the latter, different specialists with diverse experience often take part, and the discussion between them is the most constructive way in which the problem can be solved. As a scrum master, I will create all the conditions for a productive dialogue. If this discussion directly concerns the appearance of the product or the deadlines for its delivery (by which we are all limited), then it is appropriate for the Product Owner to take part in it.
Depending on the specific case, such an idea can be good or bad. The answer will be found in the dialogue between all team members.

Your Product Owner is away on a business trip again. Will not attend the Sprint Planning meeting.

Tells the team to feel free to choose work for their Sprint Backlog list and set their Story Points. According to him, there is no interesting information he can provide them and his departure will not affect anyone negatively.

There is something very positive about this situation, and that is the supposed freedom, self-organization, and initiative of the team. Once the Product Owner has given them such confidence, it’s probably not the first time they’ve successfully handled item selection and all sprint planning tasks. If the backlog items are relatively familiar, the work is of the same type, and there is nothing to clarify, the provided backlog with clearly prioritized items is sufficient.

It is not a good practice anyway for the Product Owner to regularly be absent from the sprint planning. This event is particularly important for the successful execution and completion of the sprint. If this situation is repeated often, I would talk to the Product Owner about the importance of his presence. If we have encountered problems in the past due to ambiguities or other types of lack of cooperation on his part, I would also point to this as an argument. Naturally tactful, tolerant, and respectful, without in any way causing conflict or showing a lack of understanding of his ‘busy schedule’.

In 5 minutes, your Sprint Planning meeting starts. 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.

Perhaps the Product Owner acts this way because the information that the project manager will provide him is key to determining the priority tasks for the sprint planning. Reference: Otherwise, I don’t see why he would need this involvement so urgently at the last minute, probably he didn’t organize himself well or there were emergencies. Either way, knowing the team well, if I know it will embarrass them or affect their organization badly, I will discuss with the Product Owner that the team’s work during the sprint planning is very important and the whole sprint can fail. if tasks are not planned well. As a compromise, I would suggest that we spend time at the beginning of the meeting to clarify the necessary details by PM to the client, and then let the team continue with their regular tasks during the event undisturbed. This can be announced at the beginning of the meeting itself.

Of course, if in the specific case it won’t hurt or I have too little time to react, I would exceptionally allow such a phenomenon. However, having a representative of the client present at the planning seems risky to me, it can put unnecessary pressure and tension on the team. I would certainly have a conversation with the PO about the necessary calm and productive environment we are required to provide the team. Such surprises can have a very bad impact.

You have a 1-week sprint. You get comfortable with your Sprint Planning and the Product Owner presents the Product Backlog items he has selected for the Development team to develop during the Sprint.

All items seem clear and understandable. The team has no questions about them and suggests that they start quickly forecasting item times for the next sprint.

Usually, such short sprints are done on relatively clear, short, and even monotonous tasks. Reactions of team members (calmness, clarity) – nothing suggests that any member has questions, concerns, or the need for further discussions. The only thing that seems wrong to me is that the Product Owner specifies everything that needs to be worked on during this sprint. His role is to provide a prioritized list from which the members of the development team can choose the individual tasks themselves. Such a situation calls into question the work in a team spirit and with the presence of sufficient freedom at the disposal of the Development team. If the latter is used by the Product Owner to determine the volume and type of tasks without their active participation, this is a violation of the basic principles of self-organization and initiative. If such a problem is identified, the Product Owner should step back from this more project management role and let the team be guided only by questions and recommendations, not by strict instructions to follow.

Leave a Reply

Your email address will not be published.