```html
<picture>
<source srcset="https://firebasestorage.googleapis.com/v0/b/buildthenmarket-3cb50.appspot.com/o/img%2Fhome%2FLogo%20white%20-%20BUILD%20then%20MARKET%202023.png?alt=media&token=667f478c-9bc3-4dcb-8d3b-27865a5c8b62" media="(prefers-color-scheme: dark)" />
<img src="https://firebasestorage.googleapis.com/v0/b/buildthenmarket-3cb50.appspot.com/o/img%2Fhome%2FArtboard%201%400.5x.png?alt=media&token=75e45069-1327-4656-91ba-58dc9d9650e1" alt="build then market logo" />
</picture>
Glossary of Agile Management Terms
A description of the day-to-day operations of the company, including staffing, processes, and systems. How will the success of the business be measured and evaluated over time?
Table of Contents
A | B | C | D | E | F | G | I | J L | M | N | O | P | S | T | U | V | W
A
| A | Definition |
|---|---|
| acceptance criteria | Acceptance criteria in Agile methodology are specific conditions or requirements that must be met in order for a user story or feature to be considered complete and accepted by the product owner. They are typically defined during the sprint planning or sprint refinement meetings, and are used to ensure that the team have a shared understanding of what is expected of the feature or user story. Acceptance criteria should be specific, measurable, and achievable, and should be written in a way that is easily understood by all members of the development team. They should also be testable, so that the development team can verify that the feature or user story meets the Definition of Done (DoD), which is a shared understanding of what it means for a feature or user story to be considered complete. By defining clear acceptance criteria, the team can ensure that the delivered product is of high quality and meets the needs of the customer. |
| Agile | is a method of working quickly that is designed to adapt to rapid changes. Teams are often small and work in short sprints without lengthy processes or blockers to slow them down. Agile development teams continuously plan and adjust their work based on feedback from stakeholders and team members.Agile software engineering is an iterative and incremental approach to software development that emphasizes collaboration, flexibility, and customer satisfaction. The Agile methodology was first introduced in the 1990s as a response to the limitations of traditional software development methodologies, such as the Waterfall model. The Agile methodology values individuals and interactions, working software, customer collaboration, and responding to change. Agile development teams work in short iterations called sprints, typically lasting 1-4 weeks. At the end of each sprint, the team delivers a working increment of the software that can be reviewed and evaluated by stakeholders. Iterative and incremental development: Agile teams work in short iterations, delivering working software at the end of each iteration.Continuous delivery and deployment: Agile teams strive to deliver software quickly and frequently, and may automate the deployment process to streamline delivery.Overall, Agile software engineering is a flexible and adaptive approach to software development that emphasizes collaboration, customer satisfaction, and continuous improvement. |
| Agile decision-making | a flexible and iterative process that allows teams to make quick and effective decisions in a dynamic environment. By involving the entire team in the decision-making process, organizations can leverage the collective knowledge and expertise of their team members to make better decisions and achieve their goals more effectively. |
| Agile Process | continuously building better software product and increasing business agility. Can be combination of both. |
| Agile Team |  Agile teams are typically composed of members with diverse skills, such as developers, testers, and business analysts. |
| Agile Product Delivery | Agile Product Delivery is a customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users. |
| Agile Teams | In SAFe, an Agile team is a cross-functional group of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box. |
| Architectural Runway | The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay. Think of the Architectural Runway as a ready-to-use technical foundation---the existing code, components, and infrastructure---that allows the development team (or an Agile Release Train, ART) to implement new user-facing features quickly and without excessive redesign or delay. Analogy: If your business features are the planes carrying customer value, the Architectural Runway is the airport runway they need to take off and land safely. You need a functioning, long-enough runway to support future planes (features) that might be bigger or faster. Purpose: It ensures sustainable development velocity, reduces technical debt, and supports the long-term architectural vision of the solution. It's about having "just enough" architecture designed and implemented just in time to support the next set of business features. |
| Agile ceremony | Agile ceremonies are meetings where a engineering team comes together at various stages during the engineering process for discussions on planning future work, communicating ongoing work or reviewing and reflecting on past work. |
B
| B | Definition |
|---|---|
| backlog | The backlogs represent a continuous flow of work, moving from large, strategic initiatives down to small, executable tasks. It is a dynamic list of all desired features, enhancements, and bug fixes for the project. It is regularly refined and prioritized by the team. The backlog serves as a single source of truth for the project's requirements and guides the team's work. Tasks—or deliverables—in a backlog are organized and done in priority order. It also contains the upcoming Features intended to address user needs and deliver business benefits. |
| baseline | an original plan or estimate for a project’s timeline, budget, scope, and goals. It is an important tracker to compare progress against and make adjustments. |
| Blockers | literally block or slow the way forward—and should be anticipated and removed ahead of time. These project impediments range from technology complications to budget constraints. |
| bottleneck | narrows and constricts the flow, pace, and capacity of a project. This could be stakeholders that have too many deliverables to approve or processes that can get overloaded. |
| Boy Scout Rule | Leave things better than you found them. As applied to a technical team, whenever you work in an area of code, always make even a small improvement, maybe to tests, or documentation, or otherwise improve clarity, readability or maintainability. |
| budget | the estimated total cost to complete a project. Project costs should be calculated as a total sum of parts and include project phases, tasks, operating costs, labor, and tools or services needed. |
| Brainstorming | a tool for creative ideation and solutions. Brainstorm sessions follow a variety of different techniques, but the key is to gather many ideas and find the best within those. |
| Brownfield development | The opposite of greenfield development, working with existing legacy systems, often heavily impacted by tech debt. You're stuck with the high-level decisions that have been made in the past and you have limited flexibility for large change. |
| Built-In Quality | Built-In Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development. |
| Business Model: | A business model is the framework that outlines how a business will generate revenue and make a profit. It defines the key components of the business, including its target market, value proposition, revenue streams, cost structure, and competitive advantage. The business model is a high-level strategic overview of how the business will operate and make money. |
| Business Agility | Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally-enabled business solutions. |
| Business and Technology | The Business and Technology icon in SAFe describes how functional domains in all parts of the enterprise enable business agility by continuously exploring new ways to apply Lean-Agile principles and practices to their unique contexts. |
| Business Owners | Business Owners are 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 tech department. They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events. |
C
| C | Definition |
|---|---|
| Case studies | are resources that dive into use-cases and various approaches to project management. They’re usually research-based studies that help an aspect of the decision-making process. |
| Change management | is, well, literally how to manage and control changes within an organization, team, or project. This method aims to maintain control and efficiency when changes are made. |
| A contingency plan | is a detailed emergency backup plan for how to effectively manage any short and long-term disruptions or disasters that could arise throughout the project. |
| CALMR | SAFe’s CALMR approach to DevOps is a mindset that guides ARTs toward achieving continuous value delivery by managing simultaneous advancements in delivery culture, automation, lean flow, measurement, and recovery. |
| 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. |
| Capacity Planning | the process of forecasting and then accommodating the capacity needs of a project, specifically the amount of work, time and other resources needed to complete a sprint. |
| Compliance | Compliance refers to 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 ensuring they meet any regulatory, industry, or other relevant standards. |
| Context switching | Changing from one task to another. For engineers that means setting aside the problem being worked on and starting to work on another. The act of switching is generally time consuming and less efficient than working on one problem at a time. |
| Continuous Delivery Pipeline (CDP) | The Continuous Delivery Pipeline (CDP) represents the workflows, activities, and automation needed to shepherd a new piece of functionality from ideation to an on-demand release of value to the end user. |
| Continuous Deployment (CD) | Continuous Deployment (CD) is the process that takes validated Features in a staging environment and deploys them into the production environment, where they are readied for release. |
| Continuous Integration (CI) | Continuous Integration (CI) is 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. Agile teams frequently integrate code changes and test the software to ensure quality and reduce the risk of defects. |
| Continuous Learning Culture | The Continuous Learning Culture competency describes a set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation. |
| 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. |
| Customer | Customers are the ultimate beneficiaries of the value of the business solutions created and maintained by the portfolio value streams. |
| Customer Centricity | Customer centricity is a mindset and a way of doing business that focuses on creating positive experiences for the customer through the full set of products and services that the enterprise offers. |
D
| D | Definition |
|---|---|
| Definition of done | a formal, shared, and evolving checklist of quality-centric criteria that a product backlog item must satisfy to be considered complete and releasable. |
| Defintion of ready | "Definition of Ready" is an agreed-upon checklist of criteria that a backlog item must meet---such as being clear, estimated, testable, and appropriately sized---before the development team can confidently commit to starting work on it in a sprint. |
| Deliverables | All projects have one or more deliverables, which are the results delivered throughout or at the end of a project. These outputs are products and/or services, such as reports, service updates, marketing materials, or goods. |
| Design Thinking | Design Thinking is a customer-centric development process that creates desirable products that are profitable and sustainable over their lifecycle. |
| Development Value Streams | Development value streams (DVS) are the sequence of activities needed to convert a business hypothesis into a digitally-enabled Solution. Examples include designing a medical device or geophysical satellite, or developing and deploying a software application, SaaS system, or an e-commerce web site. |
| DevOps | DevOps is 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. |
| Direct-to-Consumer (DTC or D2C) | is a business model where manufacturers or brands sell their products directly to end customers, bypassing traditional retail intermediaries like grocery stores, department stores, or wholesalers. The Core Idea is Brand → Customer with no middleman Why Brands Go DTC: - Higher margins (no retailer cut)- Customer data ownership - Stronger brand loyalty - Faster feedback & innovation |
E
| E | Definition |
|---|---|
| Enablers | They are essentially strategic investments in the technology stack that don't deliver direct customer value themselves but enable the delivery of future customer-facing value. An Enabler supports the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, architecture, infrastructure, and compliance. Enablers are captured in the various backlogs and occur throughout the Framework. |
| Epics | An Epic is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio. Due to their considerable scope and impact, epics require the definition of a Minimum Viable Product (MVP) and approval byLean Portfolio Management (LPM) before implementation. |
F
| F | Definition |
|---|---|
| Features | An interactive or functional component (e.g., gallery with lightbox, booking form, blog feed). 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 software engineer or group in a Program Increment (PI). |
| Feature parity | While it's a simple concept to state, might be hard to implement. Build a new system, in a more appropriate technology stack, with exactly the same features and behaviors as the existing system. Whenever anyone has a question about what the new system should do, we answer that question with "do what the existing system does". I’m working on a product that spans multiple platforms (iOS, Android, macOS, Windows, Chrome). What are best practices for organizing teams and maintaining feature parity when targeting multiple platforms?” |
| Foundation | The Foundation contains the supporting principles, values, mindset, implementation guidance, and leadership roles needed to deliver value successfully at scale. |
| Forming, Storming, and Norming | "Storming, forming, and norming" are stages of group development that were first described by psychologist Bruce Tuckman in 1965. These stages describe the typical progression of a group as they work together to achieve a common goal.Overall, these stages describe the process that groups typically go through as they work to become an effective team. By understanding these stages, group members and leaders can anticipate some of the challenges that may arise and work to address them proactively. The "forming" stage is the initial stage, where group members come together and start to get to know each other. At this stage, there is usually a lot of uncertainty and anxiety about the group's purpose and goals. The "storming" stage is the next stage, where conflicts and differences of opinion start to emerge. This can be a difficult stage, as group members may disagree about how to achieve the group's goals or have different ideas about how things should be done.The "norming" stage is the stage where the group starts to come together and establish a sense of shared identity and purpose. At this stage, group members start to develop a sense of trust and cooperation, and they begin to work together more effectively. |
H
| H | Definition |
|---|
I
| I | Definition |
|---|---|
| inactive time | This refers to the time that has been allocated for working but some members of the team, or all members sometimes, will not be working. It includes holidays, team breaks, off days, ad hoc meetings (unplanned), agile events etc. Take this down to the individual level. The goal here is to estimate and get rid of all the time that will not actually be spent on doing the actual work throughout the sprint. |
| Industrial-Organizational (I/O) Psychology | Applies psychological principles and research methods to the workplace and organizations. Its goal is to improve productivity, efficiency, and the well-being of employees through areas like personnel selection, training, performance assessment, and workplace culture. |
| Innovation and Planning Iteration | The 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) | The Inspect and Adapt (I&A) is 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. In SAFe, iterations are typically one or two weeks in length, with two being the most common. |
| Iteration Execution | Iteration Execution is how Agile Teams manage their work throughout the Iteration timebox, resulting in a high-quality, working, tested system increment. |
| Iteration Goals | Iteration Goals are 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 software projects as a self-organizing, self-managing team of teams. |
| Iteration Planning | Iteration Planning is 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 | The Iteration Retrospective is a regular event where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve. helping the team gain a shared understanding of the work, and how you best work together. |
| Iteration Review | The Iteration Review is 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. |
J
| Terms | Definitions |
|---|---|
| just-in-time requirements | the practice of delaying detailed requirements gathering and documentation until they are needed for development. It is based on the principle that requirements are likely to change or evolve over time, and investing a significant amount of effort into gathering and documenting requirements upfront may result in wasted time and resources if those requirements become outdated or irrelevant. Instead, in the just-in-time requirements approach, agile teams focus on identifying and capturing high-level requirements and user stories at the beginning of a project or iteration. These high-level requirements provide a general understanding of the desired functionality and goals of the software system. However, the details and specific requirements are deferred until they are needed for development. The benefits of just-in-time requirements include: 1. Adaptability: By delaying detailed requirements, teams can respond more effectively to changing business needs and priorities. They can incorporate new insights and feedback into the development process without being constrained by extensive upfront documentation. 2. Reduced waste: Traditional requirements gathering often involves significant time and effort spent on capturing and documenting requirements that may never be implemented or may change significantly. Just-in-time requirements help minimize this waste by focusing on what is currently needed. 3. Iterative refinement: Agile development encourages an iterative and incremental approach. With just-in-time requirements, teams can refine and update requirements based on ongoing collaboration, learning, and feedback, resulting in a more accurate and relevant understanding of the system's needs. However, it's important to note that just-in-time requirements do not mean ignoring or neglecting requirements altogether. They are still essential for effective software development. The approach emphasizes balancing the need for flexibility and responsiveness with the need for clear guidance and understanding of the system's objectives. |
K
| K | Definitions |
|---|---|
| Kaizen: Kaizen is the philosophy of continuously improving all processes in an organization. |
L
| L | Definition |
|---|---|
| Lean Budget Guardrails | Lean Budget Guardrails describe the policies and practices for budgeting, spending, and governance for a specific portfolio. |
| Lean Budgets | Lean Budgets is a Lean-Agile approach to financial governance which increases throughput and productivity by reducing the overhead and costs associated with project cost accounting. |
| Lean Portfolio Management | 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. |
| Lean-Agile Mindset | The Lean-Agile Mindset is the combination of beliefs, assumptions, attitudes, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It’s the personal, intellectual, and leadership foundation for adopting and applying SAFe principles and practices. |
| Lean-Agile Principles | SAFe is based on ten immutable, underlying Lean-Agile principles. These tenets and economic concepts inspire and inform the roles and practices of SAFe. |
| lead Time | how long it takes you to make product changes.How are we performing relative to before? Where are there bottlenecks in our development process? Which changes took us the longest to make? Is this increase in our lead time caused by longer review and deploy times or an increase in our work load? |
| Low hanging fruit | "Low hanging fruit" is a metaphorical expression that refers to tasks, opportunities, or solutions that are relatively easy to accomplish or obtain with minimal effort or resources. The term is commonly used in various contexts, including business, problem-solving, and decision-making. 1. Ease of Achievement: Low hanging fruit typically represents tasks or goals that can be accomplished quickly and with minimal effort. They are straightforward and require less time, complexity, or resources compared to other more challenging or time-consuming endeavors. 2. Immediate Impact: Low hanging fruit often offers immediate benefits or results. By focusing on these tasks or opportunities, individuals or organizations can quickly achieve positive outcomes, generate value, or make noticeable improvements. 3. High Probability of Success: The likelihood of success is relatively high when pursuing low hanging fruit. The tasks or goals are usually well within reach and align with the existing capabilities, resources, or expertise of the individual or organization. This increases the confidence that the desired outcome can be achieved. 4. Quick Wins: Low hanging fruit can provide a sense of accomplishment and momentum. By identifying and tackling these tasks or opportunities early on, individuals or organizations can create positive feedback loops, boost morale, and build confidence for more challenging endeavors. 5. Efficiency and Resource Optimization: Prioritizing low hanging fruit allows individuals or organizations to optimize their use of time, energy, and resources. By focusing on tasks that offer significant returns for relatively little investment, they can maximize their efficiency and make the most of available resources. It's important to note that while low hanging fruit can provide immediate benefits, they should not be the sole focus of efforts. It is also essential to tackle more complex and long-term initiatives to drive sustainable growth and address deeper challenges. |
M
| M | Definition |
|---|---|
| Measure and Grow | Measure and Grow is the way portfolios evaluate their progress towards business agility and determine their next improvement steps. |
| Metrics | Metrics are agreed-upon measures used to evaluate how well the organization is progressing toward the portfolio, large solution, ART, and Agile team’s business and technical objectives. |
| Milestones | Milestones are key points throughout a project’s timeline that can be used as markers to celebrate and assess progress. Milestones are 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. |
| Multivariate Testing | Multivariate & A/B testing: Tests multiple variables simultaneously to determine which combination of changes produces the best results, unlike A/B testing which tests one variable at a time. |
| Model-Based Systems Engineering (MBSE) | Model-Based Systems Engineering (MBSE) is 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. |
| Migration Strategy | dimmer switch approach, excitement vs fear of new UI / UX |
N
| N | Definition |
|---|---|
| Noise | shifting answers makes it error-prone to predict and decide |
| Nonfunctional Requirements (NFRs) | 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. |
O
| O | Definition |
|---|---|
| Operational Value Streams | Operational value streams (OVS) are the sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a professional service. |
| Organizational Agility | The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities. |
| organizational hierarchy / Organization Structure |  |
P
What is a Product?
a SaaS Service is a Product. The term "product" generally refers to any good or service that is offered to a market to satisfy a need or want. It encompasses the entire user experience from discovery to use. "product" is a broad concept that includes:
- Physical Goods: Tangible items like smartphones, cars, furniture, or home appliances.
- Digital Goods: Intangible items such as software, mobile applications, websites, video games, or e-books.
- Services: Intangible offerings where the consumer receives value through an action or performance, often facilitated by a digital or physical platform.
| P | Definition |
|---|---|
| Project constraints | are any factors that can limit a project’s success such as risk, scope, timeline, budget, and quality issues. |
| Participatory Budgeting | Participatory Budgeting (PB) is the process that Lean Portfolio Management (LPM) uses to allocate the total portfolio budget to its value |
| PI Objectives | Program Increment (PI) Objectives are a summary of the business and technical goals that an Agile Team or train intends to achieve in the upcoming Program Increment (PI). |
| Portfolio SAFe | Portfolio SAFe aligns strategy with execution and organizes solution development around the flow of value through one or more value streams. |
| Portfolio Vision | The Portfolio Vision is a description of the future state of a portfolio’s Value Streams and Solutions and describes how they will cooperate to achieve the portfolio’s objectives and the broader aim of the Enterprise. |
| 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 | Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle. |
| Product Owner (PO) |  The Product Owner (PO) is responsible for defining the product vision, creating and prioritizing the product backlog, and ensuring that the team is focused on delivering business value. They maximize the value delivered by the team and ensure that the Team Backlog is aligned with customer and stakeholder needs. |
| Program Increment (PI) | A Program Increment (PI) is a timebox during which an engineering dept 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 | Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the software project management, 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. |
R
Rational Unified Process Unified Process
| R | Definition |
|---|---|
| Release | To release is to make functionality that has been deployed to a production (or operational) environment available for use by a defined set of end-users or systems. |
| Release Planning | release planning is a technique to implement the product road map which is derived from the product vision. A release plan sets out the number of iterations within a release |
| Release on Demand | Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand. |
| Roadmap | The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a planning horizon. |
| role clarity | the clear definition of roles and responsibilities within a team. In an agile team, each member has a specific role and is responsible for specific tasks. Role clarity helps ensure that everyone on the team understands their responsibilities and how they contribute to the success of the project. In an agile team, there are typically three main roles: Scrum Master: The Scrum Master is responsible for facilitating the Scrum framework by coaching the team on agile principles, removing impediments, and ensuring that the team is following the Scrum process. Development Team: The Development Team is responsible for delivering the product increment by working together to complete the tasks in the Sprint Backlog. Within these roles, there may be additional responsibilities or sub-roles, depending on the specific needs of the team and project. It is important for everyone on the team to understand their role and how they contribute to the project's success. Role clarity is important because it helps to minimize confusion and misunderstandings within the team. When everyone knows their role and responsibilities, they can work more effectively together to achieve the project's goals. It also helps to ensure that everyone is accountable for their work and that the team is working towards a common objective. |
| Risk mitigation | is a strategy where the probability of risk or its impact on a project is minimized by taking certain precautions depending on the type of risk. |
| A risk owner | is a person who is charged with the responsibility of risk management and mitigation. |
| risk Management | This is the process of looking out for, identifying, assessing, responding to, and managing risks that could impact a project. Risks can range from service disruptions to resource reallocations. |
| Resource Allocation | Resources are anything or anyone necessary to complete a project or task. This can range from talent (people) to finances, time, services, and tools. Resource allocation is the act of recognizing and assigning the best available resources (often within a budget) to a particular project. |
| RACI | stands for Responsible, Accountable, Consulted, and Informed. This chart is a way to assign roles and responsibilities to stakeholders and team members on project activities. |
| Revenue: | measures the amount of money generated by the company through its products and/or services and is useful for understanding the financial health and sustainability of the project. Only if the revenues are sufficient, the costs can be covered and there can be a chance to grow. |
S
| S | Definition |
|---|---|
| Story Points |  Story points are a unit of measurement used in Agile project management to estimate the relative size of a task or feature. They are based on the complexity and effort required to complete the task or feature, and are used to prioritize and plan work. Story points are a relative measure, meaning that they are not based on absolute time or effort, but rather on the relative size of the task or feature. |
| SCRUM | was first introduced in the early 1990s by Jeff Sutherland and Ken Schwaber. |
| SAFe for Lean Enterprises | SAFe for Lean Enterprises is the world’s leading framework for business agility. SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality. |
| Scrum Master | The major responsibilities are to assist the teams in delivering value by facilitate the Agile ceremonies and processes. They also communicate with stakeholders, help manage risk, and drive relentless improvement. SAFe 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 followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement. |
| Set-Based Design | Set-Based Design (SBD) is 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. |
| Spanning Palette | The Spanning Palette contains various roles and artifacts that may apply to a specific team, program, large solution, or portfolio context. |
| Stories | Stories are 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 | Strategic Themes are 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 | A Supplier is 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 Demo | The System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the tech department. Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI). |
| System Team | The System Team is 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. |
| scrumban | |
| Use cases | are all of the ways that an end-user could use a product or service and can be helpful to understand a project’s scope and requirements. |
| Sprint | In Scrums and agile project management, teams work in a continuous development cycle of short sprints. A sprint is a predetermined amount of time to complete one cycle, iteration, or task within a project. |
| Stakeholders | are any individuals, teams, or organizations that may be impacted by a project outcome or aspect of it—and may need to be considered or consulted throughout. |
| The scope | is an outline of the boundaries of all aspects of a project and includes budget, timeline, deliverables, tasks, expectations, and so on. It should address the what business needs, problems, or opportunities such as market demand, business need, legal requirement, social need, customer request, or technological advance |
| Scope creep | happens when the scope of a project expands uncontrollably and begins to take time and resources from other allocations. |
| Sprint Reviews | A Sprint Review is a collaborative meeting held at the end of each sprint where the development team demonstrates completed work to stakeholders and gathers feedback to inform future development priorities. |
T
| T | Definition |
|---|---|
| Team and Technical Agility | The Team and Technical Agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers. |
| Team Backlog | The lowest-level backlog, managed by each individual Agile team. The 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 | Team Kanban is 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. |
| turnaround time | |
| Tier One System | A Tier One system, in the context of enterprise and infrastructure management, is the most mission-critical systems within an organization's IT portfolio. A Tier One system is an application or service that is absolutely essential to the core functionality, revenue generation, or legal compliance of the business. |
| Transaction volume | the total number of transactions processed in a given time interval. From the analysis of this data we can obtain the level of usage and demand of the platform and have an idea whether the company has adopted a correct sizing of resources and the necessary measures for scalability. |
U
| U | Definition |
|---|---|
| User Story | Break down the problem into its smallest pieces and create user stories that represent specific tasks. Consider the business goals, user needs, and technical feasibility when prioritizing. Involve the entire team in the process. Use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, and Testable) to ensure well-formed user stories. |
| User adoption | the number of users who are actively using the platform or product. The success of any Web3 initiative is closely related to how many users can be engaged. |
| User retention: | how many users continue to use the platform (or the product) after a certain amount of time. This also allows to esteem the quality and value offered by the company, and also if the user base has no surprises. The indicator is also related to customer satisfaction and the presence of competitors. |
V
| V | Definition |
|---|---|
| vanity metrics | they don't really matter |
| validation roadmap | A validation roadmap is a strategic plan designed to assess and confirm the viability of a product, service, or idea. It's commonly used in startups and product development to ensure that a concept meets market needs and has the potential for success before significant resources are committed. It is essential for startups and product teams to systematically test assumptions, gather user insights, and ensure the product is on the right track before full-scale development or launch. Risk Mitigation: Reduces the risk of failure by ensuring that the product aligns with market expectations. Resource Efficiency: Helps allocate resources effectively by focusing on validated ideas. Informed Decision Making: Provides data-driven insights to support strategic decisions. |
| Value Stream Coordination | Value Stream Coordination defines how to manage dependencies and exploit the opportunities that exist only in the interconnections between value streams. |
| Value Stream KPIs | Value Stream Key Performance Indicators (KPIs) are the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes. |
| Value Streams | Value Streams represent the series of steps that an organization uses to implement Solutions that provide a continuous flow of value to a customer. |
| Vision | The Vision is 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. |
| Velocity |  Velocity is a measure of a team's productivity and capacity to deliver work within a given time frame, typically measured in story points or units of effort. It represents the average amount of work completed in each iteration or sprint. Velocity is used for estimating how much work can be accomplished in future sprints and for tracking the team's progress over time. It helps with predicting project timelines and managing workload. |
W
| W | Definition |
|---|---|
| Weighted Shortest Job First (WSJF) | Weighted Shortest Job First (WSJF) is 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. |