Disciplined Agile^® Glossary

Term

Description

Acceptance test-driven development (ATDD)

Acceptance test-driven development (ATDD) employs a test-first mindset where business, developers, and testers work closely to write acceptance tests before implementation begins. ATDD is very similar to behavior-driven development (BDD) and they are frequently discussed together.

Acceptance testing

Formal testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

Agile

Agile is a way that you choose to think and act.

As agilists, we choose to:

• Accelerate our value realization by embracing worthwhile changes.
• Delight customers by taking a customer-centric view to our work.
• Improve group capability by proactively collaborating instead of working in functional silos.
• Improve predictably by refining our understanding of what is needed through regularly showing our work and acting on feedback.
• Optimize flow by working on small things instead of big things. Big things are accomplished incrementally as a series of small things.
• Keep workloads within capacity by finishing the things we work on instead of starting lots of things. This is called limiting work in process.
• Improve continuously by frequently learning from our experience and evolving our practices based on what we learned.

See also: Agility, Agility at scale, Enterprise agility. 

Agile software development

Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life cycle of the project. Scrum and Extreme Programming are two software development methods based on agile tenets. See also: Scrum, XP.

Agile coach

A coach is a specialist role where the focus is on guiding people through their learning journey.

Types of agile coaches include:

• Team coach
• Specialized coach (such as agile data warehouse/business intelligence (DW/BI) coach, agile marketing coach)
• Enterprise coach

Agility

Agility predictably, sustainably, and rapidly delivers high-quality value in changing, complex environments.

See also: Agile, Agility at scale, Enterprise agility.

Agility at scale

The Disciplined Agile tool kit supports both types of agility at scale:

• Tactical agility at scale. This is scaling agile at the team level. The aim is to apply agile deeply to address all the complexities/scaling factors (team size, geographic distribution, organizational distribution, domain complexity, technical complexity, and regulatory compliance) appropriately.
• Strategic agility at scale. This is scaling agile at the organizational level. This is the application of agile and lean strategies broadly across your entire organization. This includes all divisions and teams within your organization, not just your IT department.

See also: Agile, Agility, Enterprise agility.

Architecture owner

The architecture owner is the person who owns the architecture decisions for the team and facilitates the creation and evolution of the overall solution design. It may not be necessary to formally designate a team member as an architecture owner on small teams. The person in the role of team lead will often also be in the role of architecture owner. This isn't always the case, particularly at scale, but it is very common for smaller agile teams.

Backlog

A list of work to be completed that has various degrees of commitment associated with it depending upon where it is being used.

Behavior-driven development (BDD)

Behavior-driven development (BDD) is a method of specifying a required behavior prior to doing design or implementation. It is very similar to acceptance test-driven development (ATDD) in that it typically is done in Given <an initial state> When <an event> Then <the desired resulting state> (GWT). The difference is that ATDD is also executable (manually or through automation). We discuss both together.

Build verification test

A group of tests to determine the health of a build at a high level. Typically, these tests exercise the core functionality of code and help determine whether further testing is warranted. These are also known as “smoke tests.”

Burndown chart

A chart showing the rate (story points per day) at which stories or tasks are being completed.

Burnup chart

A chart showing the rate (story points per day) at which business value is growing.

Business

The “business” is shorthand for someone from another part of the organization who is not part of the technical development team but has expertise and/or responsibility for profitably and addressing customers and markets. We also speak about the organization or the enterprise.

Business agility

See Enterprise agility.

Business value

Business value is what drives product development. It is the measurable or intangible return the business anticipates it can realize from the product. The business is responsible for identifying business value. Business value is what the business is willing to pay for. Development work should always be traceable to business value.

Here are types of business value:

• Delivering value to the customer
• Discovering what is of value
• Discovering how to build it
• Building it
• Preparing for consumption
• Improving our internal methods
• Mitigating risk
• Learning something new 

Cadence

The flow or rhythm of events, especially the pattern in which something is experienced. In agile/lean, cadence is the rhythm of when backlogs are refreshed, work is readied for synchronization, retrospections are done, demos are presented, and teams reflect on their work.

Capability

The combination of people and people skills, processes, and technologies required to equip the business/customer to use a product. All three are required because until the business can begin to use a product, the product merely represents potential.

Center of excellence (CoE)

Typically, a group of experts whose job is to educate, coach, and mentor people. Sometimes called a community of experts.

See also: Community of practice (CoP).

Code analysis

The process of checking that code conforms to design guidelines, looking for common coding and design errors per coding standards. The team makes an agreement to conform to these coding standards; thus, code analysis serves an integrity check with how well the team is working according to their standards.

Code coverage

A metric used to describe the degree to which source code has been tested. Code coverage is expressed as a percentage of lines of code tested over the total lines of code.

Cognitive bias

Cognitive bias occurs when an individual sees things from their own subjective view instead of seeing them as they really are. Humans automatically see the world through their own filter. When this happens, risks are often not noticed or attended to.

