Materiel Solutions Analysis (MSA) Phase
Agile Fundamentals Overview
Agile Glossary
MATERIEL SOLUTION ANALYSIS (MSA) PHASE
Materiel Development Decision (MDD)
Analyze Requirements
Analysis of Alternatives (AoA)
Develop Acquisition Strategy
Market Research
Cost Estimation
Risk Management
TECHNOLOGY MATURITY AND RISK REDUCTION (TMRR) PHASE
Milestone A
Mature Requirements
Competitive Prototyping
Systems Engineering
Mature Acquisition Strategy
Contract Preparation
Risk Management
Request for Proposal
ENGINEERING & MANUFACTURING DEVELOPMENT (EMD) PHASE
Milestone B
Manage Program Backlogs
Release Execution
Manage Contracts
Metrics
Scaling Agile
Analyze Requirements
During the Materiel Solution Analysis (MSA) phase the program works with its operational sponsors to refine and structure the program’s requirements. To set the stage, the team should have a clear understanding of the users’ Concept of Operations (CONOPS), performance objectives, and operational environment. The requirements are prioritized to support an Analysis of Alternatives (AoA), tradeoffs, and the advantages and disadvantages of structuring development via releases. As requirements mature, frequent collaboration with end users is critical to ensure the requirements capture users’ priority needs and that all stakeholders have a common understanding of current and future CONOPS. Collaboration with other stakeholders (e.g., engineers, testers, and enterprise architects) is also critical during the shaping of the requirements. The program identifies a Product Owner, structures the requirements documents, and establishes the requirements management processes.
Identify a Product Owner
The product owner fulfills one of the most important roles in the Agile team. In general, the product owner/Product Owner’s responsibilities across the lifecycle include:
- Establishes a clear vision for what the program is to accomplish
- Conveys the concepts of operations to the Program Management Office (PMO) and development team
- Manages the program and release backlogs to ensure the requirements/user stories are current, prioritized, technically feasible, and have a clear “definition of done” acceptance criteria
- Works with the development team to convert requirements into user stories
- Adds/deletes/refines user stories and acceptance criteria with inputs from multiple stakeholders
- Coordinates with senior operational sponsors, expert stakeholders, and a broad pool of end users to capture their requirements, priorities, and feedback while sharing insights, and providing demos on the program’s progress
- Answers questions from the development team on user stories, functionality, and user interface
- Coordinate capability demonstrations with operational sponsors and end users after each sprint to provide feedback to the development team.
- Provides reguarly feedback to development team on interim developments
- Identifies active participant in release and sprint planning and retrospectives
- Identifies active participant in modeling, mock-ups, and testing
- Coordinates with other product owners of related programs the product will interface or integrate with
- Coordinates deployment of releases.
The more closely the Product Owner can work with the development team and the PMO during development, the better the chances for success. If co-location with the development team or PMO is not achievable, there should be frequent synchronous collaboration sessions, such as face-to-face meetings, video/audio teleconferences, and online collaboration/demonstrations. A Product Owner should be available to provide timely information and decisions. Asynchronous collaboration involving tools such as JIRA can also enable the Product Owner to work closely with the development team.
The program must select someone who has the operational experience, communication skills, and vision necessary to shape the program. The program should designate and empower product owner(s) who can convey the program vision, serve as the voice of the customer, and manage the program backlog. This could be done by a single leader or a small team of leaders from the operational community who perform day-to-day requirements management.
Product Owner References:
Structure Requirements Documents
Approval of the Information System-Initial Capabilities Document (IS-ICD) at the MDD empowers the program to use the IT Box model of the JCIDS Manual, to tailor subsequent requirements documents per approval of their designated flag-level requirements oversight board. Programs may decompose requirements into Requirements Definition Packages (RDPs), Capability Drops (CDs), and/or alternative document structure. The figure below shows a potential document structure as outlined in the JCIDS Manual. In this example, RDPs and CDs are incrementally developed and approved over time. RDPs are the primary documents that capture a subset of the ICD requirements. CDs can either cover a small subset of an RDP or a standalone item such as a small application.
The IT Box model offers a significant flexibility advantage over the traditional JCIDS documents, but an Agile environment will need even more flexibility in order to dynamically manage requirements. Agile prioritizes working software over documentation; it is critical to not invest too much time and energy creating and approving lengthy requirements documents ahead of time. Agile relies on continual user engagement and requirements refinement throughout the program. The flag-level requirements oversight board identified in the IS-ICD and the Product Owner should share a clear understanding of expectations and authorities.
Establish Requirements Management Process
Requirements Best Practices from Early Agile Adopters
- Operational environments support small, frequent capability deliveries.
- Requirements are clearly decomposed into small tasks.
- End-users can engage throughout requirements and development to share CONOPS insights and provide immediate feedback from demonstrations.
- Managed a program backlog via half page work packages with a rough government estimate, design context, and technical interfaces
- Empowered Product Owners – Single/multiple based on user community’s size/diversity
The Mature Requirements page describes the next steps in the requirements process and supplies additional references.
Additional references:
- IT Box
- Eliciting, Collecting, and Developing Requirements, MITRE Systems Engineering Handbook
- Analyzing and Defining Requirements, MITRE Systems Engineering Handbook
- Agile Software Requirements, Dean Leffingwell
- User Stories Applied: For Agile Software Development, Mike Cohn
- Requirements Engineering in an Agile Software Development Environment, Alan Huckabee, Sep 2015
- Agile Requirements Best Practices by Scott Ambler
- Requirements by Collaboration by Ellen Gottesdiener (See also the book by same name)
- Agile Requirements Modeling by Scott Ambler
- Agile Software Requirements by Dean Leffingwell
- Writing Effective Use Cases by Alistair Cockburn
- To slice stories, first make sure they are too big, Gojko Adzic
0 Comments