SAFe Glossary

Agile Release Train (ART) = a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.

Agile Team = The SAFe Agile Team is a cross-functional group of 5 to 11 people who have the responsibility to define, build, test, and where applicable deploy, some element of Solution value—all in a short Iteration timebox. Specifically, the SAFe Agile Team incorporates the Dev Team, Scrum Master, and Product Owner roles.

Architectural Runway = the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Built-In Quality = Built-In Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.

Business Owners = a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.

Business Solutions and Lean Systems Engineering = The Business Solutions and Lean Systems Engineering competency describes how to apply Lean-Agile principles and practices to the specification, development, deployment, and evolution of large, complex software applications and cyber-physical systems.

Capabilities = A Capability is a higher-level solution behavior that typically spans multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in a single PI.

Communities of Practice (CoPs) = organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain.

Compliance = a strategy and a set of activities and artifacts that allow teams to apply Lean-Agile development methods to build systems that have the highest possible quality, while simultaneously assuring they meet any regulatory, industry, or other relevant standards.

Continuous Delivery Pipeline (also referred to as the ‘pipeline’) = the workflows, activities, and automation needed to shepherd a new piece of functionality all the way from ideation to an on-demand release of value to the end user.

Continuous Deployment (CD) = the process that takes validated Features from a staging environment and deploys them into the production environment, where they are readied for release.

Continuous Exploration (CE) = the process that fosters innovation and builds alignment on what should be built by continually exploring market and Customer needs, and defining a Vision, Roadmap, and set of Features for a Solution that addresses those needs.

Continuous Integration (CI) = the process of taking features from the Program Backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release.

Core Values = The four Core Values of alignment, built-in quality, transparency, and program execution represent the fundamental beliefs that are key to SAFe’s effectiveness. These guiding principles help dictate behavior and action for everyone who participates in a SAFe portfolio.

Customers = the ultimate buyer of every Solution. They are an integral part of the Lean-Agile development process and the Value Stream and have specific responsibilities in SAFe.

Dev Team = a subset of the Agile Team. It consists of dedicated professionals who can develop, test, and deploy a Story, Feature, or component. The Dev Team typically includes software developers and testers, engineers, and other dedicated specialists required to complete a vertical slice of functionality.

DevOps = a mindset, a culture, and a set of technical practices. It provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a Solution.

DevOps and Release on Demand = The DevOps and Release on Demand competency describes how implementing DevOps and a continuous delivery pipeline provides the enterprise with the capability to release value, in whole or in part, at any time necessary to meet market and customer demand.

Develop on Cadence = an essential method for managing the inherent variability of systems development in a flow-based system, by making sure important events and activities occur on a regular, predictable schedule.

Economic Framework = a set of decision guidelines that align everyone with the financial objectives of the Solution and informs the economic decision-making process.

Enablers = support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.

Enterprise = represents the business entity to which each SAFe portfolio belongs.

Enterprise Architect = promotes adaptive design, and engineering practices and drives architectural initiatives for the portfolio. Enterprise Architects also facilitate the reuse of ideas, components, services, and proven patterns across various solutions in a portfolio.

Epic = a container for a Solution development initiative large enough to require analysis, the definition of a Minimum Viable Product (MVP), and financial approval before implementation. Implementation occurs over multiple Program Increments (PIs) and follows the Lean startup ‘build-measure-learn’ cycle.

Epic Owners = are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.

Essential SAFe configuration = the basic building block for all SAFe configurations and is the simplest starting point for implementation. It provides the Lean-Agile Leadership competency, the Team and Technical Agility competency, and the DevOps and Release on Demand competency.

Features = A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a Program Increment (PI).

Foundation = contains the supporting principles, values, mindset, implementation guidance, and leadership roles needed to deliver value successfully at scale.

Full SAFe configuration = includes all Five Core Competencies of the Lean Enterprise. It is the most comprehensive version of the Framework and supports enterprises that build and maintain a portfolio of large and complex solutions.

Innovation and Planning (IP) Iteration = occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

Inspect & Adapt (I&A) = a significant event, held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.

Iteration = Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. The recommended duration of the timebox is two weeks. However, one to four weeks is acceptable, depending on the business context.

