The Professional Scrum Master Certification level 1 is one of those easy certifications you can easily obtain by reading a little bit about scrum and doing a couple mock tests.
This article will compile a list of useful resources that will help learn more about the scrum framework and eventually pass the certification.
I highly suggest reading the official scrum guide. It is short and simple to read. With that said I will outline below the most important parts of each section and then mention important points to keep in mind while passing the scrum certification.
Highlights from the Scrum Guide
Definition of SCRUM
Scrum is a
lightweight frameworkthat is based on
empirical process control theory. This framework is used to create and maintain complex products.
Being empirical, means that scrum extracts its knowledge from experience.
Scrum relies on small teams of people that are
highly flexible and
Scrum is built on three main pillars:
The work of everyone is visible to all the people in the organization.
Some example of where we find transparency in scrum:
During the daily stand up meeting, every member of the dev team talks about his work and issues he is having. this allows everyone to have an idea of what everyone else is doing, and potentially helping solve some of the encountered issues
The Definition of Done (DOD) is another example of transparency in scrum. it allows the dev team and the PO to have an idea about what will be done.
Inspection should be done frequently to make sure there are no unwanted variances from the sprint goal. An example of inspection is the sprint review during which a team can hold a demo.
If a person detects that a particular process has deviated outside of acceptable limits (and that the resulting product will be impacted/unacceptable) then that process must be adjusted as soon as possible to minimize further deviations.
There are 4 official opportunities to inspect and adapt in scrum:
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
The 5 Scrum Values are:
The Scrum Team
The Scrum Teams are self organizing (They chose how to best accomplish the work and not directed by someone) and cross functional (they have the necessary skills to accomplish all the work without depending on others outside the scrum team). The Scrum Team consists of:
The Product Owner
The product owners job is to maximize the value of the work done by the development team. He is the only person responsible for managing the product backlog by:
- Clearly expressing P.B items
- Ordering the P.B by priority
- The P.B items should be visible, transparent and clear to all.
The Development Team
The Dev team is responsible for doing the work and delivering a potentially releasable increment of the product.
A done increment is required at the Sprint Review.
The dev team should have the following characteristics:
- Self Organizing They organize amongst themselves to turn product backlog item to a product increment
- Cross Functional The Dev team should have the skills necessary to create the product increment
- No Titles There are no titles inside the dev team
- No Sub-Teams regardless of the work being done. No testing team, business analysts…
- Accountability belongs to the entire Dev Team
The Dev team should be between 3 and 9 people. Making the scrum team between 5 and 11 people
The Scrum Master
The keywords that you will often hear associated to the scrum master are:
- Removes Impediments
The scrum masters role is also to support the theory of scrum and help everyone apply it correctly.
The Scrum Master can support the PO by finding techniques to effectively manage the product backlog, maximize the value of the work and facilitate scrum events.
The Scrum Master can also support the dev team by teaching them to be self organized and cross functional as well as create a high value product.
The Scrum Master also supports the Organization as a whole by coaching it in its scrum adoption, increasing the productivity of the scrum team and working with other scrum masters to increase the effectiveness of scrum within the organization.
All events in Scrum are time boxed. A Sprint has a fixed duration and cannot be shortened or lengthened. Each event in scrum is an opportunity to inspect and adapt. They are designed to make the work more transparent. So omitting one of those events will lead to a loss in transparency and an inability to inspect and adapt.
A Sprint is time boxed at one month or less. Its duration is fixed and does not change during a sprint. During a sprint a Done increment of a potentially releasable software is created.
During a Sprint:
- No change is allowed if it endangers the Sprint goal
- Quality goal does not decrease
- Scope may be changed and re-negotiated between the PO and the Dev Team as more is learned
A Sprint may be cancelled by the product owner (only the product owner) if the sprint goal becomes obsolete. When a Sprint is cancelled, any completed “Done” items are reviewed and if it is potentially releasable, the PO typically accepts it. All incomplete work is re-estimated and put back in the Product Backlog.
The entire Scrum Team collaborated to create a plan for the Sprint.
The Sprint Planning is Time-Boxed to 8 hours for a one month Sprint. The scrum master has to make sure the event takes place and that it remains within its allocated time box.
The input of the sprint planning are:
- The Product Backlog
- The latest done increment
- The projected capacity of the dev team
- The past performance of the dev team
During the Sprint Planning, only the dev team can assess what can be done. The items to be selected are solely up to the dev team.
The sprint goal provide guidance to the dev team as to why it is building the increment.
The dev team may invite other (external) people to the sprint planning to provide expert advice.
The daily scrum is time boxed to 15 minutes. It is held at the same time and place everyday to reduce complexity.
The daily scrum should be organized in a way to better achieve the sprint goal. Scrum suggests the following format:
- What did I do yesterday that helped achieve the sprint goal?
- What will I do today to help achieve the sprint goal?
- Do I see any impediments that prevent me from achieving the sprint goal?
The scrum master is only responsible for insuring the dev team holds the meeting and that the latter is kept within its time boxed. The daily scrum is an internal meeting for the dev team. if others are present, the scrum master makes sure they do not disturb the meeting.
The sprint review is held at the end of every sprint and is time boxed at 4 hours for a one month sprint. During this ceremony, the scrum team and the stakeholders collaborate on what was done during the sprint and on the next thing that could be done to optimize value.
The result of the sprint review is a revised product backlog that define the probable items for the sprint planning.
The sprint retrospective is an opportunity for inspection and adaptation. It is time-boxed at 3 hours for a one month sprint.
The scrum master insures that this meeting is positive and productive and participates as a peer team member.
The purpose is to:
- Inspect how the last sprint went
- Identify and order the major items that went well and identify potential improvements
- Create a plan for implementing improvements
Artifacts by scrum are designed to maximize transparency.
The Product backlog is an ordered list of everything that is known to be needed in the product. The PO is responsible for the product backlog including its ordering and content. It is never complete, it evolves as the product evolves. as long as a product exists, the PB also exits.
If multiple scrum teams are working on the same product, they all share the same product backlog but different Sprint Backlog. If that is the case, it becomes imperative that everyone has a clear understanding of what is to be done in the increment.
No more than 10% of the Dev Team capacity should be spent on the product backlog refinement.
The Sprint Backlog is the set of product backlog items selected for the sprint. It is owned by the Dev team and can contain items that are not related to the product backlog. It includes at least one high priority process improvement identified in the previous retrospective.
Monitoring Sprint progress in the sole responsibility of the Development Team.
The increment is the sum of all the product backlog item completed during a spring and the value of all previous increments.
The Definition of Done
The definition of “Done” is a shared understanding of what it means for a work to be done. It helps provide transparency and guide the dev teams in picking the number of product backlog items to select for the upcoming sprint.
All scrum team working on the same product must follow the same definition of done (to a minimum)
List of Key Points for the Test
There are some key points you need to keep in mind that will allow you to pass the test.
Scrum is based on
Empirical Process Control Theory
The scrum team: consists of the Dev team + the product owner (PO) + the Scrum Master
Scrum is a light framework for developing and maintaining complex products (not necessarily software)
You cannot pick an choose components from scrum as you please. every component is essential
The Dev team is a self organizing unit
Scrum recognizes no specialized roles in the dev team (tester, front, back…) and no hierarchy.
The Dev team as a whole should have all the skills necessary to accomplish the “work” (commonly known as User Stories/Features…)
The Dev team should do all the work on the task including the tests. (everything in the definition of done). which means that the scrum framework does not recognize teams such as “Integration Testers”, “quality assurance” ect…
Know the time limits of the different scrum ceremonies. A new sprint starts when the time limit of the previous sprint expires.
The scrum master is here to facilitate. His job is not to attend all the dailies and make sure its below 15 min (time-box) his job is to facilitate the work of the dev team and po. he should also insure that the dev team do hold the daily.
The Dev team delivers the product in small increments. at the end of the sprint, the increment should be potentially releasable to production. but it doest have to be released (only when it makes sense to do so)
When multiple dev teams are working on the same product, they should:
- Make sure they have a clear definition of the requirements.
- It is highly advisable that their work be integrated at the end of each sprint so that the PO can inspect the work done by the dev team
The dev team determines how the work will be done as well as the amount of work to take on (with the coordination of the PO)
Adding a new member to the dev team will decrease the velocity for a short amount of time before the latter starts picking up again.
Product backlog is ordered by priority
The Product Owner is the expert in the business part of the product
The PO has a final say in matters of product backlog. Dev teams have a final say in matters of Sprint Backlog
A dev team member cannot
owna sprint backlog item. The entire dev team is responsible for all the items on the sprint backlog.
Update: Additional Resources
Of the 2 or 3 people that actually read this blog (from time to time), someone asked me to add some additional resources. More specifically mock tests that can be used to further complete one’s understanding of the subject and make sure that one is ready to pass the exam. So here’s a short list of useful resources:
https://mlapshin.com/index.php/scrum-quizzes (both learning mode and real mode)
https://quizlet.com/261765971/scrum-master-flash-cards/ Fun flashcards for your daily commute 🙃