Scrum Guide: Purpose and Definition

Purpose of the Scrum Guide

• Scrum was developed in the early 1990s.
• The first version of the Scrum Guide was written in 2010.
• The Scrum Guide defines Scrum and its framework elements, each serving a specific purpose for overall value and results.
• Altering the core design, omitting elements, or not following the rules of Scrum can cover up problems and limit its benefits, potentially rendering it useless.
• Scrum has been adopted in many domains beyond software product development.
• Patterns, processes, and insights that fit the Scrum framework may be found, applied, and devised, but their descriptions are beyond the scope of the Scrum Guide.

Scrum Definition

• Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
• Scrum requires a Scrum Master to foster an environment with a Product Owner who orders work into a Product Backlog.
• The Scrum Team turns work into an Increment of value during a Sprint.
• The Scrum Team and stakeholders inspect results and adjust for the next Sprint.
• The Scrum framework is purposefully incomplete, defining only the parts required to implement Scrum theory, and is built upon the collective intelligence of the people using it.
• Processes, techniques, and methods can be employed within the framework.

Scrum Theory

• Scrum is founded on empiricism and lean thinking.
• Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
• Lean thinking reduces waste and focuses on the essentials.
• Scrum employs an iterative, incremental approach to optimize predictability and control risk.
• Scrum engages people who collectively have the skills and expertise.
• Scrum combines four formal events for inspection and adaptation within a Sprint, implementing the empirical Scrum pillars of transparency, inspection, and adaptation.

Transparency

• The emergent process and work must be visible to those performing and receiving the work.
• Decisions are based on the perceived state of three formal artifacts, and low transparency can diminish value and increase risk.
• Transparency enables inspection, but inspection without transparency is misleading and wasteful.

Inspection

• Scrum artifacts and progress toward agreed goals must be frequently inspected to detect undesirable variances or problems.
• Scrum provides cadence in the form of its five events to help with inspection.
• Inspection enables adaptation, and is considered pointless without it.

Adaptation

• If any process aspects deviate outside acceptable limits or the resulting product is unacceptable, adjustments must be made as soon as possible.
• Adaptation becomes more difficult when people are not empowered or self-managing.
• A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Scrum Values

• Successful Scrum depends on people becoming proficient in living five values: Commitment, Focus, Openness, Respect, and Courage.
• The Scrum Team commits to goals, supports each other, and focuses on the Sprint to make progress.
• Scrum Team members and stakeholders are open about the work and the challenges
• Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.
• Scrum Team members have the courage to do the right thing, and to work on tough problems.

Scrum Team

• The fundamental unit of Scrum is a small Scrum Team consisting of one Scrum Master, one Product Owner, and Developers.
• There are no sub-teams or hierarchies; it is focused on one objective at a time, which is the Product Goal.
• Scrum Teams are cross-functional, having all skills necessary to create value each Sprint.
• Scrum Teams are self-managing, meaning they decide who does what, when, and how.
• The Scrum Team should be small enough to remain nimble, usually 10 or fewer people, communicating better and being more productive.
• Scrum Teams are responsible for all product-related activities and are structured and empowered by the organization to manage their own work.
• The Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
• Scrum defines specific accountabilities of the Developers, the Product Owner, and the Scrum Master within the Scrum Team.

Developers

• Developers in the Scrum Team are committed to creating aspects of a usable Increment each Sprint.
• Specific skills needed by the Developers vary with the domain of work.
• The Developers are accountable for creating a plan for the Sprint, instilling quality by adhering to a Definition of Done, and adapting their plan each day toward the Sprint Goal while holding each other accountable as professionals.

Product Owner

• The Product Owner is accountable for maximizing the value of the product from the work of the Scrum Team, with practices varying across organizations, Scrum Teams, and individuals.
• The Product Owner is accountable for effective Product Backlog management, including developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering the items, and ensuring the Product Backlog is transparent, visible, and understood.
• The Product Owner may delegate work, but remains accountable.

Scrum Master

• The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide by helping everyone understand Scrum theory and practice within the Scrum Team and the organization.
• The Scrum Master is accountable for the Scrum Team's effectiveness by enabling the Scrum Team to improve its practices within the Scrum framework.
• Scrum Masters serve the Scrum Team and the larger organization using leadership.
• The Scrum Maseter helps team members in self-management and cross-functionality.
• Scrum Master helps the Scrum Team focus on creating high-value increments that meet thee definition of Done
• Caises the removel of impediments to the Scrum Team's progress
• Ensures that all Scrum events take place and are positive, productive, and kept within the timebox.

Scrum Events

• The Sprint is a container for all other Scrum events
• Events are specifically designed to enable the transparency required.
• Failure to operate any events as prescribed results in lost opportunities to inspect and adapt.
• Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
• Optimally, all events are held at the same time and place to reduce complexity.

