202004-Scrum-Master-Certification-Training-Manual.pdf

Scrum School
Scrum Master Certification Training Manual
Tips and tricks manual for passing the Scrum.org PSM I
exam
Version 4.0
April 2020
Scrum School

Scrum School
We help people to pass Scrum.org exams with more confidence through our reliable
tips and tricks training content.
Alert 1: We are not affiliated with Scrum.org and do not claim that our contents are
endorsed and confirmed by Scrum.org, but we work hard in this context to prepare
and evolve quality contents continuously.
Alert 2: It is expected that candidates before using this booklet, would have read
the Scrum Guide and other resources (we mentioned in our website) carefully and
then use this tips and tricks content to increase their confidence for taking the real
exam.
Scrum School

Scrum School
Why is Scrum a framework not a methodology?
A methodology is a set of principles, tools and practices, which can be used to guide
processes to achieve a particular goal. Usually there is a prescriptive approach in a
methodology and tend to replace the creativity, autonomy and thinking of people.
A framework is a boundary, which leaves room for other practices and tools to be
included but provides much of the process required. Usually a framework is an
abstract process with a freedom of selecting and using other concrete processes
and practices in it.
Scrum is a framework within which people can address complex adaptive problems,
while productively and creatively delivering products of the highest possible value
through a variety of practices and tools that a team can select for its environment.
So, Scrum is a framework not a methodology, technique, tool or practice.
How does Scrum use the main concept of Agile?
Scrum is an implement of agile mindset and is based on adaptive approach that
fundamentally comes from empirical process control against the predictive or plan
driven approach that waterfall and other traditional methods are based on.
Is customized Scrum acceptable?
Scrum as a whole is immutable which means although implementing and
customizing some parts of Scrum is possible, the result is not Scrum so its tailoring
is not acceptable.
What happens for the project manager role in Scrum?
According to the Scrum rules, there are just three roles in a Scrum Team as the
Scrum Master, the Product Owner and the Development Team and nothing else.
Project manager’s responsibilities are distributed among three pre‐defined Scrum

Scrum School
roles. In addition, the Scrum Master or the Product Owner roles are not the same
things as a traditional project manager.
Why does a Scrum Team always need a Scrum Master?
The Scrum Master has two main responsibilities. First, taking care of implementing
Scrum properly and helping the Team to be mature about using Scrum. Second,
removing impediments. It may seem when a Team becomes mature, they will not
need a Scrum Master. Indeed, it is not true. According to the second responsibility
that impediments always can occur, even when the Team becomes mature, the
Team always needs a Scrum Master.
What are characteristics of a high‐performance Scrum Team?
A high‐performance Scrum Team lives the Scrum Values deeply. Mistakes are
mandatory and when they are made, they are celebrated. There are many
constructive conflicts based on trust in the Team. Instead of living by the rules, they
make the rules. They help their customers become more successful. The team can
release the Increment with just one press of a button through an automated
continuous delivery pipeline. They evolve DoD (Definition of Done) over time and
add more stringent criteria to it continuously and adhere to it completely. Almost
every Sprint, the team reaches the Sprint Goal and sometimes they exceed
expectations. You can obviously see a high level of creativity, productivity, and
accountability in the Team. Members are highly knowledgeable, autonomous and
self‐organizing and use the continuous improvement in all aspects of their
processes and environment.
Who decides and is responsible for the Product Backlog items order in the
Product Backlog?
Product Owner’s main responsibility is maximizing the value of the product
resulting from work of the Development Team. Furthermore, Product Owner is the

Scrum School
sole person responsible for managing the Product Backlog. Therefore, (s)he has the
final say and decides about Product Backlog Items order.
What are the daily activities of the Product Owner during the Sprints?
During the Sprint, Product Owner works with the Development Team to clarify
requirements and answer developers’ questions. (S)he manages Product Backlog
through ordering, breaking down PBIs, creating new Items, and assigning value to
the Items. Refines the Product Backlog continuously with the Development Team
collaboration. Participates actively in the Sprint Planning, Sprint Review and Sprint
Retrospective events. In addition, measures project performance, collaborates and
engages with customers and stakeholders …
Who are responsible to monitor the progress over the Project and Sprint?
The Product Owner is responsible to monitor the progress of the project toward a
business goal or high‐level goals at least for every Sprint Review and the
Development Team is responsible to monitor the progress of the work toward the
Sprint Goal at least for every Daily Scrum.
How many times should the Development Team monitor the progress over the
Sprint?
The Development Team should monitor the progress of the work toward the Sprint
Goal at least once a day during the Sprint but it can do it more times in a day if
needed or makes sense.
How does the Scrum Master help the Product Owner for the Product Backlog
management?
According to the Scrum Guide, one of the Scrum Master’s service to the Product
Owner is finding techniques for effective Product Backlog management, so (s)he
can suggest these techniques to the Product Owner. In addition, (s)he should help
the Product Owner to understand the product planning in an empirical

