UNCLASSIFIED

UNCLASSIFIED

Minimum Viable Product (MVP) and Product

Roadmap What are they and why programs should have them?

Version 1.0

August 2019

OUSD(A&S)

UNCLASSIFIED

UNCLASSIFIED

This page intentionally left blank.

UNCLASSIFIED

UNCLASSIFIED

iii

Table of Contents Purpose ....................................................................................................................................................................1

Minimum Viable Product (MVP) .................................................................................................................2

2.1 Defining MVP Strategies ........................................................................................................................5

2.2 When Would Multiple MVPs Make Sense? ...................................................................................5

Product Roadmap ...............................................................................................................................................7

3.1 Product Roadmap Development Strategies .................................................................................9

Common Benefits and Challenges Associated with MVP & Product Roadmaps ............... 11

4.1 Benefits of MVP ....................................................................................................................................... 11

4.2 Benefits of Product Roadmap .......................................................................................................... 11

4.3 Challenges of MVP ................................................................................................................................. 11

4.4 Challenges of Product Roadmap ..................................................................................................... 11

Culture Change .................................................................................................................................................. 12

Summary .............................................................................................................................................................. 14

Abbreviations and Acronyms .............................................................................................. 15

Definitions ..................................................................................................................................... 16

List of Figures Figure 1 Build-Measure-Learn ...............................................................................................................................2

Figure 2 Iterative Development and Risk Reduction ..................................................................................3

Figure 3. Defining an MVP ........................................................................................................................................4

Figure 4. How to Build a Minimum Viable Product ......................................................................................4

Figure 5. Sample Agile Product Roadmap 1 .....................................................................................................8

Figure 6. Sample Agile Product Roadmap 2 .....................................................................................................8

Figure 7. Long Term, Complex Solution Roadmap .......................................................................................9

List of Tables Table 1. Four Values of Agile Software Development .............................................................................. 12

Table 2. Twelve Principles Agile Manifesto .................................................................................................. 12

UNCLASSIFIED

UNCLASSIFIED

iv

This page intentionally left blank.

UNCLASSIFIED

UNCLASSIFIED

1

Purpose The Department of Defense (DoD) is working with Government and industry leaders to modify how DoD plans and delivers information technology (IT) systems, products, and services. Many projects today continue to use a waterfall delivery approach which typically delays delivery of working software to the end-user. The increasing complexity of systems, rapidly changing environment, threats, security vulnerabilities, decentralization of tools and technologies, challenge our current ability to deliver much-needed capabilities on time and within budget. Addressing these issues requires a significant change in approach to planning and delivery of system capabilities to the end user: specifically, a shift to Agile project management, methods, and delivery.

The base premise of Agile is built around frequent, small batch delivery of working functionality into the hands of users to gain fast feedback with short learning cycles that enable the development team to hone the solution. These quick iterations mold the end-product to better meet the evolving needs of the end user. Agile methodologies use the Minimum Viable Product (MVP) concept to refer to the first delivery of meaningful capability of a product. The MVP is a collection of features that provide just enough capability to accomplish minimum functionality for the targeted end-user so that this early user of the system can provide feedback to influence future development iterations. To successfully achieve this approach, the MVP should be a manageable piece of work that provides the ability to use and assess how the targeted system solution performs in a production setting and give that fast feedback to the system development team to be incorporated into future iterations.

Business/mission preparation of a product roadmap and establishing frequent reviews, on a predictable cadence, while working along with development teams is required when implementing Agile methodologies. Product roadmaps provide a high-level plan and direction for the future of a product. The product roadmap communicates product capabilities and plans that provide the basis for business/mission and technical product decisions. It helps to bring alignment of the development team with the product team to ensure a common understanding of delivery, priorities, and key events to enable teams to better plan together for the critical events. In an Agile environment, the roadmap drives definition of feasible key feature sets (or capabilities) and supports prioritization and timing of work to be accomplished.

This white paper provides Pilot teams, Product Owners/Product Managers (PMs), Project/Program Managers and key stakeholders with a better understanding of what a product roadmap and MVP are and strategies for defining each for their Pilots and/or Agile initiatives.