Iteration Execution = how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment.

Iteration Goals = a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams.

Iteration Planning = an event where all team members determine how much of the Team Backlog they can commit to delivering during an upcoming Iteration. The team summarizes the work as a set of committed Iteration Goals.

Iteration Retrospective = a regular meeting where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.

Iteration Review = a cadence-based event, where each team inspects the increment at the end of every Iteration to assess progress, and then adjusts its backlog for the next iteration.

Large Solution Level = contains the roles, artifacts, and processes needed to build large and complex solutions.

Large Solution SAFe configuration = introduces the Business Solutions and Lean Systems Engineering competency, which supports those building the largest and most complex solutions that require multiple Agile Release Trains and Suppliers, but do not require portfolio-level considerations.

Lean Budget Guardrails = describe budgetary, governance and spending policies and practices for the lean budgets allocated to a specific portfolio.

Lean Budgets = a set of funding and governance practices that increase development throughput by decreasing funding overhead and friction while maintaining financial and fitness-for-use governance.

Lean Enterprise = a thriving digital age business that delivers competitive systems and solutions to its customers in the shortest sustainable lead time.

Lean Portfolio Management (LPM) = 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.

Lean User Experience (Lean UX) = Lean User Experience (Lean UX) design is a mindset, culture, and a process that embraces Lean-Agile methods. It implements functionality in minimum viable increments and determines success by measuring results against a benefit hypothesis.

Lean-Agile Leadership = The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential. They do this by learning, exhibiting, teaching, and coaching SAFe’s Lean-Agile mindset, values, principles, and practices.

Lean-Agile Mindset = the combination of beliefs, assumptions, 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.

Lean-Agile Principles = SAFe is based on nine immutable, underlying Lean-Agile principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe.

Metrics = agreed-upon measures used to evaluate how well the organization is progressing toward the portfolio, large solution, program, and team’s business and technical objectives.

Milestones = used to track progress toward a specific goal or event. There are three types of SAFe milestones: Program Increment (PI), fixed-date, and learning milestones.

Model-Based Systems Engineering (MBSE) = the practice of developing a set of related system models that help define, design, and document a system under development. These models provide an efficient way to explore, update, and communicate system aspects to stakeholders, while significantly reducing or eliminating dependence on traditional documents.

Nonfunctional Requirements (NFRs) = define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs.

Program Increment (PI) Objectives = a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI).

Portfolio Backlog = the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.

Portfolio Canvas = a type of Business Model Canvas that has been adapted to charter and describe the structure and purpose of a SAFe portfolio.

Portfolio Kanban = a mechanism used to visualize, manage, and analyze the prioritization and flow of portfolio Epics from ideation to implementation and completion.

Portfolio Level = contains the principles, practices, and roles needed to initiate and govern a set of development Value Streams. This is where strategy and investment funding are defined for value streams and their Solutions. This level also provides Agile portfolio operations and Lean governance for the people and resources needed to deliver solutions.

Portfolio SAFe configuration = provides the Lean Portfolio Management competency which aligns portfolio execution to enterprise strategy. It organizes development around the flow of value through one or more value streams.

Pre-and Post-PI Planning = Pre– and Post–Program Increment (PI) Planning events are used to prepare for, and follow up after, PI Planning for Agile Release Trains (ARTs) and Suppliers in a Solution Train.

Product Management = has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.

Product Owner (PO) = a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.

Program Backlog = the holding area for upcoming Features, which are intended to address user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the enabler features necessary to build the Architectural Runway.

Program Increment (PI) = a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

Program Increment (PI) Planning = a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision.

Program Kanban = The Program and Solution Kanban systems are a method to visualize and manage the flow of Features and Capabilities from ideation to analysis, implementation, and release through the Continuous Delivery Pipeline.

Program Level = contains the roles and activities needed to continuously deliver solutions via an Agile Release Train (ART).

Release Train Engineer (RTE) = a servant leader and coach for the Agile Release Train (ART). The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

Release on Demand = the process by which new functionality is deployed into production and released immediately or incrementally to Customers based on demand.

Roadmap = a schedule of events and Milestones that communicate planned Solution deliverables over a planning horizon.