Scrum School
environment. Doing ordering instead of the Product Owner prevents self‐
organization fostering. The Scrum Master’s tools are just coaching, mentoring,
facilitating, training and teaching others to work properly in the Scrum framework
and in this case Product Backlog management.
Which Scrum role determines how many Items should be selected for the Sprint
from the Product Backlog?
The Product Owner or Scrum Master should not determine or force the
Development Team selecting enough items from the Product Backlog because this
manner decreases their commitment, as they may not believe they can finish all
the selected items until the end of the Sprint. It is up to the Development Team to
select enough items for the Sprint without any worry about blame or outside force,
as they know the best how to do the work. Therefore, the authority of selecting
enough amount of PBIs for the Sprint belongs to the Development Team.
What does cross‐functionality mean in Scrum?
Cross‐functionality means the Development Team as a whole should have all
required skills to create potentially releasable Increments without any dependency
to others outside the team. Individual Development Team members may have
some specialized skills or some focused areas of expertise but they do not need to
be cross‐functional one by one. Although, in each situation, all team members
should collaborate with all other organizational functional units or departments, it
does not mean cross‐functionality.
What are the self‐organizing Development Team’s responsibilities and
characteristics?
The Development Team has many responsibilities as following:
Developing and creating Increments, estimating the Product Backlog Items and
tasks, selecting Items for the Sprint Backlog, decomposing selected Product Backlog
Items into tasks, measuring Sprint performance and productivity, calculating

Scrum School
velocity, resolving team internal conflicts, composing / refining the DoD, making
technical decisions, etc.
In addition, the Development Team has many characteristics as following:
3‐9 members, have no titles, preferably full‐time, with no sub‐teams, autonomous,
self‐organizing and cross‐functional.
What is the recommended size of the Development Team in Scrum?
Optimal Development Team size is small enough to remain nimble and large
enough to complete significant work within a Sprint. Fewer than three
Development Team members decrease interaction and results in smaller
productivity gains. Smaller Development Teams may encounter skill constraints
during the Sprint, causing the Development Team to be unable to deliver a
potentially releasable Increment. Having more than nine members requires too
much coordination. Large Development Teams generate too much complexity for
an empirical process to be useful.
What are the Scrum Master’s responsibilities and characteristics?
The Scrum Master has many responsibilities as following:
Taking care of the Scrum framework, ensuring Scrum is understood by everyone,
ensuring Scrum is enacted, helping others to find techniques, may facilitate the
events if required or requested, facilitating the team’s decision making, removing
Impediments, working with other Scrum Masters, helping the organization to adopt
Scrum, teaching time‐boxing to the Team members, ensuring the Product Owner
spends enough time with the Development Team and stakeholders, promoting self‐
organization and cross‐functionality, etc.
In addition, the Scrum Master has many characteristics as following:
One Scrum Master for each Team, servant leader, a manager (not managing people
but managing Scrum process), not a project manager, not a team leader, full‐time
or part‐time job, can be the Product Owner or a member of the Development Team
at the same time, etc.

Scrum School
What are the Product Owner’s responsibilities and characteristics?
The Product Owner has many responsibilities as following:
Maximizing value, creating Items in the Product Backlog, assigning value to the
Items, ordering the Items, explaining the Items to everyone (developers / customer
/ …), measuring project performance, contacting the customer, etc.
In addition, the Product Owner has many characteristics as following:
Owns the Product Backlog, is always one and just one person not a committee, can
be influenced by others, is respected by everyone, can delegate some their
responsibilities, full‐time or part‐time job, can be the Scrum Master or a member
of the Development Team at the same time, etc.
Which position or role in Scrum is responsible for the Product quality?
All members of the Development Team are developers and there is no title such as
programmer, tester, etc. These are skills that each member might have some of
them and accountability of the product quality belongs to the whole Development
Team not a special member.
Who is responsible for the PBIs and tasks estimation?
The Development Team does PBIs estimation after clarifying with the Product
Owner. In addition, the Development Team estimates tasks because they know the
best how to convert the Product Backlog into the releasable Increments.
Which Scrum roles can be part‐time?
Each Scrum Team has three roles: Product Owner, Scrum Master and Development
Team. All team members could be part‐time or full‐time but dedicated members is
recommended for the Development Team members. On the other hand, these are
the roles not assigned people. It means one member can have two roles at the
same time for example as a Product Owner and a Development Team member.

Scrum School
How does adding a new team member affect the Team’s productivity?
Adding new resources to the Team will lead to a temporary reduction in
productivity because new member needs a time to be familiar with team’s
environment, culture and the product and old members need to collaborate on
new member’s onboarding. Furthermore, a bigger Team does not mean that it can
create more value. It is recommended to change Team composition at the
beginning of the Sprints.
Who is responsible for adding or removing members to/from the Development
Team?
The Development Team is self‐organizing so it can add or remove members by
itself. There is no hierarchical management manner in removing a member in
Scrum for example hiring manager, CEO or other top managers. In addition, if
removing a member is going to be an impediment, the Scrum Master can intervene
to help the Development Team removing that person.
What does self‐organizing Development Team mean?
When a team is self‐organizing, it can manage its work without any need to outside
guides or orders. In addition, in self‐organization state, creativity, productivity,
flexibility and commitment (buy‐in) will emerge.
Who makes the decisions about technical concerns?
The Development Team is self‐organizing which means they manage all required
work to implement and convert the Product Backlog into the releasable Increments
without receiving orders from outside the team. In addition, the Development
Team knows best about creating usable Increments so they decide on all technical
concerns as a whole (the Development Team).