UNCLASSIFIED

UNCLASSIFIED

2

Minimum Viable Product (MVP) Whether your end-user is internal to your organization or external, the common goal is to build what the customer needs and when they need it. Using traditional software development practices, it can take a long time before the user can see the solution to provide feedback. Agile methodologies are based on the goal to incorporate the end-user within the development team, iterate often, and in small batch sizes to clarify the need and provide flexibility to incorporate feedback quickly. While Agile development is improving the pace of value delivery, teams are still struggling to identify where to start development.

The Build-Measure-Learn cycle depicted in Figure 11 communicates the process of taking ideas, making decisions to influence development/build, measuring the impact (reviewing and evaluating the feedback received from the build) and taking the learning to influence the next iteration/build. The continuous learning that Agile/iterative development promotes also provides benefits in support of informing and refining the ongoing product/program outcomes. When the MVP is incorporated into the Build-Measure-Learn method, the concept helps minimize risk. Deploying the MVP allows end-users to see and use the capability and react early. Sometimes end-users realize what they asked for isn’t what they really need or want. Other times, it helps the end-user communicate what they want changed or clarify the need. This pattern enables Agile projects to be flexible enough to accommodate incremental changes and permits continuous delivery of working capability prioritized based on end-user needs and emergent design principles as a project unfolds. The MVP is the first delivery of value to the end-user, which begins the process of continuous value delivery while reducing risk from large batch size deliveries. Future iterations after deployment/delivery of the MVP add functionality/capability to mature the solution and provide a rich experience.

Figure 1 Build-Measure-Learn

“The term MVP was coined and defined by Frank Robinson and popularized by Steve Blank and Eric Ries.”2 An MVP is typically defined during project initiation and refined during subsequent planning periods. The MVP provides a baseline set of capabilities to test

1 http://innovationnewanglia.com/business/commercial-viability-market-demand/ 2 https://medium.freecodecamp.org/the-minimum-viable-product-explained-8f1187ca7cec?gi=a5b5d46a5eca

UNCLASSIFIED

UNCLASSIFIED

3

assumptions of the proposed system and gather appropriate data to determine if the proposed system is delivering the expected or acceptable end-user value.3

As shown on the left side in Figure 24 a traditional waterfall development lifecycle builds the entire product with a single delivery at the end, thereby increasing the risk of either delivering the wrong product or not successfully delivering a product. End-user feedback is generally not received until the full solution is developed, and the end-user receives no value potentially for years. On the right side, an Agile development lifecycle provides continuous incremental delivery and provides opportunities for user feedback, adjustments, and realignment within each delivery cycle.5 This iterative process provides incremental value in weeks or months, further enabling the fast feedback and learning cycles and thus reducing the risk of missing the target of product outcome.

Figure 2 Iterative Development and Risk Reduction

Common guidance in industry indicates the MVP should be sized as a manageable, demonstrable set of capabilities. The MVP feedback received from end-users is critical to help decide the future of the solution. Variability and risk are inherent in technology programs. Because of this, developing and measuring an MVP provides an opportunity to evaluate the solution, obtain results, and reduce risk before committing to the investment of the entire system. The feedback from end-users can also identify that the product/service isn’t needed, negating the need for future iterations.

The layers of the pyramid in Figure 36 identifies needs of a solution.

• Functionality – solving a problem. • Reliability – available when the end-user needs it. • Usability – easy to learn, use and remember. • Design – the end-user has a positive reaction/likes it.

3 Ries, Eric (2011). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, Random House, Inc. 4 https://www.maine.gov/oit/project_management/agile.html 5 https://www.maine.gov/oit/project_management/agile.html 6 https://dvmobile.squarespace.com/dvmobile-blog/tag/Lean

UNCLASSIFIED

UNCLASSIFIED

4

The pyramid on the left (in Figure 3) is communicating that the MVP deliverable is focused only on functionality. The assumption is that building minimal functionality allows the end-user to provide feedback. The argument is to focus only on limited functions, the end-user doesn’t have enough of the experience. To gain meaningful feedback from the end-user the MVP needs to present a reliable, functioning solution with enough design usability for the end-user to react. The pyramid on the right highlights the need for the MVP to be a vertical slice of the pyramid. Delivering minimum capability of infrastructure, functionality, and design so that the end-user can evaluate the experience and provide helpful feedback. The delivered MVP (slice) should allow the end-user to experience a piece of the proposed solution in a state that provides learning.

