Roles: Product-Owner

This checklist supports documentation teams in ensuring that userfacing content is accessible to all users, including those using assistive technologies. It can be applied during content creation, review, and prepublication.

"Area Path" and "Iteration Path" are standard fields in Azure DevOps (ADO), and they are used to organize work items by product classification, team, and time period.

For an introduction to the concept of baselining, see the Highlevel baseline guide.

This guide describes how bugs – when they are created in Azure DevOps (ADO) – also are classified to ensure that they are handled with regards to their severity and potential impact.

This checklist ensures that user documentation adheres to relevant regulatory, legal, and organizational standards. It is particularly important for regulated industries (e.g. medical, automotive, and industrial IoT) or when documentation is published publicly.

This guide describes the most fundamental parts of component capabilities. It also includes a flowchart of component capabilities updates and a list of attributes sometimes mistaken for component capabilities.

This conceptual guide explains the purpose of configuration audits and presents the main parts of a configuration audit and the highlevel approach adopted in PCP.

This is the overall description of how to handle configuration release management within ABB PCP.

The quality dashboard can help teams measure and compare product quality by setting appropriate widgets and queries. A common template based on standardized queries will help save effort and improve efficiency. By setting appropriate widgets and queries, the quality dashboard can help teams measure and compare product quality. A template based on standardized queries helps save effort and improve efficiency.

The "Definition of Ready" (DoR) are the checks performed when a system epic, epic, feature, story, or bug is defined and ready to start work on. The "Definition of Done" (DoD) is the checks performed when the work items are completed before it is closed.

The Development Team process manages the planning, prioritization, and visualization of all activities related to the development of software and hardware components. There are multiple development teams in each development stream.

Division testing (DT) is an optional testing stage carried out with ABB divisions (e.g., PAEN, PAPI, PADI) during the project if it is relevant to the respective product or system release.

The term Document Management includes both Office files and wiki pages. While the general processes are the same – such as version control, review, and approval – the specific procedures for each type of document differ and are described in the relevant guides.

Use this checklist to ensure user documentation is clear, consistent, accurate, compliant, accessible, ready for localization, properly reviewed, and finalized.

The definition of done (DoD) for L4 bugs are the checks performed when an L4 bug is considered completed.

During L4 fault tracing it may be required to send a debug release outside of PCP. This has to be handled with care as it isn't a formally released software.

A product issue is a uniquely identified problem impacting a product, requiring clear communication with various stakeholders. It must be documented with accurate information and version details and managed in parallel with bug management and product releases.

In emergency situations, software corrections may be required in a short time frame to solve a critical issue on the customer site. This type of emergency correction will be handled as a temporary correction (TC).

The purpose of this guide is to provide handson support to the roles involved in setting up a test plan and test suites in Azure DevOps (ADO), demonstrating the product's test coverage.

This guide describes how to use Markdown to document technical information using the Azure DevOps (ADO) wiki. The Markdown files can be reviewed, approved, and baselined with the code. The code and technical documentation can be restored from the same baseline when a released product needs to be updated.

This guide provides handson support for the roles involved in executing test cases and reviewing test results.

Introduction

A bug can exist in multiple releases, and such bugs can be challenging to track and fix. This guide describes how to manage them.

During the development of a release, if a bug is found but the CCB decides to fix it in a later version, the bug is deferred. After the official release, it will then be a known bug in the product or system.

A work item of type "Bug" can be used to suggest an enhancement, something that is not a real defect, but an idea for improvement. This guide describes how to handle enhancements as bugs.

Some minor hardware changes to products can be implemented without setting up a project. This guide describes the steps involved and the checklists that shall be used.

This guide describes the process for handling software vulnerabilities in products within PCP R&D. It includes instructions on everything from recording a description of a reported issue to documenting and communicating its remediation.

This guide describes how to determine if a malware suspicion is correct or false and how to handle both scenarios. It also includes information about how malware is detected in ABB software.

A bug is an unexpected problem in the software or hardware which can be reported for any issue in a product by e.g. product managers, product owners, test engineers, or customers (via L3 or L4 Support).

This guide describes the routines for stopping and restarting the manufacturing, delivery and/or ordering of products within PCP.

