Change Control Board

The Change Control Board (CCB) is a team of experts responsible for deciding whether to implement software, hardware, or documentation changes based on bug reports.

Description

The CCB is responsible for deciding on bugs that cannot be resolved otherwise. These bugs may originate from L3/L4, and an initial analysis may be conducted to determine which teams or individuals the bug should be assigned to. Bugs can also arise from tests and be escalated to the CCB if the teams cannot resolve them.

Product owners and teams should strive to make decisions independently without involving the Change Control Board (CCB). To coordinate decisions across different teams, use the Program Increment (PI) sync meetings (e.g., product owner syncs and scrums of scrums). Ensure that the CCB does not take over responsibilities that belong to other roles, such as product owners, architects, technical coordinators, and release owners.

Depending on the needs, the CCB can be established permanently (e.g., on system, product, or component levels) or temporarily (e.g., close to a release when quick decisions about fixing or deferring bugs must be made). The CCB can improve the flow by providing faster decisions about bugs that do not impact the scope, budget, or timeline, and reduce escalations to the steering committee.

The CCB consists of permanent members such as product managers, product owners, release owners, technical coordinators, L4 coordinators, and representatives for L3. Optional experts can be invited when needed.

The configuration management (CM) plan details the organization of the CCBs, the participants in meetings, and their respective roles. The CM plan must also include an agreement on the minimum number of attendees necessary to facilitate decision-making during meetings.

CCBs collaborate closely with L4 support and involve L3 support in managing external requests and establishing priorities. In urgent situations, the CCB can initiate investigations and corrections, even if they impact current PI planning, which may result in reorganization or reprioritization of ongoing work.

Forums for handling bugs:

1. Daily Standup with product owners and teams.
   Managing introduced bugs from unit and component tests (reported after a feature is completed).
2. Sync meetings with product owners and product managers (PPM).
   Managing bugs from product and system tests across teams.
3. CCB meetings with experts (SMEs) in a stream or product line.
   L4 bugs, and bugs from product and system tests across streams or product lines, or when senior experts are needed to analyze the bugs.
4. Steering committee
   Bug corrections that affect scope, budget, release time, or quality

Note: Quality control managers (QCMs) independently report quality issues to the steering committee, including bug trends and status.

Responsibilities

• Handle level 4 (L4) requests: Respond to L4 support requests and start maintenance actions when necessary.
• Review and prioritize: Assess bugs' priority and severity and determine recommended actions for resolution.
• Ensure informed decision-making: Gather and assess all necessary information from development and test teams to make informed decisions about bug fixes, initiating further investigations if required.
• Approve corrections: Ensure the changes do not negatively impact quality, performance, reliability, standards, and similar factors.
• Communicate decisions: Document and share resolutions with stakeholders to ensure transparency and alignment.
• Analyze metrics: Monitor bug metrics to enhance quality and reduce technical debt.
• Escalate issues: If bugs substantially affect the project's scope, budget, or timelines, escalate them to the Steering Committee for resolution.