SAFe Implementation Roadmap = an overview graphic and a 12-article series that describes a strategy and an ordered set of activities that have proven to be effective in successfully implementing SAFe.

SAFe® Program Consultants (SPCs) = Certified SAFe® Program Consultants (SPCs) are change agents who combine their technical knowledge of SAFe with an intrinsic motivation to improve the company’s software and systems development processes. They play a critical role in successfully implementing SAFe. SPCs come from numerous internal or external roles, including business and technology leaders, portfolio/program/project managers, process leads, architects, analysts, and consultants.

SAFe® for Government = a set of success patterns that help public sector organizations implement Lean-Agile practices in a government context.

SAFe® for Lean Enterprises = a knowledge base of proven, integrated principles, practices, and competencies for Lean, Agile, and DevOps.

Scrum Master = Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is being followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.

ScrumXP = is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe. It combines the power of Scrum project management practices with Extreme Programming (XP) practices.

Set-Based Design (SBD) = a practice that keeps requirements and design options flexible for as long as possible during the development process. Instead of choosing a single point solution upfront, SBD identifies and simultaneously explores multiple options, eliminating poorer choices over time. It enhances flexibility in the design process by committing to technical solutions only after validating assumptions, which produces better economic results.

Shared Services = represents the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be dedicated full-time.

Solution = Each Value Stream produces one or more Solutions, which are products, services, or systems delivered to the Customer, whether internal or external to the Enterprise.

Solution Architect/Engineer = responsible for defining and communicating a shared technical and architectural vision across multiple ARTs to help ensure the system or Solution under development is fit for its intended purpose.

Solution Backlog = the holding area for upcoming Capabilities and Enablers, each of which can span multiple ARTs and is intended to advance the Solution and build its architectural runway.

Solution Context = identifies critical aspects of the operational environment for a Solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. Solution context heavily influences opportunities and constraints for releasing on demand.

Solution Demo = where the results of development efforts from the Solution Train are integrated, evaluated, and made visible to Customers and other stakeholders.

Solution Intent = the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior. Where required, this includes both fixed and variable specifications and designs; reference to applicable standards, system models, and functional and nonfunctional tests; and traceability.

Solution Management = has content authority for the Solution Backlog. They work with customers to understand their needs, prioritize Capabilities, create the Solution vision and roadmap, define requirements, and guide work through the Solution Kanban.

Solution Train = the organizational construct used to build large and complex Solutions that require the coordination of multiple Agile Release Trains (ARTs), as well as the contributions of Suppliers. It aligns ARTs with a shared business and technology mission using the solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI).

Spanning Palette = contains various roles and artifacts that may apply to a specific team, program, large solution, or portfolio context.

Stories = short descriptions of a small piece of desired functionality, written in the user’s language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration.

Strategic Themes = differentiating business objectives that connect a portfolio to the strategy of the Enterprise. They influence portfolio strategy and provide business context for portfolio decision-making.

Supplier = an internal or external organization that develops and delivers components, subsystems, or services that help Solution Trains and Agile Release Trains provide Solutions to their Customers.

System Architect/Engineer = responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to help ensure the system or Solution under development is fit for its intended purpose.

System Demo = a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).

System Team = a specialized Agile Team that assists in building and supporting the Agile development environment, typically including development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. The System Team may also support the integration of assets from Agile teams, perform end-to-end Solution testing where necessary, and assists with deployment and Release on Demand.

Team Backlog = contains user and enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team’s local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.

Team Kanban = a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.

Team Level = contains the roles, activities, events, and processes which Agile Teams build and deliver value in the context of the Agile Release Train (ART).

Team and Technical Agility Competency = describes the critical skills and Lean-Agile principles and practices that are needed to create high-performing Agile teams who create high-quality, well designed technical solutions.

Value Stream Coordination = provides guidance to manage dependencies and exploit the opportunities in a portfolio.

Value Streams = the series of steps that an organization uses to build Solutions that provide a continuous flow of value to a customer. A SAFe portfolio consists of a set of development value streams, each of which builds and supports one or more solutions.

Vision = a description of the future state of the Solution under development. It reflects Customer and stakeholder needs, as well as the Feature and Capabilities, proposed to meet those needs.