Colocated team

A team in which everyone on the team sits in the same room. With “pure” colocation:

• The team has their own dedicated room.
• Key stakeholders are also in the room, at least part time every day.

Team members often have access to “quiet rooms” where they can occasionally have private conversations.

See also: Distributed subteam, Fully dispersed team, Near-located team, Partially dispersed team, Subteam. 

Collaboration

Collaboration benefits organizations, teams, and individuals by enabling colleagues to work together to create new ideas from a starting point that is: uncertain, poorly understood, or innovative; adaptive or intangible; or requires change to accomplish.

Collaboration assumes that no one has the best, correct, or full answer and that the solution can only be found by exploring and synthesizing diverse points of view and using thought experiments and what-if scenarios.

Collaboration is creative and the work of humans, not machines.

Commonality/
variability analysis (CVA)

A technique that enables developers to write code that can be easily modified later. It complements iterative development. It is described in Design Patterns Explained (Shalloway & Trott, 2004).

Community of practice (CoP)

A group that focuses on sharing and enhancing skills within a group of like-minded people organized on a volunteer basis. CoPs may adopt common strategies, including internal discussion forums, training sessions, and “brownbag lunches.” They may also support the certification of practitioners.

Constraint

Anything that limits a system from achieving higher performance or throughput; it is also the bottleneck that most severely limits the organization’s ability to achieve higher performance relative to its purpose or goal.

Complex adaptive system

A complex adaptive system is a system in which a perfect understanding of the individual parts does not automatically convey a perfect understanding of the whole system’s behavior.

Continuous process improvement

A philosophy and attitude for analyzing capabilities and processes and improving them repeatedly to achieve customer satisfaction. Also known as continuous quality improvement.

See also: Guided continuous improvement (GCI), PDSA.

Cooperation

Cooperation benefits organizations, teams, and individuals by spreading the work across numerous functions, abilities, and methods (such as humans and machines can cooperate to produce work). Cooperation assumes that the work to be done is well understood, generally predictable, and has an accepted action plan. It is about helping to execute an already determined plan. Cooperation improves efficiency.

Cost-benefit analysis

A method of project evaluation that compares the potential benefits with the anticipated costs.

Cost of delay (CoD)

The cost, usually in terms of lost revenue or opportunity, caused by the delay between conceiving the idea and having customers realize value from it. This can be expressed both as a total anticipated amount at the start or on an ongoing basis as the project goes forward.

Don Reinertsen says, “If you only quantify one thing, quantify the cost of delay” (Reinertsen, 2009). 

Coupling and cohesion

Coupling refers to the strength of a connection between two routines or classes.

Cohesion refers to how closely the internal elements or operations in a routine or class are related. Some people refer to cohesion as “clarity” because the more operations are related in a routine or class, the easier it is to understand the code and what it’s intended to do.

Coupling and cohesion are complements of each other.

The goal is to create architectures and routines and classes with internal integrity (strong cohesion) and small, direct, visible, and flexible relations to other routines and classes (loose coupling).

Cross-functional team

Teams that have all the capabilities to deliver the work they’ve been assigned. Team members can specialize in certain skills, but the team is capable of delivering what they’ve been called on to build.

CRUFT

Test case documentation suffers from the CRUFT challenges associated with all forms of documentation. CRUFT is a mnemonic to express the effectiveness of an artifact. Each letter stands for a variable of effectiveness.

C The percentage of the artifact that is currently correct
R The chance that the artifact will be read by the intended audience
U The percentage of the artifact that is understood by the intended audience
F The chance that the material contained in the artifact will be followed
T The chance that the document will be trusted

Multiply the variables together to get the score. For example, if each of these were 0.95 (very high), the score would be 0.77.

The only way we can write effective documentation is if we know what stakeholders actually need and how they will work with the deliverable documentation that we produce.

Customer

The recipient of the output (product, service, information) of a process. Customers may be internal or external to the organization. The customer may be one person, a department, or a large group. Internal customers (outside of IT) are sometimes called the “business.”

Customer satisfaction

The result of delivering a product, service, or information that meets customer requirements.

Cycle time

The total elapsed time to move a unit of work from the beginning to the end of a process. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.

Daily coordination meeting

A regular, short meeting of the team where status is exchanged, progress is observed, and impediments are noted and removed. There are many approaches to do this. Also known as the daily standup.

Definition of done (DoD)

The criteria for accepting a minimum business increment (MBI), feature, or story as finished. Specifying these criteria is the responsibility of the entire team, including the business.

Definition of ready (DoR)

The minimum criteria that a minimum business increment (MBI), feature, or story must meet before the team will begin work on it. The DoR is a simple “quality gate” that protects the team from poorly formed work items. Specifying these criteria is the responsibility of the product owner in conversation with the team.

Demonstrable product

A version of a product that can be demonstrated to customers. It may not be quite ready for release or delivery since that usually requires additional work (such as artwork and production plans). It is the primary deliverable of an iteration.

