Preparation for CMS and PSM Certified Scrum Master exam with sample questions

Preparing for the CMS and PSM Certified Scrum Master exam with sample questions is much easier. If you are just trying to memorize the whole Scrum Guide. It is not easy to win the title of Certified Scrum Master (PSM or CSM).

Without diligence, reading, and learning you will not be able to pass your exam. In the article, we share many topics that directly affect the Scrum Master and share possible correct reactions. Reference: “Preparation for the Certified Scrum Master exam (PSM, CSM, BVOSM)“, https://mpmu.org/preparation-for-the-certified-scrum-master-exam-psm-csm-bvosm/

Your team is very eager to go on holiday and asks you to postpone the retrospective of your sprint to the beginning or end of the other sprint.

The team itself, by consensus, decides how long the sprint should be. Retrospection is part of the sprint that was planned before the team went on vacation, it should not be counted as part of the next sprint – ie. even if it is done purely ‘at the beginning of the next sprint, the day/days of retrospection will be counted as part of the first sprint. Ie it will be extended. More Scrum topics: https://customessaysonline.net/

If the team agrees to postpone the retrospective until after the holiday – OK. If the team has the opportunity to finish the job faster than planned so that the flashback can be inserted before the holidays – I think it’s better. But it all depends on how fast the team works. It may not be possible.

The most effective flashback is done ‘while things are still fresh, important things may be forgotten while the team is on holiday. But I do not think there is a problem to postpone if everyone agrees.

The client informs you that he/she is starting repair procedures in his / her office and asks you to send him/her a summary by e-mail from your meeting with the team and your opinions about the Sprint Review meeting. He trusts you completely for your analysis.

It sounds a bit illogical that the client did not want/had the opportunity to participate in the sprint review meeting – however, the meeting is aimed at presenting what has been done and getting feedback from the client – ideas, opinions. If there is no feedback, the team decides to go in the wrong direction in its development or to lose the direction altogether.

It should not be a normal practice in Scrum for the client not to participate in case he cannot participate, and at the risk of the sprint taking a long time (we do not know how long this repair will take), I would prefer everyone to attend. If there is no such possibility, I will consult with the Product Owner – let him decide whether the increment is so important at all that we can not do the review without the client. Much depends on what has been developed in the sprint – maybe not everything is so important to the client (although it sounds strange). Reference: “Preparation for Scrum Master certification exam on Sprint event“, https://medfd.org/preparation-for-scrum-master-certification-exam-on-sprint-event/

Your principal has heard that your Sprint is over, but there is unfinished business. He is angry and asks you to remove some of the big User Stories from those planned by the end of the sprint and replace them with smaller ones that you can find in the general list.

We have already explained that the director has no role here, but it is OK that he is addressing me. I will talk to the Product Owner – I will explain to him that the desire comes from the director, as Scrum Master cannot, under his responsibility, move, prioritize or divide and collect User stories. If the Product Owner agrees to think about it, I would expect him to discuss with the team whether they agree to move/split the tasks and whether they are well enough described. Reference: “Preparation for Scrum Master certification and tips for Scrum professionals”, https://www.kievpress.info/preparation-for-scrum-master-certification/

The team informs you this morning that they are ready with all their work two days before the end of the sprint and ask you to arrange a meeting with the client to hold a Sprint Review meeting with him and start the new sprint tomorrow. While you are at the Sprint Review meeting, they will attend an interesting company training, but promise to make amends by asking the HR department to give you an extra day off this year.

As written in the lecture, the Scrum bagpipe does not give clear guidelines on who exactly should present to the client (but it is mentioned, however, that it is most often either Product Owner or Scrum Master).

The team is obliged to follow the Scrum rules and principles. Also, ‘Everyone participates with Scrum events, does not miss them and ignores them and realizes the importance of the events and their participation.’ Read more: “Preparation with sample questions for Scrum Master certification exam CSM & PSMI”, https://wikipedia-lab.org/preparation-sample-questions-scrummaster-certification-exam/

The best option is for the whole team to be on-site during the presentation, but if it’s just one time and company training is important (often these company training are done for all teams at once, I should not ignore it just because it happens on a not very convenient day for my team), I think to compromise. Yes, it has its positives in seeing people’s reactions when the product is presented – including the reactions of developers or if there are any questions that Scrum Master / Product Owner cannot answer. If the team thinks it is good that the company training is important or interesting, that the two meetings should be exchanged – OK.

The Development team informs you that they prefer not to work with a fixed time for sprints, but prefer each sprint to have a duration according to their work and judgment. They have already discussed this proposal with the Product Owner role and he said he has no claims.

The sprint must be work-oriented so that at the end of each sprint, a working result can be delivered that can be demonstrated to stakeholders and stakeholders.
The sprint, or sprint work, must be ‘comparable’ to a previous sprint. This is done to facilitate the estimation of tasks to maintain the rhythm and cyclicity of the process. So that team members can get used to the pace and be more efficient.

