2.31.1. One Solution Delivery Life Cycle Guidance

Name

Description

Business

Business is responsible for defining the business value and acceptance of the product. They write and submit the Lean Business Case for funding approval and speak to the functional competence of the current and near-term solutions. They are actively involved throughout the development of the product as key participants in planning and reviewing the solution, eliminating impediments, and representing the customers' needs. Business is organized into four primary Business Operating Divisions (BODs): Wage & Investment (W&I), Large Business & International (LB&I), Small Business/Self Employed (SB/SE), and Tax Exempt & Government Entities (TEGE)

Contracting Officer Representative (COR)

A COR is responsible for the contract administration process and focuses on post-award administration during the procurement cycle. They contribute to the contract's overall success by ensuring the terms and conditions of the contract are fulfilled, the Department of the Treasury's mission is upheld, and taxpayer dollars are prudently spent

Executive Steering Committee (ESC)

The ESC sponsors the Governance Board(s) and provides executive approval authority over Governance Board recommendations. The responsibilities of the ESC are overseeing its portfolio and subordinate Governance Boards; resolving escalated risks and issues; approving performance baseline and baseline changes; sponsoring governance and advisory boards as needed; and delegating decisions to a Governance Board when appropriate

Facilitator

A facilitator plans and leads events, ceremonies, and meetings to ensure attendees achieve the intended purpose. They can be team members or non-team members and will differ depending on the event. The facilitator's sole focus is guiding attendees through the event. They do not participate in discussions as a team member during the meeting

Governance Board

The Governance Board provides support to the ESC for all investments, products, and initiatives within its assigned portfolio to ensure information technology (IT) investment, program, and project objectives are met; risks are managed appropriately; and the expenditure of enterprise resources is fiscally sound. The Governance Board may establish lower-level advisory boards to provide specific management studies and recommendations

Process Owner

A Process Owners is an organization or individual accountable for the management of an enterprise process. They are responsible for sponsorship, design, change management, continuous process improvement, and certifying compliance. Process Owners define the process policies and standards; ensure that the process is formally documented in a directive, IRM, or process description; define the implementation strategy; review the project's compliance with the process owner's process; and provide a written approval/disapproval

Product Sponsor

The Product Sponsor leads the initiative for the enterprise business and executive leadership who own the product. They oversee the initiative's scope and objectives to ensure alignment is maintained with organizational goals and priorities. The Product Sponsor provides and/or manages funding, strategic input, and approval throughout the evolution of the product vision; as well as the expected benefits, risks, and outcomes of the initiative. They are also responsible for removing organizational impediments that are beyond the Product Owner's purview

Product Manager

The Product Manager is responsible for managing the Product Roadmap and supporting the Product Team as needed. They communicate the state of the initiative and manage expectations from leadership and the team. The Product Manager also collaborates with the Product Owner and Product Sponsor to validate assumptions and refine strategies to achieve product Objectives and Key Results (OKRs)

Product Owner

The Product Owner manages and prioritizes the Product Backlog and Mid-range Backlog. They are responsible for defining stories and prioritizing the Iteration Backlog to streamline execution. The Product Owner has a significant role in maximizing the team's value by ensuring stories meet the user's needs and comply with the Definition of Done. They collaborate with the Product Manager, Product Sponsor and Business to validate assumptions, refine OKRs, and prioritize backlog items to achieve product goals

Resource Manager

The Resource Manager assists the Product Team with human resources planning. They determine a team's capacity to meet staffing requirements, hire new employees, and/or assign available personnel to a Product Team based on their skills and experience

Product Team

The Product Team is a cross-functional group that defines, builds, tests, and delivers a product with support from the Product Manager. The group is comprised of individuals across varying disciplines with at least one representative for all relevant skillsets required to fulfill initiative objectives as defined by the Product Owner

Scrum Master

The Scrum Master ensures that the Product Team understands and follows Agile principles while safeguarding the team from external elements. They coach and mentor the team to stay productive, remove obstacles, and develop into a self-confident, self-organizing, high-performing team. The Scrum Master typically facilitates the Iteration Planning, Daily Standup, Iteration Review, and Iteration Retrospective events, but is not responsible for the outcome of the team's work. The Scrum Master also facilitates interactions between the team and the broader organization to optimize the team's value

Stakeholder

A stakeholder is any person, organization, or business unit that has an interest or investment in the product, including the end user. They participate in developing the product vision and high-level goals. Stakeholders may also participate, in some capacity, in the funding, approvals, or other executive-level decisions of the product

