Work Breakdown Metric

The Work Breakdown metric provides insight into the type of work your team is delivering—whether it’s new development, updates to legacy code, or revisions to recently written code. Understanding the distribution of this work can reveal trends in innovation, technical debt, and code quality.

Work Type Classifications

LinearB classifies every line of code change into one of three categories based on the file history and timing of the last modification:

• New Work
  Brand new code added to the codebase. This includes feature development, greenfield code, or entirely new modules and components. New Work typically indicates innovation and forward momentum in delivering new functionality.
• Refactor
  Updates made to legacy code—that is, any code that hasn’t been modified in the past 21 days. Refactor work often involves improving readability, structure, maintainability, or performance without changing external behavior. It’s essential for managing technical debt, but excessive refactoring during active sprints may signal misaligned priorities or hidden stability issues.
• Rework
  Changes to recent code, defined as any code modified within the last 21 days. Rework is expected during the iterative development process—for example, when code is updated after peer reviews or internal testing. However, consistently high levels of rework may indicate problems with initial implementation, planning gaps, or unclear requirements.

Interpreting work breakdown

A balanced distribution of new work, rework, and refactor is typically a sign of a healthy engineering process. While some variation is natural, an overemphasis on one category at the expense of others can signal inefficiencies or misalignment with team goals.

For example:

• A team investing heavily in refactor work may be addressing technical debt, but too much can stall feature development.
• A team focused entirely on new work may risk accumulating long-term maintenance issues if older code is never revisited.
• Rework is expected—especially during peer reviews and iteration cycles—but consistently high rework may point to deeper issues like unclear requirements, poor code quality, or overly large PRs.

The ideal mix depends on your organization:

• A high-growth startup may skew toward rapid feature delivery, resulting in mostly new work and minimal refactoring.
• A regulated enterprise, like a bank or healthcare provider, might prioritize maintainability and reliability—leading to a higher ratio of refactor and rework.

Ultimately, your Work Breakdown data should reflect the priorities and values of your team. Use this metric to confirm that your team’s coding activity aligns with business goals and engineering standards.

Viewing Work Breakdown

• Click on the arrow icon in the top right corner to see all branches represented in your work breakdown graph.
• Click on the graph icon to see your work breakdown over time.

Calculating Work Types

LinearB determines whether a code change is categorized as new work, rework, or refactor using git blame analysis.

• If a line of code did not exist in any earlier commit, it is classified as new work.
• If the line did exist and was last modified more than 21 days ago, it is considered refactor work.
• If the line did exist and was last modified within the last 21 days, it is identified as rework.

Unlike a simple diff against the main branch, LinearB evaluates the entire commit chain leading up to the current commit. This ensures accurate classification—even when prior changes haven’t yet been merged to the release branch. As a result, rework performed during the code review process is still accurately detected and included in reporting.