Scrum master roles and resonsibilites

https://www.softwaretestinghelp.com/scrum-roles-responsibilities/

https://agilemania.com/agile-definition-of-done/?gclid=Cj0KCQiAoY-
PBhCNARIsABcz771OYNpnCLpm7LozBJP5u4QtocFQeMYMqJP83KMRT05DIWuUiVDGYzMaAi9tEALw_
wcB
Explanation
The main rule is that the Product Owner is a single person, not a group of people.
The Stakeholders may influence the them, but ultimately, the final decision is taken
by the Product Owner.

The Product Owner will maximize the Product's value by managing the Product
Backlog, not the Sprint Backlog. The Product Owner cannot modify the Sprint
Backlog. That is the responsibility of the Developers.

While the Product Owner can delegate some responsibilities to others (including the
Developers), we cannot say that this "usually" happens. This is why Scrum has
different accountabilities.
 Explanation
The idea is as follows: if the Scrum rules are modified, it will be easier for an
organization to adopt Scrum. But some of the benefits of Scrum will be lost, and
probably not much will change, as the old habits will kick in.
The Scrum Guide v2020 warns about this: “Scrum is free and offered in this Guide.
The Scrum framework, as outlined herein, is immutable. While implementing only
parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety
and functions well as a container for other techniques, methodologies, and
practices.”
Scrum has rules that must be followed. If it is hard for a company to adopt Scrum, it
is because the company does not want to change in the first place.
Explanation
When multiple teams work on the same Product, the same rules apply. No later than
the end of the Sprint, the Increment must be done and usable, which means it must
contain all teams' work. If possible, multiple Increments can be created and released
during the Sprint.
 Explanation
You can deal with such questions using a process of elimination. First of all, the
Scrum Team cannot ignore the Definition of Done as this impacts transparency. Not
taking into account the Definition of Done, makes it useless, which is not the point of
having one in the first place.

In Scrum, no events are stopped or suspended. Everything is time-boxed so that the

risk remains acceptable and limited to one Sprint. If something goes wrong, the
Scrum Team will have a chance to inspect and adapt during the Sprint Retrospective.

Can quality goals be decreased?

No, they should not be decreased, especially during the Sprint. The assumption here
is that the Scrum Team already has the skills needed to do the work according to
the Definition of Done but may be tempted to lower the quality just to get things
done with the Sprint time-box.
The Scrum Guide v2020 says the following: "During the Sprint quality does not
decrease,"  and we can safely say that the Definition of Done is responsible for
ensuring quality.

This can mean that the Scrum Team should not lower the quality goals to complete
the Sprint.

The scenario described in the question is slightly different. Scrum Team does NOT
have all the skills needed to complete the selected Product Backlog Items according
to the Definition of Done.
While this is less than ideal, a strict Definition of Done is not very useful in this
context. Even if the Scrum Team wants to do everything according to the Definition
of Done, this is currently not possible.

In this case, it is acceptable to lower the quality and restore transparency over the
work performed and work toward improving it over time, and this is the only sensible
thing to do. It is better to have a lower quality standard than no standard at all.

Adapting the Definition of Done is typically done when the development work has
stopped (during the Sprint Retrospective).

xplanation
A Product Backlog Item is complete and potentially releasable when it meets the
Definition of Done.

The purpose of the Sprint Review is not to approve or reject work.

"The Sprint Review should never be considered a gate to releasing value." - Scrum
Guide v2020.

The Scrum Team uses the Sprint Review to get feedback from the Stakeholders, but if
work is completed earlier in the Sprint, the Product Owner may decide to release it.
]
\
Explanation
The Developers continuously collaborate with the Product Owner. They need to
discuss if the Sprint Goal is still reachable and try to adapt the Sprint scope. Since this
is the Sprint Planning meeting, it is even possible to change the Sprint Goal.

Changing the Sprint Goal alone without adapting the selected Product Backlog Items
(the scope) won’t help.

Even if the Sprint Goal and the scope remain the same during the Sprint Planning
meeting, the Developers still need to monitor the Sprint's progress. If needed, they
can work with the Product Owner to change the Sprint Backlog as long as the Sprint
Goal remains intact.

Remember, the content of the Sprint Backlog can be changed even during the Sprint.
The Sprint Goal cannot change once the Sprint Planning meeting has concluded.
Explanation
Trick question! The Scrum Team decides when (and how) refinement is done, not
only the Product Owner. It is a collaborative work.

The Sprint is the container for everything that happens. There is nothing between
two Sprints.
Explanation
The Daily Scrum is for the Developers, not for the Product Owner, Scrum Master, or
any external parties. Also, the organization of the Daily Scrum is left to the
Developers.

