All ServiceNow teams are “making battle” with an ever-growing backlog and losing. Backlogs are always more significant than your capacity to execute them. And the business meaning of it is simple – a hampered down return on investment. The backlog reflects many underlying issues which can unlock hyper-growth with ServiceNow and enable you to drive more functionality, more innovation and more business value from ServiceNow itself.

In this article I am going to review what the backlog is, what are the underlying complexities and discuss some of the most effective ways to manage and win this backlog game.

So what is a backlog?

In its simplest form, a backlog is the list of everything you need to complete.

In ServiceNow, just like any other development project, your backlog represents the high-level requirements (a.k.a. “Epics” in backlog speak), the smaller building blocks of those (a.k.a. “User stories”), and the list of bugs and fixes that need fixing. As a whole, your backlog represents how far you are behind on meeting your objectives. Product managers and owners “groom” the backlog regularly, add new features and requirements, rank each element’s priority and track development teams as they clear items off the list, day in and day out. The backlog “feeds” developers. On the surface, this is a perfect system, usually represented in a friendly UI with drag and drop functionality and some fancy kanban or any other fancy board view. Excellent tools like Agile 2.0 in ServiceNow or Atlassian Jira make managing the backlog pretty straightforward, and It’s all goodness.

Except it’s not.

The problem with the backlog isn’t the recording of it or the visual management of it. The problem with the backlog is that it depends on your ability to execute against it, and that is where “real-life” comes into play, more significantly if your organization has grown.
The frustration happens when you realize that instead of clearing the backlog, it just keeps growing and growing, and at some point, you just can’t meet your business objectives no matter how much you grow your team and your ServiceNow instances count.
Here are a few of the canning ways your ServiceNow backlog is whipping you:

  • Dependencies
  • Instance “drift”
  • Rework
  • A narrow, messy pipeline
  • The dreaded production release

Dependencies can occur due to “pure” technical reasons like when one user story implementation depends on another being ready ahead of it but can also be related to resource availability such as a testing instance availability, and, even occur due to time constraints. The dependency matrix, unfortunately, becomes even more complex over time. ServiceNow instances tend to drift apart in configuration and versioning state due to a lack of shared code base and synchronization. These complexities eventually lead to rework due to the complex dynamics of scaled ServiceNow development.

ServiceNow production releases are also notoriously fragile. Release managers need to ensure everything is ordered correctly to protect against merge conflicts, developers are needed on hand in case of any code issues and there are multiple nuances with regards to loading of data, executing fix scripts and items that ServiceNow does not capture in an update set automatically.

 This has lead to the current release procedure in many organizations, which, includes detailed and very long documents for each release, and a staff of multiple people peasant in each release to cover any potential problem that might happen during the release window, etc.

Back to the backlog. 

As I have described above, the backlog reflects many of these underlying issues. When we talk to platform owners and the ServiceNow core team leaders, we often hear the problem described as an evergrowing backlog and an explosion in demand thanks to ServiceNow’s constant product innovation and a real challenge meeting business needs. 

So how do we solve for this?

When considering this problem, I believe the most important fact to keep in mind is that the backlog is merely a representation of the underlying complexities I explained above. Solving for progress on the backlog and catching up with demand and pace of new requirements is entirely dependant on our ability to solve the underlying problem.
Which, is what we explain, in detail, in our free e-book on Mastering ServiceNow DevOps