Design pattern

A collection of best practices for solving problems in a recurring context. The more general term is “pattern” because patterns are involved with analysis, design, implementation, and testing.

Disciplined Agile^® (DA^™)

Disciplined Agile (DA) is a process-decision tool kit that provides straightforward guidance to help people, teams, and organizations to streamline their processes in a context-sensitive manner.

Disciplined Agile Delivery (DAD)

A people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery life cycle, is goal driven, is enterprise aware, and is scalable.

Disciplined Agile Enterprise (DAE)

A Disciplined Agile Enterprise (DAE) is able to sense and respond swiftly to changes in the marketplace. It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces. Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

Disciplined Agile Information Technology (DAIT)

Disciplined Agile Information Technology (DAIT) addresses how to apply agile and lean strategies to all aspects of information technology (IT)/information services (IS). This includes the majority of, if not all, IT delivery teams and the IT-level teams supporting activities such as enterprise architecture, operations, support (IT help desk), portfolio management, IT governance, and more.

Disciplined Agile FLEX

Disciplined Agile Flow for Enterprise Transformation (DA FLEX) is an approach (based on lean thinking and process patterns) that improves an organization’s ability to achieve business agility: the quick realization of value reliably, sustainably, and with high quality.

Disciplined DevOps

Disciplined DevOps is the streamlining of IT solution development and IT operations activities, along with supporting enterprise-IT activities such as security and data management, to provide more effective outcomes to an organization.

Distributed subteam

A subteam in which collaboration occurs as a cross-functional, whole team. Some coordination will be required between subteams.

See also: Colocated team, Fully dispersed team, Near-located team, Partially dispersed team, Subteam

Emergent design

Allowing a design to emerge over time, as part of the natural evolution of a system. Requires good practices and testing to ensure that the system is not inadvertently allowed to decay or become overly complex over time. See Emergent Design: The Evolutionary Nature of Professional Software Development (Bain, 2008).

Enterprise agility

Enterprise agility is the timely realization of business value predictably, sustainably, and with high quality. It is the ability of an organization to rapidly adapt to market and environmental changes in productive and cost-effective ways.

Enterprise agility focuses on value realized by having stakeholders identify, prioritize, and sequence the work to be done and allocate it appropriately to the product/service teams.

Sometimes referred to as business agility or organizational agility.

See also: Agile, Agility, Agility at scale.

Error proofing

The ability to catch errors immediately and take corrective action to prevent problems down the line. Four strategies for error proofing are: 1) eliminate the possibility of error, 2) reduce occurrence if elimination is not possible, 3) reduce consequences of errors, 4) capture and address errors early if they cannot be eliminated.

Extreme Programming (XP)

See XP.

Facilitator

An individual specifically trained to enable groups to work more effectively, collaborate, and achieve synergy. The facilitator is a "content neutral" party who does not take sides or express or advocate a point of view during the meeting, and who advocates for fair, open, and inclusive procedures to accomplish the group’s work.

Feature

A feature is a business function that the product carries out. Features are large and chunky and can be implemented by using many stories. Features may be functional or nonfunctional. Features form a basis for organizing stories.

FIT

Framework for integrated test

Flow

Flow is the ability to produce value continuously. A flow-based process delivers products, services, or information on a regular cadence in small batches. In fact, cadence helps lower transaction costs and makes small batches more economically feasible. Flow focuses on reducing the cost of delay by realizing the most important business value quickly. This also reduces risk.

Focused solution team

The focused solution team (FST) is a value-creation structure where a group of people work together on a particular product or group of related products. They typically work on one minimum viable product (MVP) or minimum business increment (MBI) at a time.

Fully dispersed team

A team in which everyone works from different locations. This requires significant coordination between people when the work requires collaboration. It works well when the work is piecemeal with little dependencies between tasks. It enables a work from anywhere, anytime approach. It often requires people to gather at critical times to coordinate and plan the next tranche of work.

See also: Colocated team, Distributed subteam, Near-located team, Partially dispersed team, Subteam.

Functional test

The activity that validates a feature against customer requirements. Functional tests are usually done by a tester as part of the customer team.

Gemba

The “gemba” is the place where value-added work is being done: a work cell, the developer team room, the help desk, the customer’s office. Management must go to these locations to observe, evaluate, coach, and engage with the team. This contrasts with management practices that rely on management hierarchies, team leads, or formal status meetings in conference rooms or management offices.

Generalizing specialist

A generalizing specialist is someone who has one or more specialties, has at least a general knowledge of the overall process, has at least a general knowledge of the business domain in which they work, actively seeks to gain new skills in both their existing specialties as well as in other areas, and shares their skills and knowledge with others.

Good practice

A superior method or innovative practice that contributes to the improved performance of an organization, usually recognized as “best” by other peers for given contexts. It is often worthwhile to focus on “good” practices rather than striving for “best” practices.

