The Agility Guide to Evidence-Based Change: Using Scrum to Transform Your Enterprise

Purpose of the Agility Guide

Many organizations want to gain a competitive advantage by improving the value they derive from software development. They desire to take advantage of opportunities, respond effectively and deliberately to challenges, all while controlling risk and optimizing the return on investment. These organizations often turn to Agile processes such as Scrum, and embrace initiatives to become “Lean.”

The initiatives to improve organizational value often represent a substantial investment. The Evidence-Based Change Framework described in this guide, allows an organization to manage and optimize the outcome and the value of this investment. An enterprise uses this framework to progressively increase its agility, the value of its products and the workplace for its people.

Evidence-Based Change provides a framework to guide a progressive organizational transformation, with processes, metrics and tools. Management employs it to iteratively invest in change. Management measures the resultant return on its investment and selects the next changes to implement.
The Evidence-Based Change Framework is targeted at organizations deriving competitive advantage from developing software. The software may be part of products sold in the marketplace or maybe part of new, more agile internal operations. It employs the Scrum principles and rules as the iterative engine of continuous improvement.

This Guide contains the definition of Evidence-Based Change. The definition consists of its roles, events, artefacts, and the rules that bind them together.

Evidence-Based Change Overview

Evidence-Based Change (n): A framework within which people can address complex organizational change, while productively and creatively improving the enterprise and its products.

Management uses Evidence-Based Change to optimize its investment in its software development capabilities, while continuously improving the enterprise and the value of its products and systems.

Evidence-Based Change is:

• Lightweight
• Simple to understand
• Difficult to master, as is all change

Its principles and practices were first described in “The Enterprise and Scrum” and later in “Software in Thirty Days”.

Framework

Evidence-Based Change is a framework designed for continuous organizational improvement with the goal to optimize the value of products and systems the organization develops. It originates from the Scrum framework but is lightly adopted for the delivery of increments of functional change in the organization, rather than developing and sustaining a complex product.

Evidence-Based Change consists of Agility Teams and their associated roles, events, artefacts, and rules. Each component within the framework serves a purpose and is essential to Evidence-Based Change’s success and usage.

Evidence-Based Change is not a prescriptive methodology or assessment; rather, it is a process framework within which managers and leaders of change can continuously improve the organization, its structures and operations, through the incremental delivery of change. Evidence-Based Change provides clear management roles and accountability for managing the benefits and return on investment of changes caused by implementing new or revised new practices.

Domains

Specific areas of operational accountability exist in the enterprise. Evidence-Based Change calls them ‘Domains’. One or more business function constitutes a domain. The purpose of a domain in Evidence-Based Change is to create an area of cohesive change and accountability. When one or more business functions exist upon which continuous change can be cohesively made, thereby contributing to an overall business benefit that can be measured and improved, these business functions are grouped into a domain.

The Evidence-Based Change domains are:

• Enterprise: Responsible for the overall continuous improvement of the organization. This domain encompasses all domains and business functions. Those in management responsible for the overall benefits of the Evidence-Based Change initiative are in this team.
• Process: responsible for the effective use of Scrum, whether in building software products with the Scrum framework or as part of the Evidence-Based Change effort. This domain is composed of all of the Scrum Masters.
• Productivity: responsible for the productivity of building increments of product. These are the development teams in the Scrum Teams.
• Quality: responsible for the standards, conventions, guidelines, frameworks, and tooling that guides the quality of products developed in the Productivity domain. Architects, quality standards, build and infrastructure developers, user interface designers, framework developers, standards and conventions developers, and database architects are in this domain.
• Value: responsible for improving the value of the releases of products or systems. The value domain includes portfolio, product family, program, and release management. The value domain also includes the Product Owner function of Scrum Teams developing software and often the Project Management Organization (PMO).

Evidence-Based Change Theory

Evidence-Based Change, like 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. Evidence-Based Change employs an iterative, incremental approach to optimize predictability and control risk.

Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.

Transparency

Significant aspects of the change process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.

For example:

• Every change that is caused is measurable; and,
• The measurement must be relevant to the overall continuous improvement initiative.

Inspection