Scrum School
How does the Scrum Master get others’ help for removing impediments?
The Scrum Team is self‐organizing and cross‐functional that should not need any
outside help. In addition, all team members are accountable for the team’s
productivity and they should help their teammates if needed. Therefore, if the
Scrum Master could not resolve some problems, she or he can ask her (his)
teammates i.e. the Product Owner or the Development Team for help.
What should the Development Team do when one outside the Team orders them
to do unplanned work?
The Product Owner is responsible for maximizing the value of the Development
Team’s work. Changing the Sprint Backlog items in the middle of the Sprint may
endanger the Sprint Goal and interrupt team’s focus. So, in this case, the
Development Team should inform the Product Owner so that (s)he can work with
the ones who have ordered unplanned work.
What is the purpose of each Sprint?
The Development Team tries to produce a done usable and potentially shippable
and releasable Increment and a piece of working software at the end of each Sprint.
How can the Product Owner order the Product Backlog?
Although there are a lot of methods and guides for ordering Product Backlog such
as importance, value, ROI, cost, new knowledge, risk, etc., the final say is the
Product Owner’s opinion. Therefore, (s)he can order Product Backlog items based
on whatever (s)he deems most important through his/her perspective.

Scrum School
Why is a person less productive when (s)he switches between two or more
teams?
When a person works in two or more teams, (s)he will pay context‐switching cost.
It means (s)he should pay warm‐up, preparation time and resource for each switch.
Therefore, (s)he will be less productive rather than when just works on one team.
What are the most important things for increasing transparency?
Scrum is based on agile mindset so collaboration is the most important thing that
can help the Team to increase transparency. Also, effective collaboration needs
common language. In addition, having a Definition of Done is another important
thing that can increase the transparency. Furthermore, there are other things for
increasing transparency but these are most important.
What is Scrum policy for undone Sprint Backlog Items at the end of the Sprint?
If the Development Team does not complete all Sprint Backlog Items at the end of
the Sprint, the Sprint will be over with the completed items. There is no blame or
other same things. However, it is a valuable fact as an input for the Sprint
Retrospective to inspect if there is any problem in the development process or
anything else.
Extending or shortening a special Sprint duration is forbidden. Undone items should
not be included in the Increment. Instead, all undone items should be re‐estimated
and move back to the Product Backlog and if through Product Backlog ordering,
these items remain on top of the Product Backlog, they can be selected for the next
Sprint.
What are the Scrum events’ lengths?
Sprint: it is used as a container for other events and its length could be explained
as a maximum in various ways i.e. 30 days, one calendar month, a month or 4
weeks.

Scrum School
Sprint Planning: at most 8 hours for one‐month Sprints and usually shorter for
shorter Sprints.
Daily Scrum: at most 15 minutes and it has no dependency to the Sprint length and
the Team size.
Sprint Review: at most 4 hours for one‐month Sprints and usually shorter for
shorter Sprints.
Sprint Retrospective: at most 3 hours for one‐month Sprints and usually shorter for
shorter Sprints.
Except the Sprint, all other Scrum events could be terminated before their time‐
box if the Team has achieved event’s goal. In addition, events’ duration has no
dependency to the Team size.
Who are the participants of Scrum events?
There is a difference between participation and attendance in Scrum events in
which participation means actively talking during the event but attendance means
just listening and observing.
Sprint Planning: All Scrum Team members. The Development Team may also invite
other people to provide technical or domain advice.
Daily Scrum: All Development Team members. Others can attend for listening and
observing but cannot participate actively.
Sprint Review: All Scrum Team members plus key stakeholders invited by the
Product Owner.
Sprint Retrospective: All Scrum Team members.
Which types of Sprint are there in Scrum?
Absolutely there is just regular Sprint in Scrum within which the Development Team
tries to create releasable Increment. Therefore, there is no such things as Sprint
Zero, Hardening Sprint, Stabilization Sprint, Integration Sprint, Release Sprint, etc.

Scrum School
Which work can be done between two Sprints?
Nothing. There is no special time between two Sprints and a new Sprint starts
immediately after the conclusion of the previous Sprint.
When is a Sprint canceled?
A Sprint is canceled when the Sprint Goal becomes obsolete or if it no longer makes
sense. This might occur if the company changes direction or because of the market
or technology conditions change. Just Product Owner has the authority to cancel a
Sprint although others can affect his/her but (s)he has the final say.
When is a Sprint finished?
Sprint is the sole event that cannot get finished or over earlier or later than its
predefined time‐box duration. Other events are time‐boxed but can be finished
earlier if the team achieves each event’s goal.
What can the Development Team do if during the Sprint Planning they find they
have selected too many items for the Sprint?
The Development Team has not closed their planning yet, so can change their
Sprint Backlog even selected PBIs. Therefore, they can remove some Items from
the bottom of the Sprint Backlog, or inform the Product Owner and at the end of
the Sprint adjust the work with Product Owner’s collaboration. As a tip, adding
more developers to the team based on the more selected PBIs during the Sprint
Planning is not acceptable because adding new members to the team leads to a
temporary reduction in the productivity. In addition, adding new members should
be based on a long‐term needs.

