The team backlog

In his excellent presentation on Heartbeat retrospectives Boris Gloger makes a passing reference to a team backlog. This chimed with me since I’ve had teams ask recently “where do we put tasks we know we have to do but are not on the product backlog?”.

This is an interesting questions (IMHO). Should tasks exist if they are not on the PB? Who gets to prioritise? Is this a good way to handle technical debt?

I have used such a backlog but with certain rules. A team keen to keep track of previously accrued debt did maintain their own backlog. This could have items added to it by a team member at any time. The team would take items from the team backlog into the sprint often as an output from the retrospective. This worked because the product owner understood the importance of clearing away technical debt.

I do still have reservations. Who owns the technical debt on a project? The team are best placed to identify such debt but is important that a team backlog is not hidden from the product owner. We cannot absorb velocity with no regard for the product owners needs.

The team that I used this technique with had the team backlog large and visible next to the task board. Items were proposed to the product owner during the planning meeting. Acceptance of tasks from the team backlog into an iteration formed a part of the commitment for that iteration.

The product owner needs to care about technical debt. Making debt visible is a teams responsibility. Providing capacity to pay back accrued debt is the responsibility of the product owner.