Part 2. Information Technology

Chapter 31. Lifecycle Management

Section 1. One Solution Delivery Life Cycle Guidance

2.31.1 One Solution Delivery Life Cycle Guidance

Manual Transmittal

January 23, 2023

Purpose

(1) This transmits new IRM 2.31.1, One Solution Delivery Life Cycle (OneSDLC) Guidance.

Background

This document establishes One Solution Delivery Life Cycle (OneSDLC) as a single delivery model for IT projects within the IRS and will supersede IRM 2.16.1, Enterprise Life Cycle (ELC), ELC Guidance.

For the initial period of at least one year, in conjunction with this IRM, "Supplement to Internal Revenue Manual (IRM) 2.31.1" artifact will be used as reference by all OneSDLC Stakeholders

Material Changes

(1) This is a new IRM to provide guidance for OneSDLC which is a single delivery model for IT projects.

Effect on Other Documents

This guidance provided by this IRM will effectively replace the existing guidance provided by IRM 2.16.1 for Enterprise Life Cycle for IT projects.

Audience

This IRM applies to IRS managers, personnel, and executives who manage, directly support, or provide oversight to projects that effect business change. This IRM also applies to contractors who conduct projects on behalf of the IRS that effect business change.

Effective Date

(01-23-2023)


Nancy Sieger
Chief Information Officer

2.31.1.1 (01-23-2023)

Program Scope and Objectives

  1. One Solution Delivery Life Cycle (OneSDLC) provides a product, software and service delivery model to support organizational transformation priorities focused on process improvement and efficiencies and streamlining communications.

  2. The purpose of this initiative is to support organization transformation priorities and agility. OneSDLC transforms IT practices and optimize delivery of IT systems and applications at the IRS using Agile and Lean practices. IT product delivery is modernized through a single software development life cycle approach and delivery model. OneSDLC optimizes product, software and service delivery and reduces lead and cycle time through agile and lean processes and practices and is governed by tool-based content. The focus is on enterprise level transformation and driving efforts that will enable that transformation.

  3. OneSDLC enables an enterprise transformation through organizational and cultural change and upskilling of the existing workforce through:

    • agile mentoring

    • coaching and guidance

    • training, tools

    • visualization and ad hoc project support and

    • agile organizational transformation/change strategies

  4. The audience for this initiative information is those involved with transformation priorities, organization agility, systems and software development, oversight, budget, or financial management. The Associate Chief Information Officer (ACIO) for Strategy and Planning has the overall responsibility for this program.

  5. The IRS’s Chief Information Officer (CIO) is the program owner.

  6. The primary stakeholders are all ACIO areas within IRS IT organization and IRS business units

  7. The goal of this program is to support overall organizational transformation priorities and agility.

2.31.1.1.1 (01-23-2023)

Background

  1. Z20RM001 is the Fund Program for OneSDLC under the budget activity, "Operational Support" and "Functional Area 9Z". This budget activity is funded by appropriation fund 9Z-ZZ227-001. This initiative was sponsored by the Requirements Engineering Program Office (REPO) which also manages the Agile Central Team

2.31.1.1.2 (01-23-2023)

Authority

  1. This Strategy and Planning program is funded via the appropriation fund, “Operations Support (0919)”, which is for necessary expenses of the Internal Revenue Service to operate and support taxpayer services and tax law enforcement programs.

2.31.1.1.3 (01-23-2023)

Responsibilities

  1. The Chief Information Officer ultimately is responsible for this program.

2.31.1.1.4 (01-23-2023)

Program Management and Review

  1. Operational reports are used to provide information regarding the reporting of this initiative’s objectives.

  2. Performance plans are used to determine how the initiative’s goals are measured.

2.31.1.1.5 (01-23-2023)

Program Controls

  1. This program uses the IRS Internal Management Documents System to establish controls. This IRM section constitutes one of the controls. OneSDLC also established governances and compliance within the delivery model.

2.31.1.1.6 (01-23-2023)