Weighted Shortest Job First (WSJF) = a prioritization model used to sequence jobs (eg., Features, Capabilities, and Epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by job size.

© Scaled Agile, Inc.
Include this copyright notice with the copied content.

Author = Scaled Agile, Inc.

https://scaledagileframework.com/glossary/

Fishbone (Cause-Effect / Ishikawa) Diagram

A fishbone diagram, also called a cause and effect diagram or Ishikawa diagram, is a visualization tool for categorizing the potential causes of a problem in order to identify its root causes. Typically used for root cause analysis, a fishbone diagram combines the practice of brainstorming with a type of mind map template.

A fishbone diagram is useful in product development and troubleshooting processes to focus conversation. After the group has brainstormed all the possible causes for a problem, the facilitator helps the group to rate the potential causes according to their level of importance and diagram a hierarchy. The design of the diagram looks much like a skeleton of a fish. Fishbone diagrams are typically worked right to left, with each large “bone” of the fish branching out to include smaller bones containing more detail.

Dr. Kaoru Ishikawa, a Japanese quality control expert, is credited with inventing the fishbone diagram to help employees avoid solutions that merely address the symptoms of a much larger problem. Fishbone diagrams are considered one of the seven basic quality tools and are used in the “analyze” phase of Six Sigma’s DMAIC (define, measure, analyze, improve, control) approach to problem solving.

How to create a fishbone diagram
Fishbone diagrams are typically made during a team meeting and drawn on a flipchart or whiteboard. Once a problem that needs to be studied further is identified, teams can take the following steps to create the diagram:

The head of the fish is created by listing the problem in a statement format and drawing a box around it. A horizontal arrow is then drawn across the page with an arrow pointing to the head, this acts as the backbone of the fish.
Then at least four overarching “causes” are identified that might contribute to the problem. Some generic categories to start with may include methods, skills, equipment, people, materials, environment or measurements. These causes are then drawn to branch off from the spine with arrows, making the first bones of the fish.
For each overarching cause, team members should brainstorm any supporting information that may contribute to it. This typically involves some sort of questioning method, such as the 5 Whys or the 4P’s (Policies, Procedures, People and Plant) to keep the conversation focused. These contributing factors are written down to branch off their corresponding cause.
This process of breaking down each cause is continued until the root causes to the problem have been identified. The team then analyzes the diagram until an outcome and next steps are agreed upon.

When to use a fishbone diagram
A few reasons a team might want to consider using a fishbone diagram are:
To identify the possible causes of a problem.
To help develop a product that addresses issues within current market offerings.
To reveal bottlenecks or areas of weakness in a business process.
To avoid reoccurring issues or employee burnout.
To ensure that any corrective actions put into place will resolve the issue.

Author = Margaret Rouse (WhatIs.com)

https://whatis.techtarget.com/definition/fishbone-diagram

This cause analysis tool is considered one of the seven basic quality tools. The fishbone diagram identifies many possible causes for an effect or problem. It can be used to structure a brainstorming session. It immediately sorts ideas into useful categories.

WHEN TO USE A FISHBONE DIAGRAM
When identifying possible causes for a problem
When a team’s thinking tends to fall into ruts

FISHBONE DIAGRAM PROCEDURE
Materials needed: marking pens and flipchart or whiteboard.
Agree on a problem statement (effect). Write it at the center right of the flipchart or whiteboard. Draw a box around it and draw a horizontal arrow running to it.
Brainstorm the major categories of causes of the problem. If this is difficult use generic headings:
Methods
Machines (equipment)
People (manpower)
Materials
Measurement
Environment
Write the categories of causes as branches from the main arrow.
Brainstorm all the possible causes of the problem. Ask “Why does this happen?” As each idea is given, the facilitator writes it as a branch from the appropriate category. Causes can be written in several places if they relate to several categories.
Again ask “Why does this happen?” about each cause. Write sub-causes branching off the causes. Continue to ask “Why?” and generate deeper levels of causes. Layers of branches indicate causal relationships.
When the group runs out of ideas, focus attention to places on the chart where ideas are few.

Author = ASQ

https://asq.org/quality-resources/fishbone

Impact Mapping

Impact Mapping in Under 200 words

Step 1. Identify a User Goal. Write a User Goal on a white board or note card/post-it note.
Step 2. Identify Actors. Write the Actors (Personas/types of users) who would need to achieve the User Goal.
Step 3. Identify the Impact(s). Write the Impact(s) of achieving the User Goal (think in terms of “Why are we doing this now? / What problem does it help a user solve? / What business need does it address?).
Step 4. Identify Deliverables. Write the Deliverables (analogous to epics or features) that would need to be completed to make achievement of the User Goal possible.
Step 5. Repeat as necessary for additional User Goals. Add nodes to the impact map until each goal has been included.

Note: Impact Mapping works nicely as a complement to story mapping.

Author = Philip Rogers (Medium)

https://medium.com/agile-outside-the-box/impact-mapping-in-under-200-words-a7528bba901f

Using impact mapping to help your team experiment

This simple technique helps teams map the effects of their work to an organization’s broader processes and outcomes.

What is impact mapping?
The simplest way to understand impact mapping is to unpack the phrase itself.
The term “impact” in this context refers to a human behavioral change, something affected by the delivery of a product feature or a process change. Impact mapping defines the value of any work effort in terms of its “impact” (not merely its “completion”). This idea comes to us from the design thinking community, and has significant implications for the ways leaders incentivize risk-taking and therefore innovation (as I’ll discuss in the next section).
The term “mapping” is derived from the concept of the “mind map,” which participants build as part of the workshop. This special kind of mind map—also known as an “impact map”—is carefully constructed to surface the assumptions underlying a work effort. Specifically, impact mapping seeks to highlight all assumptions that:
a specific deliverable will lead to a specific behavioral change, and
a particular behavioral change will help the organization achieve its goal

Making experimentation expected behavior
In the context of an organization’s IT culture specifically, the application of economic decision rules derived from impact mapping has two significant implications:
Project teams have incentive to experiment with low cost prototypes to validate that their approach will deliver the required outcomes early in the delivery process. This is opposed to the traditional IT project delivery model that focuses on delivering a negotiated list of requirements at all costs.
Managers have incentive to ensure their desired outcomes have well defined measurements to enable the team to be confident in the results of their experiments. This is opposed to the traditional approach, where managers focus on ensuring requirements have been properly defined and successfully handed over to the project team.

Author = Justin Holmes (Red Hat, via opensource.com)

https://opensource.com/open-organization/17/6/experiment-impact-mapping

What is impact mapping?
Impact mapping is a strategic planning technique. It prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.

Author = Impactmapping.org

https://www.impactmapping.org/about.html

Impact Mapping is a collaborative approach to Agile requirements gathering and planning created by Gojko Azdic.
It helps us uncover the areas we are likely to create the greatest impact for a particular objective or goal.
Impact Mapping asks four questions:

  1. WHY ARE WE DOING THIS?
    This is the business goal or objective we’re hoping to achieve for our next phase of our product’s development, e.g. increase the number of visitors to this blog.
    The goal should be SMART – an acronym which stands for Specific, Measurable, Attainable, Relevant and Time-based.
  2. WHO WILL HELP US?
    The people that will help us achieve this, e.g. the readers of this blog. Gojko uses the term “actors” to describe the people who interact with our system and categorises them as primary, secondary and off-stage actors. This equates to the 1st, 2nd and 3rd-degree users of your service.
  3. HOW WILL THEY HELP US?
    The way the actor will help us achieve this – e.g. share this blog’s posts on social media. In essence, this describes the outcomes that we believe will help us reach our goal.
  4. WHAT WILL WE DO?
    The things we’ll create or change to encourage this behaviour – e.g. make blog posts easily shareable. These are the changes we’ll undertake to our product in order to create the behaviour we desire.
    In this step, we’ll write down as many actions as we can think of, for each of the outcomes we identified in step 3.

Author = Paul Flewelling

https://theagilecoach.co.nz/impact-mapping/

Impactmapping.org | Official Website

Author: Impactmapping.org

https://www.impactmapping.org/

5 Whys

Five whys (or 5 whys) is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem.

The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?”. Each answer forms the basis of the next question.

The “five” in the name derives from an anecdotal observation on the number of iterations needed to resolve the problem.

An example of a problem is: The vehicle will not start.

Why? – The battery is dead. (First why)
Why? – The alternator is not functioning. (Second why)
Why? – The alternator belt has broken. (Third why)
Why? – The alternator belt was well beyond its useful service life and not replaced. (Fourth why)
Why? – The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)

