Software Acquisition

AAF  >  Software Acquisition  >  Active User Engagement  >  User Agreement

User Agreement (UA)

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

 

 

Reference Source: DODI 5000.87 Glossary

 

User Agreement: A commitment between the sponsor and PM for continuous user involvement and assigned decision making authority in the development and delivery of software capability releases.

 

Reference Source: DODI 5000.87 Section 3.2

 

Frequent user engagements are critical to the success of modern software development to ensure delivered software capabilities address their priority needs.

  • The sponsor and PM will develop a UA before the execution phase to gain commitment to continuous user involvement and assign decision-making authority for the development and delivery of software capability releases. Decisions include defining and prioritizing required capabilities, tradeoffs of software features and cadence, user acceptances, and readiness for operational deployment.
  • The UA will commit proper resourcing of operational user involvement to provide acquirers, developers, and testers insights into the operational environment, provide feedback on interim and fielded software, support test and evaluation, and shape future requirement details (e.g., user stories and features).

“While we initially did not have continuity in user participation, we worked with them to assign specific representatives to support. This facilitated a new, habitual relationship that enabled continuity of planning and increased predictability.”

Integrated Air and Missile Defense (IAMD), an 873 Agile Pilot Program

User Agreement Guidance

Reference Source: USD(A&S) Guidance

Agile software methodologies require users to make a commitment to the program to enable successful execution.  Effective software acquisition requires engagement with users to understand their concepts of operations, environment, existing capabilities, external systems with which the required capability must interface, interoperability requirements, threats, and other specific needs. This may require additional and/or separate funding to ensure users have the resources to support as needed.

Agile software acquisition also requires decentralized decision-making authority to meet delivery timelines.  This requires alignment of roles and responsibilities by the sponsor, project/product team, and user communities. The specifics of these commitments should be captured in a User Agreement (UA) signed by all relevant stakeholders before a software program enters the execution phase.  The UA is developed and signed by the Operational Sponsor and the Program Manager with input from other key stakeholders to:

  • Ensure developments address user priority needs
  • Support active collaboration between the operational users, acquisition community and software development teams.
  • Support the role of an empowered Product Owner to shape and prioritize requirements.
  • Establish roles and responsibilities for the key stakeholders to achieve these objectives
  • Ensure sponsor, users, and stakeholder inputs are captured and integrated into Value Assessments

More specifically, the UA ensures each user community is properly represented and engaged throughout software development and delivery. It defines responsibilities and expectations for:

Finally, the UA includes specific user engagement events and activities to ensure:

  • All user communities are identified, represented, and engaged.
  • Users have a shared understanding of the product, service, or problem.
  • Developers understand the operational environment from a users’ perspective.
  • Approaches to engaging each user community are clearly elaborated.
  • Users have clear expectations about when and how to engage with the program.

Roles and Responsibilities

Reference Source: USD(A&S) Guidance

The program commits to working closely with user communities, who will in turn commit personnel (user representatives) to participate as needed in appropriate acquisition and program responsibilities. To deliver capabilities that address user priority needs and generate mission impact, it is critical to have users actively involved throughout development and that the operational, requirements, acquisition, development, security, and test communities work closely together to apply DevSecOps best practices.

Further, it is critical that the Product Owner and Program Manager commit to a clear delineation of responsibilities that will allow them to work together effectively for the benefit of the program. Similarly, the roles of the Sponsor and Decision Authority will need to be clearly defined to ensure that there are not overlapping responsibilities. Additional technical roles (including those of the Integrated Product Teams (IPT) noted in the diagram that follows) will be addressed in other documents, so that this document focuses primarily on roles that will engage end-users.  The following is a notional outline of key roles.

Key Roles in a Software Acquisition

The following are notional roles and responsibilities of the key stakeholders involved in requirements, design, user engagements, and value assessments. This is not intended to be a comprehensive document capturing the responsibilities of all stakeholders in the program community, but rather the key relationship between operations/requirements and acquisition leaders. Each organization will often have unique processes and roles. Programs are encouraged to tailor responsibilities to their unique needs. Some of the key players include, but are not limited to:

Role Responsibilities
Operational Sponsor
  • The senior official who champions the program from the operational community.
  • Drafts and signs the Capability Needs Statement (CNS) or Software ICD and submits it to Service requirements boards per their established approval processes.
  • Responsible for programming/budgeting and allocating necessary funds to plan, develop, test, and deploy the solution.
  • Identifies the Product Owner to support the program.
  • Ensures users and stakeholder inputs are captured and integrated into value assessments
Product Owner
  • Typically, from either the operational or requirements organizations.
  • Understands the user organization and the capability being developed
  • Capably of advocating for the product.
  • Responsible for the day-to-day requirements management.
  • Responsible for the long-term vision of the project and guiding its progress.
  • Provides guidance and expertise about the users and their operational needs.
  • Coordinated User Representatives and participates with them in requirements identification and prioritization forums. Works with other stakeholders to scope the Minimum Viable Product and Minimum Viable Capability Release effectively.
  • Removes obstacles and helps the team work as effectively as they can.
  • Validates that content in the CNS or SW-ICD is clear and realistic.
  • Engages a broad range of end users to determine capabilities and needs along with desired and assessed value.
  • Works closely with the Program Manager to ensure that software development addresses the users’ priority needs and that capabilities are iteratively delivered.
  • Reviews and manages the product backlog with the Program Manager and has authority to prioritize and change requirements (large and small).
  • In partnership with the Program Manager, manages the product roadmap and program backlogs.