Figure 3. Defining an MVP

Figure 4 provides an additional visual of defining the vertical slice of the pyramid. Step one in the “like this” model reveals that the MVP (iteration 1) is a working solution. The first iteration providing infrastructure, functionality, and design that allows the end-user to ride the solution and provide feedback to incorporate in the next iteration. The meaningful feedback from experiencing the skateboard delivered in iteration 1 (MVP) suggests iteration 2 should add capability to stop and a capability to help balance the rider (the handle).

Figure 4. How to Build a Minimum Viable Product7

7 https://www.techuntold.com/minimum-viable-product-mvp/

UNCLASSIFIED

UNCLASSIFIED

5

In industry the MVP is deployed to end-users in a production setting. There may be situations in which the MVP cannot be deployed to an operational environment. In such cases, the program must align on the definition of “delivery”. For example, the MVP is “delivered” in a staging area that mimics production to allow the end-user to test the capabilities and provide the program with feedback.

2.1 Defining MVP Strategies

The product owner/product manager (collectively referred to as the product management team, for larger systems solutions) and development team(s) should work together to identify and agree upon the MVP. The product management team is responsible to ensure the MVP provides end-user value and the development team identifies if the scope of the MVP is reasonable to be achieved within the set delivery period. When defining an MVP keep in mind the following:

• Select and Engage the User Community/End-User – The product roadmap may impact multiple end-user groups and the MVP may select a subset that will be the focus of the first deployment. Make sure those end-users are identified, agree to their role, and understand what is expected of them and are engaged from the start.

• Think Simple/Bare Bones – Keeping the identified user community/end-user in mind, select the simplest possible, most bare bones capability to focus on delivering. Typically, this should be an end-to-end scenario or thread of functionality that is demonstrable and allows the system/product to perform in the production or near-production environment, providing end-user capability, and subsequently providing the development team with valuable user feedback to incorporate into future iterations.

2.2 When Would Multiple MVPs Make Sense?

Industry has provided examples where it makes sense to have multiple MVPs. One such example recognizes there can be multiple concepts to meet the same need. In this situation, the program management team is tracking multiple MVPs, each MVP represents a concept solution and a singular focus for a development team. Having multiple, concurrent MVPs offers an opportunity to gauge end-user feedback for each concept at the same time. The benefit is that the program management team can evaluate multiple concepts using a relatively low-cost option to explore demand and response. A small investment in multiple MVPs may afford the opportunity to test theories and find that “sweet spot” of market demand for a new product, help define a new community of users, or choose the best concept to meet end-user needs.

Identifying and tracking multiple MVPs can also make sense when large system solutions consist of multiple components and services that each have their own Agile development team. Each team may have their own MVP for the capability they are responsible for developing. An example could be when building a modular weapon system where a set of standardized interfaces allow modular components (e.g., a hardware and software component for a common specific instrumentation purpose, like an altimeter or video display module).

UNCLASSIFIED

UNCLASSIFIED

6

Defining an MVP does not always require code development. When funds or time is limited a video can be generated as the MVP. The video is used as a tool to gain feedback from a focus group or target market of probable consumers. The MVP/video communicates the idea for the product or service to obtain feedback from a focus group (potential end-user). The video is used to measure focus group reaction for interest and feedback to provide a learning opportunity prior to investing in development work. If the idea is a bust, the organization has saved the time and effort of building out a prototype product and can conserve their capital for the next best concept. If response is strong, then the feedback can be leveraged to obtain funding and define capability to proceed with the development of a more robust MVP. This additional MVP continues the learning but has moved the idea into an initial product/service. Development is expensive, and it is important to develop solutions focused on meeting the end-user need grounded in demonstrated response, not what may be perceived to be something end-users are willing to buy or use. The MVP for the product/service continues the learning cycle and the product backlog would then reflect the collective learning.

UNCLASSIFIED