Evidence-Based Change participants must frequently inspect artifacts and progress toward a goal. They should be able to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed.

Adaptation

If one or more aspects of a change deviate outside acceptable limits so that the resulting improvement will be unacceptable, an adjustment must be made as soon as possible to minimize further deviation.

Evidence-Based Change prescribes five formal opportunities for inspection and adaptation, as described in the Events section of this document:

• Sprint Planning
• Weekly Scrum
• Sprint Review
• Sprint Retrospective
• Evaluation

Agility Team

An Agility Team consists of a Product Owner, Change Team, and Scrum Master. The team is self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others who are not part of the team. The team model is designed to optimize flexibility, creativity, and productivity.

The Agility Team that is initiating the overall improvement is named the Enterprise Agility Team. Each of its members is also prefixed with “Enterprise” (Enterprise Product Owner, Enterprise Change Team, Enterprise Scrum Master).

The Enterprise Agility Team can lead the change of every other domain, or each domain can have its own Agility Team. When a domain has its own team, this is called a ‘Domain’ Agility Team. The members are named the ‘Domain’ Product Owner, the ‘Domain’ Change Team, and the ‘Domain’ Scrum Master (where ‘domain’ is replaced by ‘Process’, ‘Productivity’, ‘Value’ or ‘Quality’). Each domain’s Product Owner works with the Enterprise Product Owner for ordering the work for the specific domain. Each domain’s Scrum Master works with the Enterprise Scrum Master for removal of higher-level impediments within the organization.

Larger organizations may wish to employ multiple Agility Teams for developing change within a domain. These teams are simply called Agility Teams. Each team’s members are named the Product Owner, the Change Team, and the Scrum Master. Their Product Owners report to the Domain Product Owners.

The Agility Teams deliver improvement iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of change ensure measurable improvement that progressively improves an organization while controlling and potentially minimizing disruption.

Enterprise Product Owner

The Enterprise Product Owner is responsible for maximizing the value of each change and its progressive application within the enterprise. How this is done may vary widely across organizations.

The Enterprise Product Owner is the sole person responsible for optimizing value of all of the changes in domains by ordering of the overall Practice Backlog. The Enterprise Product Owner may delegate areas of the Practice Backlog to specific domains, based on applicability and impact.

Enterprise Product Owner accountabilities include:

• Clearly expressing Practice Backlog items;
• Ordering the items in the Practice Backlog to best achieve goals and missions;
• Ensuring the value of the work all of the Agility Teams perform;
• Ensuring that the Practice Backlog items likely to be selected for an upcoming Sprint are small enough that they can be understood and that one or more can be potentially completed within a Sprint; and;
• Ensuring that the Practice Backlog is visible, transparent, and clear to all, and shows what the Agility Teams will work on next.

The Enterprise Product Owner may do the above work, or have others do it. However, the Enterprise Product Owner remains accountable.

The Enterprise Product Owner is one person, not a committee. The Enterprise Product Owner may represent the desires of a committee, but those wanting to change a Backlog item’s order must convince the Enterprise Product Owner.

For the Enterprise Product Owner to succeed, the entire organization must respect his or her decisions. The Enterprise Product Owner’s decisions are visible in the content and ordering of the Practice Backlog. No one is allowed to tell the Agility Teams to work to implement different Practices, and the Agility Teams aren’t allowed to work on what anyone else says.

Domain Product Owner

If Domain Agility Teams are employed, each has a Domain Product Owner. The accountabilities for the Domain Product Owner are identical to those of the Enterprise Product Owner, except only for that domain and any other Agility Teams engaged in Evidence-Based Change within the domain.

Product Owner

If additional Agility Teams beyond the Domain Agility Teams are employed within a domain, each has a Product Owner. The accountabilities for the Product Owner are identical to those of the Domain Product Owner, except only for the area of Practice Backlog assigned to that Product Owner by the Domain Product Owner.

Enterprise Change Team

All Agility Teams engaged in Evidence-Based Change have a Change Team. The Change Team consists of managers, supervisors, and professionals who have the authority and knowledge to implement a change with maximum impact and value, and minimum disruption. Members of the Change Team may need to enlist the support and work of people within the domain to create the Increment of change. If so, this support must be elicited prior to starting the Sprint.