Terms/Definitions/Acronyms

  1. This program has specific terms and acronyms associated with it. Definitions for these terms and acronyms follow.

  2. Defined Terms

    Word Definition
    Appropriation A law enacted by Congress that authorizes Government agencies to incur obligations, and the Treasury to make payments for designated purposes.
    Budget Activity A subdivision of an appropriation identified in the formal request to Congress.
    Budget Activity Code A code that identifies a budget activity.
    Functional Area

    • A detailed program, which constitutes a specific phase or segment of IRS operations.

    • A grouping of related work operations that constitutes a specific phase or portion of an overall work program.
    Operation Continual work managed to serve a function or mission.
    Program

    • An operation that constitutes a functional area.

    • An operation that is managed via a designated organizational unit and may involve managing related projects

    • An operation managed according to a published plan, approach, method, standard, or discipline for program management.
     

    Acronyms

    Acronym Definition
    BAC Budget Activity Code
     

2.31.1.1.7 (01-23-2023)

Related Resources

  1. IRS Document 12353, Financial Management (Revision 4-2016) (Catalog Number 48241J) is a resource for information about this program.

  2. This IRM was created to reflects stable content within OneSDLC Delivery Model primarily focused on AGILE DELIVERY. While compliance is essential and in most cases inherently built into the model, it may not be explicitly stated as such. OneSDLC and it's associated IRM is not prescriptive. Therefore IRM 2.31.1 will be supplemented by Internal Revenue Service Document (IRSD) or its equivalent (IRM Supplement, SOP, Job Aid, Software or Application Specific Document, Training Document, ...) to reflects the details and evolution of the delivery model into the near future as new and existing projects are onboarded Agile Central team briefed TIGTA team on the OneSDLC Delivery Model and provided them with the draft of IRM 2.31.1 for review and feedback. TIGTA has been positive and supportive in their initial feedback of the delivery model and the draft IRM and understand the evolutionary nature to model development and maturity.

    Supplement to IRM 2.31.1

2.31.1.2 (01-23-2023)

Overview

  1. One Solution Delivery Life Cycle (OneSDLC) is an IRS tailored, flexible delivery model developed by Agile Central that enables and encourages initiatives slated for OneSDLC delivery to deliver value-based outcomes early and often. The model provides guardrails for quality, compliance, and executive oversight, while empowering teams to find the best solution. Additionally, Agile Central provides products and services to support projects in utilizing OneSDLC.

2.31.1.2.1 (01-23-2023)

Agile Central

  1. Agile Central maintains and supports this IRM. Agile Central Team is managed by the Requirements Engineering Program Office (REPO). The e-mail address for this team is *IT.Agile Central (*it.agile.central@irs.gov)

2.31.1.2.1.1 (01-23-2023)
Agile Central Mission

  1. The mission of Agile Central is to:

    • Support the coordination, integration, and progression of efforts to enable an efficient and effective IRS transformation by optimizing IT product delivery;

    • Enable Organizational Change, to move towards a whole team, product-based structure;

    • Transition to a model that enables frequent small batch delivery;

    • Assist the IRS to implement their strategic vision for OneSDLC that includes cultural and organizational change that will enable an Agile Transformation;

    • Define, develop, and institutionalize a proven set of best practices for managing change in the IRS business processes and systems.;

    • Integrate and standardize process management activities to improve consistency; and

    • Provide leadership, consultation, and assistance to ensure understanding and effective use of OneSDLC by all impacted stakeholders.

2.31.1.2.1.2 (01-23-2023)
Agile Central Purpose

  1. The purpose of Agile Central is to provide organizational transformation and change expertise and support to develop and implement a strategy to influence continual organizational, cultural, and IT change that will optimize IT product delivery. This support will build upon the OneSDLC approach being implemented by Agile Central to simplify product development by enabling delivery in small increments that satisfies governance through transparent tool-based content in the IRS enterprise standard delivery tools.

2.31.1.2.1.3 (01-23-2023)
Agile Central Objective

  1. The objectives of Agile Central are to:

    • Standardize the approach for managing, governing, and supporting projects following the OneSDLC throughout the IRS;

    • Improve the probability of successfully achieving desired change within scope and delivering value and impact;

    • Thought leadership in Agile transformation to continuously develop emergent Agile training and guidance to include agile frameworks, implementation methods, and scaling frameworks;

    • Provide agile mentoring, coaching, guidance, training, tools, visualization and ad hoc project support, and Agile organizational transformation/change strategies; and

    • Help ensure project success by reducing risk and ensuring compliance with applicable internal and external standards and mandates.