This guide describes the approach for mapping the lifecycle components derived from the technology product releases, to the branded products (800xA, Symphony Plus, etc.). It also covers how to gather the data and share relevant ECCNrelated information with the product classification team.

The purpose of configuration auditing is to objectively assess the integrity of a product, both from a functional and physical perspective.

This guide describes how to handle epics in streams. It includes examples of epic descriptions and information about the epic definition, grooming, and change management.

This guide describes how to handle features in streams. It includes examples of feature descriptions and information about the feature definition, grooming, and change management.

The purpose of this guide is to provide handson support to the roles involved in defining the system architecture influenced by requirements, captured in the system epics, epics, and features.

This guide describes how to handle system requirements and system epics. It includes descriptions and information about the system requirement / system epic definition, workflow, grooming, and change management.

For a new epic, feature, or user story, there may be a need to write new test cases or modify existing test cases. The purpose of this guide is to provide handson support to the roles involved in writing, updating, or reviewing test cases of a product.

This guide provides an overview of Kanban and its application to software development teams.

R&D quality dashboards can be automatically created, based on Azure DevOps (ADO) data, to support the organization in visualizing project progress based on quality key performance indicators (KPIs).

The PCP System Epic Dashboard is used to visualize the implementation progress of system epics, by planning and tracking child epics and features whose completion is required to fulfill a given requirement.

Product capabilities describe what the product “can do” for anyone who wants to understand its capabilities. They represent the product's property and are updated throughout its lifecycle through multiple releases.

This guide explains what a product issue number (PIN) is and how it is used within the PCP organization.

A Product lifecycle management (PLM) system enables collaboration between different functions by gathering all productrelevant data in one place. For hardware development, the choice is in Windchill. This page intends to be a goto page for how to find information regarding Windchill.

The product owner (PO) is a team member responsible for defining and prioritizing epics and features in the backlogs as well as securing the quality of resulting deliverables.

The product test verifies that the product to be released has acceptable quality. It applies to new products and maintenance/updates of existing products.

A regression bug is a bug that causes a completed feature that worked correctly to stop working after updates (e.g., system upgrade, system patching, or bug fixes). This definition applies both before and after releasing the feature to customers.

The requirements process describes how the market opportunities and system requirements are received from Portfolio and Product Management and transformed into epics, features, and stories.

This guide describes how system requirements in Decision Focus are broken down into system epics, epics and features in Azure DevOps (ADO).

The developer/author scope definition quick checklist.

This guide describes how Scrum can be used by teams to manage their work. Scrum is a framework that implements the principles of Agile as a concrete set of artifacts, practices, and roles.

This guide describes different types of software vulnerabilities and associated threats. It also describes various defense mechanisms that are typically needed to be prepared for software attacks.

This guideline describes the custom standard fields used in bug templates. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the Document Update work item type and the custom standard fields used in its template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Epic template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the custom standard fields used in the Feature template. For a more general picture of the standard work item template change process in Azure DevOps, see the ADO standard work item template change management process.

This guideline describes the fields used in the system epic template.

This guideline describes the custom standard fields used in the User Story template. For a more general picture of the standard work item template change process in Azure DevOps, see ADO standard work item template change management process.

This guide describes what system interfaces are, how they are documented, and how they are managed.

A system requirement review intends to improve the quality of the requirements. It applies both to system requirements and technology requirements.

The system test is a crucial step in the development process as it integrates and tests deliverables from the various development streams.

This guide gives an overall view of the test performed before a component, container, product, or system is released.

The test phase checklist is a general guide for users to gauge the quality of product build delivery before starting tests in system test (ST) or RAT. Further, tailoring can be done to align the checklist with any specific product.

This tutorial gives an overview of how to work with Markdown. It describes how to change content on the "PCP R&D Processes" website, and can also be valuable for anyone using Markdown in Azure DevOps (ADO).

This process area is responsible for the key processes involved in creating and maintaining user documentation. It covers principles, activities, artifacts, and dependencies to ensure comprehensive and accurate documentation.

This guide describes the different states of Azure DevOps (ADO) work items. Consistent work item state transitions are essential to enable consistent follow up on status.

The traceability of the work items shows the relationship between them in Azure DevOps (ADO).

This guide describes traceability between work products that are not in Azure DevOps (ADO).