Change Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy enhances the Change Team’s overall efficiency and effectiveness. Change Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Change Team how to turn Practice Backlog into Increments of change;
• Change Teams are cross-functional, with all of the skills as a team necessary to create an Increment of change;
• Evidence-Based Change recognizes no titles for Change Team members other than Change Agent, regardless of the work being performed by the person; there are no exceptions to this rule;
• Individual Change Team members may have specialized skills and areas of focus, but accountability belongs to the Agility Team as a whole; and,
• Change Teams do not contain sub-teams dedicated to particular business functions like HR or IT.

The Enterprise Change Team is responsible for creating Increments of functional change within the enterprise, and within the other domains they address. How this is done may vary widely across organizations.

Domain Change Team

If Domain Agility Teams are employed, each has a Domain Change Team. The accountabilities for the Domain Change Team are identical to those of the Enterprise Change Team, except only for that domain and any other Agility Teams engaged in Evidence-Based Change within the domain.

Change Team

If additional Agility Teams beyond the Domain Agility Teams are employed within a domain, each has a Change Team. The accountabilities for the Change Team are identical to those of the Domain Change Team except only for the area of the Practice Backlog assigned to that Change Team by its Product Owner.

Change Team Size

Optimal Change Team size is small enough to remain nimble and large enough to complete significant work. Fewer than three Change Team members decrease interaction and results in smaller productivity gains. Smaller Change Teams often augment their capabilities by enlisting regular functional employees during a Sprint. Having more than nine members requires too much coordination. Large Change Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

Enterprise Scrum Master

The Enterprise Scrum Master is responsible for ensuring the Evidence-Based Change process, as described in The Agility Guide, is understood and enacted. Enterprise Scrum Masters do this by ensuring that the Enterprise Agility Team adheres to Evidence-Based Change theory, practices,
and rules. The Enterprise Scrum Master is a servant-leader for the Enterprise Agility Team.

The Enterprise Scrum Master helps those outside the Enterprise Agility Team understand which of their interactions with an Agility Team are helpful and which aren’t. The Enterprise Scrum Master helps everyone change these interactions to maximize the value created by the Enterprise Agility Team.

Domain Scrum Master

If Domain Agility Teams are employed, each has a Domain Scrum Master. The Domain Scrum Master is the Scrum Master for a Domain Agility Team, working with the Enterprise Scrum Master. His or her responsibility is the same as the Scrum Master for the Enterprise, except for only that domain.

Scrum Master

The Scrum Master is the Scrum Master for an Agility Team within a domain, reporting to the Domain Scrum Master. His or her responsibility is the same as the Domain Scrum Master, except responsibility extends only to teams working on the assigned Practice Backlog within that domain.

Scrum Master Service

Scrum Masters of any Agility Change team serve their product owners, change teams and the organization.

Scrum Master Service to the team’s Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Finding techniques for effective Practice Backlog management;
• Teaching how to decompose Practice Backlog items into clear and concise work;
• Understanding long-term planning in an empirical environment;
• Understanding and practicing agility;
• Effectively inspecting metrics to craft upcoming Sprint Goals; and,
• Facilitating Evidence-Based Change events as requested or needed.

Scrum Master Service to Change Teams

The Scrum Master serves the Change Team in several ways, including:

• Coaching the Change Team in self-organization and cross-functionality;
• Teaching and leading the Change Team to create high-value change;
• Removing impediments to the Change Team’s progress;
• Facilitating Evidence-Based Change events as requested or needed; and,
• Coaching the Change Team in organizational environments in which agility is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization in several ways, including:

• Leading and coaching the organization in its Agile adoption;
• Planning Evidence-Based Change implementations within the organization;
• Helping employees and stakeholders understand and enact Evidence-Based Change; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Evidence-Based Change within the organization.

Evidence-Based Change Events

Formal events are used in Evidence-Based Change to create regularity and to minimize the need for extra meetings. All meetings are time-boxed events, such that every event has a maximum duration. This ensures an appropriate amount of time is spent meeting without allowing waste.