How long the sprints will be is determined before planning the work on the product, and is not something that changes over time. However, on the other hand, according to the definitions in the Scrum bagpipe, the team decides how long the sprints should be. Read more: “Free preparation for the Scrum Master certification exam (CSM, PSMI, PSMII, BVOP)”, https://brightonbot.com/preparation-scrum-master-certification-exam/
For security reasons, I would just like to introduce the team to the above. If the team still keeps the length to plan from sprint to sprint and everyone agrees – OK.

Your assigned Product Owner on a project goes on a business trip to the client and sent you a Sprint Goal this morning for the next sprint. He has also made a collection with all the user stories that the team will work on.

He was in a bit of a hurry to go on a business trip. My comment is as follows:

The Sprint goal is determined by the whole team, not just the Product Owner. It’s unprofessional for the Product Owner to email it and run away.
Not everyone on the team may understand it.

Practically, you write in the lecture that many teams do not. If he still wrote something in the e-mail and ‘was a whip’, then the team can simply ignore it and either create another – more understandable goal or just work without a sprint goal. ead more: “Free training to prepare for the Scrum Master Certification exam”, https://www.islandjournal.net/scrum-master-certification-exam/

The Product Owner cannot be sure that the team will agree to work on all user stories. The team decides which tasks to work on in the sprint and how exactly to prioritize them in the sprint itself.

The team will not be able to work on user stories that have questions and ambiguities.

If there are any questions or ambiguities, they should be clarified by the Product Owner, or a non-Product Owner should be reported so that he can clarify them with the stakeholders. The development team cannot contact the stakeholders directly, and even if this is allowed, we run the risk of remaining unclear anyway (given that the two groups of people have different qualifications, understandings, and ‘speak different languages’). That’s why it has a Product Owner role – so that it can be the link between these two groups.

The Product Owner of the project has sent you an email stating that he will collect detailed information on many details and plans to communicate with the client on an ongoing basis so that he can describe as many details as possible about the work for a long time to come.

I’m not sure I have any comment here. If the Product Owner considers this necessary, and if there is enough information about the details he wants to describe from what is described in the backlog – OK.

However, it should be clarified that the details can change quite, quite quickly, and often – when errors or inconsistencies are found in the work process or the development of new functionalities is required. Things can change literally from sprint to sprint – so ‘for a long time to come is a little disturbing 🙂 Read more: “Best Scrum Master Certifications for 2022 and 2023“, https://eduwiki.me/best-scrum-master-certifications-for-2021-and-2022/

You are returning from vacation. The project team and Product Owner tell you that there is no time and the sprint should start without planning, as the team will work independently and choose User Stories, ranked at the top of the Product Backlog collection.

The team knows best what to do. The fact that the decision has not been communicated to me should not be an obstacle. There is a belief of the team that he will be able to plan himself (he MUST plan himself) what to do and which user stories to decide as to the highest priority. Moreover, this was decided with the participation of the Product Owner.

All they have to do is try to finish everything on time by the end of the sprint, so that the development, the test, and the approval of the client fit in the time frame. Read more: “Best Scrum Master certification online”, https://scrumtime.org/best-scrum-master-certification-online/

The Product Owner role has told your team that some functionality is expected in a few months. Your team plans to do technology research from now on to save yourself any problems and lack of competencies over time.

Sounds a bit like the ‘distractions’ mentioned in the lecture. The team should focus primarily on the current sprint, not the sprint, and work in a few months.
If it is so important to start the study now, I will suggest that this be registered in the system as a task to be completed with this sprint (the study itself) to get a real idea of ​​how long this thing will take and exactly how much of the other work planned in the current sprint to move for later (if necessary).

A member of your team who is planning to go on vacation soon has just started working on User Story, which is expected to be planned for the next sprint.

I will not cut off his head. I will ask him why – if it is because he has done his thing for the current sprint. Moreover, User Story is expected to be planned, or may not be planned for the next sprint.

A member of the team expresses dissatisfaction with the idea that everyone knows what the other is doing. He is used to solitude. He prefers to work without explaining exactly what or seeing his work in software systems. It guarantees that it will deliver very good results and on time.

I will try to talk to him and explain to him that one of the main principles in Scrum is that everyone knows what everyone is doing so that the work can be synchronized and possible mistakes (due to misunderstanding or simply ignorance) can be seen in time. and to be resolved in time. I will not underestimate his abilities by questioning his work, but I will emphasize that teamwork requires everyone to be aware of everything. Just as other team members share with everyone (including him), so will he.

A colleague of yours, Scrum Master from your organization, meets you in the hallway and asks for advice on the length of his team’s sprint. None of the teams can offer a duration for their sprint. He asks you to recommend a time for their sprint.

Of course, I would help him, but I can only if I know in advance the product they are working on and how and how fast their team is doing. The second will eventually require me to observe their work for a slightly longer period.

The Product Owner role of your team wants to change the duration of the sprint to 6 weeks as you start integrating very complex systems and does not want to discredit yourself, your team, and the organization in front of the client with sprints where you risk not being able to deliver real work done.

