Professional SCRUM Master 1

Scrum is adaptive instead of predictive. It’s a framework rather than a methodology or body of
knowledge. It’s mainly about project delivery rather than project management. It’s empirical (based
on experience) rather than theoretical. It’s suitable for the development of complex products in
complex environments.

Scrum is a framework rather than a methodology, and it’s not detailed.

The Sprint Planning is timeboxed for 8 hours when the Sprint is one month long, and shorter
proportionally.

All Sprints are done to create Increments: a piece of working software which is potentially
shippable and “Done”, based on the Definition of Done (including all the tests). All items we deliver
are non­technical and independent of each other.

Scrum doesn’t have a project manager role. The project management activities are distributed
among the three Scrum roles.

Only the Product Owner has the authority to cancel a Sprint. It is done when the Sprint doesn’t
make sense any more or the Sprint Goal has become obsolete.

When Sprints are shorter, there are more opportunities for demonstration, receiving feedback, and
adaptation. So, when risks are higher, it’s better to have shorter Sprints (if it’s possible).
Generally, shorter Sprints are preferred.

The Product Owner is responsible for engaging them, understanding them, communicating with
them and so on.

All events are necessary and are held every Sprint; including the Sprint Retrospective, which is
the last event inside each Sprint.

There’s only one type of Sprint, and its goal is to create a potentially releasable Increment of
features that bring value to the customer. There’s no Sprint zero, hardening Sprint, integration
Sprint, release Sprint, etc.

There are two elements in the Sprint Backlog:
1. The items selected from the Product Backlog: we don’t change them after the Sprint Planning
2. The tasks created by breaking down the items: only a few of them are created in the Sprint
Planning, and the rest will be created during the Sprint. Otherwise, it would be a form of
upfront planning. Tasks are referred to as “work” or “plan” in the PSM I exam.

Every Scrum Team needs a Scrum Master and a Product Owner, even if they are mature. Both
roles can be part­time.
Remember that the Scrum Master is also responsible for removing impediments. And it doesn’t
matter how mature you are in the process; it’s always great to have someone to help you with
issues.

Facilitation (as requested or needed), removing impediments and solving problems, training,
coaching, consulting, and convincing people to do the right thing are the things we expect from the
Scrum Master. S/he is not supposed to block the team’s self­organization by giving developers
orders, or deciding for them, and s/he is not supposed to do other people’s jobs (e.g. ordering the
items instead of letting the Product Owner do so).

Sprints are timeboxed and they are not extendable. Some timeboxes have a maximum duration
and will be finished earlier if everything is done, but Sprint timeboxes have a fixed duration, which
does not shrink either. If everything is finished before the end of the Sprint, the Development Team
will pick the next item from the Product Backlog and starts working on that.

The Sprint Goal is composed by the whole Scrum Team during the Sprint Planning. Besides
that, we don’t cancel the Sprint Planning anyway! The Sprint can be canceled only in extreme
situations, by the decision of the Product Owner.

The decision on the order of items can be influenced by a committee, the customer, or any other
stakeholder, but the final say belongs to the Product Owner. This decision should be respected by
the whole organization.

The Product Backlog order and composition, project performance measurement, and release
planning are the Product Owner’s responsibilities. The Sprint length is determined by the whole
Scrum Team.

Anyone “can attend” any meeting, but note that the questions is asking who’s required to do so.
Daily Scrum is only for the Development Team, so no one else is “required to attend”, and if they
do, they are not supposed to “participate”; they just listen and watch.

There are only three roles in Scrum: Product Owner, Scrum Master, and Development Team. It’s
not allowed to define new roles and the Development Team members should not have any titles;
they are all just “developers”. It is so, because we want all of them to be accountable for
everything and to collaborate with each other.
Each person has his/her own area of expertise, such as testing, and that person will be more
focused on testing tasks, but it doesn’t mean that we can call the person “tester”; they are just
developers who are experts in testing.

The Sprint Goal is created during the Sprint Planning meeting by the whole Scrum Team.

All estimates are done by the Development Team, since they are the ones who know how to do
the work.

There’s no such thing as Sprint zero. The first Sprint is called Sprint 1, and it’s exactly the same as
other Sprints: creates an Increment. The infrastructure and tools and requirements are prepared
gradually throughout the project.

