29. Here’s why you need a technical backlog

Product owners and their development teams always face the same problem: the product owner advocates for new features, while the developers demand time for refactoring. The technical part often gets neglected, causing technical debt to pile up. The problem, however, is not in the harsh reality of the business world, but in the programmers’ inability to manage the technical backlog properly. Their backlog usually consists of tasks like “To refactor a controller.” The value of such tasks is not obvious to the product owner. Here are the key principles of turning scrappy tasks into a proper backlog:

1. VALUE. Tasks need to be organized into epics; each epic must contain a clear, valuable action. Here’s an example of a bad epic: “Refactor the project”, and a good one: “Improve the building speed from 5 minutes to 20 seconds.” Another bad example: “Rewrite JS”. And a good one: “Improve the speed of new report development from 2 weeks to 1 day.”
2. EVALUATION. Each separate task and each epic in the technical backlog need to be evaluated using the same units as in your product backlog. Store points, S/M/L — anything works, just make sure it gets evaluated.
3. REGULARITY. Managing a technical backlog needs to become a regular thing in your calendar. In our team, we hold 1.5-hour backlog grooming sessions twice a week.

Following these principles will make it easier for the development team to communicate with their product owner and set correct technical tasks in each sprint.

NEXT: 30. Do not postpone a release

PREV: 28. Technical debt and how to handle it

Tales of a Product Owner: concentrated wisdom about project management, team creation and UX.