Scrum School
How often should the Sprint Planning be conducted?
Sprint Planning is a mandatory event of Scrum and is a feedback loop that team
members could inspect the Product Backlog and select enough work to develop
during the Sprint. It should be conducted at the beginning of each Sprint.
How often should the Daily Scrum be conducted?
Daily Scrum is a mandatory event of Scrum and is a feedback loop that the
Development Team members synchronize their work daily and monitor progress
toward the Sprint Goal. It should be conducted every day during the Sprint.
What are the outcomes of the Daily Scrum event?
The purpose of the Daily Scrum is to share information, and to re‐plan the
Development Team’s collective work so that they progress in the best possible way
towards the Sprint Goal. Its outcomes are:
 An updated Sprint Backlog
 A shared understanding and updated Sprint plan to achieve the Sprint
Goal
 A list of new impediments for the Scrum Master to resolve
Why is conducting Daily Scrums in the same time and place important?
The Daily Scrum is a 15‐minute daily meeting. Changing its place and time regularly
leads to a coordination overhead for a member to prepare a place and increases
complexity for the Team members to find the meeting time and place. Having it in
the same time and place reduces its overhead and complexity.
How often should the Sprint Review be conducted?
Sprint Review is a mandatory event of Scrum and is a feedback loop that team
members demonstrate the Increment to the stakeholders, elicit feedback, and
determine likely PBIs for the next Sprint. Also, the last forecasted project end date,

Scrum School
budget, market status, new capabilities and insights about the project could be
discussed. It should be conducted at the end of each Sprint before the Sprint
Retrospective.
How often should the Sprint Retrospective be conducted?
Sprint Retrospective is a mandatory event of Scrum and is a feedback loop that
team members could inspect their process to establish continuous improvement.
It should be conducted at the end of each Sprint.
What subjects can be discussed in a Sprint Retrospective?
During the Sprint Retrospective, five subjects can be discussed including people,
tools, processes, working relationship, and quality. Indeed all things except the
Product can be discussed in this event.
Which Scrum events are a feedback loop?
All four Scrum events are a type of feedback loop or inspect and adapt opportunity
include Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
Although Sprint is an event but its role is being a container for other events. Product
Backlog refinement is a continuous activity and is not a feedback loop.
What concerns are important for determining Sprint length?
Sprints are limited to one calendar month. When a Sprint horizon is too long the
definition of what is being built may change, complexity may rise, and risk may
increase. Sprints enable predictability by ensuring inspection and adaptation of
progress toward a Sprint Goal at least every calendar month. Sprints also limit risk
to one calendar month of cost.

Scrum School
What are the activities of the Product Backlog Refinement?
There are many activities in Product Backlog Refinement as follows:
 Breaking down the huge items (Epic)
 Creating new items
 Removing items
 Adding detail to the items
 Analysis
 Design
 Estimation
 Valuation
 Ordering
 …
Product Backlog Refinement is done by the Product Owner and the Development
Team collaboration. It should not take more than 10% of the Development Team
capacity but the Product Owner should work on refinement without any constraint.
What are the most important topics that should be presented in the Sprint
Review?
Fundamentally the Sprint Review is an inspect and adapt loop, not just a demo
meeting. The most important topics in this event are:
‐Inspect the Increment through showing it by the Development Team and try it by
stakeholders and customers in order to elicit feedback
‐Check how the current Sprint went and if the Sprint Goal was achieved or not
‐Adapt Product Backlog through the Team and stakeholders’ collaboration to
nominate things that can be done during the next Sprint
‐The Product Owner explains the project status and the latest forecast of the
project completion date
‐Stakeholders collaborate with the Team to adjust the budget, inspect market
status and every project level interesting things

Scrum School
‐Is an informal meeting and there is not any hand‐off / sign‐off in it
What would be the reaction of the Development Team in the middle of the Sprint
when they find they have over committed?
When the Development Team is in the middle of the Sprint, they could not change
the Sprint Backlog items by itself. If they find they have over committed, they
should inform the Product Owner to review the items together and negotiate about
the scope if necessary or they might leave the Sprint Backlog intact that may lead
to some undone items at the end of the Sprint, which naturally will move back to
the Product Backlog.
How would new emerged tasks during the Sprint change the Sprint Backlog?
In the Scrum, task and work are two keywords with the same meaning that are used
to break down the PBIs. Tasks are the activities that need to be done by the
Development Team in order to create usable and releasable Increments. As
explained, Scrum is founded on adaptive approach and the Development Team
should inspect and adapt its work continuously. Therefore, each time they find a
new task or work for each PBI in the Sprint Backlog they can add that task to the
Sprint Backlog and even they can remove some tasks.
The Development Team owns the Sprint Backlog so the Scrum Master and the
Product Owner should not change it.
What are the Sprint‐level risks?
There are many potential risks in Sprint level. The main tool for these risks’
identification is inspecting and observing all risk points through all Team members’
collaboration. In addition, the Sprint Planning is a suitable meeting to identify risks
and make a plan to manage and control them. Sprint level risks can be as following
list:
- Selected Product Backlog Items for the Sprint do not present maximum
value

