Define Capability Needs
Engage Users, Assess Value
MVP, MVCR, Deployment
Ent Services, DevSecOps
Metrics and Reporting
DBS in SWP
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.”
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:
- Anticipated developer and user ceremonies, events, and interactions.
- Prioritizing features and stories in roadmaps and backlogs against the overarching Capability Needs Statement.
- Determining Minimum Viable Product (MVP), Minimum Viable Capability Release (MVCR), and other releases.
- Developing and participating in user training and knowledge sharing.
- Performing user testing and software demonstrations.
- Decision-making regarding software release and deployment.
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.
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:
|Acquisition Decision Authority||
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)||
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.
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.”