Your backlog will only grow bigger. And that's OK.

28 Apr 2024 - Frans Vanhaelewijck

Why do you need a backlog?

A backlog serves as a crucial tool for managing tasks or features that are not currently being planned as part of your product development. By keeping a well-maintained backlog, you can limit your work in progress (WIP), ensuring that your attention and resources are focused on your current priorities. Humans and teams of humans have a limited attention span, so the less items on your WIP, the better. Numerous articles discuss the positive impact of reducing your work in progress (WIP) on enhancing your team’s throughput, but that topic is beyond the scope of this article.

Backlog items come in multiple flavors

Not all of your backlog items need to have a fixed priority or due date. In fact, most will not have a due date. In product development, a growing backlog is a natural occurrence and should be accepted as such.

Prioritized & Planned Backlog Items

A small subset of backlog items may be assigned a priority and planned for a specific date. These tasks could be related to time-sensitive events or commitments made to customers. For example, they might be associated with year-end closings or specific promises made to customers.

Will it come back to haunt us?

Another category worth managing is items that might cause problems in the future if not addressed. (I call these “This will come back to haunt us” list) These items are often identified by development teams or business analysts as potential issues that may arise at a later date. It can manifest itself as application downtime, urgent priority 1 ticket in the weekend, escalation to the CEO and other stress inducing problems.

By regularly reviewing and allocating resources to tackle the tasks on this list, you can prevent future crises and minimize support-related issues. Make sure to set up an indicator on your dashboard to spend time on this list and implement the ones that have the most impact.

Essential Attributes for Managing Backlog Items

Besides the typical attributes, make sure to add these:

• Unique identifier (ID): Source event details, such as the origin of a customer question, the context of a meeting, or the specifics of a sales conversation. Make sure to add it, because everyone in the team will have a different memory about it.
• Backlog item history, including updates and revisions made over time: Tracking these attributes helps ensure that each backlog item can be easily identified, revisited, and updated as needed. Some teams even keep ‘Revisited’ counters that are incremented each time a backlog item is discussed again but not implemented.

Work the list

To maintain an organized and relevant backlog, be sure to:

• Prune and maintain the list regularly
• Ensure proper documentation and titles for each item
• Update history logs as items are revisited

There’s a bad smell in here

When looking through some backlog lists in the past, I sometimes got an uneasy feeling, like experiencing a bad smell when you enter a room. This is when there are many backlog items that refer to unfinished feature requests. You know that urgent feature that needs to be developed superfast. This deadline is met, but there are many aspects about the feature that are not yet implemented and that are consequently put on the backlog. This is to be avoided at all cost as it indicates a poorly managed product. The cure is to develop and maintain a “Feature Complete” checklist. This typically contains topic like

• Multi-language aspects
• Impact on apps or on responsive design’
• Is there an impact on our APIs?
• How are our user roles and rights impacted?
• Is there an impact on installation or customer onboarding?
• Is our Privacy Policy impacted?
• Did we use any new libraries?
• and so on.

Creating this feature checklist for new developments can help prevent the backlog from becoming cluttered with incomplete tasks. This approach can help maintain team morale, encourage a sense of accomplishment, and prevent feelings of inadequacy.

Deciding Whether to Make Your Backlog Public

I generally advise against making a backlog public for several reasons:

• Intellectual property concerns, as you don’t want to reveal valuable information about missing features that competitors might exploit
• Potential negative customer reactions to incomplete or missing features, which might cause them to question the quality of your product
• The inherently incomplete nature of many backlog items

Embracing the Growth of Your Backlog: A Conclusion

The conclusion of this blog post is plain and simple: Your backlog list will only grow and that’s okay.