In the day to day work of any product development team there are often situations in which the team decides not to implement some cool idea, or improve existing feature right away. As team rigorously prioritises work it often needs to put things “on hold“. There are several approaches on what to do in such situations.
One approach is to just close the tickets you are not implementing right away. This approach follows the philosophy that backlog should contain just the tasks the team is definitely going to work on, which would not be the case here. This approach requires no backlog admin, but the downside is that it requires an external system to store such “work for later“.
Alternative approach is to just drop the items that the team decided to put on hold in the backlog, without additional structure. In the future, during backlog grooming sessions team may decide to finally implement these postponed items. In this case there is almost no upfront backlog admin, but the situation changes over time. Backlog can quickly grow, become cluttered and really hard to navigate and to manage. This can be partly mitigated by regular “backlog pruning“ sessions, but lack of structure still makes the work much harder.
Third approach, and it is the one I prefer the most, is to group such postponed items in the backlog in themed “epics“. These epics are not exactly following scrum convention as they do not represent piece of work that should be done together, but rather they provide a way to group tickets in the backlog in whatever way is useful in a given product. For example, such epics may include “Improvements to dashboard“, “Billing improvements“, etc. As team plans future work, it can look through such sorted backlog in much faster and more productive manner, focusing their attention only on items that they want to review during one session. Ability to filter such epics out also allows to keep the backlog clean and structured.