UNCLASSIFIED

7

Product Roadmap The product roadmap informs the planned evolution of the solution capabilities. The capabilities align to the product vision, enable the MVP and visibly communicate the capabilities/feature sets targeted for delivery (coded and built, integrated, tested, accepted, and delivered to the designated end-user environment as well as the expected order and timing). A product roadmap provides a rolling calendar-based view of key feature sets to be delivered in the near term (10-12 weeks) through the coming 12-18 months. The feature sets identified on the product roadmap provide focus and align the development team(s) with the product management team on those feature sets to be delivered first (representing the highest value features to the end user community, as assessed by the product management team). The identified feature sets should consider key risk areas, as well as technical dependencies as assessed by the development team(s). The product roadmap should include key upcoming external-facing milestones such as legislative events, participation in exercises, or field events that will be a performance priority.

The product roadmap should be reviewed frequently (frequency being driven by the level of change and the emerging system solution). This review helps ensure the necessary alignment of the teams with the priorities of the product management team. An Agile-based product roadmap, provided and discussed during planning sessions, provides context for the decomposition of near-term capabilities/features into smaller component parts that will comprise the work to be accomplished during the upcoming sprints.

The product roadmap should be at a high enough level of abstraction to allow teams to elaborate and decompose the high-level capabilities and features to the emerging system design. The lower-level user stories and tasks should not be referenced on the product roadmap. A product roadmap neither assigns work to specific teams nor dictates explicit design. The Agile product roadmap provides a prioritized, value-driven view of work to be performed. The functionally oriented product roadmap helps the team set a pace for work and provides just enough information to plan work for future sprints. The roadmap depicts the capabilities or features to be developed over time while avoiding overly prescriptive plans. Because Agile program roadmaps are defined at a higher level of abstraction, they promote/allow the teams to collaborate on lower-level requirements and design details.

Figure 58 and Figure 69 visually depict two different sample product roadmap formats. The Agile roadmap seen in Figure 5, illustrates the end-user objective to be met (the “what and why” of the delivery), the features or feature sets that summarize the technical solution in common language terminology (the “how” of the delivery), and a description of the full end-user value, the acceptance criteria for the features. The most common form lists only the features in short end-user/mission terms along with the delivery dates and any key external events that affect the focus and efforts of the development team(s), as depicted in

8 From GSA Tech Guides https://tech.gsa.gov/guides/develop_an_agile_product_roadmap/ 9 From ProductPlan https://www.productplan.com/example-roadmaps-for-product-managers/

UNCLASSIFIED

UNCLASSIFIED

8

Figure 6. This version offers the added benefit of displaying key functional groups responsible for the features horizontally shown in each of three “swim lanes”.

Figure 5. Sample Agile Product Roadmap 1

Figure 6. Sample Agile Product Roadmap 2

There are often larger and more complex system solutions with critical delivery dates and end-user commitments. These solutions are built using many development teams with multiple contractors, external suppliers, and long lead times for developing hardware and major subsystems. For these types of solutions, longer planning and investment horizons are required and consequently, longer-term roadmaps are built to support these needs. As

UNCLASSIFIED

UNCLASSIFIED

9

with the first roadmaps, the most detail is provided for the near-term delivery functions, moving to broader time intervals and less specificity the further out the planning horizon goes.

Figure 710 illustrates a solution roadmap that covers about three years. The first year is planned in quarters (e.g., Q1, Q2, etc.), which may or may not align with program planning boundaries. The second year is planned in six-month increments (e.g., H1 and H2). Anything beyond that is scheduled in years (e.g., Y3 and Y4). As the time horizon extends, the level of granularity and certainty is significantly reduced.11

Figure 7. Long Term, Complex Solution Roadmap

A word of caution: because this complex solution roadmap may span multiple years, it requires longer-term estimating. Such forecasts can reduce agility and adaptability of the organization because, while many may see long-term predictability as the goal, the organization cannot adapt and change if the future is fixed. Error! Bookmark not defined.12

3.1 Product Roadmap Development Strategies

The Product Management team needs to own development and maintenance of the product roadmap. Keeping the following strategies in mind will help ensure your product roadmap highlights and communicates the right information.