The Sprint

• Sprints are the heartbeat of Scrum, where ideas are turned into value.
• Sprints are fixed-length of one month or less to create consistency.
• A new Sprint starts immediately after the conclusion fo the previous Sprint
• All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.
  • No changes are made that would endanger the Sprint Goal.
  • Quality does not decrease.
  • The Product Backlog is refined as needed.
  • Scope may be clarified and renegotiated with the Product Owner as more is learned
• Sprints enable predictability by ensuing inspection and adaptation of progress towards a Product Goal
• Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame.
• A Sprint can ne cancelled if the Sprint Goal becomes obsolete and only the Product Owner has the authority to cancel the Sprint

Sprint Planning

• Sprint Planning involves a collaorative process from the entire Scrum Team
• The process lays out the work done for the Sprint
• The Product Owner is prepared to discuss the most important Product Backlog items and hot they map to the Product Goal
• The Scrum Team can invite people to attend Sprint Planning to provide vice

Topics Addressed In Sprint Planning

• Topic One: Why is this Sprint valuable?
  • The Product Owner propposes ho the product could increase its value and utility in the currents Sprint.
  • The team collaborates to define a Sprint Goal that comminicates why the Sprint is valuabe to stakeholders.
  • The Sprint Goal must be finalized prior to the end of Sprint Planning
• Topic Two: What can be Done this Sprint?
  • Through discussion with the Product Owner, the Developers select items from the Product Backlog to includ eon the current Sprint.
  • The Scrum Team also refines these items which increase understanding and confidence
  • Developers need to know about their past performance, their upcoming capacity, and their Definition of Done, that way the can be confident in their Sprint forecasts
• Topic Three: How will the chosen work get done?
  • The Developers plan the work necessary to create an Increment that meets the Definition of Done.
  • This is often done by decomosing Product Backlog items in smaller details, and is at the sole discretion of the Developers.

Daily Scrum

• Purpose is to insepct the progress towards meeting the Sprint Goal
• Daily Scrums are 15 minutes long for the Developers of the Scrum Team
• Happend at the same time and place every day for the duration of the Sprint
• The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on agress toward the Sprint Goal and produces an actionable plan to achieve it
• Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meeetings

Sprint Review

• Purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations
• Scrum Tem presents the results of theii worl to get key stakeholders and discuss process and issues
• The Sprint Review is a working session and everyone should participate, avoding limiting the work to a presentation
• Timeboxed to a maximum of four hours for a one-month Sprint, and is usually shorter for Sprint's that are shorter

Sprint Retrospective

• Purpose is to improve the overall quality and effectiveness of the processes
• Scrum Team inspects how the last Sprint went with egards to individuals, interctions, processes, tools and the Definition of Done
• Any issues are identified to prevent a repeat and assumptions are challenged
• Timeboxed to a maximum of three hours for a one-month Sprint and is usually shortee for shorter Sprints

Scrum Artifacts

• Scrum is a representation of work or value
• All artifacts are designed to maximize transparency to encourage adaptation

Artifact Commitments

• For the Product Backlog, it is the Product Goal
• FOr the Sprint Backlog, it is the Sprint Goal
• Fore the Increment, it is the Definition of Done

Product Backlog

• Is an emergent, ordered list of what is need to improve the product and is the single source of work for the Scrum Team
• It is ordered for selection in a Spirnt Planning Event with the order following activities
• The itesm are broken down by defining order, attributes and size

Product Goal

• Is in the Product Backlog
• Describes a future sate of the product which can serve as a target from the Team plan agains

Sprint Backlog

• The Sprint Backlog is composed of the Sprint Goal, the set of Product Backlog items selected for the Sprint, as well as an actionable plan for delievering the Increment
• Is updated continuously as more is learned

Sprint Goal

• The Sprint Goal is the single objective for the Sprint
• Is created durin the Sprint Planning event
• Is added to the Spring Backlog
• Developers keep the Sprint Goal in mind
• Developers and the Product Owner all collaborate on the work of the Sprint Backlog within the Spring

Increment

• An Increment is a concrete stepping stone toward the Product Goal
• Each Increment is additive to allpriorIncrements and thrououghly verified, ensuring all Increments worl together
• In order to provide value, the Increment must be usable

Definition of Done

• The Definition of Done is a formal description of the start of the Increment when it meets the quality measures required for the product
• Is part of the standards of the organization, all Scrum Teams must fellow it as a minimun
• Multiple Scum Teams working together must mutually define and comply witgh the ame Definition of Done.

End Note

• Scrum is immutable
• Scrum only funcions in its entirety and functions well as a container for other techniques and methodologies

History

• Co-presented by Ken Schwaber and Jeff Sutherland at the OOPSLA Conference in 1995
• Essential documentations and learnings from over the few years