Explanation
This is one of the trick questions, so let's have a look at the wrong answers first:

Sprints must have consistent durations, so the length should not change when the
workload changes.

Sprints are also limited to a maximum of one month. "As long as needed" is not
appropriate in this situation.

Now the correct answers:

Determining the proper duration of the Sprint is a balancing act. Risk is significant in
Scrum, so the shorter the Sprint, the lower the risk that the development goes in the
wrong direction.

The Scrum Guide v2020 says the following: “When a Sprint’s horizon is too long the
Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter
Sprints can be employed to generate more learning cycles and limit risk of cost and
effort to a smaller time frame.”
The Scrum Guide does not explain this, but as requirements never stop changing in
some industries, the Sprint length may need to be synchronized with the needs of
the business. You can’t commit to Sprint Goal for 4-weeks if the business conditions
change every two weeks.

Explanation
The Developers doing the work are responsible for quality. Nobody needs to verify
that they do their job.
Explanation
Please note that this question does not indicate how many answers are correct, and
you need to select only the correct ones.

From the possible answers, only the Sprint Retrospective is a requirement in Scrum. It
does not mean that the other answers are wrong, but they are simply not required.

Burn-down charts or other charts are mentioned in the Scrum Guide, but they are
not mandatory.
Release planning or Product planning needs to be adapted to an empirical
environment, but it is not a requirement in Scrum.
Daily Stand-up meeting. There is nothing in the Scrum Guide which demands the
Developers to stand during the Daily Scrum. In practice, this helps remind the team
that this is a short meeting.
Smaller Product Backlog Items are easier to manage and estimate, so Scrum Teams
always try to work with smaller items.

Therefore, the items at the top of the backlog (soon to become Sprint Backlog Items
once selected) are usually more refined and smaller than the rest of the Product
Backlog Items since they have already gone through refinement sessions.
Tricky question! Notice the "must." The Scrum Guide does NOT require for Sprints to
be aligned.

While it might be a good idea to do so, the Scrum Guide only refers to the Definition
of Done, the Product Backlog, and that by the end of the Sprint, a potentially
shippable Product Increment is created. These are the only requirements.

Explanation
The Scrum Team does not need to wait for the end of the Sprint to release
something to production. An Increment may be ready anytime during the Sprint. The
idea with the Increment is that it should be done by the end of the Sprint. As soon as
a Product Backlog Item is completed, a new Increment is created. Having small and
well-refined Items helps to achieve this.
Many software products are deployed to production multiple times per day while still
using Scrum. If the Developers' work is according to the Definition of Done and the
Scrum Team decides to release the work, it can do that during the Sprint, without
waiting for the Sprint to end or for the Sprint Review meeting.

This does not mean that the Stakeholders or any ofter parties affected are not
informed. People in a well-functioning organization don’t talk only during the
prescribed Scrum events. They collaborate all the time throughout the Sprint.

In software Products, the Developers use modern CI/CD tools and automated testing
to ensure that the Increment respects the Definition of Done.

Scrum is just a framework, not something that stands in the way of doing what is
valuable for customers.
Explanation
The Scrum Master needs to find a way to make things work given the current
situation and stay within the Scrum rules.

If the Product Increment is not complete, it does not fulfill the Definition of Done. So
transparency is impacted by this. The Product Owner cannot accept incomplete work.

To restore transparency, it would make sense to adapt the Definition of Done to

match what the team can currently deliver. The Definition of Done needs to be
achievable. A reduction in quality is needed to have a common understanding of the
work performed.

Example: The Definition of Done requires a test-coverage of 80%, but the current test
coverage is only 10%. It is better to set the Definition of Done at 15%, to maintain
and improve that over time compared to merely ignoring the test-coverage aspect.
Maybe after 5 Sprints, the Developers can reach 50%.

The Scrum Master should coach the Developers into improving their tools, skills, and
processes over time. The Definition of Done can be later changed, as soon as the
problems mentioned above are resolved.
It has no significance how many members the Scrum Team has. The time-box is 15-
minutes.
The architecture and infrastructure of the Product will be constantly improved
throughout the project, as more is learned. Every Sprint should build just enough
architecture and infrastructure. Building the Product (including the architecture and
infrastructure) is the responsibility of the Developers. Nobody external tells them
how to do their work.

We often refer to this as "emergent architecture." This is one of the main ideas in
Scrum: you don't know everything in advance, so you cannot create the architecture
and infrastructure at once and certainly not in the beginning.
The Scrum Guide v2020 explains: “The Scrum Team consists of one Scrum Master,
one Product Owner, and Developers.”