2.31.1.2.2 (01-23-2023)

OneSDLC Delivery Model

  1. The OneSDLC delivery model consists of three states:

    • Allocation - A lean funding state that distributes funds toward prioritized needs for chosen strategic themes.

    • Readiness - A one-time preparation state that gets new teams ready to execute funded work, as soon as possible.

    • Execution - A continuous delivery state that empowers teams to ‘Plan, Perform, Produce’ by building, testing, and delivering solutions through ongoing learning.

    Figure 2.31.1-1

    This is an Image: 93036001.gif

2.31.1.2.2.1 (01-23-2023)
Allocation State

  1. The Allocation State provides transparency around the various IRS investment types that are available to secure funds for IT related demand. The IRS mission and enterprise strategic goals drive the selection and funding of IT related demand. Additionally, enterprise investments are commonly driven by legislation, modernization efforts, desired business capabilities, and operational/infrastructural needs. In the OneSDLC model, currently the Allocation State is informational only.

2.31.1.2.2.2 (01-23-2023)
Readiness State

  1. The Readiness State is a one-time sequence of activities and events that allows new initiatives to transition from planning to execution in a quick and efficient manner. Once an initiative is approved and funded during the Allocation State, the Proposal Owner is informed and a Product Manager is assigned. During readiness teams engage Process owners to ensure specific IT organizational processes are completed for a successful Readiness Exit Review and Transition to Execution State.

2.31.1.2.2.3 (01-23-2023)
Execution State

  1. The Execution State supports the development of new work, improvements, and maintenance for the life of the product. For new Agile Delivery, the Execution State starts after exiting the one-time Readiness State. For existing products, it will come after the Allocation State. The Product Team executes a sequence of activities where they continuously refine, develop, and deliver the work in the backlog with the potential to ’Release on Demand’ in the future.

2.31.1.2.3 (01-23-2023)

Products

  1. In addition to this IRM, the Agile Central provides resources in support of the OneSDLC delivery model to include the following:

    • Comprehensive delivery model

    • Tips, techniques, and training

    • Integrated compliance by OneSDLC states

    • Standardized Governance Framework

2.31.1.2.3.1 (01-23-2023)
Comprehensive Delivery Model

  1. OneSDLC is a delivery model that positions our IT assets to respond to emergent needs as quickly as possible without impacting productivity, product quality, security, and/or employee morale. OneSDLC is designed to meet teams where they are while encouraging agility with appropriate guardrails for quality, compliance, and executive oversight while empowering teams to find the best solution.

2.31.1.2.3.2 (01-23-2023)
Tips Techniques and Training

  1. A comprehensive collection of Tips, techniques and training are provided by Agile Central in support of OneSDLC

2.31.1.2.3.3 (01-23-2023)
Integrated Compliance by OneSDLC States

  1. OneSDLC delivery model is interactive, and compliance is integrated within the model to ensure project compliance through Readiness and Execution States.

2.31.1.2.3.4 (01-23-2023)
Standardized Governance Framework

  1. OneSDLC has an integrated governance process that empowers teams to deliver frequent small inrements. Compliance Artifacts for OneSDLC are available to assist projects through Readiness and Execution States to meet governance and compliance.

    Note:

    Details regarding IT Governance and how it is integrated within OneSDLC can be found here.

2.31.1.2.4 (01-23-2023)

Services

  1. Agile Central Team provides services in support of OneSDLC as follows:

    • Onboarding projects

    • Coaching

    • Training