Author = Wikipedia

https://en.wikipedia.org/wiki/Five_whys

Scrum Glossary

Burn-down Chart = a chart which shows the amount of work which is thought to remain in a backlog. Time is shown on the horizontal axis and work remaining on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing work remaining may be expected to fall. The amount of work may be assessed in any of several ways such as user story points or task hours. Work remaining in Sprint Backlogs and Product Backlogs may be communicated by means of a burn-down chart. See also: Burnup Chart

Burn-up Chart = a chart which shows the amount of work which has been completed. Time is shown on the horizontal axis and work completed on the vertical axis. As time progresses and items are drawn from the backlog and completed, a plot line showing the work done may be expected to rise. The amount of work may be assessed in any of several ways such as user story points or task hours. The amount of work considered to be in-scope may also be plotted as a line; the burn-up can be expected to approach this line as work is completed.

Coherent/Coherence = The quality of the relationship between certain Product Backlog items which may make them worthy of consideration as a whole. See also: Sprint Goal.

Daily Scrum = daily time-boxed event of 15 minutes for the Development Team to re-plan the next day of development work during a Sprint. Updates are reflected in the Sprint Backlog.

Definition of Done = a shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.

Development Team = the role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint.

Emergence = the process of the coming into existence or prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly.

Empiricism = process control type in which only the past is accepted as certain and in which decisions are based on observation, experience and experimentation. Empiricism has three pillars: transparency, inspection and adaptation.

