By Ruben Sibon

These are notes on the official Scrum Guide that were made as part of two Professional Scrum Master (PSM-I & PSM-II) trainings given by The Liberators.

Some parts of the guide and the trainings may have been paraphrased or directly quoted in these notes without proper aknowledgement.

These notes may be edited in the future. Suggestions and pull requests are welcome!

Scrum:

• is lightweight
• is a framework
• helps generate value through adaptive solutions for complex problems.

Scrum is founded on empiricism. Empiricism means that knowledge comes from experience and making decisions based on what is observed.

• Transparency, everything is visible to everybody so that they can do:
• Inspection, progress towards agreed goals must be inspected frequently to detect problems in order to allow for:
• Adaption, adaptive teams are self-managing, self-learning and agile; they are always improving.

• Commitment: team commits to achieving its goals and to supporting each other;
• Courage: members have the courage to do the right thing;
• Focus: primary focus is on work to make the best possible progress towards the goals;
• Openness: team and stakeholders are open about the work and the challenges;
• Respect: members respect each other and are respected to be capable, independent people.

When these values are embodied and lived by the Scrum Team the Scrum pillars come to life and build trust for everyone.

• Are committed to creating any aspect of a usable Increment each Sprint.
• They are accountable for:
  • Creating a plan for the Sprint, the Sprint Backlog;
  • Instilling quality by adhering to a Definition of Done;
  • Adapting their plan each day toward the Sprint Goal; and,
  • Holding each other accountable as professionals.

• Is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
• Is also accountable for effective Product Backlog management, which includes:
  • Developing and explicitly communicating the Product Goal;
  • Creating and clearly communicating Product Backlog items;
  • Ordering Product Backlog items; and,
  • Ensuring that the Product Backlog is transparent, visible and understood.

• Is accountable for establishing Scrum as defined in the Scrum Guide.
• Is accountable for the Scrum Team’s effectiveness.
• Serves the Scrum Team in several ways, including:
  • Coaching the team members in self-management and cross-functionality;
  • Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done;
  • Causing the removal of impediments to the Scrum Team’s progress; and,
  • Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.
• Serves the Product Owner in several ways, including:
  • Helping find techniques for effective Product Goal definition and Product Backlog management;
  • Helping the Scrum Team understand the need for clear and concise Product Backlog items;
  • Helping establish empirical product planning for a complex environment; and,
  • Facilitating stakeholder collaboration as requested or needed.
• Serves the organization in several ways, including:
  • Leading, training, and coaching the organization in its Scrum adoption;
  • Planning and advising Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact an empirical approach for complex work; and,
  • Removing barriers between stakeholders and Scrum Teams.

• No changes are made that would endanger the Sprint Goal;
• Quality does not decrease;
• The Product Backlog is refined as needed; and,
• Scope may be clarified and re-negotiated as more is learned;
• Can be cancelled (if continuing no longer makes sense);
• Starts immediatly after the previous sprint;

• Topic One: Why is this Sprint valuable?
  • The Product Owner proposes how the product could increase its value and utility in the current Sprint.
  • The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
  • The Sprint Goal must be finalized prior to the end of Sprint Planning.
• Topic Two: What can be done this Sprint?
  • Development Team forecasts functionality that will be developed.
  • Product Owner discusses objective that the Sprint should achieve.
  • The Product Backlog is the input for the Sprint Planning. Only the Development Team can assess what items from the Product Backlog it can accomplish in the Sprint.
  • Formulation of Sprint Goal: provides guidance to the Development Team on why it is building the Increment.
• Topic Three: How will the chosen work get done?
  • The Sprint Backlog is the output of the Sprint Planning.
  • The Product Owner can provide clarifications.
  • People not in the Scrum Team may also be invited to provide technical or domain advice.
  • At the end of the Sprint Planning the Development Team should be able to explain to the Product Owner and the Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

[From about here the guide still needs to be updated according to the 2020 edition - RS]

• Team inspects progress towards Sprint Goal;
• Adapts the Sprint Backlog as necessarry;
• Held at same time and place each day to reduce complexity
• Possible questions or discussion points:
  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
• Scrum Master ensures that the meeting takes place, but the Development Team is responsible for conducting the Daily Scrum.

• Held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.
• Scrum Team and stakeholders collaborate about what was done in the sprint.
• The Product Owner explains what has been “Done” and what has not been “Done”.
• The Development Team discusses what went well during the Sprint, what problems it ran into and how those problems were solved.
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment
• The Product Owner discusses the Product Backlog as it stands.
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning.
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next.
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

• The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
• Purpose:
  • Inspect how the last Sprint went with regards to people, relationships, process, and tools.
  • Identify and order the major items that went well and potential improvements.
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

Scrum Artifacts are pieces of work or value to provide transparency and opportunities for inspection and adaptation. Artifacts are designed to maximize transparency of key information so that everybody has the same understanding of the artifact. Examples of Scrum Artifacts:

• Product Backlog
• Sprint Backlog
• Burn-Down Chart
• Increment

• The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
• Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when "Done".
• Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

• Set of Product Backlog items selected for a Sprint.
• Plus a plan for delivering a Product Increment.
• At any time the total work remaining in the in the Sprint Backlog can be summed.

• The sum of all Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
• At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done".

• Everyone must understand what “Done” means
• This is the definition of "Done" for the Scrum Team and is used to assess when work is complete on the product Increment.
• If "Done" for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of "Done" appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of "Done".

I am Ruben Sibon and I am a creative web developer who prefers to work in Scrum/Agile teams.

On February 2, 2018 I received the certification for Professional Scrum Master I with a 96.3% score on the Scrum.org PSM-I assesment.

The course was paid from the education budget that I received from my very friendly employer Saxum.