GQM

Goal question metric (GQM) is an approach to measuring progress on software. It defines three levels: the goal (conceptual level), the question (at the operational level), and a set of quantitative metrics that help assess progress in a measurable way.

See also: KPI and OKR.

Guided continuous improvement (GCI)

A DA approach to continuous improvement that guides you agnostically to identify a new practice/strategy that is likely to address the challenge you are dealing with. The hope is to speed up your efforts to improve your way of working (WoW).

See also: Continuous improvement, PDSA.

Harness tests

A group of test scenarios with expected outcomes related to a specific system module to confirm that defects have not been introduced because of current iteration programming activity. For example, a pricing test harness would confirm that there are no defects from the current pricing module programming.

Idealized value stream

A description of what an effective value stream for a particular organization would look like. Used by the value stream consultant in transition planning.

See also: Value stream map.

Impediment

A technical, personal, or organizational issue that is preventing or delaying progress on delivering product.

Information radiator

A type of visual control that displays information in a place where passersby can see it and get details about the project without having to ask questions. To be effective, the information must be current and must be easy to see and understand, with sufficient detail to explain status.

Intangible

Intangible metrics and deliverables are indirect drivers of change. For example, culture, leadership, behaviors, mental models, assumptions, teaming dynamics, social physics, and the ability to work on the organization. Intangible drivers of change are used to positively impact technical delivery and, when ignored, often have a negative impact on technical delivery and results.

Integration system test

The activity that verifies that software code does not harm other parts of the software product. Preferably, integration system testing is done by a tester with automated tools.

Iteration

A timeboxed period during which the team is focused on producing a demonstrable product or some amount of functionality that is ready to be shown to the customer and potentially ready to be delivered. Usually, iterations are 2-4 weeks long. In Scrum, an iteration is called a “sprint.” 

Iteration plan

The list of user stories for the upcoming iteration.

Iteration planning

The activity to prioritize and identify the stories and concrete tasks for the next iteration.

Investment pillar

An area in which an organization is investing in order to drive value for the customers and the business. There is a strong relationship between investment pillars and strategies. In planning, some organizations prefer to start with investment pillars. Others start with strategies and then get clarity on what these strategies are based on.

Just-in-time (JIT) design

The process of waiting until you know what the design needs to be and then refactoring code to meet these new needs before adding the functionality that is forcing the design change.

Kaizen

A Japanese term that means gradual, unending improvement by doing little things better and setting and achieving increasingly higher standards. Masaaki Imai made the term famous in Kaizen: The Key to Japan’s Competitive Success (Imai, 1986).

Kanban

Kanban is an approach to managing work by means of pull. There are various approaches. They all create visibility and use signaling to show when to start work. A kanban board is used to show work in process.

KPI

Using key performance indicators is an approach for measuring performance. Organizations use KPIs to evaluate progress and success in particular activities such as projects, programs, and initiatives.

See also: GQM and OKR.

Lean

An approach that produces value for customers quickly through a focus on reducing delays and eliminating waste, which results in increased quality and lower cost.

Lean governance

Lean governance is the leadership, organizational structures, and streamlined processes involved to enable teams within an organization to work as partners in sustaining and extending the organization’s ability to produce meaningful value for its customers.

Here are principles of lean governance:

• Collaboration over conformance
• Enablement over inspection
• Continuous monitoring over quality gates
• Transparency over management reporting

Lean governance ensures that people and teams:

• Are empowered to carry out their work
• Regularly and consistently create real business value
• Provide appropriate return on investment (ROI)
• Deliver consumable solutions in a timely and relevant manner
• Work effectively with their stakeholders
• Work effectively with their colleagues
• Adopt appropriate processes and organizational structures
• Present accurate and timely information to stakeholders
• Mitigate risks
• Sustain and extend strategies and objectives

Manual test

A document that lists the steps a person follows to complete a test pass. Not automated.

Minimum business increment (MBI)

The smallest viable enhancement to an existing product or service that delivers realized value for an internal or external customer.

The MBI is a holistic container for everything needed for its delivery and use (including marketing and support). 

An MBI is an investment in potential value.

See also: Minimum viable product (MVP). 

Minimum viable product (MVP)

The smallest piece of work to be used to validate a hypothesis about a potential product. The MVP is geared toward startups and/or the first time a product/service is released. It is usually built by a small team that can pivot.

An MVP is an investment in discovery.

See also: Minimum business increment (MBI). 

Near-located team

A team in which team members sit near one another, typically in the same area of a single floor, but do not have their own dedicated work room.

See also: Colocated team, Distributed subteam, Fully dispersed team, Partially dispersed team, Subteam. 

OKR

Objectives and key results (OKR) is a framework for defining and tracking objectives (clearly defined goals) and their outcomes (specific measures to track that goal). Measures should be concrete, measurable, and specific.

See also: GQM and KPI. 

Open-closed principle

