All ServiceNow teams are in a constant 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 will review what the ServiceNow backlog is, what underlying complexities to expect, and discuss some of the most effective ways to manage and win this backlog game.
So what is a ServiceNow 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 behind you are on meeting your objectives. Product Managers and Product 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 really solving the ServiceNow backlog problem.
The problem with the ServiceNow backlog isn’t the recording or the visual management; 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 cunning ways your ServiceNow backlog is whipping you:
- Instance “drift”
- 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. Unfortunately, the dependency matrix 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 data loading, executing fix scripts, and mending items that ServiceNow does not capture in an update set automatically.
This has led to the current release procedure in many organizations, which includes detailed and convoluted documents for each release, a staff of multiple people present in each release to cover any potential problem that might happen during the release window, etc.
Back to the ServiceNow backlog.
As I have already mentioned, the ServiceNow 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 ever growing 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 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 progress on the backlog and catching up with demand and the pace of new requirements is entirely dependent on our ability to solve the underlying problem.
Namely, the lack of modern deployment and release capabilities natively in the platform.
ServiceNow development bottlenecks tend to cluster around a few key issues:
- Core platform process complexities, especially at scale
- Multi-instance architecture, lack of “environment view”
- Feature and mechanism complexity; update sets, store applications, version control, plugins, data…
- No out-of-the-box support for CI, CD, or Release Management/Release Automation
- Administrative complexity
In addition, there is no orderly release process built into ServiceNow, meaning organizations create their own ad hoc manual processes. Team leads and product managers are essentially using spreadsheets and even Microsoft Word to document the release process, including what needs to be deployed and in what order prior to release. These types of failure-prone manual processes vary from organization to organization, it’s no wonder that delivery times for ServiceNow apps have been notoriously slow and eventually showing up as a backlog problem.
Implementing a continuous delivery model with ServiceNow requires that you both automate deployment and handle all the inherent complexities, including chaining of test automation, change management processes, and security and compliance tools. Creating a continuous deployment chain will turn your landscape into a truly agile continuous delivery factory and help your team keep up and get ahead.
To learn more about this and get practical advice you can download our free e-book on Mastering ServiceNow DevOps.