Effective POA guides the direction of the product and maximizes the value of the product through a product backlog. The product backlog is a list of items related to building a product, referred to as product backlog items (PBIs).

The source of PBIs may trace back to the customer, business, or technical items that are gathered throughout the strategy and initiative horizons. The Product Owner owns the product backlog and is accountable for managing it.

Iterative and adaptive planning both reference the need to "prioritize and refine the work." "The work" is captured as product backlog items in the product backlog. The PBIs roll up to a component, feature, or shippable product.

A product backlog is not a dumping ground for every request, an issue log for every submission, or a placeholder for every piece of work that may be considered for a product. In general, a healthy, well-managed product backlog:

• Demonstrates the product development strategy,
• Is the single source for product requirements,
• Includes 1 - 2 iterations of PBIs that meet the Definition of Ready,
• Includes 1 - 2 iterations of PBIs that are in refinement,
• Includes PBIs as a list of all work that needs to be completed to deliver a product,
• Is prioritized, estimated, and sorted, and
• Articulates the business and/or technical value of every PBI.

How POA Helps Manage Product Backlog

As the owner of the backlog, the Product Owner understands the importance and value of consistent backlog management and can use POA practices to good effect. As a central touchpoint for everything related to the delivery of value, the product backlog is a continuous:

• Receipt of work,
• Refinement of work, and
• Delivery of done work.

POA encompasses all the background work that the Product Owner or any other POA Practitioner does to manage the product backlog in a healthy condition. While the Product Owner is accountable for the management of the product Backlog, multiple building blocks contribute to the level of health.

The health of the product backlog is reflective of the health of the team. Each domain within this Guide helps the team navigate the give and take required for better culture and teamwork, leading to better backlog health and, ultimately, better product delivery.

POA Techniques to Manage Product Backlog

Agile Extension Techniques

• Job Stories: Explain common activities, transactions, and workflows in a product as PBIs.
• Real Options: Determine when to make decisions. It is useful in determining the flow of the product backlog and the priority of PBIs.
• Relative Estimation: Make future predictions based on:
  • Experience,
  • Knowledge,
  • Complexity,
  • Size, and
  • Uncertainty required to complete backlog items.
• Story Mapping: Assist with prioritizing product delivery and creating an understanding of:
  • Product functionality,
  • The flow of use, and
  • Assist with prioritizing product delivery.
• Value Stream Mapping: Provide a complete, fact-based, time-series representation of the stream of activities required to deliver a product.

BABOK® Guide Techniques

• Backlog Management: Record, track, and prioritize remaining work items.
• Balanced Scorecard: Manage performance in any business model, organizational structure, or business process. It helps with aligning backlog items to objectives.
• Brainstorming: Collaborative planning of PBIs.
• Collaborative Games: A tool to increase participation, collaboration and shared understanding of product backlog or elaboration of PBIs.
• Concept Modelling: Capture the main product and industry domain concepts to help build an understanding of concepts and their interrelationships. It aids in understanding PBIs and their dependence on prioritization, estimation, and elaboration.
• Data Modelling: Capture data elements tied to the product and their relationships which help detail the PBIs and their effect on the underlying data and data structures.
• Functional Decomposition: Successively decompose components, features and PBIs into implementable items and tasks.
• Interface Analysis: Identify where, what, why, when, how, and for whom information is exchanged between solution components, making the PBIs more comprehensive.
• Interviews: An elicitation tool to discover PBIs from stakeholders.
• Metrics and Key Performance Indicators (KPIs): Verify the success and failure of successful implementation of PBIs.
• Prioritization: A set of tools to manage the flow of the products and PBI.
•  Process Modelling: Create a detailed understanding of different processes involved or affected by the product, which helps in discovering new PBIs or analyzing the effectiveness of deployed items.
• Prototyping: Demonstrate the delivered and deployed PBIs to stakeholders in order to gather feedback or elicit future PBIs.

Case Study: Manage Product Backlog - Food Manufacturer