Subject Matter Expert (SME

A SME is a specialist that serves in a predominantly advisory capacity. They are responsible for supporting the Product Team to meet their OKRs and goals

Acronym

Meaning

AD

Applications Development

CCB

Configuration Control Board

CII

Configuration Identification Index

CM

Configuration Management

COTS

Commercial-Off-the-Shelf

CPE

Current Production Environment

CTR

Customer Technical Review

DBMS

Database Management System

DOR

Definition of Ready

DID

Data Item Description

DOD

Definition of Done

EA

Enterprise Architecture

ELC

Enterprise Life Cycle

ESC

Executive Steering Committee

EST

Enterprise Systems Testing

EoTCR

End of Test Completion Report

FISMA

Federal Information Security Management Act

GEL

Government Equipment List

IRM

Internal Revenue Manual

IRS

Internal Revenue Service

IT

Information Technology

ITRAC

IItem Tracking Reporting and Control System

ITSM

IT Service Management

LCSR

Life Cycle Status Review

MER

Milestone Exit Review

MRR

Milestone Readiness Review

MRVR

Milestone Readiness Validation Review

MS

Milestone

OKR

Objectives and Key Result

O & M

Operations and Maintenance

OMB

Office of Management and Budget

PAL

Process Asset Library

PCLIA

Privacy and Civil Liberties Impact Assessment

PD

Process Description

PLC

Product Life Cycle

PM

Project Manager

PMP

Project Management Plan

PTP

Project Tailoring Plan

PR

Procedure

QMP

Quality Management Plan

REPO

Requirements Engineering Program Office

RFP

Request for Proposal

RIM

Records and Information Management

RM

Risk Management

RMA

Records Management Application

RMP

Risk Management Plan

RP

Requirements Plan

SAT

Systems Acceptability Testing

SDLC

Software Development Life Cycle

SBU

Sensitive But Unclassified

SIT

System Integration Test

SM

Senior Manager

SME

Subject Matter Expert

SP

Security Package

SR

Sprint Review

TIGTA

Treasury Inspector General for Tax Administration

TWA

Team Working Agreement

USI

User System Interface

UWR

Unified Work Request

WBS

Work Breakdown Structure

Term

Description

Acceptance Criteria

Acceptance Criteria “Acceptance criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system. Acceptance Criteria are a set of statements, each with a clear pass/fail result, that are applicable at the Epic, Feature, and Story Level."
Source: www.leadingagile.com

Agile Development

A set of software development principles emphasizing ongoing collaboration between the customer and the self-organizing, cross-functional delivery teams. Agile promotes early and frequent value delivery, empowerment, frequent value delivery, technical excellence, and process adaptability throughout the life-cycle of the project. There are a number of specific Agile methods and practices, such as Scrum, Extreme Programming, etc.
Source: Adapted from Agile Alliance

Agile Team

The Agile Team consists of professionals who do the work of delivering a potentially releasable, "Done" product at the end of each Sprint. Agile Teams are structured and empowered by the organization to organize and manage their own work. Only they work on the sprint backlog items producing product. The resulting synergy optimizes the Agile Teams' overall efficiency and effectiveness.
Source: Adapted from the Scrum Guide definition of Development Team
Synonym: "Federated Delivery Team" (FTD) is similar but not entirely synonymous. Development Team and Scrum Team are also synonyms of Agile Team

Backlog

An ever-evolving list of items relating to needed product functionality or actions (e.g., bug fix), prioritized by the Product Owner, that conveys to an Agile team what functionality is desired to be implemented first. Agile initiatives typically employ a top level backlog, known as a product backlog, often also a release backlog, and each Agile team working on a product typically creates a backlog for each development iteration or sprint, known as an iteration backlog or sprint backlog.
Source: Adapted from The Agile Dictionary

Burn Down Chart

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis [usually measured in story points or task hours], with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum.
Source: Wikipedia

Capacity

Total number of available hours for a sprint is called the develoment team's Capacity. Available hours is calculated based on the number of development team members, their daily work schedules, the percentage each team member is allocated to the team, and planned days off or holidays.
Source: Adapted from ProjectManagement.com

Daily Scrum

The Daily Scrum is a 15 minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, Each Development Team member reports: What did I do yesterday that helped the Development Team meet the Sprint Goal? What will I do today to help the Development Team meet the Sprint Goal? Do I see any impediments that prevent me or the Development Team from meeting the Sprint Goal?
Source: Scrum Guide

Definition of Done

The team agrees upon criteria for work to be complete. Criteria could exist for user stories, sprints, and any other items the team finds useful.
Source: Agile Alliance and Scrum Guide

Epic

Large user stories are typically referred to as epics. There's no magic threshold at which we call a particular story an epic. It just means “big user story.” Epics generally take more than one or two sprints to develop and test. They are usually broad in scope, short on details, and will commonly need to be split into multiple, smaller stories before the team can work on them.
Source: Mike Cohn - Scrum Alliance

Feature

A coherent business function or attribute of a software product or system. Features are large and usually comprise many detailed [user stories]. A single feature typically is implemented through many stories [and potentially more than one iteration]. Features may be functional or non-functional; they provide the basis for organizing stories. [Today, Agile initiatives that do make use of the term "features" place them between Epics and User stories. Simply going from Epics to users stories is common.]
Source: Adapted from SolutionsIQ

Impediment

An Impediment is anything that keeps the Team from getting work Done and that slows Velocity. Impediments come in many forms: a sick team member, a missing resource, lack of management support or even a cold team room. If it's blocking the team from doing its work, it's an Impediment. (Scrum Inc.)
Source: Scrum Inc.

Increment

There are two distinct but valid uses of the term "increment" in Agile. One definition is concerned with the state of the product at the end of a particular sprint. The other definition refers to the larger, multiple-sprint timebox that a set of coordinated teams will use to conduct regular joint inspect and adapt cycles of the total product and process across all teams. Definitions are given below for both usages: 1) The sum of all the product backlog items completed during a sprint and the value of the increments of all previous sprints. At the end of a Sprint, the new increment must be "Done", which means it must be in useable condition and meet the Scrum Team's definition of "Done." It must be in useable condition regardless of whether the Product Owner decides to actually release it. 2) A Program Increment (PI) is a timebox at the next level up (e.g., program level) from a set of coordinated teams operating on synchronized sprints. A PI timebox includes several team level sprints (e.g., 5 sprints). This increment provides an opportunity for the teams as a whole to inspect and adapt the integrated product and process across all teams in a larger timebox, synchronized with the team level sprints.
Source: Scrum Guide, Adapted from SAFe definition

