Introduction

There are a lot of things you want to track in a project. Broad strategic goals, milestones, planned features, requested features, technical debt, and reported bugs to name a few. Too much is often added to the backlog, leading to enormous monstrosities that seriously impede team efficiency.

Keep the backlog short

It is our strong recommendation that the backlog should be kept short. It must only contain items that the team is going to work on in the near future. The backlog is not the place to plan future functionality, collect feature requests, or record ideas. It is a tool used by the project team to understand near-time goals and to manage and organize day-to-day work.

Keep the backlog relevant

The backlog must be continuously managed and kept up-to-date. This is primarily done through two activities:

• Pruning: During pruning we remove duplicates, items that have been solved by other means, items that are no longer relevant, and items that have been inactive for too long. Everything in the backlog has to fight for its survival.
• Prioritization: Items are prioritized by urgency of the end-user, business needs, difficulty of implementation, and synergies with other initiatives.

What about all the other other things that must not be forgotten?

You can record them anywhere you want, just not in the backlog.

That doesn't mean that you can't put these things in the same project management system as the backlog. Quite the opposite. It is often a good idea to work within the same system in order to minimize the number of tools in play, and to make moving items in and out of the backlog easier.

Examples of things we often track close to the backlog:

• Feature requests from end-users and other stakeholders.
• New ideas that need to be ironed out.
• Tech debt and engineering related items that are currently hard to prioritize.
• De-prioritized items, ideas where the value isn’t clear, or items that may never materialize.
• Rejected features that have been discussed but that we’re fairly certain aren’t going to be pursued.
• Features and initiatives that are being prepared for the backlog.

Some additional tips related to working with backlogs

• As a general rule of thumb the backlog should only contain items related to the current milestone in the roadmap, and any recently discovered bugs that the team has to address more or less immediately.
• Maintaining the backlog is a team effort. Discuss, raise concerns, work together.
• It is sometimes a good idea to set a hard limit on the backlog size. If the backlog is full something has to be removed give way for the new item.
• If the backlog grows too big, burn it and start again! Trying to recover from an overgrown backlog is usually not worth the effort required.
• Give items in the backlog a "TTL" (Time to live). Delete items when they expire. If something is genuinely important it will resurface and get added again.
• Since we’re not spending time trying to fill the backlog up with things we might never build, there should be time to give the items we do add some love. Clarify requirements and acceptance criteria. Add context. Discuss implementation details.
• Divide and conquer.