Glossary

The roles, activities, and artifacts associated with the work and objectives of an individual Agile Team. (For examples, see Scrum Master, Product Owner, sprint backlog, product backlog, and PSI.) Also known as Product Level.

The completed, verified, and usable deliverable from a process, milestone, or ceremony. For example, an artifact of sprint planning is a sprint backlog and the artifact of a sprint is a PSI.

See Meetings.

In scaled agile, a capability is a high-level solution behavior that typically spans multiple release trains. They are sized and split as necessary to fit into a program increment and concepts relevant to the value stream level or portfolio level.

A group of people with a common interest in a specific technical, business, or process domain. They collaborate regularly to share information, assist each other in improving skills and performance, and advance general knowledge of the domain.

Note: In a traditional, functionally organized management structure, these individuals would likely report to a common manager (e.g., business analysts under one manager, developers under another, testers under yet another). However, Agile organizes people into long-lived, cross-functional teams, and CoPs provide the forum for sharing best practices and common concerns and developing a common culture.

A story or task that represents the work of developing or stabilizing architecture, infrastructure, process improvements, or compliance with constraints. An enabler does not necessarily provide demonstrable value to an end user; however, they are often traceable to business requirements (e.g., reliability, configurability, improved quality, faster delivery).

In the context of scaled agile, a business capability can be broken down into its functional features and feature-level enablers on a program backlog; and a feature and be broken down into user stories and story-level enablers on a product backlog. Enablers should be demo'd in sprint reviews or PI demos.

See also Non-functional Requirements.

Well-defined, high-level business or architectural solution behaviors that can be accomplished with transient (bounded) activities. In scaled agile, a feature would be broken down into user stories (or story-level enablers). Whereas user stories must be scoped to fit into a sprint, a feature must be scoped to fit within a single program increment. Features that are not functionally complete at the end of an iteration should toggled so as to not disrupt demonstrable functionality. For comparison, see non-functional requirements.

See requirements.

Constraints on all features. The NFR itself can result in an enabler feature to help functional features achieve compliance. For example, an NFR that asserts that "all PII must be encrypted according to the FIPS 140-2 standard" may result in an enabler to "Stand up and configure Vormetric Data Security Manager for all application data storage." Or, an NFR that asserts "all new commits of legacy code must be accompanied by automated unit tests" may require an enabler to "create common set-up and tear-down frameworks in jUnit".

NFRs should be included in the acceptance criteria in the various definitions of value (solutions, capabilities, features, and user stories). And NFR testing should be done continuously and built in to the automated testing process.

A portfolio is a collection of assets (a fixed set of resources, maintenance and operations responsibilities, unrelated programs, and/or unrelated projects that are not in a program). Portfolios can exist at various levels in the organization depending on the boundaries for sharing a common set of resources. Project portfolios manage projects that must share a common set of staff but not necessarily strategic or functional goals. Program portfolios similarly optimize the utilization of shared resources across unrelated programs. In an agile enterprise, portfolios may contain multiple value streams (as opposed to traditional projects and programs).

Tool to help a meeting stay focused on its purpose. Any idea or issue that arises that is outside of the purpose of the meeting can be placed on the parking lot, and the parking lot must be reviewed at the end of the meeting. Anything not addressed becomes an action item.

The roles, activities, and artifacts associated with the work and objectives of an individual portfolio. (For examples, see Portfolio Manager, Enterprise Architect, Value Streams.) (See also Scaling Agile.)

See backlog, above.

A unit of work small enough to be completed by a team in one Sprint iteration. These are usually written as user stories (i.e., statements of the business value needed) or Backlog items are decomposed into one or more tasks.

The Chief Product Owner and the Product Owners within a common program (release train).

See Chief Product Owner.

See Product Owner.

A program is a network of projects and other longer-lived components to deliver benefits that can only be achieved collectively. Programs tend to have longer time frames than projects (e.g., years); the goals are typically strategic; and the work of program-level management is in coordinating project interdependencies and monitoring milestones. Once the aims of the program are realized, the program is done.