Background Tony, the Product Owner for the New Product Intake Process at Poultry Plus, established a Now-Next-Later Product Backlog at the outset of the initiative and had the high-level features laid out on a timeline for delivery. The next step was to get started organizing the "now" portion of the backlog and drive the product team toward their delivery goals. Challenge Although the features had been broken into smaller chunks of delivery for immediate versus longer-term needs, there was a lot of work to do. The team wanted to deliver testable functionality in every sprint to ensure the business users, as well as the end customers, were getting satisfying deliveries that built confidence toward the final release and future revisions. Tony and the team had established a User Story map and organized it to guide their development timeline. Action Tony led the team in activities to manage the backlog each sprint. For the initial sprint, they used concept modelling to determine which features had dependencies and which needed to be completed before the next one could be built. For example, it did not make sense to build customer product details without an understanding of the full project. The first sprint focused on capturing project-level details as entered by the customer. The second sprint focused on breaking the project down into product- level details, including ingredients and sourcing. The third sprint focused on packaging and labelling, etc. Tony worked with the business team on process modelling and prototyping activities to better refine the backlog. He used low-fidelity techniques such as whiteboarding and hand-drawing diagrams so that the visuals drew out conversations but did not lock in the development team to certain interface designs. Outcome For example, when discussing the hierarchy of project, product, ingredients, and packaging, it was determined that one project may have one or many products. In this case, each product had many ingredients, and packaging may have been the same for some products, but not all. This was more easily determined using a visual diagram. After that, the backlog could be organized according to the agreed-upon hierarchy. Lessons Learned The business team for the New Product Intake Process was distributed across three different locations, and they did most of their discussion via web conference. Tony found that the business team could talk easier about visual depictions since it was easy to re-arrange process tasks using sticky notes and a whiteboard. Since they were not co-located, Tony had to get a bit creative with collaborative tools to use. He found the use of simple hand- held dry-erase boards held up to his camera to be effective for these conversations. Once agreed-upon, it was just a matter of adjusting the backlog to match the diagrams to keep the development process flowing.

Minimal Viable Product (MVP) is a concept used to reduce cost and risk associated with developing the wrong product, by:

• Testing a hypothesis,
• Reducing waste, or
• Increasing speed to customers for feedback and learning.

MVP is "the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort" - Agile Extension.

The MVP aims to:

• Represent the smallest, most cost-effective version of the product that maximizes validated learning opportunities from customer feedback.
• Validate a hypothesis through experimentation.
• Be inclusive of technical, market, regulatory or other supporting and enabling work.

The confusion that often exists around MVP appears to be rooted in attempts to create a cookie-cutter approach rather than providing guidance to figure it out given the uniqueness of

• Organization,
• Strategy,
• Customer,
• Product, and
• Value proposition.

The MVP concept needed more clarification to decide:

• What is enough to release,
• When to release it,
• Who to release to, and
• How to improve communication and shared understanding.

This led to the introduction of the:

• Minimal Marketable Release (MMR),
• Minimal Marketable Product (MMP), or
• Minimal Marketable Feature (MMF)

Each is aimed at defining and delivering a simple product with the right user experience.

 

One or several MVP's may roll up to an MMR, MMP or MMF, each adding components, features or improvements and providing opportunity for intelligent learning and value assessment.

The MVP demonstrated to business stakeholders may:

• Be a prototype or a pilot,
• Be just enough to deliver measurable value, or
• Provide options.

Planned delivery helps answer these questions:

• “How much is enough to add value?”
• “How will we know?”
• “Is there sufficient value to move forward?”

How POA Helps MVP Builds

Feeling the constant passion to help customers, the drive to deliver often, and the urge to demonstrate value, the team wants to get the MVP right.

The MVP Build opens opportunities for carefully planned learning. While customer intimacy is forefront, the team benefits from some technical knowledge. Recognizing the importance of security and the right technical foundation to support the product, must be a priority. Knowledge gained through trusted relationships with Developers and Architects helps the team:

• Prioritize work,
• Balance decisions, and
• Communicate effectively with stakeholders.

What it is

Building a viable product	Minimal effort with maximum learning	Evidence-based learning
Focus on core features that allow it to be a working product and provide value to the customer to gain feedback and validation.	Consider the minimum features required to get the needed feedback and learning to demonstrate value.	Maximum learning comes from customers' direct experience with the product, rather than on customer's extrinsic needs and perceptions.

What it might be

Functional prototype	Shippable product	Cheap and fast
MVP is a functional prototype that may be delivered to production. In some cases, MVP might just be the functional prototype.	While MVP should have sufficient value to be sold to the customer, in some instances it does not have the desired experience needed for it to be shippable.	Budget and time constraints should not be the primary decision when defining MVP. While it should be cost- effective and release quicker to market, having "cheap and fast" as the goal of MVP has risks.

What it is not

All must-have features	Proof of Concept (POC)	A single, fixed release
There is a difference between the must- have features of a product and core features that make a working product that delivers value to the customer. MVP focuses on core features delivering value.	POCs are built for internal use, to check if a product idea is feasible. It often validates a technical aspect of the product.	While MVP is the first release of the product, it may not include all the features that realize the full value of the product.