Scrum School
- Selected PBIs were not refined properly
- There is not strong Sprint Goal
- The Product Owner may not have enough time for the Development Team
- The Sprint Goal might be obsoleted in the middle of the Sprint
- The Team members do not collaborate with each other
- Top management may force the Team to do emergency work and
interrupt their focus
- The Team does not participate actively in the Scrum events
- Stakeholders do not collaborate actively in the Sprint Review
- Increment does not actually be releasable
- The Team does not care about process improvements
- The Team does not care about budget for each Sprint
What is the Sprint Backlog?
Sprint Backlog is the set of Product Backlog Items selected for the Sprint, plus a plan
for the Development Team for delivering the Product Increment and realizing the
Sprint Goal and is created during the Sprint Planning.
What are the statuses of ownership and assignment of each element in the Sprint
Backlog?
There are two elements in the Sprint Backlog: Sprint Backlog Items and Tasks. These
elements’ type can be user story, use case, test, bug, issue, and whatever type that
can be used for decomposing Product Backlog Items.
The ownership of both elements is shared and belongs to the Team not individual
members in order to distribute same level of accountability over all members.
There is no assignment for a Sprint Backlog Item because it contains some tasks
that when these tasks are done, the result will be a done Sprint Backlog Item.
Tasks are assigned to the individual Team members with an agreement by all
teammates.

Scrum School
Is it possible to change Sprint Backlog during the Sprint?
Sprint Backlog contains two elements: Sprint Backlog Items and Tasks. Although
changing Sprint Backlog Items is not allowed, tasks could add or remove any time
during the Sprint when the Development Team learns more about the work needed
to realize the Sprint Goal. So, the Sprint Backlog could be updated and changed
during the Sprint.
What are the inputs to the Sprint Planning?
Inputs to the Sprint Planning are: the last Increment, capacity of the Development
Team for current Sprint, team’s last velocity or performance, the Product Backlog,
and even a list of improvements as conclusion of the last Sprint Retrospective.
What are the outputs of the Sprint Planning?
Outputs of the Sprint Planning are Sprint Goal and Sprint Backlog which itself
contains selected Product Backlog Items and their related tasks. The Sprint Goal is
created by all Scrum Team members’ collaboration. In the Sprint Planning, usually
enough tasks are defined for the early days of the Sprint and other tasks emerge
during the Sprint when the Development Team learns more about the work.
What is the usual comparison of PBIs average size in the Product Backlog and
Sprint Backlog?
During the Product Backlog refinement, Items are expressed with more details and
broken down to the smaller items that can be finished in a Sprint. In addition, more
effort will pay for refining Items on top of the Product Backlog because they have
more probability to implement in the upcoming Sprints so usually PBIs on top of
the Product Backlog are smaller than PBIs in the bottom. Further, the Development
Team selects Items for the Sprint from top of the Product Backlog. Consequently,
average size of the Items in the Product Backlog are usually larger than Items in the
Sprint Backlog.

Scrum School
When is the Sprint Backlog created?
Creating the Sprint Backlog is a collaborative work that is done by the Development
Team members during the Sprint Planning not before or after it.
Why is not Product Backlog a comprehensive and predictive plan?
All upfront effort to create a complete and comprehensive plan is a type of waste
because during the project when members learn more about the project and new
things emerge, changes in the requirements and direction are inevitable. So some
of the planned work should throw away. On the other hand, Scrum is an adaptive
approach, not predictive and uses empiricism. Furthermore, there are not any
phases such as requirement specification phase or special Sprints such as Sprint
Zero in Scrum for project upfront planning. Finally, it is not a baseline plan with a
purpose to maintain it intact.
Briefly, Product Backlog provides just enough information to enable the
Development Team to select and develop for the next few Sprints. Also, it evolves
throughout the project and is never complete.
When can a feature or PBI be seen as done or complete?
Finishing Product Backlog Items is an important concept in Scrum. It emphasizes
that all team members should have a common understanding of done. Therefore,
Definition of Done is introduced as part of the Scrum and defines all required work
that should be completed before an end user be able to use the product and
nothing else remain before its release.
Although the Product Owner approval is required, it does not mean the PBI
completeness. As a tip, the Product Owner approval would be a criteria in the
Definition of Done. Furthermore, approving PBIs’ completeness is not the Scrum
Master’s responsibility. In addition, there could be many things in the Definition of
Done that customers do not know about them such as code quality metrics’
thresholds, so customers also could not determine PBIs’ completeness. Finally, the

Scrum School
Development Team agreement is not enough about an Item’s completeness
because they may forget doing some tasks for having a usable and releasable
feature.
Done or completeness of a PBI can be explained through the following statements:
‐ When everything is done based on the Definition of Done
‐ When there is nothing more to do before it can be used by the end users
‐ When it is potentially releasable and shippable
‐ The Item is usable by the end user
How does the Definition of Done help the Development Team?
Definition of Done is a fundamental concept of Scrum which creates a common
understanding of when work is complete, helps developers understand how many
Product Backlog Items they can select for each Sprint and increases transparency.
In addition, it can be considered as a development process and contains many
things such as quality criteria, metrics, non‐functional requirements, etc. Finally, it
is created by the Development Team (or development organization which can
make minimum rules for all teams over the organization) while the Product Owner
can prepare some inputs for example Non‐functional requirements thresholds. The
Development Team should have a Definition of Done at least based on the
organization definition or with more stringent criteria.
What is the difference between Definition of Done and Acceptance Criteria?
Definition of Done is a concept with a set of requirements that should be applied
to a feature in order to be called as complete. On the other hand, Acceptance
Criteria or Conditions of Satisfaction contains a list of scenarios that should be
passed to ensure that the feature is working as expected. The difference is that
there is one Definition of Done for the product and is common for all features while
there is a separate and specific Acceptance Criteria for each feature. Passing
Acceptance Criteria would be an item of the Definition of Done.