Acquisition Decision Authority
  • Acquisition executive responsible for overseeing the acquisition program.
  • Decision authority for those decisions identified in the Acquisition Strategy, Acquisition Decision Memorandums, and the UA.
Program Manager
  • Responsible for developing acquisition strategies and executing the acquisition program.
  • Contributes to backlog management discussions based on engineering needs, budget constraints, and other programmatic factors.
  • Ensures the development team’s work is delivered in timely iterations, based on the user stories/backlog prioritized by the Product Owner.
  • Works closely with the Product Owner to ensure the software development addresses the users’ priority needs.
  • Ensures regular demonstrations of interim developments between the development teams and end users.
  • Organizes MVP and MVCR feedback events and user acceptance testing.
  • Leads frequent planning and reviews with the Product Owner, for each iteration of work (e.g., for sprints, program increments).
  • In partnership with the Product Owner, manages the product roadmap and program backlogs.
  • Works with Product Owner and sponsors to ensure user communities are informed in a timely fashion about upcoming and deployed changes in system capability.
  • Provides the sponsor a summary of capabilities delivered as an input to the value assessment.

Note: If the user community cannot provide the dedicated resources needed, the PMO can take on the Product Owner role(s), as long as the individual(s) can perform the responsibilities described above for the Product Owner.

Development Team (led by Team Lead / Scrum Master)
  • Responsible for establishing the team environment.
  • Responsible for determining team ways of working.
  • Responsible for establishing team ceremonies, events, and meeting cadence.
  • Responsible for day-to-day team execution.
User Community
  • Leaders in the community identify and commit user representatives to participate in shaping acquisition and software development efforts.
  • Provides acquisition and developer communities insights into the operational environment (i.e., people, process, systems).
  • Provides meaningful feedback and evaluation of software developed (e.g., demonstrations, testing, other related events in this UA).
  • Provides input on Value Assessments as required.
  • Provides support in change management, training, and other rollout activities.
“What’s most important about this is it highlights an area where the acquisition structure and the acquisition roles are making substantial changes to enable software delivery. Under the new agreement, the relationship between the MAJCOM and the software factory has been redefined so there is “oversight defined in a way that’s relevant to software as opposed to hardware.”
Kessel Run

Engaging User Communities

Reference Source: USD(A&S) Guidance

Engaging user communities is critical to the success of Agile software development efforts.  Therefore, the UA should identify the technique(s) that the program will use to select and engage user representatives.  Some recommendations on selecting and engaging user representatives include:

  • Select user representatives from all user communities.
  • Balance the user population to ensure the product is optimized for all user communities.
    • Note: If a program has too many representatives from a specific community (e.g., a single Military Occupational Skill (MoS) or a single military unit), the software may become optimized for that user community, but sub-optimal for other communities.
  • Select user representatives that provide proportional representation based on program objectives/goals.
    • Note: If software is for command and control, anticipate having more user representation from that population.
  • Select user representatives with both a deep understanding of the mission and familiarity with modern software development methods.
    • Note: If users lack familiarity with modern software development methods, training will be required and should be factored into the program budget.
  • Consider the use of test detachments that are specially designated to work with software programs to prioritize features and evaluate early versions of software.
    • Note: Test detachments are typically populated with operational users who return from deployment and spend a rotation in the test detachment.
  • Embed end-users within the software development team or (if not possible) consider other methods to actively engage with end-users.
  • Collocate users and developers and establish virtual/remote tools to fosters a holistic team environment, active collaboration, and information exchange.
“This user agreement ensures the active participation of end users in order to mitigate operational risks to the warfighter. It allows us to deliver higher quality capabilities faster”
Kessel Run

Activities Covered Under a User Agreement

Reference Source: USD(A&S) Guidance

The UA identifies the types of activities that require user engagement and sets clear expectation of decision-making authorities, which may include regular user input and feedback on:

  • Context of operational environment – understanding the people, processes, systems, and evolving needs/capabilities. This should also include any assumptions, constraints, priorities, or threats.
  • Feature identification and prioritization.
  • Appropriate MVP and MVCR.
  • The Product Roadmap.
  • Development activities and assessment of working software.
  • CNS development, refinement, and maintenance.
    • Note: the initial CNS is refined during planning.
  • Interface considerations and interoperability requirements to ensure a System of System view (technical and operational processes).
    • Note: This is especially true for software embedded on a weapon system for design, usability, and schedules.
  • End user testing and validation – identify who is involved in demonstrations and testing, as well as how demonstrations and user testing will be accomplished (test plan, test environment) prior to deployment and rollout of the software.
  • Deployment and rollout decisions – specify who has authority to make rollout decisions, what sites will receive new features/capabilities, sequencing of rollout locations, and the decision-making authorities for ‘go/no-go’ decisions.
  • Human System Interface Assessment (HSI) Assessment – the formal reporting mechanism to ensure usability and operational suitability issues are managed and/or mitigated as software matures. It also codifies how user testing was accomplished, how the program ensured optimum user experiences, and reports out on any outstanding user performance risks that should/could be mitigated in future software releases/upgrades/etc.
  • Value Assessments – how the sponsor will capture and integrate user and stakeholder inputs to shape value assessments.

“Agile has improved delivery of value and the ability to capture feedback from 3 years on average to 10 months. This helps ensure what we are not delivering obsolescence (requirements defined at beginning of three years are not obsolete on delivery).  We also can capture better feedback faster over the life of the product to evolve it in future releases.” 

Information Screening and Delivery System (ISDS), an 873 Agile Pilot Program