POA Practitioners will utilize people, processes, and technology to elicit and analyze information to find the right fit to deliver thoughtful calculated MVP builds. The first MVP is important. How it is delivered may be as important as what is delivered.

POA Techniques for MVP Builds

Agile Extension Techniques

• Backlog Refinement: Ensure items selected for the MVP are defined in detail and with clarity.
• Minimal Viable Product: Determine the MVP build that needs to have rapid feedback.
• Product Roadmap: Communicate direction and progress towards the product vision. It can help the MVP scope to be determined.
• Kano Analysis: Understand which product characteristics or qualities will prove to be a differentiator in the marketplace and help drive customer satisfaction.

BABOK® Guide Techniques

• Backlog Management: Record, track, and prioritize remaining work items including those for the MVP.
• Prioritization: Used with backlog management and backlog refinement, to prioritize items for the MVP.

Case Study: MVP Builds - Food Manufacturer

Background Early in the development of Poultry Plus' New Project Intake Process, the Product Owner, Tony, recognized that there were other opportunities to connect the information gained from the process to other systems and processes across the company. When planning the product strategy, this was laid out in a Now-Next-Later Product Backlog. Challenge Tony and the development team needed to confirm MVP for the New Project Intake Process. Initially, it seemed that simply delivering an online tool for the customer to enter the details would suffice. After all, the main problem was that customer requests existed in disparate, and sometimes not even electronic, systems. In interviews with Sales Representatives, Tony discovered that: Customers often did not understand enough about the manufacturing processes and regulations to provide complete information. They had to help the customers determine what needed to be considered. Customers had creative ideas that may not be able to be achieved in their initial form but could be adjusted minimally to succeed. Research and Development and Quality Assurance might have information that they needed from customers to confirm the viability of the request. Based on this new information, Tony realized that simply asking a customer to fill in a form online might result in incomplete information and not address the main problem. Action Tony realized that to ensure the initial release addressed the main problem in a meaningful way, the functionality for MVP needed: Guardrails for customers, and Functionality for Sales, R&D and QA. Tony worked with the analysts to determine which data elements from customers were required, or optional. Where data came from: Directly from the customer, Collaboration with Sales, or Some other source. Opportunities to: Limit customers selections for certain data, or Enter free-text specifications. That Sales, R&D and QA needed to have interfaces to the online form to provide their internal information. Lessons Learned The team learned that while Minimal Viable Product should be a small, cost-effective version of the final product, the V was critical to assess. Viability leads to adoption, not just by the end-users of a system, but by others impacted by it. Simply providing an online form for customers to fill in would have been fast and cost-effective, and it would have been modern, but it would not have achieved a viable solution for Poultry Plus. It would have shifted ongoing work online. For MVP to be achieved, the team had to assess what was minimally viable for their internal users as well as the external customer.

The team prioritized the product backlog and shaped it into an MVP, MMF,

MMP, or MMR aligned to the product vision and Roadmap identifying the "what" to deliver.

The tactical preparation that includes when and how to deliver is called release planning. Release planning translates customer value into an iterative progression to deliver prioritized features.

The outcome of a successful release plan is alignment on:

• The objectives for the next 3 to 6 months,
• The number and duration of the iterations,
• Deliverables or features the team aims to achieve iteratively,
• The iteration level goals,
• Management of identified dependencies and risks,
• The commitment and timing of resources doing the work, and
• The number of releases, value delivered in each release, and ship date for each release.

A release planning session typically takes place every 3 to 6 months (or 2 to 3 months within a scaled framework), although the release plan may need revision after each Iteration.

Participants in the release planning session include:

• POA Practitioners,
• Product Owner,
• Full delivery team,
• Stakeholders,
• Architects,
• Shared service teams, and
• Any essential contributors.

Criteria of the Definition of Ready for release planning:

• High-level capacity plan:
  • The delivery team, and
  • Any supportive resources.
• High-level refinement with t-shirt sizing estimates:
  • PBI elaboration,
  • Development, and
  • Testing efforts.
• High-level dependencies have been identified:
  • Technical,
  • Operational, and
  • Business considerations.

Release criteria are defined, including any hardening or stabilization requirements.

Release planning should be highly collaborative and interactive. It is important to include remote team members.

Tools include:

• Sticky notes, flipcharts, and whiteboards.
• Video conference tools for collaboration.
• An Agile product management tool to manage and share results.

Release Planning Session - Agenda example

