O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Changes Between Different Versions Of Scrum Guides
MAY 20, 2021
KEN SCHWABER & JEFF SUTHERLAND
Changes between 2017 and 2020 Scrum Guides
Even Less Prescriptive
Over the years, the Scrum Guide started getting a bit more prescriptive. The 2020
version aimed to bring Scrum back to being a minimally sufficient framework by
removing or softening prescriptive language. e.g. removed Daily Scrum questions,
soften language around PBI attributes, soften language around retro items in Sprint
Backlog, shortened Sprint cancellation section, and more.
One Team, Focused on One Product
The goal was to eliminate the concept of a separate team within a team that has led to
“proxy” or "us and them” behavior between the PO and Dev Team. There is now just
one Scrum Team focused on the same objective, with three different sets of
accountabilities: PO, SM, and Developers.
Introduction of Product Goal
The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for
the Scrum Team toward a larger valuable objective. Each Sprint should bring the
product closer to the overall Product Goal.
A Home for Sprint Goal, Definition of Done, and Product Goal
Previous Scrum Guides described Sprint Goal and Definition of Done without really
giving them an identity. They were not quite artifacts but were somewhat attached to
artifacts. With the addition of Product Goal, the 2020 version provides more clarity
around this. Each of the three artifacts now contain ‘commitments’ to them. For the
Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the
Increment has the Definition of Done (now without the quotes) . They exist to bring
transparency and focus toward the progress of each artifact.
Self-Managing over Self-Organizing
Previous Scrum Guides referred to Development Teams as self-organizing, choosing
who and how to do work. With more of a focus on the Scrum Team, the 2020 version
emphasizes a self-managing Scrum Team, choosing who, how, and what to work on.
Three Sprint Planning Topics
In addition to the Sprint Planning topics of “What” and “How”, the 2020 Scrum Guide
places emphasis on a third topic, “Why”, referring to the Sprint Goal.
Overall Simplification of Language for a Wider Audience
The 2020 Scrum Guide has placed an emphasis on eliminating redundant and complex
statements as well as removing any remaining inference to IT work (e.g. testing,
system, design, requirement, etc). The Scrum Guide is now less than 13 pages.
Changes between 2016 and 2017 Scrum Guides
Added section on the 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.
Changed wording in The Scrum Master section to provide better
clarity to the role. The text now reads:
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.
Added to the section Scrum Master Service to the Product Owner
Ensuring that goals, scope, and product domain are understood by everyone on the
Scrum Team as well as possible.
Updated the first paragraph of the Daily Scrum section to read:
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.
Updated the Daily Scrum section to provide clarity on the goals of
the Daily Scrum including this text:
The structure of the meeting is set by the Development Team and can be conducted in
different ways if it focuses on progress toward the Sprint Goal. Some Development
Teams will use questions, some will be more discussion based. Here is an example of
what might be used:
What did I do yesterday that helped the Development Team meet the Sprint
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?
Added clarity around time-boxes
Using the words “at most” to remove any questions that the time-box for Events
means maximum length, but could be shorter.
Added to the Sprint Backlog section:
To ensure continuous improvement, it includes at least one high priority way in which
the team works, identified in the previous Retrospective meeting.
Added clarity to the Increment section:
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.
Changes between 2013 and 2016 Scrum Guides
A section on Scrum Values. 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
events, roles and artifacts.
Successful use of Scrum depends on people becoming more proficient in living these
five values. People personally commit to achieving the goals of the Scrum Team. The
Scrum Team members have courage to do the right thing and work on tough problems.
Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The
Scrum Team and its stakeholders agree to be open about all the work and the
challenges with performing the work. Scrum Team members respect each other to be
capable, independent people.
Changes between 2011 and 2013 Scrum Guides
A section on Artifact Transparency has been added. 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.
Sprint Planning is now one event. Two topics are addressed in it: What can be done
this Sprint, and How will the chosen work be done. After the Development Team
forecasts the Product Backlog items for the Sprint, the Scrum Team crafts a Sprint
Goal. The Sprint Goal creates coherence in the Development Team’s work that would
not be present in separate initiatives without a common goal. Note the formal
inclusion of a Sprint Goal.
The Product Backlog is refined rather than groomed. The refined Product Backlog
items are transparent, well enough understood and granular enough to be input for
the Sprint Planning and for selection for the Sprint. Product Backlog items with this
transparency are called “Ready.” Ready and Done are two states that reinforce
Scrum prescribes its events to create regularity and to minimize the need for meetings
not defined in Scrum. All events are time-boxed events, such that every event has a
maximum duration. A Sprint, as container event, has a fixed duration that cannot be
shortened or lengthened. The remaining events may end whenever the purpose of the
event is achieved; ensuring an appropriate amount of time is spent without allowing
waste in the process.
The importance of the Daily Scrum as a planning event is reinforced. Too often it is
seen as a status event. Every day, the Development Team should understand how it
intends to work together as a self-organizing team to accomplish the Sprint Goal and
create the anticipated Increment by the end of the Sprint. The input to the meeting
should be how the team is doing toward meeting the Sprint Goal; the output should be
a new or revised plan that optimizes the team’s efforts in meeting the Sprint Goal. To
that end, the three questions have been reformulated to emphasize the team over the
What did I do yesterday that helped the Development Team meet the Sprint
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?
The concept of value is reinforced to use in the Sprint Review. 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.
Changes between 2010 and 2011 Scrum Guides
Development Teams do not commit to completing the work planned during a Sprint
Planning Meeting. The Development Team creates a forecast of work it believes will be
done, but that forecast will change as more becomes known throughout the Sprint.
Scrum does not mandate a burn-down chart to monitor progress. Scrum requires only
Remaining work for a Sprint is summed and known on a daily basis.
Trending toward completing the work of the Sprint is maintained throughout the
Release Planning is a valuable thing to do when using Scrum, but isn’t required by
The Sprint Backlog is the Product Backlog items selected for the Sprint, plus a plan for
delivering them. There is no longer a required concept of "Sprint Backlog items"
although that technique can make a great plan. A self-organizing Development Team
always has a plan.
The Product Backlog is "ordered," instead of "prioritized," providing flexibility to the
Product Owner to optimize value in his or her unique circumstances.
Added the practice of Product Backlog Grooming.
Removal of many tips, optional practices and techniques.
The team of people performing the work of creating an Increment is the Development
Team. Regardless of the work performed by individual team members, they are known
Removed the reference to chickens and pigs.
Removed reference to undone work.
SAFe 5 for Lean Enterprises
SAFe for Lean Enterprises is the world’s leading framework for business agility.
SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive
operating system that helps enterprises thrive in the digital age by delivering
innovative products and services faster, more predictably, and with higher quality.
Configurable and scalable, SAFe allows each organization to adapt the framework
to its own business needs. With four out-of-the-box configurations, SAFe supports
the full spectrum of solutions, from those requiring a small number of teams to
those complex systems that require hundreds—and even thousands—of people to
build and deliver.
Business Benefits of SAFe
Surviving in the age of digital is not guaranteed. Business agility isn’t an option;
it’s imperative. Even businesses that don’t consider themselves Information
Technology (IT) or software companies—professional services, financial services,
manufacturers, healthcare institutions, defense contractors, government
agencies, and more—are now all highly dependent on their ability to rapidly
produce new, high-quality, innovative, digitally-enabled products and services.
The mission of Scaled Agile, Inc. (SAI), the provider of SAFe, is to help enterprises
grow their business through the Framework’s knowledge base. SAI also offers
certification, training, courseware, community resources, and a global network of
more than 400 service, tooling, and Global service partners.
Improves Business Outcomes
Created from over a decade of field experience, SAFe draws from four primary
bodies of knowledge: Agile development, systems thinking, Lean product
development, and DevOps. It helps enterprises answer the following types of
How do we align technology development to strategic business goals?
How do we deliver new value on a predictable schedule so the business can
plan? How do we improve the quality of our solutions and delight our
How do we scale Agile practices from teams to ARTs and across value
streams and the enterprise to deliver better results?
How do we organize people around value so that our programs deliver
effectively and avoid the delays inherent in a traditional, functional
How do we create an environment that fosters collaboration, innovation,
and relentless improvement for our people? How can we change our culture
so that it is safe to fail?
How do we encourage people to take risks, think creatively, and embrace
How can we help our teams improve without getting in the way?
By adopting SAFe—and applying its well-described set of values, principles, and
practices—the enterprise can address these questions and realize more significant
business and individual benefits.
SAFe 5 enables business agility and improving business outcomes for
organizations of all sizes across the world. SAFe has produced dramatic
improvements in time to market, employee engagement, higher quality, higher
customer satisfaction, and overall improved economic outcomes. It also helps
create cultures that are more productive, rewarding, and fun.
Figure 1 highlights these benefits as derived directly from Case Studies written by
“We had multiple waterfall efforts, third-party integration, and a hard, regulatory
mandate that made coordination and execution exceptionally difficult. SAFe
provided the agility, visibility, and transparency needed to ensure we could
integrate with the numerous other efforts, get predictable in our delivery, and
ensure timelines are met.”
— David McMunn, the Director of Fannie Mae’s Agile Center of Excellence (COE)
SAFe Evolves Continuously
A hallmark of SAFe is that it stays current with new and evolving business and
technology trends. Our incremental delivery model enables enterprises to adapt
more quickly and stay ahead of the competition by leveraging the latest knowledge
in SAFe. For example, COVID-19 forced many organizations to change how Agile
teams and ARTs collaborate. In response, the guidance for PI Planning,
Organizational Agility, and Agile Teams were quickly updated.
Most updates to SAFe simply require changes to various articles and new advanced
topics. Sometimes, however, updates to the Big Picture (BP) are needed for
emphasis and to provide ready access to the latest content. Minor releases of the
BP occur under a ‘dot release” like the current BP version 5.1. Such minor releases
are truly incremental and do not require upgrades to training and certification.
Over time, the incremental advances and significant new knowledge drive the
release of a new version, as was the case with SAFe 5—which extended SAFe into
true business agility. In these cases, SAFe practitioners and SPCs must keep pace
with upgraded knowledge, training, and certification.
To help our community keep current with the latest guidance, we’ve introduced a
new feature that provides a log of meaningful incremental changes on the home
page under the heading, ‘What’s New in SAFe.’ When you click on a change item,
it will open a blog post to inform our readers of the ‘why’ and ‘what’ for the
Introduction to SAFe 5.1 Big Picture
The SAFe Framework website features an interactive ‘Big Picture’ graphic. It
provides a visual model of the Framework and is the primary user interface to the
knowledgebase. Each icon of the image is clickable and offers access to extensive
SAFe guidance. The configurations support a full range of development and
business environments and the foundational principles, values, mindset,
roles, artifacts, and implementation elements that make up the SAFe framework.
The main components of the SAFe framework are described in the following
Figure 2: Full SAFe WithhConfiguration Tabs
SAFe 5 includes an overview tab shown in Figure 3. This graphic provides a
simplified view of SAFe’s Seven Core Competencies of the Lean Enterprise and their
twenty-one dimensions that enable business agility. Lean-Agile Leadership remains
at the foundation. The customer is prominently featured at the center as the focal
point for all the competencies. Measure and Grow at the top right is a reminder of
periodic assessments needed to track the organization’s progress towards the
principles and practices that enable business agility. This overview is a useful tool
for providing an initial orientation to SAFe, introducing the business agility
assessment, and framing
Figure 3: The SAFe Overview
Seven Core Competencies of the Lean Enterprise
SAFe 5 is built around the Seven Core Competencies of the Lean Enterprise. These
competencies include major re-writes to the original five competencies introduced
in SAFe 4.6, along with two entirely new competencies (Organizational Agility and
Continuous Learning Culture). The competencies are the primary lens for
understanding and implementing SAFe, as illustrated in the Overview tab on the
Each of the following competencies offers the knowledge, skills, and behaviors,
enabling enterprises to achieve business agility:
The Lean-Agile Leadership competency describes how Lean-Agile
Leaders drive and sustain organizational change by empowering
individuals and teams to reach their highest potential. They do this by
leading by example, adopting a Lean-Agile mindset, and leading the
change to new ways of working. The result is more engaged employees, increased
productivity and innovation, and successful organizational change.
The Continuous Learning Culture competency describes a set of values and practices
that encourage individuals and the enterprise to increase knowledge,
competence, performance, and innovation continually. Organizations
become a learning organization by committing to relentless
improvement and promoting a culture of innovation.
The Team and Technical Agility competency describes the critical skills and Lean-
Agile principles and practices that high-performing Agile teams and
Teams of Agile teams use to create high-quality solutions for their
customers. The result is increased productivity, better quality, faster
time-to-market, and predictable delivery of value.
The Agile Product Delivery competency is a customer-centric approach to defining,
building, and releasing a continuous flow of valuable products and
services to customers and users. This competency enables the
organization to provide solutions that delight customers, lower
development costs, reduce risk, and outmaneuver the competition.
The Enterprise Solution Delivery competency describes how to apply
Lean-Agile principles and practices to the specification, development,
deployment, operation, and evolution of the world’s largest and most
sophisticated software applications, networks, and cyber-physical systems.
The Lean Portfolio Management competency aligns strategy and execution by
applying Lean and systems thinking approaches to strategy and
investment funding, Agile portfolio operations, and governance. These
collaborations give the enterprise the ability to align strategy to
execution, meet existing commitments reliably, and enable innovation.
The Organizational Agility competency describes how Lean-thinking
people and Agile teams optimize their business processes, evolve
strategy with clear and decisive new commitments, and quickly adapt
the organization as needed to capitalize on new opportunities.
SAFe 5 continues to expand guidance for Lean-Agile adoption in Government.
Based on the foundation and principles of SAFe, the guidance emphasizes:
Building on a solid foundation of Lean-Agile values, principles, and practice
Creating high performing teams of government teams and contractor
Aligning technology investments with agency strategy
Transitioning from projects to a Lean flow of epics
Adopting Lean budgeting aligned to value streams
Applying Lean estimating and forecasting on cadence
Modifying acquisition practices to enable Lean-Agile development and
Building in quality and compliance
Adapting governance practices to support agility and Lean flow of value
The government article is a unique element within the Framework. It’s a portal to
a series of articles on SAFe adoption in the public sector, providing links to Agile
government resources, videos, and events. Many of them are hard to find, and
some are available only through our government portal. Our portal is a small way
SAI gives back to the thousands of dedicated civil servants and their industry
partners working tirelessly to bring agility to government.
SAFe supports the full range of development environments with four out-of-the-
box configurations. The configurations can be accessed using the tabs shown in
Figure 1. Each is described in the following sections.
The Essential SAFe configuration is the basic building block for all SAFe
configurations and is the simplest starting point for implementation. This
competency builds on the principles and practices found in the Lean-Agile
Leadership, Team and Technical Agility, and the Agile Product Delivery
SAFe is anchored by an organizational structure called the Agile Release Train (ART),
where Agile teams and key stakeholders are dedicated to a meaningful, ongoing
Essential SAFe includes both the Agile team and ART constructs, as shown in Figure
Figure ϰ : Essential SAFe Configuration
Large Solution SAFe
The Large Solution SAFe configuration introduces the Enterprise Solution Delivery
competency, which supports those building the largest and most complex solutions
that require multiple ARTs and Suppliers but do not require portfolio-level
Such solution development is typical for aerospace and defense, automotive, and
government industries, where the large solution—not portfolio governance—is the
The Solution Train organizational construct helps enterprises with the biggest
challenges—building large-scale, multidisciplinary software, hardware, cyber-
physical, and complex IT systems. Developing these solutions requires additional
artifacts, events, and coordination, as Figure 5 illustrates.
Figure 5 :(Large Solution SAFe Configuration
The Portfolio SAFe configuration is the minimum set of competencies and practices
that can fully enable business agility, as indicated by the blue ‘Business Agility’ bar
at the top. This bar also includes a link to Measure & Grow for guidance on
conducting SAFe business agility assessments. Portfolio SAFe provides two
additional competencies, Organizational Agility and Lean Portfolio Management,
beyond the three core competencies of Essential SAFe. Lean Portfolio Management
aligns portfolio execution to enterprise strategy and organizes development around
the flow of value through one or more value streams. Organization Agility extends
Lean thinking and practice throughout the enterprise and enables strategy agility.
Continuous Learning Culture describes how everyone in the organization learns
together, relentlessly improves, and builds innovation into the culture. In addition
to the competencies, Portfolio SAFe provides principles and practices for portfolio
strategy and investment funding, Agile portfolio operations, and Lean governance.
Figure 6 : (Portfolio SAFe Configuration
Full SAFe is the most comprehensive configuration, including all seven core
competencies needed for business agility. It is typically used by the world’s largest
enterprises to maintain portfolios of large and complex solutions. In some cases,
multiple instances of various SAFe configurations may be required.
The Spanning Palette contains various roles and artifacts that may apply to a
specific team, program, large solution, or portfolio context.
An essential element of SAFe’s flexibility and adaptability, the spanning palette
contains additional guidance elements that can be used in specific contexts. Figure
8 illustrates two versions of the spanning palette. The leftmost figure is used by the
Essential SAFe configuration, while the rightmost one serves all other
configurations. However, since SAFe is a framework, enterprises can apply any item
from the larger spanning palette to Essential SAFe.
Figure 2: Full SAFe WithhConfiguration Tabs
Below is a brief description of each spanning palette element:
Vision – The vision describes a future view of the solution to be developed,
reflecting customer and stakeholder needs and the Features and
Capabilities proposed to address those needs.
Roadmap – The roadmap communicates planned ART and value stream
deliverables and milestones over a timeline.
Milestones – Milestones are used to define important events on a roadmap.
SAFe describes fixed-date, Program Increment
(PI), and learning milestones.
Shared Services – Represents the specialty
roles necessary for an ART or Solution Train’s
success but cannot be dedicated full time to any
Community of Practice (CoP) – A community
of practice is an informal group of team members
and other experts, acting within the context of a
program or enterprise, that has a mission of
sharing practical knowledge in one or more
System Team – The system team is a special
Agile team that provides assistance in building
and using the continuous delivery pipeline, and
where necessary, validating full end-to-end
Lean User Experience (UX) – Lean UX brings
Lean principles to user experience design. It uses
an iterative, hypothesis-driven approach to
product development through constant
measurement and learning loops (build-measure-
Metrics – The primary measure in SAFe is the
objective measurement of working solutions. In
addition, however, SAFe defines additional
intermediate and long-term metrics that teams, ARTs, and portfolios can use to
The Foundation contains the supporting principles, values, mindset,
implementation guidance, and leadership roles needed to deliver value
successfully at scale.
Each foundation element illustrated in Figure 9 is briefly described next.
Lean-Agile Leaders – Management has the ultimate responsibility for
business outcomes. Leaders are trained in SAFe and become trainers of
these leaner and more agile ways of thinking and working. To this end, SAFe
describes a new leadership style exhibited by the enterprise’s new ‘Lean-
Core Values – Four core values of Alignment, Built-In Quality, Transparency,
and Program Execution define the belief and value system for SAFe.
Lean-Agile Mindset – The Lean-Agile Mindset is the combination of beliefs,
assumptions, attitudes, and actions of SAFe leaders and practitioners who
embrace the concepts of the Agile Manifesto and Lean thinking. It’s the
personal, intellectual, and leadership foundation for adopting and applying
SAFe principles and practices.
SAFe Principles – SAFe practices are grounded in ten principles that
synthesize Agile methods, Lean product development, DevOps, and systems
thinking, coupled with decades of practical field experience.
Implementation Roadmap – Implementing the changes necessary to
become a Lean-Agile technology enterprise is a substantial change for most
companies. SAFe provides an implementation roadmap to help guide
organizations on this journey.
SPCs – SAFe Program Consultant (SPCs) are change agents who combine their
technical knowledge of SAFe with an intrinsic motivation to improve their
company’s software and systems development processes.
Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled: Achieving Business
Agility with the Scaled Agile Framework. Addison-Wesley.
WHAT’S NEW IN SAFE 5?
Evolving the Scaled Agile Framework
• Generative culture
• People do all the work
• Your customer is
• Build long-term
• To change the culture
you have to change
• Management applies and teaches lean thinking,
bases decisions on this long-term philosophy
• Principles of Lean-Agile Leadership
• Sustainable shortest lead time
• Best quality and value to people and society
• High morale, safety, customer delight
• Optimize sustainable
• Build in quality
• Understand, exploit,
and manage variability
• Move from projects
• Innovative people
• Time and space
• Go See
• Pivot without mercy
• Innovation riptides
• Constant sense
• Optimize the whole
• Problem solving
• Base improvements
processes and tools
over contract negotiation
Responding to change
over following a plan
Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for the
customer’s competitive advantage.
Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
Business people and developers must work together
daily throughout the project.
Build projects around motivated individuals. Give
them the environment and support they need, and
trust them to get the job done.
information to and within a development team is
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
Continuous attention to technical excellence and good
design enhances agility.
Simplicity—the art of maximizing the amount of work
not done—is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
become more effective, then tunes and adjusts its
S.No. Topic Data Source
Different Versions Of
SAFe 5 For Lean
Scrum Guide November 2020 , Changes Between All Scrum Guides Versions And SAFe Agile