Other than the Sprint itself, which is a container for all other events, each event in Evidence-Based Change is a formal opportunity to inspect and adapt some artefact. These events are specifically designed to enable critical transparency and inspection. Failure to include all of these events results in reduced transparency. A lost opportunity to optimize the value of the overall continuous improvement occurs.

Sprint

The heart of Evidence-Based Change is a (Change) Sprint, a time-box of one calendar month during which a working change to business functionality is created. The Sprint is a container for all other Enterprise Scrum events. A new Sprint starts immediately after the conclusion of the previous Sprint

During the Sprint:

• No changes are made to the Sprint Goal, but changes can be added to the Sprint Backlog for the Sprint Goal;
• Quality goals do not decrease; and
• Scope may be clarified and re-negotiated between the Product Owner and Change Team as more is learned.

Sprints are used to accomplish actual, measurable change. Each Sprint has a definition of what is to be changed, a flexible plan of the steps to do so, and the resultant change.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a goal at least every calendar month. This way, Sprints limit risk to one calendar month of cost.

Sprint Planning

The work to be performed in the Sprint, the actionable change, is planned at the Sprint Planning. This work plan is created by the collaborative work of the entire Agility Team.

Sprint Planning is time-boxed to eight hours for a one-month Sprint. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

• What functional change will be in place as a result from the upcoming Sprint?
• How will the work needed to deliver the Increment of change be achieved?

Functional Change

The Change Team works to forecast the practices that will be implemented during the Sprint. The Product Owner presents ordered Practice Backlog items to the Change Team and the entire Agility Team collaborates on understanding them.

The input to this meeting is the Practice Backlog, the Evaluation Backlog, the latest Increment of change, the updated metrics, projected capacity of the Change Team during the Sprint, and past performance of the Change Team. The number of items selected from the Practice Backlog for the Sprint is solely up to the Change Team. Only the Change Team can assess what it can accomplish over the upcoming Sprint.

Sprint Goal

Upon the forecast of practices the Agility Team believes it can implement during the Sprint, a Sprint Goal is crafted. A Sprint Goal is the summarized impact on the enterprise at the end of the Sprint. Practice Backlog items are often chosen to deliver one coherent change so that their impact is focused on one area of the business. Too much change at once can destabilize a business function. The Sprint Goal can be any other coherence that causes the Change Team to work together rather than on separate initiatives.

The Sprint Goal gives the Change Team some flexibility regarding the change implemented within the Sprint. As the Change Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements change in the Enterprise. If the work turns out to be different than the Change Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint.

Sprint Backlog

The Change Team formulates the steps it will take to cause the change. The Practice Backlog items selected for this Sprint plus the steps for delivering them are called the Sprint Backlog. The Change Team may start by laying out the current functional flow. It then devises the steps that will be needed to create the changed functional flow. Steps of work may be of varying size, or estimated effort. These steps and their estimate constitute the Sprint Backlog, the work planned for the upcoming Sprint.

Enough work is planned during Sprint Planning for the Change Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Change Team is usually decomposed to units of two days or less by the end of this meeting. The Change Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

By the end of Sprint Planning, the Change Team should be able to explain to the Domain Product Owner and Domain Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment of change.

Weekly Scrum

The Weekly Scrum is a 30-minute time-boxed event for the Change Team to synchronize activities and create a plan for the next week. This is done by inspecting the work since the last Weekly Scrum and forecasting the most effective steps to do during the remainder of the Sprint.

The Weekly Scrum is held at a consistent time and place to reduce complexity. During the meeting, each Change Team member explains:

• What did I do this past week that helped the Change Team meet the Sprint Goal?
• What will I do next week to help the Change Team meet the Sprint Goal?
• Do I see any impediments that prevent me or the Change Team from meeting the Sprint Goal?

The Change Team uses the Weekly Scrum to assess progress toward the Sprint Goal and to assess how progress is trending toward completing the work in the Sprint Backlog. The Weekly Scrum optimizes the probability that the Change Team will meet the Sprint Goal. Every week, the Change Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment of Change by the end of the Sprint. The Change Team often meets immediately after the Weekly Scrum for detailed discussions, or to adapt and re-plan the rest of the Sprint’s work.