Introduction - Agenda, participant introductions, release goals. Product Vision - The Product Owner explains the vision to ensure release planning remains aligned. Deliverables - Identified, clearly defined, and assigned business value. Time-Boxes - Duration of release and iterations (number of iterations per release). Team Capacity - Estimate capacity for the delivery team to determine workload per iteration and release. Agreement - Build agreement with the team on deliverables and Definition of Done for features. Iteration Backlogs - Move items from the product backlog to iteration backlog within a release. Dependencies - Identify between items, across teams, across iterations, to resolve/remove dependencies. Workload vs. Capacity - Calculate each iteration's workload and evaluate against the team's capacity. Risks & Issues - Analyze any discovered risks and issues and determine mitigation strategies. Retrospective - Evaluate productivity of the session, ease of collaboration and areas to improve. *Based on Tabaka, 'Collaboration Explained,' Addison Wesley, 2006

The Product Owner may share the release plan progress as part of each iteration review. This transparency will help if adjustments are required based on the outcome of an iteration. Revisions to the release plan after an iteration may be required:

• PBI's not completed,
• Unexpected complexity, and
• Spikes and unplanned capacity adjustments.

How POA Helps Plan Releases

The team is responsible for much of the release planning preparation:

• Prioritized PBI's with high-level estimates,
• T-shirt sizing, and
• A defined MVP, MMF, MMP, or MMR.

Additional considerations:

• Capacity plans,
• People and technical resource needs,
• Dependencies, and
• Anything that influences the release.

POA Techniques for Plan Releases

Agile Extension Techniques

• Planning Workshops: Determine what value can be delivered in a product release.
• Reviews: Demonstrate and inspect an increment of the product with stakeholders for a release.
• Value Stream Mapping: Provide a complete, fact-based, time-series representation of the stream of activities required to deliver a product. It can be modified to assess whether the value is provided, and the strategy is sound.
• Visioning: Explain the release goals concisely. A release is compared to the entire product vision.

BABOK® Guide Techniques

• Brainstorming: Foster creative thinking to support planning activities.
• Interviews: Interact with specific stakeholders to gain information or knowledge to support planning.

Other Techniques

• Definition Concepts (Ready, Delivery, Done): Use to develop a shared understanding and significantly reduce the risk of building something incorrectly.

Case Study: Plan Releases - Food Manufacturer

Background Poultry Plus' Product Owner, Tony, had the overall roadmap for the New Project Intake Process development, and had the MVP portion planned to a lower level of detail with user stories and story maps. Challenge Tony needed a delivery schedule that made sense for everyone, delivering maximum value functionality each time. He needed to work with: The product development team, Business stakeholders, Architects, Shared services teams, and Customers. Since the stakeholders had varying schedules and responsibilities, it was going to be a difficult task. Action Tony decided to have a planning workshop with the stakeholder group, except for the external customers, whose needs would be represented by the sales team. He used the product roadmap to show which features were planned for delivery in the Now, Next, and Later sections, and the detailed user story map for the MVP delivery. Tony explained to the team that the development was being done in two- week sprints and that the goal for each sprint was to have some functionality to demonstrate. The functionality demonstrated may or may not be ready to release, although it would be available to test. The team discussed the value of releasing small sets of functionalities directly to the customer. They decided that it would be better to have the Sales, R&D and QA teams receive the releases in the small increments first, then roll out to the external customers only when the team was satisfied that MVP was achieved. This way the customers would not be exposed to functionality that may not quite seem "finished" which may lower their confidence in the product. Using sticky notes on a whiteboard, different pieces of functionality were grouped according to themes, such as "ingredients," "packaging," "volume," "financial estimates," etc. Outcomes Each theme would have its own release. Tasks from Architects and other implementation SMEs were: Captured and estimated, Added to the estimates of effort for the stories on the map for MVP, Compared to a calendar, and Scheduled with rough dates for releases. As development continued, periodic checkpoints were set to ensure that the release plan was on course, or to see if it needed adjustment. Since the Next and Later iterations were not elaborated in detail, it was agreed to hold additional release planning meetings when they were closer to begin. Lessons Learned It was important to have the external customer represented when planning releases. The sales team: Had good relationships with customers, Knew the customers may be uneasy accepting smaller increments of functionality and did not want to take that risk. Agreed to represent themselves and the customer when accepting the releases. It was important to have the implementation SMEs who were not a part of the development team, present when planning a schedule. Including SMEs early in the release planning process allowed them the opportunity to update their own work plans and save room for these tasks on the scheduled dates. Otherwise, the team may have eventually faced a situation where they were ready to release but did not have available resources in the shared service teams to complete the releases.