What Is "New Work" vs. "Other Work"?

Updated 1 month ago by Jaala

GitPrime helps you see the different types of work

  • New Work—Brand new code that does not replace other code. 
  • Legacy Refactor—Code that updates or edits old code.
  • Help Others—where a developer modifies someone else’s recent work (less than 3 weeks old)
  • Churn—Code that is rewritten or deleted shortly after being written (less than 3 weeks old)

New work 

New work is a measure of how much fresh, blue sky work is happening over time. The amount of attention to new work depends entirely on the phase of the product and business. It is very normal for a growing company to aim for more than 50% of their work to be "New Work" which is indicative of forward progress. 

Legacy Refactor

Legacy Refactor is the process of paying down on “technical debt”—is traditionally very difficult to see. New feature development oftentimes implies re-working old code, so these activities are not as clear cut as they might seem in Scrum meetings. As codebases age, some percentage of developer attention is required to maintain the code and keep things current.

The challenge is that team leads need to properly balance this kind of work with creating new features: it’s bad to have high technical debt, but it’s even worse to have a stagnant product. This balancing act is not something that should be done in the dark, particularly when it’s vital to the success of the whole company.

Objectively tracking the percentage of time engineers spend on new features vs. application maintenance helps maintain a proper balance of forward progress with long-term codebase stability.

In the Project Timeline report, you'll find a leaderboard for the top contributors to Legacy Refactoring, and for the other types of work:

Help Others

Help Others describes how much an engineer is replacing another engineer's recent code—less than 3 weeks old.

Churn

Churn is when a developer re-writes their own code shortly after it has been checked in—less than 3 weeks old. A certain amount of Churn should be expected from every developer.

For example, a Churn rate of 9-14% for a senior engineer might be completely expected. Unusual spikes in Churn can be an indicator that an engineer is stuck. Or high Churn may also be an indication of another problem like inadequate specs. Knowing immediately as your team is experiences churn spikes helps you have timely conversations to surface any potential problems.

📝 You might like: 6 Causes of Code Churn and What to Do About Them



How did we do?