This section is added for reference. If you are already familiar with Scrum feel free to skip this section and go straight to Using Scrum as Example.
A quick overview of the Scrum Guide is being presented to that we can later discuss how each of these aspects of Scrum can be viewed as a particular way of doing something useful – but not necessarily the only or even best way of accomplishing the objective. The Scrum Guide lists what to do but not usually why to do it.
Many references to the Scrum Guide will be included in the following sections. To make it clear when we are quoting the Scrum Guide, quotes from the Scrum guide will look like this:
this is a quote from the Scrum Guide.
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Oddly enough no one seems to challenge that empiricism may not be the best way to base a framework on. As Edwards Deming says (paraphrased) “theory without experience is useless, experience without theory is expensive.” Although product development of any kind is complex and must be guided through feedback, it doesn’t mean the approach being followed shouldn’t have a set of laws that it attends to. In other words, in the same way one does not need a complex approach to address a complex problem one does not need an empirical approach to address an empirical problem.
This is, perhaps a difference between Scrum and Scrum as Example. Scrum as Example is based on the scientific method of making hypotheses, observations and adjusting the hypotheses to fit the data. But no belief or practice is sacrosanct. And deductive logic is encouraged while requiring the logic to be validated by experience. In addition, Scrum as Example takes s systems-thinking point of view. Two critical aspects of systems-thinking are that the system people are in significantly affects the behavior of the people and that parts of a system are interrelated to such an extent that the whole must be considered when making any adjustments to a part of the system.
When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum roles, events, and artifacts.
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
It should be clear that this intent could be met in any number of ways. The important thing to do is not necessarily have a product owner in the way Scrum is defined, but have someone fill that role in a manner that meets the objective of the role (also from the Scrum Guide):
* Clearly expressing Product Backlog items * Ordering the items in the Product Backlog to best achieve goals and missions * Optimizing the value of the work the Development Team performs * Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next * Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
* They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality * Development Teams are cross-functional, with all the skills as a team necessary to create a product increment * Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person * Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis * Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
* The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values. * The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. * The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective
Cancelling a Sprint
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by
What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.
How will the chosen work get done?
Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.
The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal.
The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
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. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. The purpose of the Sprint Retrospective is to: • 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; and, • Create a plan for implementing improvements to the way the Scrum Team does its work.
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
The Increment is the sum of all the 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.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.
When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.