When managing tasks, there's a simple principle to follow: if a task keeps getting postponed and something else always takes priority, it might be time to accept this fact and remove it. There's no need to keep it lingering in the backlog or to keep shifting it from one sprint to another. If this happens, teams will start losing faith in the backlog as a current and relevant tool. They'll stop trusting the set priorities if they constantly change and will come to you asking for the next task to work on.

Just delete it. Don't assign it a low priority; create a special status for closure so that it doesn't hang around anywhere, not even at the bottom of the backlog. If you have a tail of tasks that are always there and visible to the team, remove them.

If the priorities are valid, but there's always a tail of tasks that never gets done, the team will again ignore the backlog. They'll come to you with the question, "What's next?" Even if there are only five tasks in the backlog, with two perpetually at the bottom and new ones always appearing at the top, they'll still come to you because your backlog isn't working.

If you want a manageable team, keep the backlog clean. Train the team and lead by example to show that the backlog is a tool they can work with, trust in, and manage without your constant involvement. It's much easier to maintain a clean backlog than to micromanage the team. Not only are you distracted, but so is the team. They won't look beyond their current task because it's unclear what else to consider.

To address the concern, "What if we suddenly need it? It's an important task," remember that if your backlog is cluttered with unnecessary tasks, it will be ignored, and duplicates will be reported anyway. There's no point in keeping such tasks. Keep them for yourself. Create a 'Removed' status and make it possible to change it back to 'New' if needed. This makes it psychologically easier. After a few months, review the statistics. You'll realize that no tasks are ever reinstated.

Even if something important does come up again, it will resurface with a new context and a fresh perspective.

What if a developer reports something important to not forget? The same rule applies. If it's being postponed, it goes to 'Removed'. Explain that this doesn't mean their input is disregarded (although, if you didn't prioritize it, in a way, it is – be honest with yourself). Is it truly important? Review the task description; it's likely that no one besides the reporter will understand what it's about or why it's needed. Imagine if they left the company. Who would take on the task? Probably no one.

If a developer has an important idea or task they don't want to forget, it's better to handle it differently than just adding it to the backlog. Encourage the developer to keep their ideas in personal notes and to discuss them with you in one-on-one meetings. This approach is much more effective in making team members feel that their contributions are valued, rather than letting their suggestions languish at the bottom of the backlog.

By engaging in direct discussions, you may gain deeper insights or better align the team, leading them to suggest more impactful and valuable ideas. Remember, one-on-one meetings have their own dynamics and benefits. If an idea isn't immediately valuable, it doesn't belong in the backlog, which should not be used as a dumping ground for every thought. The backlog is a strategic tool, meant to prioritize and organize tasks that are ready to be tackled and are of clear importance to the project's current objectives.

Keep your backlog clean, and your teams will thank you.

The Rule of Handling Tasks That Never Get Done