2.31.1.2.4.1 (01-23-2023)
Onboarding Projects

  1. When starting the project engagement, OneSDLC Point of Contact and OneSDLC Representative from the Agile Central Team are identified and assigned to the project.

  2. To get a project to start adopting OneSDLC, familiarize stakeholders with what they need to do, what they can get from the OneSDLC delivery model, how to navigate the model.

  3. These are the steps Agile Central will take:


  4. Step 1. Provide OneSDLC Overview (link)
    Step 2. Provide OneSDLC Onboarding Deck (link)
    Step 2a. OneSDLC Team Preparation (viewing and reading) – purpose is for the team to “self-educate”

    • View video: Introduction to OneSDLC

    • View Video: Three States of OneSDLC

    • View video: The Five Pillars

    • View Video: Why OneSDLC

    • Review Readiness State SharePoint pages (Optional)

    • Review Execution State SharePoint pages (Optional)


    Step 3. The OneSDLC Representative together with the project manager does the project placement to determine where the project starts in OneSDLC (i.e., Readiness, Execution - Agile Delivery, Execution – frequent delivery) The purpose is to understand where the project is placed and how they should transition to the OneSDLC delivery model and get a formal commitment from the project.
    Step 3a.OneSDLC Placement Flow - for project placement in the OneSDLC model
    Step 3b. Sign OneSDLC Onboarding Agreement (link)
    Step 4. Exploration and discovery on the current project to understand current process(es) to identify strengths, challenges and potential improvements - purpose is to trigger improvement by developing a shared understanding.
    Step 4a. Coaching Questionnaire

    • Identify training needs

    • Identify strengths, opportunities, and areas of improvements

    • Align on next steps


    Step 4b. Review and analyze ELC documentation
    Step 4c. Compare project’s ELC PTP to OneSDLC compliance structure
    Step 5. Create OneSDLC exploration outbrief deck
    Step 6. OneSDLC introduction (meeting)
    Step 6a. Present OneSDLC exploration outbrief to the project team
    Step 6b. Formally transition project from ELC to OneSDLC.
    Step 7. Agile Central will give the OneSDLC Familiarization Training
    Step 8. (optional) Education/training:
    Step 8a. Any other training as identified in step 4 (i.e., SM, PO, CAT (Core Agile Training), Kanban, MRP (Mid-range Planning))

    Figure 2.31.1-2

    This is an Image: 93036002.gif