It is completely up to the self­organized Development Team to decide on the way they work and on
the technical aspects of the project.

Only the Product Owner can add new items to the Product Backlog. Even s/he cannot add a new
item to the Sprint Backlog during the Sprint.
When someone asks for a change in the Sprint Backlog, they should be referred to the Product
Owner, so that s/he can work with them to define the item and add it to the Product Backlog for the
next Sprints.
In fact, we reject the request for adding the item to the current Sprint Backlog, but this rejection
should be done by the Product Owner, rather than the Development Team.

The Sprint Backlog is created during the Sprint Planning. It includes the items selected from the
Product Backlog (by the Development Team), and the tasks created by decomposing the items
(by the Development Team). The Development Team keeps adding tasks during the Sprint, so, the
Sprint Backlog updates. It’s the Development Team’s plan for the current Sprint. This plan is not
detailed upfront.
If the Development Team cannot deliver some of the items, they will go back to the Product
Backlog at the end of the Sprint, and they will be ordered again; they do not go to the next Sprint
automatically.
Each task is assigned to one developer or a pair of developers, but the ownership is still shared.
Items are not assigned or owned by specific developers; all of them share accountability

it is totally up to the Development Team to decide how many items they are going to select for the
Sprint.

The Developers share the ownership of the items and tasks in the Sprint Backlog.
Tasks are assigned to the Developers (by themselves), but they all stay accountable (own the
task).
Items are not assigned to Developers, as each item consists of multiple tasks that need varying
expertise.
To summarize:
1. Items are not owned by individuals or pairs
2. Items are not assigned to individuals or pairs
3. Tasks are not owned by individuals or pairs
4. Tasks are indeed assigned to individuals or pairs

The Scrum Master serves as a servant-leader for the Scrum Team, helping them understand and apply Scrum principles and practices. They facilitate Scrum events, remove impediments, and coach the organization in adopting Scrum. However, they do not assign tasks to individual developers. The Development Team is self-organizing and decides how to best accomplish the work in the Sprint Backlog.

Items are not really Done, unless we have tested them; so, tests should be included in the
Definition of Done. In this case, the Increments will be closer to what we can practically call
“complete”, “done”, “potentially releasable”, or “potentially shippable”; to something usable for the
users.
Increments should be potentially releasable; for starters, because it makes it easier for the
customer to try it and give us useful feedback. The feedback enables adaptation, which is
essential to Agile.
Having an effective Definition of Done increases transparency, because everyone will know what
we mean when we say an item is Done.
Reporting to the “project manager”? We don’t have a project manager in Scrum.

It’s the Development Team’s responsibility to measure their productivity and performance during
the Sprint, find their way, plan, and optimize the work required for items and the Sprint Goal, and to
resolve their own conflicts. Remember that they are self­organized.

An Increment of “Done” working software, which is potentially releasable, must be produced at the
end of each Sprint.
Remember that all Sprints are the same, and there are no Sprint Zeros, Hardening Sprints,
Integration Sprints, Release Sprints, etc.

Only the Product Owner has the authority to cancel a Sprint. It happens when the Product Owner
realizes that the Sprint doesn’t make sense any more, or in other words, the Sprint Goal has become obsolete. E.g. if the customer doesn’t need most of the Sprint Backlog items any more.
Note: it’s OK if we forecast that the team cannot deliver some of the Sprint Backlog items (or even
many of them) and it’s not a reason for canceling a Sprint. We will just go on and deliver as many
items as possible.

The Product Backlog is ordered based on the value of the items to the business, and it is up to the
Product Owner to determine how to calculate the value.
Size, criticality, and risk all affect the “value”, but are not directly the basis for ordering.
Items should be independent of each other, so that we can freely order them based on the value.

The horizontal axis is time, the vertical axis is the remaining amount of work, and the trend line
shows the forecast finish date if the Product Backlog and the team capacity stay the same.

A few related points to remember:
1. Scrum is a framework, not a methodology or body of knowledge.
2. Scrum is empirical, rather than theoretical.
3. Scrum is more about project delivery rather than project management.
4. Scrum is adaptive, rather than predictive (it’s more than just using Sprints and related
artifacts).
5. Scrum should be used entirely (we do not tailor it).

The Definition of Done includes quality methods and that’s why we keep improving it when we
mature.
All Scrum roles, events, and artifacts are necessary and should not be ignored for any reason.