The open-closed principle suggests that it is better to create designs that can accommodate change by adding to them, rather than by changing them. “Open-closed” means we are “open to extension but closed to modification.” This is a principle, and it is impossible to follow it literally at all times, but it can guide us in refactoring as well.

Operating model

An organization is a complex system for delivering value. An operating model breaks this system into components, showing how it works. It can help different participants understand the whole. It can help those making changes check that they have thought through all elements and that the whole will still work. It can help those transforming an operation coordinate all the different changes that need to happen.

Operational metrics

Operational metrics are direct drivers of change and governance. Operational metrics show status across the entire program or project. There are two kinds of operational metrics:

• Program- and project-level operational metrics. These are owned by the product owner and are calculated weekly. Examples include: release burnup, total top-line, satisfaction, and process improvement.
• Daily operational metrics. These are owned by the scrum master and are calculated daily. They are based on velocity. Examples include unestimated stories, open stories, open defects, tests passed, open issues, and impediments.

Partially dispersed team

A team in which some people work together at a single location, whereas others work at different locations. Often used to support a “work from home” strategy.

See also: Colocated team, Distributed subteam, Fully dispersed team, Near-located team, Subteam.

Pattern

A collection of best practices for solving problems in a recurring context, represented as collections of forces. It provides a professional language for high-fidelity communication among developers. It is the subject of many books, including Design Patterns Explained (Shalloway & Trott, 2004).

PDSA

The Plan-Do-Study-Act (PDSA) cycle is an iterative, four-step problem-solving process for quality improvement. Also known as the Deming Cycle, Shewhart Cycle, and Deming Wheel.

• Plan: Development of plan to effect improvement
• Do: Plan is carried out
• Study: Effects of plan are observed
• Act (or Adjust): Results studied and learning identified for future usage

Performance test

A test that ensures the required level of performance of a product is met. This test checks both that the functionality works and that the time required to do the work is acceptable.

Persona

A description of the typical skills, abilities, needs, tasks, behaviors, and backgrounds of a particular set of users. As an aggregation, the persona is a fiction but is used to ensure groups of users are accounted for.

Phase

In Disciplined Agile, phases provide focus and reduce risk. Phases enable teams to focus on critical themes and allow senior management to govern consistently.

There are three phases common across the project life cycles:

• Inception. Initiate the endeavor in a streamlined manner, including initial planning and modeling, and obtain agreement regarding the vision with the primary stakeholders.
• Construction. Develop a consumable solution in a collaborative and incremental manner. The team requests feedback in a regular manner which they then act on accordingly.
• Transition. Release/deploy the solution to stakeholders, ideally at the point where a new minimum business increment (MBI) has been developed.

Planning

The activity that seeks to prioritize and define the stories and tasks for the next iteration. Also known as “loading the product backlog.”

Portfolio level

The portfolio level includes a diverse group of stakeholders working across organizational boundaries. The portfolio level is responsible for identifying, prioritizing, sizing, and sequencing work based on business value. Roles involved in the portfolio include the value stream owners, the business and technology sponsors, and stakeholders. Business strategy flows into the technology organization at the portfolio level.

Practice

The customary, habitual, or expected procedure or way of doing of something. As used in goal diagrams, not knowing anything about your context, a selection of common practices is provided for each decision point, along with considerations to help a team select practices that help them to define their way of working.

See also: Good practice.

Process

A series of actions, changes, or functions performed in the making or treatment of a product.

Process blade

A process blade addresses a specific organizational capability, such as finance, people management, data management, agile solution delivery, procurement, and more. A process blade encompasses a cohesive collection of process options—including practices, strategies, and workflows—that should be chosen and then applied in a context-sensitive manner.

Process goals

A process goal captures the detailed, process-related decisions and options for a cohesive subset of a team’s way of working (WoW). Process goals provide guidance so that a team can tailor and scale agile strategies given the context of the situation they face. Sometimes called a process capability.

Product

A collection of tangible and intangible features that are integrated and packaged into releases that offer value to a customer or market.

Product owner

The product owner is the one individual on the team who speaks as the “one voice of the customer.” They represent the needs and desires of the stakeholder community to the agile delivery team. As such, they clarify any details regarding the solution and are responsible for maintaining a prioritized list of work items that the team will implement to deliver the solution. While the product owner may not be able to answer all questions, it is their responsibility to track down the answer in a timely manner so that the team can stay focused on their tasks.

Product vision

A short statement of the vision that is driving the project, expressed in business and customer terms while taking technological enablers into consideration: who it is for, the opportunity, its name, the key benefit, and differentiators. Typically, the product manager provides the product vision. Sometimes called the “project charter.”

Program increment

A larger development timebox that uses cadence and synchronization to facilitate planning, coordinate higher-level retrospectives, and aggregate work for feedback. The program increment is usually composed of multiple team iterations, often 4-6 team iterations.

Program level

