Scrum Master Certification Preparation & 240+ Prep Questions

Artifacts in Scrum represent work or value. They provide transparency and opportunities for inspection and adaptation.

The Scrum Guide defines three Scrum artifacts:

• Product Backlog

• Sprint Backlog

• Increment

Scrum is based on transparency, inspection, and adaptation.

It is the Scrum Master's job to work with everybody within and outside of the Scrum Team to ensure that the artifacts are transparent.

In Scrum, the Product Backlog is an artifact, designed to provide transparency and opportunities for inspection and adaptation.

The Product Backlog is made up of an ordered list of everything that is needed in the product. It a list of requirements that can be new features or improvements, fixes or any other changes that need to be done on the Product. As long as the Product exists, so will its Product Backlog.

How a Product Backlog Item is described it is left to the Scrum Team. The Scrum Guide does not offer any templates or make any recommendations regarding the format itself. In practice, it is quite common for Scrum Teams to use the User Stories. It is actually so common that the Product Backlog items are simply referred to as stories.

The Scrum Guide does not impose a specific way of managing the Product Backlog, in terms of how the Product Backlog Items should be written.

Scrum Guide does not make any suggestions regarding this. Scrum Teams are usually free to decide what they prefer to use. And this can be simple sticky notes, arranged on board so that they are transparent for everybody and to facilitate planning and discussions or a software-based solution.

In organizations that already practice agile methodologies, such software tools are already available. Using a software tool for this task can also make it easier to adapt to the content.

It is common for organizations nowadays to use a digital Product Backlog and a Scrum Board. While there are many tools out there, many companies use Jira, created by Atlassian to manage their Agile projects, including Scrum and Kanban.

This video shows how to create a Product Backlog in Jira.

Now the Stories (Product Backlog Items) have a description, a test description, and order. As you can notice, the Story is not complete yet. The next step would be to take this Product Backlog Item written as a User Story and discuss it with the Team to clarify the details, add order and to get an estimate.

This collaboration between the Product Owner and the Development Team happens during the Product Backlog Refinement meeting.

After the Development Team has estimated a Story, the Product Owner can enter that estimation in the software tool used for managing the Product Backlog, in our case Jira.

The Product Owner can also define a scale and use Value Points. In this way, each User Story will also have a number of value points assigned.

This quiz tests your understanding of the Product Backlog.

Before attempting this quiz, make sure you read the following sections from the Scrum Guide:

- Product Backlog

The Sprint Backlog makes transparent all the work that the Development Team deems as necessary to reach the Sprint Goal.

You can view the Sprint Backlog as a temporary artifact that exists only during the Sprint. The Sprint Backlog is the responsibility of the Development Team.

The Development Team will modify the Sprint Backlog throughout the Sprint. It is a decomposition of each Product Backlog Item in smaller units of work that allow the Team to build the increment.

The Sprint Backlog is created during the Sprint Planning meeting. The Development Team will pull Product Backlog Items from the Product Backlog into the Sprint Backlog.

This video shows how to create a Sprint Backlog in Jira.

The Increment (or Product Increment) is represented by all the Product Backlog Items completed during a Sprint plus the value of all Increments from all the previous Sprints.

It is solely the decision of the Product Owner if and when to release the Increment, but it needs to be in useable condition.

When a Product Backlog Item is considered complete or "done", everyone must understand what done means.

In order to make it easier for everybody to understand that, the Scrum Team should create a Definition of Done which can be used to asses if the work performed is in accordance with the definition.

So each Sprint will create a Product Increment that needs to adhere to the Definition of Done.

As the Scrum Team gains more experience, it is expected that the Definition of Done will contain more strict criteria that ensure higher quality.

By the end of each Sprint, the Increment must be "done", according to the Definition of Done.

This is an example of the "Definition of Done". Each Development Team or development organization may formulate the Definition of Done in a different may.

Some Scrum Teams prefer to create a Definition of Ready as well.

Similar to the Definition of Done, the Definition of Ready refers to Product Backlog Items but this time the ones that are still in the Product Backlog and are about to be selected for the Sprint Backlog by the Development Team.

Scrum uses prescribed events (or Scrum meetings or Scrum ceremonies) to create a routine and to reduce the need for other meetings that are not defined in Scrum.

At the heart of Scrum is the Sprint, which acts as a container for all the events. All events inside Scrum are time-boxed.

Scrum defined the following events:

• Sprint Planning (where the work to be performed in the Sprint is planned)

• Daily Scrum (which is held every day of the Sprint)

• Sprint Review (which is held at the end of the Sprint to review the Increment)

• Sprint Retrospective (which is an opportunity improve the process)

All events that are a formal opportunity to inspect and adapt.