Scrum School
Is there the “Definition of Ready” concept in Scrum?
There is no “Definition of Ready” concept in Scrum so the Development Team
cannot refuse PBIs because they are not ready. Through Product Backlog
refinement, the Product Owner and the Development Team collaborate to clarify
all aspects of the PBIs but if they did not do so, they would select PBIs from top of
the Product Backlog, start the Sprint, and add more details to the selected PBIs
during the Sprint.
What is scaled Scrum?
Scaled Scrum is based on the Scrum framework and uses Scrum parts as its building
blocks with some additions or changes within which multiple teams work on the
same product for one or more Sprints in order to produce a releasable integrated
Increment at the end of each Sprint.
Scrum.org has introduced the Nexus framework for this purpose with some
differences with scaled Scrum, which contains 3‐9 Scrum Teams and a Nexus
Integration Team.
What are two main subjects that arise in scaled Scrum?
When multiple teams work on the same product, one main subject is minimizing or
removing dependencies among teams. Dependencies make a challenge for all
teams’ outputs integration. Next subject is teams’ outputs integration, means how
teams can collaboratively create an integrated releasable Increment at the end of
each Sprint.
What is deliverable Increment in scaled Scrum to be demonstrated in the Sprint
Review?
In scaled Scrum, each Team creates their done Increment and they integrate their
work in a daily basis. However, the integrated Increment as a whole, which contains
all Teams’ outputs is used to be demonstrated in the Sprint Review.

Scrum School
What is Scrum of Scrums?
When multiple teams are working on the same product, everyday representatives
from all Development Teams gather to talk about new dependencies and issues
that may affect other teams. This meeting is called Scrum of Scrums that is used to
align all teams.
How many Definition of Done can be used in scaled Scrum?
When multiple Development Teams are working on the same product they can (not
should) have one Definition of Done for all Teams or each Team can have its own
one or something between these two extremes. The rule here is that their outputs
should be combined and integrated continuously and at the end of the Sprint they
should deliver just one integrated Increment as all Teams’ output so all Definition
of Done should not violate each other.
What is the way of dividing developers into multiple teams for a single Product?
The developers in Scrum are self‐organizing, so based on knowing the product and
its vision, they should decide how to divide themselves into multiple teams.
Moreover, nobody else such as the Product Owner, the Scrum Master or top
management should make this decision.
In addition, they should consider each team should be cross‐functional which
means each team should have all required skills to convert Product Backlog Items
to a releasable Increment. Also, they should adhere to the recommended minimum
and maximum number of developers in each team i.e. 3‐9 members.
Furthermore, based on the situations, Teams’ compositions can be changed after
each Sprint if needed.
How is Sprint Planning conducted in scaled Scrum?
All Scrum Teams’ members should be present in the Sprint Planning. The Product
Owner provides domain knowledge and guides selection and priority decisions. All
members discuss dependencies and their effects on each Team. Then each Team

Scrum School
selects their PBIs with all other Teams’ consensus and Product Owner guide as their
Sprint Backlog items. Each Team has a separate Sprint Backlog.
What are the quantity of each Scrum role in scaled Scrum?
In scaled Scrum which multiple Teams work on a single Product, there is just one
Product Owner, multiple Development Teams and one Scrum Master position for
each Development Team that can be filled with one or multiple Scrum Masters.
In scaled Scrum environment, how can compare velocity of a team to another?
Velocity is the average amount of work that a Team can complete in a single Sprint.
Its main use is helping Teams during the Sprint Planning as a guide to the Teams’
capacity. It means how much work they could pick to complete until the end of the
Sprint. In addition, velocity is a relative concept, which cannot be compared with
other projects and other teams. Different Teams have different characteristics,
skills, experiences, and different goals. Using velocity as a comparison tool is wrong
that can lead Teams to focus on increasing their velocity through unacceptable
ways like inflation in estimation or cutting quality corners instead of delivering high
value and quality software continuously.
In scaled Scrum environment, should all the Scrum Teams have the same
Sprint length?
In scaled Scrum, having the same Sprint length for all Scrum Teams is not
mandatory. However, having the same Sprint length is a good practice.
Furthermore, Scrum Teams can have different Sprint lengths and it is better that
the Sprint lengths be a multiple of each Sprint length. For example, if the longer
Sprint is four weeks, the shorter Sprint can be two weeks while the shortest Sprint
can be one week. Because at the end of the longest Sprint length, all Scrum Teams
should have an opportunity to bring an integrated releasable increment
collectively.

Scrum School
How many hours per day should the Development Team work?
Development Team should be fast and nimble through its productive processes and
individuals’ skills not by working overtime or organizational policies or forces.
Overtime is a symptom that there are some problems in the process or
environment. On the other hand, establishing a balance between work and
personal life leads to better productivity that occurs via sustainable pace. This
sustainable pace is usually between 6 and 8 hours per day.
What is the reliable approach for starting a project in Scrum framework?
At the start of a project, Scrum Master should try to establish a trust foundation in
the team. It could be accessible by introducing team members by themselves. By
this policy, individuals will know more about each other’s capabilities, strengths,
weaknesses, and backgrounds. On the other hand, knowing about the product is
important so the Product Owner should explain the project, its business need,
history, goals, and vision. Also, it is a good idea that the Development Team knows
about the Definition of Done concept and the importance of creating done
increments continuously. All these things make a common understanding among
the team and align all team members so it will decrease the probability of occurring
conflicts.
When should potentially releasable functionalities be available?
Outputs of each Sprint should be some business deliverables that are potentially
shippable and releasable based on the Definition of Done. Product Owner could
not request it each time for example at the beginning of the Sprint. In addition,
each release usually contains several Sprints outputs, which the Product Owner can
release them if it makes sense.
Why should not completing features based on the Definition of Done be
postponed to the end of the release plan?
The main purpose of the Sprint time‐box is developing releasable features and
getting feedback from the market, customers and stakeholders based on done