The program level is the center of responsibility that is focused on an application area. Work is comprised of releases, enhancements, production support, and maintenance requests. The program level includes cross-functional representatives including the product manager, business program manager, and others who prioritize work across the value stream. This level is also responsible for the program ecosystem and operational metrics.

Project

A collection of releases, iterations, team members, and stories that creates a product. May have defined end dates or be ongoing. These may be:

• All of the software a team or related teams are working on
• A specific product or product group
• A version of a company’s product suite
• A specific client implementation 

Quality assurance (QA)

A role and activity that ensures integrity of the code to be released. The job of QA is to prevent defects from happening in the first place. It is not “merely” to find bugs.

Refactor

The disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Refactoring encourages and supports incremental design and implementation, the conversion of proofs of concept and early code into more suitable, stable code.

Two types of refactoring are fixing bad code and injecting better design into good code as requirements change.

Refactoring to the open-closed

The same tools and techniques that are used to clean up poor design and code (aka legacy refactoring) can be used to change a design just enough to allow for a clean addition or change to it. We take a design that was adequate initially, but cannot be changed cleanly to accommodate a new or changed requirement. We refactor the code until it follows the open-closed principle and then integrate the new code.

Release

A version of a product that is released externally to customers. Releases represent the rhythm of the business and should align with defined business cycles. A release contains a combination of minimum business increments (MBIs) that form a releasable product. A release may be internal and may be used for further testing.

Release testing

The activity that validates that the product is good enough to release to customers. Release testing is typically performed by a tester and is sometimes called quality assurance (QA).

Release testing explores the statement, “We have built something that users can use.” Often, release testing exposes requirements that fail to satisfy actual users’ needs.

See also: Quality assurance, Test. 

Retrospection

Retrospection is the structured, reflective practice of learning and improving based on what has already been done. The purpose of retrospection is to build team commitment and transfer knowledge to the next iteration and other teams.

Risk-value delivery cycle

The risk-value delivery cycle is where teams attack riskier work early on to help eliminate some or all of the risk, thereby increasing the chance of success. This term is used in the description of Disciplined Agile Delivery (DAD).

See also: Disciplined Agile Delivery. 

Role

A role is assumed by an individual on a given project. People may serve different roles on different projects or even different iterations. See specific role definitions.

Root cause

This is a factor that caused nonconformance to the plan and should be permanently eliminated through process improvement. Quality assurance helps lead root cause analysis.

Scaling factors

Defining a strategy that fits the team’s situation involves selecting a strategy and tailoring it based on complexity. This selection is informed by factors such as skills, culture, and constraints. These choices are then tailored based on the situation and complexity the team faces. DA identifies seven “scaling factors” to help tailor the selection.

• Team size
• Geographic distribution
• Organizational distribution
• Skill availability
• Compliance
• Solution complexity
• Domain complexity

Understanding the context that teams and organizations face involves identifying where they are for each of the factors, which can range from relatively simple to relatively complex.

It helps to plot these tactical scaling factors on a spider chart, each axis moving from simple to complex.

Scrum

An iterative and incremental agile software development methodology or framework for managing product development.

Scrum master

The scrum master champions both the needs of the team to the organization and the needs of the organization to the team. The scrum master is the team’s facilitator, shepherding the team as a servant leader by creating a positive and safe environment; improving team cohesion; being creative and focused; asking difficult questions about process aimed at challenging the team to improve; bringing issues and impediments to the team, product owner, or management; and helping to develop the product backlog. This goes beyond the common understanding in Scrum.

See also: Team lead.

Self-organizing team

In a self-organizing team, the people who do the work are the ones who plan and estimate the work. Team members volunteer to do certain work, collaboratively planning together, rather than being assigned the work by a manager.

Serial

There are several flavors of the traditional life cycle, sometimes called the serial life cycle, the waterfall life cycle, or even the predictive life cycle. Potential value is produced in a mostly linear manner through a series of functional phases (i.e., requirements, architecture, design, programming, testing, deployment). This life cycle is not explicitly supported by DA, although the DA mindset explicitly addresses the fact that many organizations will have traditional teams working in parallel with more modern agile/lean teams. It is also true that agile project teams work in a serial manner at a high level.

Standard work

Standard work is the work process agreed to by the team doing it. By “standard,” we do not mean imposed or fixed, but rather the best way to do something.

Standard work acts as a backdrop for doing our job and immediately seeing how well we are doing. Its intention is to create tension between what we’re doing and what we’re supposed to be doing. This promotes learning.

Stakeholder

A stakeholder is someone who is materially impacted by the outcome of a solution. In this regard, the stakeholder is clearly more than an end user. A stakeholder can be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the team, support (help desk) staff member, auditor, program/portfolio manager, developer working on other solutions that integrate or interact with the one under development, or maintenance professional potentially affected by the development and/or deployment of a software-based solution.

There are four stakeholder categories:

• End users. These are the people who will use your solution, often to fulfill the goals of your principals. They typically want solutions that are usable and enable them to do their jobs more effectively.
• Principals. These are the decision makers who ultimately pay for and then put your solution to use. This includes gold owners, senior business management, and purchasers of the commercial solutions.
• Partners. These people make the solution work in production. This includes operations staff, support staff, trainers, legal experts, installers, application hosting companies, and application developers on external solutions that integrate with yours.
• Insiders. These are members of the development team and people who provide technical and business services to your team. This includes enterprise architects, database administrators, security experts, network experts, tool smiths, marketing experts, and sales staff. 

Story

An invitation for a conversation about requirements, features, and/or units of business value that can be estimated and tested. Stories describe work that must be done to create and deliver a feature for a product. Stories are the basic unit of communication, planning, and negotiation between the development team, business owners, and the product manager.

Story point

The sizing metric used in the team estimation game. They express relative complexity for the purpose of estimating how much to place into an iteration. A common approach is using Fibonacci numbers (1,2,3,5,8, …), where 1 is low complexity and 8 is more complex, and then using team estimation or planning poker to get the team to agree on estimates.

Story point burnup chart

A chart showing the rate of progress the team is achieving in completing the project. It is measured as the number of story points completed per iteration and tracked toward the full project scope. Along with velocity, it visibly shows the duration and length of the current project.

Subteam

Subteams are organized around job functions such as testing or programming. Significant collaboration and communication are required between subteams.

Subject matter expert (SME)

A person who can speak with authority on an aspect of a project or who knows to whom to talk in order to get answers. SMEs may represent a technology, the business, the customer, process, or any other topic of importance to the project.

Swarm

The activity of a small team that forms to complete a work item. The rules for swarming are:

• Focus on one story at a time. Within an iteration, teams should have only a few stories open at a time because the focus is on burning down stories. Do not dissipate energy by focusing on too much at once.
• The swarm is the priority. While individuals may work on other tasks, their priority should be the swarmed story.
• Swarms are skill based. If you have the skills to contribute to burning down a story, and you have capacity, you are expected to join in the small team, even if it is not exactly in your job description to do so.

System evolution

System evolution is the process of building functionality from the system perspective. For example, building one layer (such as a database) and then another on top of it (such as a business layer).

Systems thinking

Systems thinking is considering a system to be an interrelated and interdependent set of parts which is defined by its boundaries and is more than the sum of its parts (subsystems).

Changing one part of the system affects other parts and the whole system, often in unanticipated ways. Systems do manifest patterns of behavior; understanding these patterns is the key to helping improve the system.

Positive growth and adaptation of a system depend upon how well the system is adjusted with its environment, and systems often exist to accomplish a common purpose (a work function) that also aids in the maintenance of the system, otherwise the operations may result in system failure.

The goal of systems thinking is to systematically discover a system’s dynamics, constraints, and conditions, and to elucidate principles (purpose, measure, methods, tools, etc.) that can be discerned and applied to systems at every level of nesting, and in every field, for achieving an optimized end state through various means. 

Tactical scaling factors

This term has been renamed. See Scaling factors.

Task

Tasks are descriptions of the actual work that an individual (or subteam) does in order to complete a story. Typically, there are several tasks per story. Tasks have the following attributes:

A description of the work to be performed, in either technical or business terms

An estimate of how much time the work will take (hours, days)

Exit criteria and verification method (test or inspection), and an indication of who will be responsible for the verification; all tasks must be verified, not just “done”

Team lead

An important aspect of self-organizing teams is that the team lead facilitates or guides the team in performing technical management activities instead of taking on these responsibilities themselves. The team lead is a servant leader to the team, creating and maintaining the conditions that allow the team to be successful.

See also: Scrum master. 

Team level

The team level consists of individual teams responsible for producing and implementing a business value increment, quality assurance, and continuous incremental improvement. Work is composed of the stories and tasks for a specific release, enhancements, production support, and maintenance requests.

The team level also includes shared services.

Team member

The role of team member focuses on producing the actual solution for stakeholders. Team members will perform testing, analysis, architecture, design, programming, planning, estimation, and many more activities as appropriate. Note that not every team member will have every single one of these skills, at least not yet, but they will have a subset of them, and they will strive to gain more skills over time. Team members will identify tasks, estimate tasks, sign up for tasks, perform tasks, and track their status toward completion. In addition to the general responsibilities described earlier, team members have several additional responsibilities.

Team working agreement

A team working agreement defines the team’s internal way of working (WoW) and how they are willing to interact with other teams.

External working agreements are sometimes defined in terms of service level agreements (SLAs).  

Test

Automatic and manual inspections of code and process to ensure correctness and completeness. Types of tests include unit, integration, system, regression, performance, and user acceptance (customer acceptance).

Test-driven development (TDD)

An evolutionary approach to development. In TDD, each test is written before the functional code that makes the test pass. The goal of TDD is specification and not validation, to think through a design before code is written, and to create clean code that always works.

Timebox