All four events inside the Sprint are feedback loops and opportunities for inspection and adaptation
(but not the Sprint itself). So, any of the following are right answers for questions like this:
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
Remember that while Scrum.org considers “release planning” necessary, and a responsibility of
the Product Owner, it’s not explained in the Scrum Guide.

The Product Backlog is a type of planning. However, we don’t create predictive, detailed upfront
plans in Agile environments: the Product Backlog is dynamic and never complete. It provides only
enough information for a self­organized team to find its own way. It’s always changing to enable adaptation.
There are no “tasks” in the Product Backlog; they belong to the Sprint Backlogs

Many of the security concerns are non­functional features, and therefore will be added to the
Definition of Done to be applied to all Product Backlog items.
Some security concerns are specific, and only about a certain part of the product; they can be
items in the Product Backlog.
The Development Team is cross­functional and should take care of every aspect of the product,
including security. So, it won’t be handled by external people.
Each Sprint should be focused on developing items with the highest value, and delivering Done
items. We don’t keep things such as security, tests, and integration for a time in the future.

Nothing happens! The Development Team will deliver only the items that are 100% done based on
the Definition of Done.
The only things the Development Team may do, is inform the Product Owner, so that s/he can
revise the order of items ­if necessary­ and work with her/him to review and adjust the work
(“work” here refers to the “tasks”, not the “items”).

When the item is complete based on the Definition of Done (which means that the end users can
use it), and it creates an Increment of working software that is potentially releasable.
Note: if all the tasks for an item are complete, it doesn’t necessarily mean that the item is complete,
because we might have forgotten to add some of the tasks to begin with.

We do not prepare the infrastructure and tools upfront, because it requires an understanding of the
whole product, which is against the adaptation concept. The required infrastructure and tools
depend on the product we’re going to create, which in turn is defined throughout the project. So,
the infrastructure and tools will be prepared gradually throughout the project.
There’s no Sprint zero in Scrum. All Sprints are the same, used to create an Increment of working
software.

There’s no time between one Sprint and the next.
Ordering the Product Backlog items and estimating the amount of work of new items needed for
the next Sprint Planning is done during the previous one, in a continuous process called Product
Backlog refinement (or Product Backlog grooming).

This is how it works:
a. Items of different sizes are added to the Product Backlog.
b. Items are sorted based on their business value.
c. Then we check the items on the top of the Product Backlog, and if they are large, we’ll break
them down into smaller items. We leave the large items on the bottom of the Product Backlog
as they are for now.
d. The business values will be estimated again, and the Product Backlog sorted based on them.
Based on this explanation, the items on the top of the Product Backlog would be, statistically
speaking, smaller than the average. Since the items in the Sprint Backlog come from the top of the
Product Backlog, we can say that “the items in the Sprint Backlog are usually smaller than the
average item in the Product Backlog”.
Remember that we sort the Product Backlog items based only on their business value. The
difference in size happens naturally, and is not a basis for sorting.

It’s almost impossible to make the estimate units (e.g. story points) comparable, and only creates
problems such as padding. Besides that, the “management” is not supposed to measure their
performance; they should be focused on the values generated by the project.

Being self­organized means that the team finds its own way, instead of receiving orders. When it is
so, there is more buy­in (commitment), accountability, and creativity among team members.

This is the responsibility of the Development Team, because it’s self­organized. Since it’s some
kind of impediment, they may also get help from the Scrum Master.

All Increments must be complete based on the Definition of Done, and be potentially
releasable/shippable. However, we don’t have to actually release all of them. It’s up to the Product
Owner to decide on the releases based on the project environment.

All four events inside the Sprint are opportunities for inspection and adaptation: Sprint Planning,
Daily Scrums, Sprint Review, Sprint Retrospective
During the Sprint Review, the Development Team demonstrates the Increment and the Product
Owner presents the performance information.

The items selected from the Product Backlog are frozen in the Sprint Backlog; we don’t change
them. However, we also have the “tasks” created by breaking down the items, and the tasks are
always changing. Only the Developers can make changes to the Sprint Backlog (that is, changes
to the tasks, rather than the items).
Only tasks required for the first few days of the Sprint are created in the Sprint Planning meeting;
the rest will be created during the Sprint, whenever developers identify new work, or when it’s time
to work on a new item and they need to understand its scope.