Scrum School
features frequently. Postponing feature completion will lead to miss gathering
feedback and lose inspect and adapt opportunity and limit the Product Owner to
be as nimble as possible about releasing features. In addition, each release usually
contains outputs of several Sprints and postponing feature completion to the end
of the release, increases integration risks and related issues.
What do the burn‐down chart X‐axis and Y‐axis show?
Burn‐down chart Y‐axis usually shows total remaining work and X‐axis shows a type
of time i.e. Sprint days in Sprint burn‐down chart and Sprint numbers in Project
burn‐down chart.`
What do the burn‐up chart X‐axis and Y‐axis show?
Burn‐up chart Y‐axis usually shows total done work and X‐axis shows a type of time
i.e. Sprint days in Sprint burn‐up chart and Sprint numbers in Project burn‐up chart.
What does the Project burn‐down chart trend line show?
Project or release burn‐down chart indicates the remaining work at the end of each
Sprint. Its Y‐axis shows total remaining work and X‐axis shows Sprint numbers. If
you draw a trend line from the project beginning remaining work to the amount of
the remaining work at the end of the current Sprint and continue to cross the X‐
axis, the intersect point shows the forecast date that all remaining work will likely
be completed if nothing changes in the Product Backlog or the Development Team
composition. It means adding or removing PBIs to/from Product Backlog or
increasing / decreasing of the number of the Development Team members will
affect this forecast.
What does the Sprint burn‐down chart trend line show?
Sprint burn‐down chart indicates the remaining work of each day during the Sprint.
Its Y‐axis shows total remaining work and X‐axis shows Sprint days. If you draw a

Scrum School
trend line from the Sprint beginning remaining work to the last day of the Sprint on
the X‐axis, you will have the plan trend line and you can compare actual and plan
progress daily in order to resolve deviation as soon as possible if needed. Increasing
to the remaining work during the Sprint is natural because new tasks can emerge
when the Development Team learns more about the work.
What is an Increment?
An Increment is the sum of all new done features that are added to those delivered
in the previous Sprints. Each Increment can be seemed like a different version of
the software and includes all previous Increments.
When should an Increment be released?
All outputs of Sprints should be shippable and releasable that meet the Definition
of Done so the Product Owner could release it each time (s)he decides and makes
sense. Release and ship authority belongs to the Product Owner.
For more information, releases could happen after each few Sprints or after each
Sprint or even multiple times during each Sprint by Product Owner decision.
How are architectural and infrastructural concerns managed in Scrum?
Development Team should have some guidelines for deciding and handling
architectural and infrastructural concerns. They should handle these concerns as a
part of other Product Backlog Items during each Sprint. Doing a lot upfront in order
to make a comprehensive architecture at the beginning of the project is a type of
waste. Handling architecture should be done continuously based on the learnings
that emerge during the Sprints. It is obvious that it uses more effort at the early
Sprints and decreases during the middle and last Sprints. On the other hand, during
each Sprint, team should try to produce at least one potential releasable business
functionality in order to get feedback from customers. Therefore, adding
architectural and infrastructural items to the Product Backlog in order to do in the
early Sprints is a valid policy.

Scrum School
Who is responsible for architectural and infrastructural concerns in Scrum?
The Development Team is cross‐functional and has all required skills for producing
releasable functionality and doing all technical work e.g. architectural and
infrastructural concerns, design, develop, test and etc. Doing these concerns
through separate team, sub‐team or having dependency to outside resources are
not acceptable.
When can the Development Team change their practices, tools or techniques?
Scrum is based on adaptive approach and the Team inspects and adapts itself
continuously as they learn more about the product and development process.
During the project, Team may find many problems, issues or improvements so they
could adapt, change and improve themselves whenever needed about everything
such as practices, tools or techniques.
What are the achievements of using tests from the beginning of the project?
All the Scrum Team members are responsible for the product’s quality. In Scrum,
as an adaptive approach, quality and test should be considered from the beginning
of the project. It leads to more transparency in Increments, ensures to have
releasable Increments, decreases the risk of reworks and as it helps to produce
reliable Increments, customer feedback will be around business expectations not
about bugs or wrong implementation so it improves customer feedback’s level.
Can a feature with small bugs be considered as a deliverable?
No. Having a feature with small bugs means it is not releasable so the Product
Owner cannot accept it as a deliverable.

Scrum School
How should the development environment, tools and infrastructures be
prepared in a project?
Development environment, tools, and infrastructures required for the
development should be prepared and improved gradually during the project. It is
obvious that it uses more effort at early Sprints and decreases during the middle
and last Sprints. In addition, during each Sprint, the team should try to produce at
least one potential releasable business functionality in order to get feedback from
customers.
On the other hand, there is no special time before the first Sprint or Sprint Zero to
do such a preparation.
How can the Scrum Team manage non‐functional requirements in Scrum?
The non‐functional requirements or cross‐cutting concerns are the features of the
design that may apply across all layers and are related to the quality requirements.
There are many non‐functional requirements as following: Security, Reliability,
Performance, Availability, Globalization, Scalability, Maintainability, Robustness
etc. They can be managed through adding them to the Product Backlog or the
Definition of Done.
What is technical debt?
Technical debt comes from making bad technical decisions and is the eventual
consequences of poor technical choices. The Team should pay it back continuously.
If the Team does not pay back, it will decrease the development speed over time.
Although its measurement is hard, its growth would lead to wrong assumptions
about Increments delivery and even might prevent creating the releasable product.
Which parts of Scrum are required and should be used?
According to the Scrum Guide, mandatory rules and principles of Scrum are Scrum
Roles, Scrum Events, Sprint Goal, Product Backlog, Sprint Backlog, Increment,
Definition of Done and Monitoring progress in Sprint and Project levels.

Scrum School
Other things are practices that can be employed in the Scrum framework and are
up to the team and project and are not mandatory.
Who determines how work should be performed during the Sprint?
Development Team is self‐organizing and no one tells them how to perform work
and turn the Product Backlog into Increments of potentially releasable
functionalities. In addition, Development Teams are cross‐functional with all
required skills to create a product Increment.
What are the Scrum Values?
Scrum is based upon five core values: Commitment, Focus, Openness, Respect,
Courage.
Commitment: The Scrum players commit to the team. Commit to quality. Commit
to collaborate. Commit to learn. Commit to do the best they can, every day again.
Commit to the Sprint Goal. Commit to act as professionals. Commit to self‐
organization. Commit to excellence. Commit to the Agile values and principles.
Commit to create working versions of product. Commit to look for improvements.
Commit to the Definition of Done. Commit to the Scrum framework. Commit to
focus on value. Commit to finish work. Commit to inspect and adapt. Commit to
transparency. Commit to challenge the status‐quo.
Focus: The time‐boxing of Scrum encourages the Scrum players to focus on what’s
most important now without being bothered by considerations of what might
stand a chance of becoming important at some point in the future. They focus on
what they know now. YAGNI (‘You Ain’t Gonna Need It’), a principle from eXtreme
Programming, helps in retaining that focus. The players focus on what’s imminent
as the future is highly uncertain and they want to learn from the present in order
to gain experience for future work. They focus on the work needed to get things
done. They focus on the simplest thing that might possibly work. The Sprint Goal
gives focus to a period of 4 weeks, or less. Within that period, the Daily Scrum helps

Scrum School
people collaboratively focus on the immediate daily work needed to make the best
possible progress towards the Sprint Goal.
Openness: The empiricism of Scrum requires transparency, openness, and honesty.
The player inspectors want to check on the current situation in order to make
sensible adaptations. The players are open about their work, progress, learnings
and problems. But they are also open for people, and working with people;
acknowledging people to be people, and not ‘resources’, robots, cogs or
replaceable pieces of machinery. The players are open to collaborate across
disciplines, skills and job descriptions. They are open to collaborate with
stakeholders and the wider environment. Open in sharing feedback and learning
from one another. They are open for change as the organization and the world in
which they operate change; unpredictably, unexpectedly and constantly.
Respect: The broader Scrum ecosystem thrives on respect for people, their
experience and their personal background. The players respect diversity. They
respect different opinions. They respect each other’s skills, expertise and insights.
They respect the wider environment by not behaving as an isolated entity in the
world. They respect the fact that customers change their mind. They show respect
for the sponsors by not building or keeping functions that are never used and that
increase the cost of the product. They show respect by not wasting money on
things that are not valuable, not appreciated or might never be implemented or
used anyhow. They show respect for users by fixing their problems. All players
respect the Scrum framework. They respect the accountabilities of Scrum.
Courage: The players show courage by not building stuff that nobody wants.
Courage in admitting that requirements will never be perfect and that no plan can
capture reality and complexity. They show the courage to consider change as a
source of inspiration and innovation. Courage to not deliver undone versions of
product. Courage in sharing all possible information that might help the team and
the organization. Courage in admitting that nobody is perfect. Courage to change
direction. Courage to share risks and benefits. Courage to let go of the feint
certainties of the past. The players show courage in promoting Scrum and
empiricism to deal with complexity. They show courage to support the Scrum

Scrum School
Values. The courage to take a decision, act and make progress, not grind. And even
more courage to change that decision.
For more information about Scrum Values, please read following article by Mr.
Gunther Verheyen:
https://guntherverheyen.com/2018/09/26/the‐international‐versions‐of‐the‐
scrum‐values‐september‐2018‐update/
Special thanks to Mr. Gunther Verheyen

Scrum School
The End
Scrum School

202004-Scrum-Master-Certification-Training-Manual.pdf

Recommended

Recommended

More Related Content

Similar to 202004-Scrum-Master-Certification-Training-Manual.pdf

Similar to 202004-Scrum-Master-Certification-Training-Manual.pdf (20)

Recently uploaded

Recently uploaded (12)

202004-Scrum-Master-Certification-Training-Manual.pdf