How does the rest of the team react to this? If they agree, no problem. Scrum recommends a sprint duration of up to 4 weeks, but this is not the rule. The longer the sprints, the more part of the project will be expected to be completed, which speaks of the complexity of everything else related to the development – development, test, etc. Original source: MuzoNet Management and Business: https://www.muzonet.com/

You receive an email from your client’s Project Manager. He asks you if there is a problem if your sprint is 6 working days. He expects a quick response so he knows what to pass on to his superiors.

Again – if the whole team agrees and we can clarify, develop, test everything in 6 days (plus all other Scrum events), that’s OK.

Your director tells you that he has read a lot of information on the Internet about Scrum and asks you to set a time for your sprints to be one working week to reduce any risk.

I will discuss the proposal with the team – if everyone thinks they can finish their work in 1 week, OK.
In none of the above considerations did I mention that the shorter the sprints we have, the more often we have to meet the client at the end of the sprint. This must be following their schedule and capabilities.

Scrum or Kanban

Scrum is used to organize the work of small, manageable pieces that can be completed by the team within a certain period (usually 2-4 weeks).

Kanban is also a tool used to organize work for efficiency. Like Scrum, Kanban divides work into manageable pieces and uses the Kanban Board to visualize current work.

While Scrum limits the time to perform a certain amount of work (through sprints), Kanban limits the amount of current work. The aim is not to accumulate started but unfinished work, which will distract employees and thus make mistakes and reduce the quality of performance.

Both Scrum and Kanban are agile approaches designed to improve workflow and teamwork for optimal results.

Scrum features

• The team consists of Scrum Master, Product Owner, and members
• The tasks of the team within the sprint are visualized in columns according to their status from their creation to their completion
• Scrum processes are focused on scheduling the execution of a prioritized to-do list.
• At the end of each sprint
• No change is made within the sprint
• Velocity

Kanban features

• There are no roles
• Tasks are displayed in columns according to their stage of work, with a limit on the maximum number of tasks in a column
• There are no periods or iterations. Work is a continuous iterative process.
• Continuous
• Anytime
• Execution time, the volume of current work

What Scrum and Kanban have in common

• Preview (Board)
• Schedule
• Delivery
• Philosophy for change
• Metrics

When to use Scrum?

Scrum is an ideal approach for projects that require very short deadlines from idea to basic implementation and subsequent periodic improvements. The team works with clients throughout the project. It takes good planning for each sprint to achieve certain goals at the end.

When to use Kanban?

Kanban is more suitable for projects or teams working with constant changes such as support, helpdesk, sales related to human resources, and the like.

Using either approach or a hybrid between the two depends on many factors and is not in itself a guarantee of success.

Whether to use Scrum or Kanban to improve the workflow and achieve better results depends a lot on the teams, projects, or the nature of the work, and last but not least – on the customers.

Each approach has advantages, but may not be appropriate in certain projects or activities.

I recommend piloting Scrum and Kanban in small uncritical projects for the company to assess which approach would be more appropriate and to test the understanding of all stakeholders about the nature and benefits of the different approaches.

Why do you want to be a Scrum Master?

The idea to specialize as a Scrum Master originated in 2018 after I moved from a large company with very strict processes and dozens of Development teams to a startup of 7 people.

As we are building a complex platform, in the first month I noticed how unorganized, messy, and not adaptive work is between the product owner and the development team. So I decided to apply principles and a structure based on the Scrum Framework to optimize processes and help implement the given artifacts.

What do you expect to be a Scrum Master?

The main expectations from taking the position of Scrum Master are mainly related to the principles of the framework. Since the Scrum Master owns the process, I will make sure that the teams monitor the Scrum processes and will also work with them to improve them continuously. This also applies to meetings such as the Daily Scrum, where I have to guide the team to keep to the meeting time and not lose focus. And this often happens, especially in a startup environment. All this is to optimize the time, teamwork, and processes to create the best possible increment based on the tasks.

What are the things that worry you the most at this stage?

Change takes time. I have repeatedly witnessed leaders trying to implement a specific framework or agile process, but there is a lot of resistance from the team itself, as they are already used to their process and do not want to adapt. This is one of the things that every Scrum Master is worried about or finds difficult to implement the framework successfully so that everyone involved can understand and practice it successfully.

What problems do you think you will have in your work?

In a startup environment, it often happens that each team member wears several “hats”. In the rush to create an end product for your first customers, you often forget about process optimization and structure work. Simply because one person is responsible not only for gathering information and prioritizing the Product Backlog but sometimes for performing some of the tasks. This makes it difficult to implement the Scrum framework, where each role performs specific things. This is one of the problems that Scrum Master would face at work.

Other problems that may arise are related to the management of role expectations and last-minute urgent changes during Scrum. It often happens that the director suddenly comes up with a very important idea that comes from our first clients and is set as the number one priority to win short-term victories. This ignores the Scrum Framework and disrupts timeboxed events.