Iteration

An iteration is a standard, fixed-length time box during which teams deliver incremental value in the form of working, tested software and systems. Iteration lengths may be chosen from one to four weeks, with two weeks being the suggested, and most common, duration.[Iteration is the more general Agile term for what, in Scrum, is referred to as a "Sprint"]
Source: SAFe Glossary [note "Iteration" is a general term, not specific to SAFe, but the SAFe Glossary definition is broadly applicable.
Synonym: Sprint (in Scrum)

Minimum Viable Product

A minimum viable product has just those core features sufficient to deploy the product, and no more. Developers typically deploy the product to a subset of possible customers—such as early adopters thought to be more forgiving, more likely to give feedback, and able to grasp a product vision from an early prototype or marketing information. This strategy targets avoiding building products that customers do not want and seeks to maximize information about the customer per dollar spent.
Source: Wikipedia

Pair Programming

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently [and team members may change pairings frequently to ensure knowledge sharing].
Source: Wikipedia

Product Backlog

As described in the Scrum Guide, the Product Backlog is an ordered list of everything that might be needed in the product and is the single source for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. Source: Scrum.org

Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: • Clearly expressing Product Backlog items • Ordering the items in the Product Backlog to best achieve goals and missions • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next • Ensuring the Development Team understands items in the Product Backlog to the level needed
Source: Scrum Guide

Refinement

This activity occurs on a regular basis and may be an officially scheduled meeting or an ongoing activity [or both]. Some activities that occur during refinement are: removing user stories, creating new user stories, prioritizing, estimating, and splitting user stories. The product owner and some, or all, of the rest of the team review items on the backlog to ensure the backlog contains the appropriate items, they are prioritized, and that the items at the top of the backlog are ready for [the next planning event.]
Source: Adtapted from the term Grooming as defined by the Scrum Alliance
Synonym: Grooming

Release

A delivery of software into a production environment for use by actual users.
Source: Principles and Practice

Release Backlog

A release backlog is a subset of the product backlog that is planned to be delivered in the coming release, typically a three- to six-month horizon.
Source: MountainGoatSoftware.com
Synonym: Release Plan

Scrum

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts and rules.
Source: The Scrum Guide 2016

Scrum Master

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Source: Scrum Guide

Scrum of Scrum

The Scrum of Scrum is a scaling mechanism that limits the number of communication pathways needed to transmit information relevant to the success of the enterprise. The Scrum of Scrums is analogous to the team level Daily Scrum except the Scrum of Scrums is a virtual team composed of representatives from a number of individual Scrum teams that collaborate to integrate and ship a product(s). The Scrum Masters and anyone else needed to deliver the Scrum of Scrums collaborative Definition of Done meet and communicate impediments, progress, and any cross team coordination that needs to happen by answering for the team the same three questions used in the Daily Scrum.
Source: Scrum, Inc.

Spike

Originally defined within XP, spikes are used for activities such as research, design, investigation, exploration, and prototyping. The purpose of a spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a Story estimate.
Source: Scaled Agile Inc.

Sprint

Also referred to as an Iteration. A time-boxed interval of 1-4 weeks, during which all software-development lifecycle activities -- design, coding, testing, integration, etc. - take place. The output of each Sprint is a "potentially-shippable" version of the software. The Sprint length remains constant throughout the project and does not change to fit the amount of work. During the Sprint, teams work together actively with business representatives to clarify and refine (but not change the scope of) user stories as needed, to deliver the greatest amount of value possible within the Sprint.
Source: Principles and Practice Guide Synonym: Iteration - in Scrum an iteration is referred to as a Sprint

Sprint Backlog

The Sprint Backlog is the set of Product or Release Backlog items selected for the Sprint, plus a plan for delivering the increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment.
Source: Scrum Guide

Sprint Planning

In Scrum, the sprint planning meeting is attended by the Product Owner, Scrum Master and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies. During the sprint planning meeting, the product owner describes the highest priority [user stories] to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog. There are two defined artifacts that result from a sprint planning meeting: 1. A sprint goal 2. A sprint backlog A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated. An important point to reiterate here is that it's the team that selects how much work they can do in the coming sprint.
Source: Mike Cohn

Sprint Retrospective

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. It is an opportunity for the Scrum Team to inspect itself (people, relationship, process, and tools) and create a plan for improvements to be enacted during the next Sprint.
Source: Scrum Guide

Sprint Review

The Sprint Review occurs at the end of the Sprint. The purpose of the review is to demonstrate the working software to end users and other stakeholders to gain feedback. It also provides a defined closure event for the Sprint. The team also reviews work items that were completed, created, deferred, or not completed during the Sprint. The Sprint Goal is reviewed to ensure it was effectively met, and the project discusses what to plan for the next Sprint.
Source: Principles and Practice and ELC lexicon

Story Points

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points. Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers. Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include: The amount of work to do The complexity of the work Any risk or uncertainty in doing the work
Source: Mike Cohn

Task

In Scrum and Extreme Programming, a unit of work, estimated in hours. During the iteration planning meeting, user stories are decomposed into tasks. In his book, Agile Software Development with Scrum, Ken Schwaber writes, “Tasks should have enough detail so that each task takes roughly four to sixteen hours to finish.”
Source: The Agile Dictionary

Technical Debt

"Technical debt (also known as design or code debt) is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution."
Source: Ward Cunningham 1992, the original reference to "Technical Debt"

Test Driven Development

A software development process that relies on the repetition of a very short development cycle: user stories are turned into very specific test cases, the the software is updated to pass those new tests only. This is as opposed to software development that allows software to be added that is not proven to meet requested functionality. [includes writing the test case before the code is developed.
Source: Wikipedia

Theme

Themes may be thought of as groups of related stories. Often the stories all contribute to a common goal or are related in some obvious way, such as all focusing on a single customer. However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific work flow or be delivered together.
Source: Jeremy Jarrell - Scrum Alliance

Time-box

A previously agreed period of time during which a person or a team works steadily towards completion of a goal. Rather than allow work to continue until the goal is reached, and evaluating the time taken, the time-box approach consists of stopping work when the time limit is reached and evaluating what was accomplished. The most common usage is for Sprint length, but this technique can be useful for research, discussion, and many other activities.
Source: Agile Alliance

User Story

User stories are short, simple descriptions of a [need] told from the perspective of the person who desires the new [functionality], usually a user or customer of the system. They typically follow a simple template: As a ‘type of user’, I want ‘some goal’ so that ‘some reason. ...they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written. (Mike Cohn) Stories aren't a way to write better requirements, but a way to organize and have better conversations (Jeff Patton, from Story Mapping) Example: “as an online taxpayer, I want to create an online account so I can see my balance.”;
Source: Mike Cohn and Jeff Patton

Velocity

The average number of Story Points the team can finish in a time-boxed period. A team's average velocity is typically established after a few sprints, and can be useful for planning future sprints.
Source: Agile Training Using CLM