Engineering standards = a shared set of development and technology standards that a Development Team applies to create releasable Increments of software.

Forecast (of functionality) = the selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.

Increment = a piece of working software that adds to previously created Increments, where the sum of all Increments -as a whole – form a product.

Product Backlog = an ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner.

Product Backlog refinement = the activity in a Sprint through which the Product Owner and the Development Teams add granularity to the Product Backlog.

Product Owner = the role in Scrum accountable for maximizing the value of a product, primarily by incrementally managing and expressing business and functional expectations for a product to the Development Team(s).

Ready = a shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.

Refinement: see Product Backlog Refinement

Scrum = a framework to support teams in complex product development. Scrum consists of Scrum Teams and their associated roles, events, artifacts, and rules, as defined in the Scrum Guide™.

Scrum Board = a physical board to visualize information for and by the Scrum Team, often used to manage Sprint Backlog. Scrum boards are an optional implementation within Scrum to make information visible.

Scrum Guide™ = the definition of Scrum, written and provided by Ken Schwaber and Jeff Sutherland, co-creators of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.

Scrum Master = the role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.

Scrum Team = a self-organizing team consisting of a Product Owner, Development Team and Scrum Master.

Scrum Values: a set of fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.

Self-organization = the management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.

Sprint = time-boxed event of one month or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps.

Sprint Backlog = an overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Development Team.

Sprint Goal = a short expression of the purpose of a Sprint, often a business problem that is addressed. Functionality might be adjusted during the Sprint in order to achieve the Sprint Goal.

Sprint Planning = time-boxed event of 8 hours, or less, to start a Sprint. It serves for the Scrum Team to inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.

Sprint Retrospective = time-boxed event of 3 hours, or less, to end a Sprint. It serves for the Scrum Team to inspect the past Sprint and plan for improvements to be enacted during the next Sprint.

Sprint Review = time-boxed event of 4 hours, or less, to conclude the development work of a Sprint. It serves for the Scrum Team and the stakeholders to inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period.

Stakeholder = a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Technical Debt = the typically unpredictable overhead of maintaining the product, often caused by less than ideal design decisions, contributing to the total cost of ownership. May exist unintentionally in the Increment or introduced purposefully to realize value earlier.

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. Download the Scrum Values Poster

Velocity = an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

Author: Scrum.org

https://www.scrum.org/resources/scrum-glossary

Scrum FAQ

The article is a good read to go over basic Scrum concepts, as a refresher or to share with someone new to Scrum, to give them a quick idea.