• Communicate Product Goals – When building the product roadmap, the Product Management team should map out the goals for the product, informed by the MVP and product vision. The goals should identify end-user base changes, key capabilities and/or objectives.

• Support Enterprise/Organization Roadmap – A product roadmap should consider and support an overall organization or enterprise roadmap, the strategic plan of the organization. Development team members should clearly see and understand how the product supports the goals of the larger organization.

10 https://www.scaledagileframework.com/roadmap/ 11 https://www.scaledagileframework.com/roadmap/ 12 https://www.scaledagileframework.com/roadmap/

UNCLASSIFIED

UNCLASSIFIED

10

• Identify Key Product Capabilities – The product roadmap should show a progressive growth (or for products being phased out, the removal of capabilities). The roadmap should show capabilities that are built upon each other providing enhancements and additional value over time.

• Keep Your Audience in Mind – The product roadmap will be used by the development team(s) to define releases, sprints, and ultimately deliver capability to meet end-user/mission priorities communicated in the product roadmap and during Agile ceremonies. For example, a product roadmap may identify the need to provide users with video content, the development team may translate this capability to build video storage functionality in one sprint and video play capability in a second sprint. The Product Owner isn’t responsible to define the sprints (or how to build the solution) but they do need to communicate the end-user need clearly and be available to the development team(s) to clarify questions and review and accept delivered functionality.

• Receive and Maintain Approval and Accuracy – Product management has the responsibility for ensuring the product roadmap is agreed to by the necessary leadership and for maintaining its accuracy over time. The product roadmap should be reviewed frequently (frequency being driven by the level of change and the emerging system solution). Team review is recommended during planning events (i.e., Sprint and Program Increment); therefore, product owners should review/make updates prior to these team planning events.

• Identify Key Dates/Timeframes – Only identify dates/timeframes on a product roadmap if they have product/capability significance. Example, the X capability is needed by employees when they select healthcare plans in November.

As with any plan, the product roadmap is a living document that should be reviewed often and should change to reflect/adapt to changing end-user needs.

UNCLASSIFIED

UNCLASSIFIED

11

Common Benefits and Challenges Associated with MVP & Product Roadmaps

4.1 Benefits of MVP

• Provides just enough function to learn from • Enables fast, focused feedback • Identifies/clarifies what the end-user wants • Establishes the need and agreement for end-user active participation • Minimizes expense if feedback negates/invalidates need for product • Lowers acquisition risk (the risk for building to the wrong requirement)

4.2 Benefits of Product Roadmap

• Visually depicts end-user capability priorities • Functionality oriented opposed to task • Identifies capabilities at high-level to promote collaboration on detail requirements

and design • Identifies important, external events/milestones • Supports/input to Sprint planning and backlog prioritization work

4.3 Challenges of MVP

• Defining the MVP can be a challenge. The end-user should experience a piece of the proposed solution not just one function.

• Leadership can expect a feature-rich capability. • Limited engagement from end-user. • Not learning/listening to feedback and incorporating into the product backlog for

future iterations.

4.4 Challenges of Product Roadmap

• Task-level detail is presented rather than capability/feature set placing restrictions on design and flexibility.

• Defined during program initiation and not reviewed and maintained through-out program life.

• Detailed long-term planning and estimation that often reduces agility and adaptability to end-users changing needs.

• Trying to satisfy too many audiences. Use technical, end-user, marketing etc. roadmaps to communicate specific information that is not product focused.

UNCLASSIFIED

UNCLASSIFIED

12

Culture Change Implementing the use of the MVP concept and product roadmaps reinforces the four values of Agile (Table 113) and the 12 principles articulated by the Agile Manifesto (Table 214). It requires organizations that are moving from traditional, waterfall software development models to understand the difference when using Agile methodologies and push for change. This transition to Agile impacts how

• End-user and technical teams work together. • Requirements are defined and maintained. • Software is developed, tested and deployed. • Contracts are shaped to support software development. • Cost and schedule are managed. • Roles and responsibilities are modified. • Decision-making takes place in terms of speed and level. • Organizational structure is adjusted.

Table 1. Four Values of Agile Software Development