The Scrum Master ensures that the Change Team has the meeting, but the Change Team is responsible for conducting it. The Scrum Master teaches the Change Team to keep the Weekly Scrum within the 30-minute time-box.

The Scrum Master enforces the rule that only Change Team members participate in the Weekly Scrum. It is not a status meeting. It is instead a session where the Agility Team inspects progress and thinks about changes to its plan in meeting the Sprint Goal.

Weekly Scrums improve communications, eliminate other meetings, identify and remove impediments to progress, and highlight and promote quick decision-making. Teams that miss or minimize the importance of this meeting often are ineffective.

Evaluation

The Agility Team monitors the impact of its work on organizational value every Sprint. It evaluates how effective previously implemented practices are being employed. It also gathers and assesses metrics indicative of an organization’s capabilities to sustain value over time. Evaluation is a critical activity, guiding upcoming improvements and optimizing the value of the previous work.

Members of the Agility Team may devote from 10% to 30% of the entire team’s capacity during a Sprint to evaluate progress and determine next best steps. Progress is evaluated both subjectively and objectively. For practices being evaluated subjectively, people and areas where new practices are being used are observed. Practices being evaluated objectively are tested to see if they are performing as expected and result in higher value creation by the organization.

Evidence-Based Metrics are used to show meaningful progress.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the functional changes made, employment of the practices in the domain, the impact on the business, and the evolution in metrics – usually the result of changes from prior Sprints. The Sprint Review is a time-box of four hours. During the Sprint Review, the Agility Team and its stakeholders collaborate over the change created during the Sprint and its impact. The Practice Backlog is reordered if needed. Based on that and any changes to the Practice Backlog during the Sprint, attendees collaborate on the next things that could be done.

The Sprint Review is an informal meeting that is sometimes heated. Different viewpoints need to be aired and resolved into the best outcome. Change occurs rarely without different viewpoints, particularly as it affects functions managed by each Enterprise or Domain Agility Team. All participants must focus on optimizing the overall value the organization can create and maximizing its ability to achieve its mission.

The Sprint Review includes the following elements:

• The Product Owner identifies what changes were made and how well the changes were absorbed by the organization;
• The Change Team presents and discusses the results of the evaluation, what went well and where issues exist. They also present their recommendations for work in the next Sprint based on what they saw.
• The Change Team discusses what went well during the Sprint, what problems it ran into, and how those problems were resolved;
• The Change Team reviews and explains any change in metrics for that domain;
• The Product Owner discusses the Practice Backlog as it stands; and,
• The entire group collaborates on what to do next so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings.

During Sprint Review new Practice Backlog items are identified that may be needed to make the change more effective. The result is a revised and re-ordered Practice Backlog that defines the probable practices for the next Sprint. The Practice Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Agility Teams to inspect their effectiveness 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. This is a three-hour time-boxed meeting.

The purpose of the Sprint Retrospective is to:

• Inspect how the last Sprint went with regard 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 Agility Team does its work.

The Scrum Master encourages the Change Team to improve, within the Evidence-Based Change framework, its working process to make it more effective and enjoyable for the next Sprint.

By the end of the Sprint Retrospective, the Agility Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Agility Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Evidence-Based Change Artifacts

Evidence-Based Change’s artefacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artefacts are designed to maximize transparency of key information needed to ensure that Agility Teams are successful in implementing incremental change

Practice Backlog

The Practice Backlog consists of Evidence-Based Practices that can be implemented within an organization to improve its ability to compete on its software capabilities. There is only one Practice Backlog prioritizing practices from all domains.

Each practice has the following attributes:

1. Recommended order of implementation based on impact and dependencies;
2. Estimated effort to implement, described as a relative effort rather than an absolute estimate; and,
3. A review value, the efficacy with which the practice is employed in the domain. There is one review value for each review performed, usually monthly prior to the Sprint Review.

Practice Backlog items are grouped as follows:

1. Domain. A practice has a primary domain, but may exist in more than one domain; and,
2. Practice Area. This groups practices into areas of impact or capability within the domain.

