The Scrum Guide – 2020
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
- A Product Owner orders the work for a complex problem into a Product Backlog.
- The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
- The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
- Repeat
Scrum is simple. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory. Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.
Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
© 2020 Ken Schwaber and Jeff Sutherland
Commentary
We may wonder why Scrum is ‘purposefully incomplete’. Can we not use it end-to-end for creating a product? Perhaps it is an unfortunate choice of word. Its incompleteness underlines that Scrum does not prescribe tools and techniques to accomplish our work. In Scrum, we receive little to no guidance on ‘how’. In contrast, even eXtreme Programming, a close relative of Scrum, wants us to use user stories, TDD and many other techniques. However, as the definition of Scrum states, it is not a methodology but a framework. If we take its scope into account, we should conclude that it is not incomplete but simply high-level.
If we compare Scrum to project management or software development approaches, we can also conclude that Scrum is lightweight. This is a significant advantage when implementing the framework, training and recruiting people, and continuously improving the practices. To illustrate this, let’s recall the history of the Rational Unified Process. It had a promising start, but gradually lost its popularity, mostly due to its complexity. RUP was difficult to implement, run and maintain. One size does not fit all, and overwhelming complexity works against efficiency. Simplicity and flexibility make Scrum so popular and powerful.
All the popular tools, techniques, and practices the Scrum Guide does not mention are not essential or compulsory parts of Scrum. While there is nothing wrong with using a Scrum Board, following a burndown chart and implementing a neat TDD framework, Scrum requires none of these. On the other hand, a Scrum Master should have a good understanding of the popular agile techniques since the teams may need guidance to choose and implement them.
Tips for exam preparation:
- While the Scrum Definition chapter looks like an intro, which is usually not critical for exam success, that is not the case with the Scrum Guide. Spend time over every single sentence. It is not that we should learn this chapter word by word but must remember the key phrases, such as Scrum is a framework, it is lightweight, etc.
- Exam scenarios may refer to tools and techniques that are not part of Scrum at all but are often applied by Scrum teams. Remember that these are there just for the context, not for testing your knowledge of particular tools and techniques.
Key Takeaways
- Scrum is a framework.
- Scrum is lightweight.
- “The Scrum framework is purposefully incomplete.”
- Scrum is great for finding solutions to complex problems.
- “Scrum is built upon by the collective intelligence of the people using it.“
The Scrum Guide – 2017
Definition of Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum is:
- Lightweight
- Simple to understand
- Difficult to master
Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.
The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.
Specific tactics for using the Scrum framework vary and are described elsewhere.
Uses of Scrum
Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:
- Research and identify viable markets, technologies, and product capabilities;
- Develop products and enhancements;
- Release products and enhancements, as frequently as many times per day;
- Develop and sustain Cloud (online, secure, on-demand) and other operational
environments for product use; and,- Sustain and renew products.
Scrum has been used to develop software, hardware, embedded software, networks of interacting function, autonomous vehicles, schools, government, marketing, managing the operation of organizations and almost everything we use in our daily lives, as individuals and societies.
As technology, market, and environmental complexities and their interactions have rapidly increased, Scrum’s utility in dealing with complexity is proven daily.
Scrum proved especially effective in iterative and incremental knowledge transfer. Scrum is now widely used for products, services, and the management of the parent organization.
The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people. They collaborate and interoperate through sophisticated development architectures and target release environments.
When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work, such as those types identified above.
©2017 Ken Schwaber and Jeff Sutherland.
The Scrum Guide – 2010
Scrum Content
The Scrum framework consists of a set of Scrum Teams and their associated roles; Time-Boxes, Artifacts, and Rules.
Scrum Teams are designed to optimize flexibility and productivity; to this end, they are self-organizing, they are cross-functional, and they work in iterations. Each Scrum Team has three roles: 1) the ScrumMaster, who is responsible for ensuring the process is understood and followed; 2) the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does; and 3) the Team, which does the work. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.
Scrum employs time boxes to create regularity. Elements of Scrum that are time-boxed include the Release Planning Meeting, the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints deliver an increment of the final product that is potentially releasable. One Sprint starts immediately after the other.
Scrum employs four principal artifacts. The Product Backlog is a prioritized list of everything that might be needed in the product. The Sprint Backlog is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product. A burndown is a measure of remaining backlog over time. A Release Burndown measures remaining Product Backlog across the time of a release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint.
Rules bind together Scrum’s time-boxes, roles, and artifacts. Its rules are described throughout the body of this document. For
example, it is a Scrum rule that only Team members – the people committed to turning the Product Backlog into an increment – can talk during a Daily Scrum. Ways of implementing Scrum that are not rules but rather are suggestions are described in “Tips” boxes.Tip
© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved
When rules are not stated, the users of Scrum are expected to figure out what to do. Don’t try to figure out a perfect solution, because the problem usually changes quickly. Instead, try something and see how it works. The inspect-and-adapt mechanisms of Scrum’s empirical nature will guide you.