How to Address High Risk Work

LinearB classifies work as high risk when a branch meets both of the following conditions:

• Contains more than 100 code changes
• More than 50% of the changes are rework or refactor work

High-risk work introduces a significant quality risk to your codebase. When branches with a large number of changes are merged, especially when much of the work is refactoring, the probability that something breaks increases substantially.

• The more code changes that are merged, the harder it becomes to thoroughly review, validate, and test every modification.
• Legacy code often interacts with other parts of the codebase in unexpected ways. Refactoring large portions of existing code increases the risk of impacting hidden dependencies and reduces the likelihood that all affected areas are fully tested.

To find high-risk branches:

1. Open the Activity tab.
2. Click the Filters menu.
3. Select High-Risk Work.

By default, this filter identifies branches with more than 100 code changes and where more than 50% of the changes are rework or refactor work.

To reduce the risk of unexpected bugs introduced by high-risk branches, consider one or more of the following actions.

Assign more than one reviewer

Having multiple reviewers increases the likelihood that quality issues are identified and resolved. More reviewers also increase the chance that someone is familiar with related areas of the codebase and can spot unexpected dependencies.

In some cases, it can be beneficial to make the review process more collaborative by reviewing the changes with the entire team. The pull request author can walk through the implementation while team members ask questions and highlight potential risks.

Assign a team leader or senior developer

Reviewers who are deeply familiar with the codebase are more likely to identify quality issues. For large or complex branches, it is a best practice to select reviewers based on relevant experience and expertise.

Increase unit and integration test coverage

High-risk branches should include increased test coverage for both unit tests and integration tests. Higher coverage improves the likelihood that newly introduced issues are caught early.

This is especially important for refactoring work. If changes break interactions between components, integration tests are more likely to surface those failures.

Break down the work into smaller subtasks

Exceptionally large branches are difficult to review and test effectively. When possible, break the work into smaller subtasks and create separate branches for each one.

Review, test, and merge each subtask independently. This improves review quality, test coverage, and overall delivery safety.