The Daily Scrum is a timeboxed event, held at the same time and place each day to reduce complexity. The Daily Scrum is held every day during the Sprint and it is an event intended for the Development Team.

The Daily Scrum helps the Development Team inspect progress toward completing the work in the Sprint Backlog and reaching the Sprint Goal.

Regardless of the size of the team, the Daily Scrum is a 15-minute time-boxed event.

During the Daily Scrum the Product Owner, the Scrum Master or other parties are not present. This is an internal Development Team meeting.

A Scrum Board is a tool that helps the Development Team make Sprint Backlog items transparent.

The board can be a simple whiteboard with post-its for each task or digital board. Please note that the Scrum Guide does not mention the term "Scrum Board" in the Scrum Guide.

The Scrum Board is constantly updated by the Development Team and shows all the work in typically three columns: TODO, In Progress, Done.

By the end of the Sprint, the Development Team should have delivered a potentially shippable Product Increment.

The Sprint Review is held at the end of the Sprint to inspect the Product Increment and adapt the Product Backlog if needed.

The Product Owner owns this meeting and will invite the key Stakeholders to this event. Also taking part are the Development Team and the Scrum Master. The Scrum Master role is to facilitate this meeting and to make sure it is held within the timebox.

The Sprint Review is an informal meeting, not a formal status meeting. The demonstration of the Increment is done in order to obtain feedback and encourage collaboration on what needs to be done next.

What happens with incomplete Product Backlog Items?

So what happens with Product Backlog items that have not been done yet or that are not fully done (for example some functionality has been built but more is needed or testing is not completed yet)? First of all, they will not be demonstrated during this meeting and they should not be part of the Product Increment. They will be put back in the Product Backlog.

The Sprint Retrospective is the very last event in the Sprint, right after the Sprint Review but prior to the next Sprint Planning. The goal of the Sprint Retrospective is to inspect and adapt the development process.

The Sprint Retrospective is an internal Scrum Team event where no external parties are involved.

The Sprint Retrospective is, as implied, a time-boxed event. For a one month sprint, the maximum duration is of 3 hours.

The Scrum Guide does not go into many details when it comes to the Sprint Retrospective and only explains the rules, purpose, and desired outcome. While the Scrum Guide does not make it explicit, the Scrum Master is typically the one who can plan and organize this meeting.

Typically Retrospective made use of post-it notes and pens, and there should be plenty of them available.

The Sprint Retrospective meeting will usually start with an icebreaker or warmup exercise. This step is to kick off the meeting, helps with team building, and to get the group interaction started.

Next, the Retrospective meeting can smoothly proceed with a simple check-in to see how everybody is feeling. One exercise is to draw a smiley face on a post-it and to put it somewhere on the board. This can express, for example, how the last Sprint went.

Next comes the core part of the event. The idea behind the next activity is to gather data about the Sprint. Typically a timebox is set in which each Scrum Team member reflects back on the Sprint and writes down ideas.

Next, the team will try to discuss the most important topics within a timebox. The goal of the meeting is to identify improvements. So the team will discuss the issues that they encountered during the Sprint and will think about possible solutions.

The Retrospective may include a final activity in which the improvements, decisions, or action points identified are clarified.

Canceling a Sprint before the time-box expires is a very very rare occurrence. I actually never encountered this. But you need to be aware of this possibility as well.

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.

What is important to remember is that Scrum Teams are self-organizing and cross-functional.

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. It means that they make the decisions when it comes to how the product should be built but also about other aspects of their work.

Cross-functional teams have all the skills needed to accomplish the work without depending on others not part of the team (especially when it comes for example to the technical expertise needed in creating the product).

The main responsibility of the Product Owner is to maximize the value of the product resulting from the work of the Development Team.

The Product Owner is one person, not a committee, a group of people or anything else. The fact that the Product Owner is a person is not left to chance but a decision made on purpose within Scrum. And it all relates to responsibility. The Product Owner is, in the end, the sole responsible for the outcome so nobody should go over him or her when it comes to decisions (such as the Product Backlog ordering).

So the Product Owner is the sole person responsible for managing the Product Backlog. So the Product Owner needs to make sure that the Product Backlog Items are clearly expressed and understood by the development team.

Is the Product Owner the Project Manager?

And just to be clear, there is no Project Manager role in Scrum and in general, the Product Owner role is by no means to be confused with a Project Manager. In Scrum, the responsibilities of a traditional Project Manager are distributed between the Product Owner, Scrum Master and the rest of the Team.

The Development Team consists of specialists who have all the skills in order to do the work needed. Their goal is to create a potentially releasable Product Increment at the end of each Sprint. It is worth mentioning that only the Development Team members can work on the product Increment. The team is self-organizing and cross-functional.

