2021 Vol. 1

Preparation for Scrum Master certification and tips for Scrum professionals

Preparing for Scrum Master certification

Preparing for Scrum Master certification requires deep knowledge of Scrum rules. However, real professional situations and conflicts happen every day in the office. That’s why we offer you several potential situations that can happen in your Scrum team.

All issues bellow are in the context of the Sprint event. The Scrum Master role places central role in all issues. Reference: Best Scrum Master Certifications for 2021 and 2022,

You can use this Scrum exam preparation post for free. The use of these sample issues in your professional daily work is also permitted.

The preparation materials are suitable for BVOP, CMS, PSMI, and PSMII. Reference: “Sample Exam (Mock) Questions for the BVOP™ Certified Scrum Master Certification Test”,

Preparation for Scrum Master certification

Long-term planning by the Product Owner role

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 continuously with the client so that he can describe as many details as possible about the work for a long time to come.

In this situation, the Scrum Master should have a conversation with the Product Owner. You have to convince him to look at this situation from another angle. If the Product Owner, after communication with the customer, describes the most details about the work for a long time ahead, this can lead to losses.

Many modern products are dynamic, depending on many factors related to consumer needs, expectations, emotions, mood. The development of competition, technology, as well as people’s habits, create high dynamics in products today.

The Scrum Master should advise the Product Owner to focus on collecting development details only for the parts of the product that will eventually be developed during the upcoming period of work. Reference: “Why do you want to be a certified Scrum Master?”, (2020, Rita Gavelis,

Gathering details, describing functionalities and product requirements that will not be developed soon is considered an unnecessary loss, as it is likely that over time, these requirements have changed based on the feedback that product users will provide. or stakeholders.

Instead of describing details of work for a long time after the conversation with the client, the Product Owner should try to get from him “valuable” information about what exactly will be done at the beginning of the project and to prioritize and clearly define the Product. Backlog Items.

Sprint and work planning

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

The Scrum Master role is responsible for ensuring that all events and processes are followed, but this situation may be the exception. The Sprint Planning event is a very important meeting because the work for the upcoming sprint is planned and prepared. The planning is joint and everyone participates. On the other hand, if the team is self-organized, has already discussed the work on User Stories with the Product Owner, its technical approaches see no obstacles, is sure to achieve the goal of the sprint and create the expected increment, the Scrum Master should accept the situation, especially if there is no time and this can lead to non-compliance with deadlines.

The scrum master returns from leave and, as part of the team, should learn what the team is currently working on, but can also do so in the process after a conversation, for example, with the Product Owner or team members. The Scrum Master needs to make sure that the team is familiar with the theory of self-organization in Scrum.

Product Owner role and new functionality in the distant future

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

The Scrum Master in this situation must try to convince the Product Owner role and the team that this action may be pointless. This functionality is expected in a few months, things can change, the customer can change the requirements, user needs can change, the budget can change, there are various factors, especially given the high dynamics in products today.

Scrum is adapted to frequent changes in product needs and requirements. Gathering details, describing functionalities and product requirements that will not be developed soon is considered a waste. After all, the team always has tasks that it is currently working on, and it would be better to focus all its efforts on this work and not be distracted by thinking about other work and issues that will not be completed as a result.

User Story planned for the next sprint

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.

In this situation, the Scrum Master must remind and explain to this team member the rules and principles of Scrum’s work. There is no point in starting to work on User Story, which is expected to be planned for the next sprint, because this may be an unnecessary loss.

The current sprint is not over yet, Sprint Review and Sprint Retrospective are forthcoming. After reviewing the increment and discussing the Product Backlog items, after the demonstration, some items from the product backlog can be commented as already lower priority and, accordingly, dropped out altogether. Also, stakeholders can suggest some logical ideas for work or have ideas for important refinement, which need to happen right after the demo (during the next sprint).

A member of the team expresses dissatisfaction

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 his work can be seen in software systems. It guarantees that it will deliver very good results and just in time.

There is a possibility that this member of the team will deliver very good results and just in time, to some extent he even has the freedom to work in a way that is more convenient for him, but in Scrum, there is such a thing as transparency. Process transparency in Scrum is not just a recommendation, but a working principle.

That is why it is important for all team members to understand the importance of this value, to share and apply it. The scrum master is responsible for this.

In this situation, the Scrum Master must make an effort to convince this team member that it is better for everyone when the development process is transparent. More on the topic: “Free preparation for the Scrum Master certification exam (CSM, PSMI, PSMII, BVOP)”, Transparency implies that team members have no secrets, that information that is important to the process is not hidden. This also applies to the relationships between different team members. Transparency is very important for the functioning of Scrum because where there is opacity, closure, gaps, errors occur and the ability to make the necessary changes to improve processes is lost. If we do not know the whole situation, we do not have enough data, we cannot make decisions and make changes to solve problems. Daily meetings are a direct tool that allows for such transparency that you can receive timely feedback on the process.

The tasks related to the developed product must be transparent and clear, visible, and easily accessible to all.

Scrum Master role and determination of sprint duration

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.

The Scrum Master should explain to his colleague that he would be happy to help, but unfortunately, he cannot. Reference: “Free training to prepare for the Scrum Master Certification exam”, This will be wrong and unprofessional on his part. He cannot give the exact number of days the sprint has to go through, as the above is closely related to the quality of the team, the technology used, and the product that the colleague’s team is working on.

Because the Scrum Master can give another piece of advice to a colleague. Each Scrum Master has responsibilities for monitoring and removing barriers to the work process, protecting the team from outside interference, supporting meetings and Scrum events, collaborating with the Product Owner role, training and guiding all persons involved in the product (Scrum team and business stakeholders) on Scrum practices and concepts. This means that the colleague should assess the situation, why it happens that team members can not reach a consensus on the length of the sprint. The Scrum Master should also remind the colleague that it is not recommended that he or any other person make this decision on behalf of the Scrum team. This will lead to losses on all possible sides.

If none of the colleague’s team can suggest a time for the sprint, then there is a problem in the team. Maybe the Product Owner role does not provide enough information to the team about Product Backlog Items, team members are not competent enough, there is no transparency, the team is not cohesive, there is not enough motivation, maybe some team members are silent or embarrassed to express their opinion.

The colleague needs to understand exactly what the problem is with the team, that he cannot reach a consensus on the length of the sprint.

The Product Owner role changes the duration of the sprint

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.

In this situation, the Scrum Master must talk to the Product Owner to remind him that in Scrum Sprints are limited to one calendar month. When the horizon of a Sprint is too long, the definition of what is being made may change, the complexity may increase, and the risk may increase. Sprints allow predictability of progress to the Sprint Goal by inspection and adaptation at least once a month. Sprints also limit the risk of loss to the cost per calendar month.

The longer a sprint, the less flexible it becomes, especially if the team follows the Scrum rules, which do not allow the sprint to be interrupted or changed in the middle.

If the sprint is too long (in this case 6 weeks), getting feedback (retrospection) can take too long, and the team may get tired of running at such long intervals.

The scrum master must defend the principles of Scrum, the team, he together with others is interested in the positive result of the project, all parties are satisfied.

The scrum wizard must discuss with the Product Owner another important point that the whole team must reach a consensus on the length of the sprint, that is, the whole team and all members estimate the time required to develop tasks. However, Scrum is based on empiricism. Empiricism argues that knowledge comes from experience and that decision-making must be based on what is known.

Your client’s project manager

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.

The scrum master in this situation should explain to the Project Manager that he cannot give him an exact answer because the Scrum team decides the length of its sprint and this is done to provide a quality and complete increment at the end of the sprint. If the team is familiar with the idea of ​​the project and has carefully discussed what it will face, it would be better for all parties to determine the duration of the Sprint.

The task of the Scrum Master in this situation is to explain to the Project Manager that Scrum sprints usually last from 1 to 4 weeks. The sprint must be long enough to create a work (a piece of the project) that is complete and can be shown to customers or users. They need to be able to review and test it and ultimately give us some feedback. They may like it or wish for changes and improvements. Reference: What is it like to be a Scrum Master?,

If the sprint is 6 working days, likely, the team will not have enough opportunities, resources, time to make a piece of the project, which is fully completed, it will negatively affect the results of subsequent work, losses, both parties ( the client and the team) will not be satisfied with the result.

Your director has read a lot of information on the Internet about Scrum

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.

One of the key responsibilities of the Scrum Master role is to protect the team from outside interference. The scrum master in this situation must explain to the director the principles of Scrum’s work and convince him that the team must determine the time of the Sprint. Each role in the Scrum team performs a specific function.

A sprint is a limited period lasting one month or less, during which a “Ready”, usable, and potentially ready-to-launch Product Increment is created. This means that for a sprint, a work (a piece of the project) must be created that is fully completed and can be shown to customers or users. They should be able to review and test it and ultimately give some feedback. They may like it or wish for changes and improvements.

The members of the team know better their capabilities, technologies, customer requirements.

If the time of the Sprint is defined as one working week, and this time is not enough to create an increment, it will lead to losses, defects, non-compliance with deadlines, dissatisfaction with the client, and a negative atmosphere in the team.

Of course, shorter sprints are more flexible, and the team can plan their work more easily. If a project requirement has changed, he or she will probably find out more quickly and easily. Because choosing the length of the Sprint is a responsible and important task, various factors must be taken into account: the capabilities of the team, the characteristics of the product, the requirements and mood of the client, etc.

Leave a Reply

Your email address will not be published. Required fields are marked *