There are answers the following questions:

What is Scrum?
Why do we need Scrum?
Why/how is Scrum better than “waterfall”?
Where did Scrum originate from?
Why work in “Sprints”?
What are the roles and responsibilities in a Scrum Team?
How might you use Scrum for maximum effect?
How do you estimate in Scrum?
How should the Product Owner organise the Product Backlog?
How do you get the best out of Scrum in terms of stories, acceptance criteria and testing?
How can Agile/Scrum make us more efficient, productive and engaged in teams?
What is the right approach for the “Definition of Done”?
How can I best help the team perform and improve?
How can I avoid being a blocker for others’ work?
How might Scrum work for research projects?
What is the difference between a time-box and a deadline?
Should the Development Team communicate with the Product Owner during the Sprint?
But how do we avoid unproductive interruptions?

Author = Neil Killick (Killick Agile Consulting)

https://www.neilkillick.com/blog/scrum-faq

Acceptance Criteria: Purposes, Formats, and Best Practices

AC = Acceptance Criteria = the conditions that a software product must meet to be accepted by a user, a customer, or other system. They are unique for each user story and define the feature behavior from the end-user’s perspective. Well-written acceptance criteria help avoid unexpected results in the end of a development stage and ensure that all stakeholders and users are satisfied with what they get.

Acceptance criteria main purposes
Feature scope detalization
Describing negative scenarios
Setting communication
Streamlining acceptance testing
Feature estimation

Acceptance criteria types and structures
scenario-oriented (Given/When/Then)
rule-oriented (checklist)
custom formats

Scenario-oriented acceptance criteria
Given some precondition
When I do some action
Then I expect some result

This approach was inherited from behavior-driven development (BDD) and provides a consistent structure that helps testers define when to begin and end testing a particular feature. It also reduces the time spent on writing test cases as the behavior of the system is described upfront.
Each acceptance criteria written in this format has the following statements:
Scenario — the name for the behavior that will be described
Given — the beginning state of the scenario
When — specific action that the user makes
Then — the outcome of the action in “When”
And — used to continue any of three previous statements

Rule-oriented acceptance criteria format
The rule-oriented form entails that there is a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios.

Article gives many examples and also covers:
Basic search interface acceptance criteria
Other formats
Roles responsible and how acceptance criteria are created

Main challenges and best practices of writing acceptance criteria
Document criteria before development
Don’t make AC too narrow
Keep your criteria achievable
Keep AC measurable and not too broad
Avoid technical details
Reach consensus
Write testable AC

Author = AltexSoft Inc (Medium)

https://medium.com/@AltexSoft/acceptance-criteria-purposes-formats-and-best-practices-d5fe25e1cd19

The Pros and Cons of Pair Programming

Pair programming = a software development practice in which two programmers collaborate on a single workstation at the same time. This collaboration can be done either in person or remotely, in which case you’ll need software for screen sharing and real-time editing.

The Pros of Pair Programming

  1. Fewer mistakes and bugs
  2. Greater resiliency
  3. Increased code quality
  4. Faster training
  5. Improved team morale

The Cons of Pair Programming

  1. Higher costs
  2. Sustainability

Conclusion = Pair programming isn’t new; it’s been around the software development industry for decades. As a practice, pair programming originates from the extreme programming (XP) methodology, which prioritizes high software quality and frequent tests and releases.
For some organizations, pair programming simply isn’t the right fit for their situation. However, a growing number of companies are finding that pair programming has a variety of benefits, including saved development time, higher-quality code, and better training and onboarding. As a result, everyone on the team is working together to build the most successful, best version of the product possible.

Author = Sam McDavid (Medium)

https://www.verypossible.com/blog/pros-and-cons-of-pair-programming

Is Extreme Programming No Longer Relevant?

Extreme programming is no longer relevant. According to the latest annual State of Agile™ survey, less than 1% of the nearly 4,000 respondents stated that they were practicing Extreme Programming, while 94% said they were practicing agile.

Article discusses XP and the importance of keeping its values/principles relevant. Note that Scrum was the leading methodology then (2015), and growing.

Author = Steve Ropa (CollabNet VersionOne)

https://resources.collab.net/blogs/is-extreme-programming-no-longer-relevant