The Development Team is structured and empowered by the organization to organize and manage their own work. In this way, the efficiency and effectiveness of the Development Team are optimized.

Scum does not recognize any official titles for the development team, regardless of the work they perform (software development, architecture, testing, design).

How big should the Development Team be?

If the Development Team is too small it may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable product Increment.

Having too many team members is also not a good idea. Having more than nine members requires too much coordination between them so the entire process becomes too complex.

The optimal Development Team size between 3 and 9 members.

The Scrum Master assists the Development Team and the Product Owner and is responsible for promoting and supporting Scrum within the organization - you can see the Scrum Master as a "Scrum coach". The Scrum Master is doing this by helping everyone understand the Scrum theory, practices, rules, and values.

The Scrum Master helps those outside the Scrum Team (for example the Stakeholders) understand which of their interactions with the Scrum Team are helpful and which aren’t.

When it comes to the Scrum Team itself, the Scrum Master is a skilled servant leader.  The Scrum Master is not a manager or somebody with formal authority. The Scrum Master is a facilitator and a coach and the goal is to serve the Scrum Team in order to maximize the value created.

How is the Scrum Master serving the Development Team?

The Scrum Master has to defend the empowerment that the Development Team has and to coach it regarding self-organization and cross-functionality.

One important focus is to help the Development Team create high-value products. The Scrum Master is successful if the Team is successful.

The Scrum Master helps to remove those impediments regardless of their nature. At times the Scrum Master will need to work people within the organization to address those issues. Any unsolved problems put the Sprint outcome in danger and therefore the Scrum Master needs to act promptly.

The Scrum Master is also facilitating scrum events as requested or needed - with an emphasis on the word facilitating. Don't misunderstand that "facilitating meetings" means setting them up, booking and arranging rooms or anything else. The Scrum Master is not the secretary of the team.

How is the Scrum Master serving the Product Owner?

The Scrum Master coaches the Product Owner to better understand and practice agility and Scrum. This means that the Scrum Master should coach the Product Owner to understand and apply the benefits and best-practices of Agile and Scrum.

It is also extremely important that the Development Team and Product Owner understand the need for clear and concise Product Backlog items and the Scrum Master is there to help with this as well.

In order to maximize value, the Scrum Master will mentor the Product Owner on how to manage the Product Backlog to ensure it is ordered and in a healthy state.

The Scrum Master also can facilitate planning and Backlog Refinement events.

What is Agile and what where does it come from?

Most of the time Agile in software development describes a way under which business requirements and potential solutions emerge through the joint effort of cross-functional, self-organizing teams and their customers or end-users.

The term Agile, used in this context, comes from the Manifesto for Agile Software Development.

Scrum is a process framework used to manage work on complex products, not only in software development.

Using the framework helps people address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

To better understand where Scrum is coming from, it is important to understand what has happened before Scrum was introduced. A lot of software development in the past has been done and is still done using the waterfall model.

Scrum is widely adopted in the software development industry but Scrum is not only used for developing software.

Scrum is based on empiricism (the empirical process control theory). This means that knowledge comes from the past experience and decisions are made based on what is known. Scrum is never about knowing or planning everything in advance.

The Scrum Values are commitment, courage, focus, openness, and respect. Scrum is based on three pillars: transparency, inspection, and adaptation.

This quiz tests the understanding of the Scrum theory as presented in this section and in the Scrum Guide.

If you have not read the first part of the Scrum Guide yet (Purpose of the Scrum Guide, Definition of Scrum, Uses of Scrum, Scrum Theory, Scrum Values) please make sure you do that before you continue with this quiz.

Heads up! Most of the questions are designed to trick you. So read the carefully before making your choice.  This is done on purpose in order to train you attention and to better prepare you for the examination.

Scrum.org provides another framework for dealing with how to scale the Scrum framework. This additional framework is called the Nexus Framework and is described within the Nexus Guide.

Remember that the content of the Nexus Guide is not part of the Scrum.org PSM I exam. The Nexus Guide introduces many other terms that will confuse you, so for that reason, I don’t necessarily recommend it.

In this section, we will go over the most important aspects that are relevant for the exam and explain to you all the rules you need to know.

The most important rule you need to remember when multiple teams work on the same Product.

1 Product = 1 Product Backlog = 1 Product Owner

So for multiple Scrum Teams, there will be a new Development Team and a Scrum Master. The Product Owner will be the same person.

It is important to remember that there is only one Product Backlog. There will not be separate Backlogs for each team.

During the Sprint Planning meeting, the Development Teams will still pull items from the Product Backlog in agreement with the Product Owner. So the Product Owner and the Development Teams will collaborate on finding solutions that make sense for them.