4 Values of Agile Software Development

Individuals and Interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Table 2. Twelve Principles Agile Manifesto

Principles Behind the Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Businesspeople and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

13 https://agilemanifesto.org/ 14 https://agilemanifesto.org/principles.html

UNCLASSIFIED

UNCLASSIFIED

13

Principles Behind the Agile Manifesto

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Incorporating the Agile principles into the daily work processes and changing the corporate culture to embrace Agile principles is required to effectively deploy use of the MVP and a product roadmap. Using Agile software development principles and transitioning from a front-loaded planning and scheduling approach to a more iterative and incremental approach is a fundamental change.

Some specific culture changes required to implement MVP and product roadmaps are:

• The product owner is responsible for understanding and communicating capabilities/feature sets (product roadmap) along with the priority for delivery. They require authority to make requirement and design decisions and approve deliverables.

• Change, risk and governance processes need to adapt to the project speed. MVP feedback received from the user needs to be incorporated into the next development iteration. If decision making authority hasn’t been given to the project team then the decision maker (leadership/executives) needs to change to be engaged daily. Waiting for a monthly/quarterly review process won’t work. Having to develop presentations to get decision makers up to speed impacts team performance and is focusing on work that has limited value. Focus needs to remain on the mission—delivering capability, fast and in support of the end-user.

• Project teams require active, daily participation from developers, end-users, testers, and operation team members.

• Acquisition/contract development approach requires changes. Requirements are not fully defined upfront. Therefore, traditional requirement documentation and architecture artifacts will not be fully defined for the contract. Capabilities are identified allowing the Agile approach to address emergent design details. The development and end-user team should define the MVP together.

This section highlighted some of the change that is required. Published resources discussing strategies for handling cultural change when adopting Agile methodologies should be referenced by teams implementing MVP and product roadmaps.

UNCLASSIFIED

UNCLASSIFIED

14

Summary The increasing complexity of systems, decentralization of tools and technologies, as well as the rapidly changing environment and presentation of highly adaptive threats and security vulnerabilities challenge our current ability to deliver solutions. The solutions are needed to provide meaningful, secure, and modern capabilities that support, protect and inform the end-users with much-needed enhanced and more relevant capabilities on time and within budget. Addressing these issues requires a significant change in approach to planning and delivery of system capabilities to the end user: specifically, a shift to Agile project management, methods and delivery.

The base premise of Agile is built around frequent, small-batch delivery of working code with fast feedback and learning cycles to hone the solution. These iterations mold the end-product outcomes to better meet the evolving needs of the end-user. This document discussed how defining an MVP and product roadmap are two valuable tools toward achieving the desired Agile outcomes.

The MVP is the first delivery of value to the end-user, which begins the process of continuous value delivery while reducing risk from large batch size deliveries. It is a collection of features that provide just enough capability to accomplish basic functionality for the targeted end-user so that this early end-user of the system can provide feedback to influence future development iterations and determine if the product/service can provide the intended value and is needed.

The product roadmap was identified as a critical plan owned by the product owner. Product roadmaps provide a high-level plan and direction for the future of a product. It communicates product capabilities and plans that provide the basis for business/mission and technical product decisions. In an Agile environment, the product roadmap drives definition of key feature sets (or capabilities) and guides prioritization and timing of work to be accomplished.

UNCLASSIFIED

UNCLASSIFIED

15

Abbreviations and Acronyms ALM Application Lifecyle Management

DoD Department of Defense

IT Information Technology

MVP Minimum Viable Product

PM Program/Project Manager

PO Product Owner

UNCLASSIFIED

UNCLASSIFIED

16

Definitions Product Manager The person primarily responsible for the definition and delivery of the system content; often

for larger programs with multiple Agile teams producing one or more integrated products. This person is the holder of the vision and overall direction of the program.

Product Owner (PO) A member of the Agile team responsible for identifying the priorities and defining the product components to be built to fulfill the capability(ies) of the end product. Also works with the team to accept or reject the work accomplished by determining if it meets the agreed upon definition of done.

Product Management The combined product focused team, comprised of the POs, directly working with the development team(s), plus the Product Manager.