A Practice Backlog is never complete. The Agility Team creates an initial set of Practices for each domain in the Practice Backlog. This may be changed or modified based on the results of the evaluation of the organization and product for which the continuous improvement is happening.

Higher ordered Practice Backlog items are clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Practice Backlog items that will occupy the Change Team for the upcoming Sprint are refined, having been decomposed so that any one item can be completed within the Sprint time-box.

As continuous improvement progresses, the Practice Backlog becomes a larger and more exhaustive list. It is a living artifact.

Practice Backlog refinement is the activity of adding detail, estimates, and order to items in the Practice Backlog. Practice Backlog gets refined through the Sprint Reviews and through the evaluation process. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.

The Change Team is responsible for all estimates. The Product Owner may influence the Change Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.

Monitoring Progress Toward an Objective that Spans Several Sprints

At any point in time, the work remaining of total practices to reach a goal that spans several Sprints can be summed. At minimum, the Product Owner presents the total work remaining at every Sprint Review. This information is made transparent to all stakeholders.

Various projective practices using trends over empirical data can be used to forecast progress. However, these do not replace the importance of empiricism. In an organizational change process, what will happen is unknown. Only what has happened may be used for forecasting and forward-looking decision making.

Sprint Backlog

The Sprint Backlog is the set of Practice Backlog items selected for the Sprint plus a plan for delivering the Increment of change and realizing the Sprint Goal. The Sprint Backlog consists of the steps needed to implement the selected practices.

The Sprint Backlog defines the work the Change Team will perform to turn Practice Backlog items into an Increment of change. It makes visible all of the steps and work that the Change Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail for changes in progress to be understood in the Weekly Scrum. The Change Team modifies Sprint Backlog throughout the Sprint, and Sprint Backlog emerges during the Sprint. This emergence occurs as the Change Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Change Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Change Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Change Team plans to accomplish during the Sprint, and it belongs solely to the Change Team.

Monitoring Sprint Progress

At any point in time during a Sprint, the total work, or number of steps, of remaining items in the Sprint Backlog can be summed. The Change Team tracks this total work remaining at least prior to every Weekly Scrum, but preferably more frequently and projects the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Change Team can self-manage its progress.

Evaluation Backlog

The Evaluation Backlog is the set of practices that need to be re-implemented based on their observed impact on the organization. The Change Team captures previously implemented practices it wants to strengthen.

Increment of Change

The Increment of change is the sum of how the organization is performing its work differently at the end of the Sprint.

At the end of a Sprint, the functional flow within a domain must have changed. The new process, practice, or technique resulting from the Practice Backlog item(s) is in use and the manner in which the enterprise operates is changed. The change must be persistent.

Evidence-Based Metrics

Evidence-Based Change relies on a set of metrics that are utilized to assess the costs and benefits of the continuous improvement effort. These are updated every Sprint prior to the Sprint Review to reflect changes in the organization.

The metrics consist of the following categories of data:

2. Value – the quantitative benefits to the organization and trends;
3. Investments – the investments made in continuous improvements and trends; and,
4. Key Performance Indicators – changes in metrics show the operational product and software development ability to sustain value in the future, reflecting strengths. These are indicative of, but not directly subordinate to, returns on investments.

They are further described in the overview “Evidence-Based Management for Software Organizations”.

Agility Index

The Agility Index is a consolidation of the various metrics into one indicator. It represents the value an organization derives from its software development capabilities. Over time, it visualizes the improvement in business outcomes.

Progress in the Agility Index reflects the contribution of improved operational and development practices to the organization.

Agility Acceleration

Agility Acceleration is the measurement of the acceleration of the enterprise’s drive toward agility. Acceleration is typically low in the beginning but begins accelerating within the first year. The Agility Acceleration is tracked over time.

Conclusion

The Agility Guide, describing how to transform your enterprise is public and freely available. It is copyrighted, however.

The roles, artifacts, events, and rules for Evidence-Based Change are immutable and although implementing only parts of it is possible, the result is not Evidence-Based Change. Rather, Evidence-Based Change exists only in its entirety and functions well as a container for other techniques, processes, and practices, such as Scrum.