When multiple Scrum Teams start working on the same Product, different challenges arise.

The key concern, in this case, is to reduce as much as possible dependencies between the teams.

• 1 Product = 1 Product Backlog = 1 PO

• Multiple teams working on the same product = 1 PO

It is important to have a single person responsible for the end results. Having a committee / multiple persons can make decision making complicated (as everyone must agree or a compromise must be found). When compromises are made, the decision may not be the best one. This also makes it unclear who is responsible for what and the shared ownership may lead to no ownership (it is somebody’s else problem, not mine).

If one person is involved, it is clear which person is responsible for the results. When multiple persons are involved and things don't work well, it can be an elaborate process figuring out what did not work.

Having multiple Product Owners can lead to micromanagement and coordination issues.

There are no Chief Product Owners (CPO) or Proxy Product Owners (PPO) in Scrum.

Scrum does not have a requirement that states that the Scrum Sprints be aligned. The only requirement is that the work should be integrated by the end of the Sprint. If all teams have the same Sprint duration and start/end dates, this is a bit easier to manage.

If the Scrum Teams have different Sprint lengths (so the Sprints are not aligned), this process will be harder but still within the Scrum rules.

Please remember that there are no Integration Sprints on Hardening Sprints in Scrum.

An important distinction to make is that a person can play different roles in Scrum. While this is not relevant for the exam, in practice it can be confusing. So the role does not necessarily define a person.

One person can play multiple roles. The Scrum Guide sets conditions on the roles, not on individual persons.

A burndown chart is a graphical representation of work (usually represented in time or story points) left to do versus time. The outstanding work usually on the vertical axis, with time along the horizontal.

This chart is used to estimate when all of the work in a Sprint will be completed. While burndown charts can be used in agile projects, they can also be applied to any project containing measurable progress over time.

The Burn-up Chart provides a visual representation of a Sprint's completed work related to its total scope, which is represented by the number of selected Product Backlog Items (or Stories).

It is quite similar to the Burn-down chart with the difference that any added work will be visible in a change of the scope.

One or two questions in the real exam could contain a reference to the term technical debt. While technical debt is a term does not appear in the Scrum Guide it is mentioned in the Glossary.

Generally speaking, technical debt is something that should be constantly dealt with and not postponed. It is part of the development process and it is a continuous process (similar to the architecture of the product which is constantly being worked on and improved).

It is tightly coupled with the quality of the product and the Development Team should constantly work together with the Product Owner to keep the technical debt manageable.

The term Cone of Uncertainty is used in software development where the technical and business environments are constantly evolving.

The Velocity of the Development Team (or simply Velocity) is a measure of the amount of work a Development Team can handle during a typical Sprint.

This is calculated by averaging the amount of work performed in the previous Sprints and can be used to get an idea of what is possible to accomplish in a Sprint.

Remember that this is an optional metric and intended only for the Scrum Team. Moreover, there are no commitments in Scrum (for example for the selected Product Backlog Items) and nobody gets punished if the estimate proves to be inaccurate.

Engineering standards refer to a set of rules and conventions within the development organization that applies to all the Product being developed.

The PSM I Scrum exam may include questions that talk about Feature teams and Component teams. As with many other terms the exam tries to test some practical knowledge but, the Scrum Guide does not mention them.

Feature Team - works through all the layers of the application to fulfill a customer or a user need. A Feature team is cross-functional and cross-component because it has all the skills needed to complete a feature and does that by working through all the layers or components of the application.

Component team (or a layer team) - focused on a single component of the system. Multiple component teams will need to work together to deliver a feature.

Some Scrum PSM I exam questions may reference the term sustainable pace. When doing development work, it is important to be able to have a constant output.

A functional requirement is a requirement that can be easily understood by the Product Owner, Stakeholders, and the users of the Product. A functional requirement describes a function of the Product.

Non-functional requirements describe qualities, behaviors, attributes, and constraints of the Product and can be placed into multiple categories: performance, security, availability, and usability, to name just a few examples.

Hardening Sprints or Integration Sprints is typically a separate Sprint in which no new features are developed. Some organizations have adopted Hardening Sprints to integrate (merge) the work of multiple Development Teams and to test the Increment before it goes in Production.

Who creates the Definition of Done?

There are two possible options:

• The development organization

• The Development Team

This is a quiz focused on learning and testing your understanding. It does not have a time limit and you get the correct answer immediately.

This set of questions contains only one correct answer.

After going through the test once, read the Scrum Guide again and retry the test until you get a perfect or near-perfect score.

This lecture explains the most important strategies for dealing with Scrum PSM I exam questions.

You can start this practice test by clicking the "Begin test" button.

You have 60 minutes to complete 80 questions.

Try to finish the test on time!