2.31.1.2.4.2 (01-23-2023)
Coaching

  1. The Agile Central Office provides guidance to initiatives/projects throughout the IRS on the implementation of OneSDLC delivery model to simplify product development by enabling delivery in small increments that satisfies governance through transparent tool-based content in the IRS enterprise standard delivery tools. OneSDLC coaching does not include creating or updating work products for projects, with the exception of any OneSDLC owned artifacts. The Agile Central Office offers the following support:

    • Help select delivery model and tailor it as appropriate.

    • Provide guidance in development of the project’s ‘About Page’

    • Assist during Readiness Exit Reviews, Product Review and other interim reviews.

    • Provide consulting services as needed (Tiered Service Level)

    • Provide web access to assets, tools, standards, guidelines, templates, and training

    • Answer questions related to the OneSDLC

    • Provide OneSDLC guidance and tools for project planning & tailoring (e.g., (Coaching Questionnaire, Onboarding Toolkit)

2.31.1.2.4.3 (01-23-2023)
Training

  1. The Training Roadmap at Agile Central in support of OneSDLC is as follows:

    Figure 2.31.1-3

    This is an Image: 93036003.gif
    The three levels of training provided by Agile Central in support of OneSDLC are as follows:

    • Fundamental

    • Role-Based

    • Skill Based

2.31.1.3 (01-23-2023)

OneSDLC Delivery Approach

  1. OneSDLC supports all development paths within the IRS such as Waterfall, Planned Maintenance, COTS, Managed Services, Iterative, Agile, etc. The Execution State supports three delivery cycles which enable products to easily increase their delivery cadence (deliver more often).

2.31.1.3.1 (01-23-2023)

Agile Delivery Approach

  1. Execute in two Week Cycles. Appropriate for efforts seeking to deliver often (daily/weekly) and existing efforts already utilizing Agile methods at the Iteration level.

    Figure 2.31.1-4

    This is an Image: 93036004.gif

2.31.1.3.2 (01-23-2023)

Frequent Delivery Approach

  1. Execute in two Month Cycles. Appropriate for initiatives with an unpredictable delivery schedule to strategically align every 6 months and connect every 12 weeks on cross-organizational alignment and tactical transparency on planned UWRs and emerging, unplanned request from congress. These initiatives are striving to deliver more frequently but are not ready or it is not appropriate for them to deliver at the iteration level.

    Figure 2.31.1-5

    This is an Image: 93036005.gif

2.31.1.3.3 (01-23-2023)

Semi-annual Delivery Approach

  1. Execute in six-month cycles. Appropriate for stable maintenance initiatives with a predictable schedule to strategically align every 6 months. These are efforts that are utilizing a waterfall approach and are not ready to change their delivery cadence or approach. These initiatives will also be enabled to deliver more frequently and Frequent Delivery path if and when they are ready.

    Figure 2.31.1-6

    This is an Image: 93036006.gif

2.31.1.4 (01-23-2023)

OneSDLC Compliance and Governance

  1. Governance is a process of putting structure around how IRS aligns IT strategy with business strategy, ensuring that it stays on track to achieve their strategies and goals, and implementing best practices to measure IT performance. It makes sure that stakeholders’ interests are considered and that processes provide measurable results.

  2. OneSDLC has an integrated governance process that empowers teams to deliver frequent small increments.

  3. OneSDLC has formal compliance and governance signoffs done at only two points - at the Readiness Exit Review and at the Product Review. New initiatives will complete compliance documentation in Readiness Exit Review and Product Review for Agile projects. Compliance documents will be signed before entering the Readiness Exit Review. At the Readiness Exit Review the projects will present their roadmap and get Governance Board approval to start executing. Once a new initiative exits the Readiness State, they will not return to it. Governance and compliance will continually occur in the Execution State. The reduction of governance and compliance to just two reviews initially for the first cycle and then just one review in execution reduces the amount of time producing compliance documentation.

    Figure 2.31.1-7

    This is an Image: 93036007.gif

2.31.1.4.1 (01-23-2023)

Readiness Exit Review

  1. Within OneSDLC, the Readiness Exit Review event signifies the end of the Readiness State. The goal of the event is to create awareness and answer any questions or concerns about the initiative before it enters the Execution State. OneSDLC will reduce the Compliance and Governance burden by increasing the quality and consistency of these checkpoints by:

    • Building upon the success ELC has had with the bundled review process.

    • Two formal review points at the Readiness Exit Review and Product Review for all project types.

    • Ensuring the right level of data is being reviewed at the right point.

    • Continually working with Process Owners to modernize compliance to reduce the burden on them and the projects.

  2. The high level steps are:

    • Teams complete compliance documentation.

    • Compliance documents are signed before Readiness Exit Review.

    • At the Readiness Exit Review the team gets Governance Board approval to start executing.

    • Once a new Initiative exits the Readiness State, they will not return to it.

    • Governance and Compliance will continually occur in the Execution State.

  3. All artifacts for new initiatives must be approved by the appropriate Governance Body before they can begin the Execution State. Compliance documents will be signed before entering the Readiness Exit Review. At the Readiness Exit Review (designated in blue with diagonal stripes below) the Product Team will present their plan, hypotheses, goals, and roadmap to get appropriate Governance Body approval to start executing.

  4. Once a new initiative exits the Readiness State, they will not return to it and Governance and Compliance will continually occur in the Execution State.

2.31.1.4.2 (01-23-2023)

Execution State Compliance Review

  1. The Process Owners review and approve compliance artifacts at the Product Review event which occurs every 6 months. The integrated governance process enables teams to release more frequently because most compliance documents only need to go through the signature process every 6 months. During each Iteration Cycle and Mid-range cycle teams are expected to update the compliance artifacts, encouraging Process Owners to check for updates as they are being made. The release process, over the course of one year, allows a Product Team to deploy to production without having to complete all artifacts or conduct reviews for every deployment.

  2. Prior to any deployment, whether it is at the Mid-range or the Iteration, Security, 508, Privacy, and the COH will be updated and signed by the respective Process Owners. Additionally, the Authorizing Official will sign off on the release. If a deployment is planned for the Mid-range or the Iteration, the Authorizing Official (AO) or equivalent Executive will be invited to the Mid-range or Iteration Review so they know what capabilities will be deployed. The rest of the ELC compliance documents will be updated throughout the Product Cycle (six months) and reviewed and signed by the end of the six-month Product Cycle.

    Figure 2.31.1-8

    This is an Image: 93036008.gif

2.31.1.4.3 (01-23-2023)

Product Cycle Compliance Process

  1. The Product Cycle Compliance Process is where Process Owners review and approve Compliance Artifacts prior to the Product Review event - which occurs every six months. The Product Cycle Compliance Process enables teams to release more frequently. During each Iteration Cycle, teams are expected to update the compliance artifacts, encouraging Process Owners to check for updates as they are being made. The compliance process, over the course of six months, allows a Product Team to deploy to production without having to complete all artifacts or conduct reviews for every deployment.

  2. All artifacts must be approved by the appropriate governance board before they can begin. The compliance process, over the course of six months, allows a Product Team to deploy to production without having to complete all artifacts or conduct reviews for every deployment.

  3. During the Product Review, the product team demonstrates the working solutions they want the executive to approve. The executives decide which solutions proceed to production and which do not. These decisions must be documented. At the end of the six months, a Product Review event is conducted to approve and sign off the remaining artifacts.

  4. Governance and Compliance will continually occur in the Execution State.

    Approval/Awareness Points State Activities Compliance
    Every six months the appropriate Governance Body approves the Product Plan (release), which consists of the high-level prioritized epics the initiative plans to work in that six-month period. They also validate the need for any additional funds or changes in schedule Execution Product Planning  
    Appropriate Governance Body acknowledge all necessary compliance documentation are up to date. Execution Product Review Product Review Checklist
    Deployment Authorizing Official (DAO) or equivalent Executive invited for awareness to the Mid-range or Iteration Review what the team plans to deploy during the Mid-range and iteration cycle(s) Execution Iteration/Mid-range  
    After the PO decided to deploy functionality, the DAO or equivalent Executive approves production release on go/no-go. Execution Production Release Execution Prior to Production Checklist
2.31.1.4.4 (01-23-2023)

OneSDLC Product Cycle Compliance Process

    • Every six months at Product Planning, the Governance Board approves the Product Plan.

    • The plan consists of high-level prioritized Epics the project plans to work on over that six-month period.

    • The project also validates the need for any additional funds or changes in schedule.

    • Governance Board approves the delegation of the decision to deploy to production for Product Cycle period to the Deployment Authorizing Official (DAO).

    • Deployment Authorizing Official (DAO) or equivalent Executive invited for awareness to the Mid-range or Iteration Review what the team plans to deploy during the Mid-range and iteration cycle(s)

    • Prior to any deployment before the six-month Product Cycle, the following artifacts must be signed by the official process owner approver:

    • - Security Package (Security Impact Assessment (SIA), Penetration Testing & Code Analysis (PTCA) scan, Security Change Request (Sec CR) as required by CyberSecurity)

    • - Privacy Package/Privacy and Civil Liberties Impact Assessment (PCLIA)

    • - 508 Accessibility and Mitigation Package

    • - Computer Operator Handbook (COH)

    • Upon verification of signature on the above artifacts, the DAO or their designated official will make a go/no-go decision on approval of deployment to production.

    • The rest of the compliance documents will be updated throughout the Product Cycle (six months) and progress is captured in the Execution Memorandum. After all compliance documents are up to date the Execution Memorandum is signed by OneSDLC Rep. The signed Execution Memorandum is acknowledged during Product Review by the appropriate Governance Body.

2.31.1.4.5 (01-23-2023)

Compliance Artifacts

  1. All artifacts for new projects must be approved by the appropriate Governance Board before they can begin Execution. Compliance documents will be signed before entering the Readiness Exit Review. At the Readiness Exit Review the projects will present their roadmap and get Governance Board approval to start executing.

  2. Readiness Exit Artifacts must be completed to support the initiative's Minimum Viable Product (MVP).

  3. These set of artifacts are initiated in the Readiness State. For future iterations in the Execution State, appropriate artifacts will be updated based on new insights/product enhancements.

Exhibit 2.31.1-1

Roles

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
Exhibit 2.31.1-2

Acronyms

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
   
Exhibit 2.31.1-3

Definitions (Agile Terms)

Lists terminology commonly used in Agile and Scrum practices.

If you have a term that is not listed here, please email it.agile.central@irs.gov

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