An allocated period of time allowed for getting work done. This means that we commit to completing work at a certain time, typically with a certain amount of effort (people and resources). We commit to getting as much work done as possible within this time frame.

Unit test

The activity that verifies that software code matches the design specifications. Typically, unit testing is performed by a developer—by the code creator or a “buddy”—however, testers often advise developers in testing approaches. Each unit test confirms that the code accurately reflects one intention of the system.

Use case

In agile/lean, use cases express the details for a requirement story. If the use case becomes so large that it cannot be implemented in a single iteration, then the requirement story associated with the use case can be broken down into iteration requirement stories first. Alternatively, if a use case is more abstract, it can represent several requirement stories.

Use cases should be expressed in the style of Cockburn’s detailed use cases  (Cockburn, 2000). They may be a white box or black box and include a main scenario, exceptions, and alternatives. Use cases can refer to business rules and data definitions.

User acceptance test (UAT)

The activity that verifies that software code matches the business intent. UAT belongs to the customer. They decide what constitutes an acceptable product. Unit tests help ensure that the acceptance tests are not about functional failures, but about the actual acceptability of the approach. Thus, UATs should not result in “it crashed,” but rather “I would like the menus to be more descriptive.”

Validation

The process of determining whether the work meets the needs of stakeholders.

Value added

A term used to describe activities that transform input into a customer’s (internal or external) usable output. An activity on a project is a value-added activity if it transforms the deliverables of the project in such a way that the customer recognizes the transformation and is willing to pay for it.

Value-creation structure

The value-creation structure of an organization refers to how the teams that are doing development/implementation are organized. This includes how they work with each other and with other teams as well as their span of control.

Value realization

Value is realized when customers begin to use what has been developed and get benefits from using it. This requires operations, marketing, support, and training.

Value stream

A value stream is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages for one or more development teams (where agile methods begin), and continues on through final delivery and support.

A value stream begins and ends with a customer. 

Value-stream-aligned teams

Teams that are optimized for flow and have all they need to realize continuous delivery of value and be fully responsive to the associated feedback cycles.

Value stream consultant

A person who works with the value stream owner and the organization to create a plan for improvement and provides the training and support to see the plan be realized. The value stream consultant sets out the process for improvement, while the value stream owner and management are focused on improving the value stream over the long term. The value stream consultant brings expert knowledge of enterprise or organizational transformation good practices.

See also: Value stream owner. 

Value stream impedance (VSI)

A measure of the resistance faced by the work in a value stream. VSI often creates delays that create more work, which creates more delays.

For example, the thrashing that occurs when integrating software developed by different teams.

Value stream map

A description (usually a diagram) that helps visualize the steps required to transform a customer request into a product or service.

DA has developed a more pragmatic and useful refinement of this approach that begins with the “idealized value stream.”

See also: Idealized value stream.  

Value stream owner

A person responsible for a systematic management approach with an immediate impact on the critical elements of a company’s value streams. They make change happen across departmental and functional boundaries.

See also: Value stream consultant. 

Velocity

Velocity measures how many points the team spends during an iteration. The following velocities are used in the planning game to determine how many stories the customer should give to the team to estimate for the iteration:

• Story velocity. The number of story points the team completes in an iteration.
• Task velocity. The number of “engineering hours” the team actually can perform in an iteration. 

Verification

The process of determining whether the work meets the specification for it.

Visual control

A visual control is a lean tool that has three primary purposes:

• It shows when there is some abnormality in the process, including blockages, people being overcapacity, dates at risk, and more.
• It provides an explicit workflow that the team is using.
• It provides management a view as to how work is flowing.

A visual control can take many forms. Simple kanban boards and complex product management systems are examples of visual controls. 

Voice of the customer

The “voice of the customer” is the term used to describe the stated and unstated needs or requirements of the customer. The voice of the customer can be captured in a variety of ways: direct discussion or interviews, surveys, focus groups, customer specifications, observation, warranty data, field reports, complaint logs, etc.

Waste

Any activity that consumes resources, produces no added value to the product or service a customer receives, or delays development of value. Types of waste include: 1) anything that does not add customer value, 2) anything that has been started but is not in production, 3) anything that delays development, 4) extra features, and 5) making the wrong thing.

XP (Extreme Programming)

A software development methodology adhering to a very iterative and incremental approach. XP consists of a number of integrated practices for developers and management; the original 12 practices of XP include small releases, acceptance tests, on-site customers, sustainable pace, simple design, continuous integration, unit tests, coding conventions, refactoring mercilessly, test-driven development, system metaphor, collective code ownership, and pair programming.

Yesterday’s weather

The expectation that a team will complete as many story points worth of work in the next iteration as they did in the last. Of course, this will only be true after they have done a few iterations and have hit a somewhat steady level. Typically, this is after 3-4 iterations. The term comes from the fact that before weather satellites, the most accurate way to predict weather was to say it would be the same as the day before. Hence, “yesterday’s weather” means we expect what happened before.