An agile implementation of a program requires a scaled agile framework in order to coordinate multiple agile teams for common delivery goals.

See backlog, above.

The roles, activities, and artifacts associated with the work and objectives of an individual program. (For examples, see release train, program backlog, program increment, Chief Product Owner.) (See also "Scaling Agile".)

See Master Scrum Master.

A project is a temporary endeavor to deliver a unique item of value (e.g., product, service, or other result). Once the goal of the project is accomplished, the project is done and the project team is disbanded. Project goals are typically functional, and progress is monitored at the task level.

Delivery of valuable, working, verified solution increments to the end user. In single-team Scrum, a release can occur when no work is left undone at the end of a sprint (i.e., the "potentially shippable product increments" have combined to create a usable product increment). In program-level agile (scaled to coordinate multiple teams and/or products), a release can align with a program increment. However, releases do not have to be time-based (i.e., aligned with the completion of usable increments). As long as the integrated solution is maintained separately from the ongoing development, it can be released at any point.

(1) A software development planning and execution method in which a series of distinct program increments, covering multiple products, are released according to a roadmap schedule.

(2) A program-level organization of coordinated agile teams that use a common vision and single program backlog to plan, commit, execute, and demonstrate value together. Like sprints in individual agile teams, the cadence of a release train is a fixed interval--typically, five or six sprints (e.g., 10 weeks for 5 two-week sprints).

Requirements in agile are defined at a high level (not detailed) in terms of epics or stories and live on the backlog. Note that “value delivery” need not be defined in terms of features fully implemented in production. For example, value can be delivered to a testing environment or staging environment.

See also non-functional requirements.

A story or task aimed at answering a question or gathering information, rather than at producing shippable product. A spike may be needed if a team is having trouble estimating a story, if a certain area of work is consistently late or poor quality, or if there is a roadblock or creeping technical issue that is preventing the team from being effective.

Whether or not a spike should be given story points and accounted for in the velocity is a hotly debated question. However your team chooses to handle this, spikes should be well-defined and short and have as the output the ability to estimate and proceed with the downstream story.

The set of product backlog items selected for the sprint plus a plan (e.g., tasks) needed to deliver the product increment and realize the sprint goal. The sprint backlog is a forecast by the agile team about what value will be in the next increment and the work needed to deliver that value.

An increment of value to be implemented in a sprint. Stories can be functional or non-functional. Functional stories (also known as "user stories") are written in the following language: As a <role>, I want to <do action> so that I can <state value proposition>. Non-functional stories (sometimes referred to as "enabler stories") provide the foundation for improved technology or process. Examples of non-functional stories include pieces of holistic architecture or design work, system upgrades, and toolset or runway technology build-outs.

Every story must have a clear definition of done and be sufficiently limited in scope to be doable within a single sprint. When groomed on the product backlog, every story is first prioritized and eventually given a relative sizing. Multiple stories (functional and non-functional) may combine to deliver an epic.

An relative, abstract measure which allows a group to separate size from duration. Over time, a stable group will achieve enough consistency to enable prediction and valuable planning of backlog items. See Estimating for relative sizing techniques.

All of the activities required to transform a customer request into a usable capability, good, or service. A value stream contains the people who do the work, the systems they develop or operate, and the flow of information and materials. For some organizations, their value streams are easy to identify: they are products, services, or solutions that they develop or sell. As the enterprise gets larger, value streams can be more complicated.

In SAFe, value streams deliver solutions realized by one or more release trains. The budget and strategic themes at the portfolio level govern the logic of the solution.

Velocity is a metric used to predict how much work an agile team can successfully complete in a time-boxed iteration. (See also capacity planning and cadence.) It is not a measure of productivity but of value throughput. Velocity turns story points into duration by allowing you to calculate how many sprints a set of backlog items should take to deliver.

Explicit team agreements on roles, meeting rules, and little things that, left unaddressed, would sow the seeds of dysfunction. In particular, working agreements helps keep the Daily Stand-Up focused and productive.