Managing ServiceNow Demand

[chuckn]

Hi all,

I'm curious: how do you manage your ServiceNow demand, whether that's for new catalog items, enhancements to processes, altogether new functionality...all of the above? Do you have catalog items with the requisite variables for the information you need? Do you track how long it takes to complete different types of work, such as developing a new item or modifying something existing? Do you use ITBM/SPM idea and demand?

Thanks!

-Chuck

[Jace Benson]

I've seen things done a number of ways.  I try to take notes about how I've done things in the past.

Keep in mind that the thing our customers want is working software.  I really think this video by NoBoilerPlate tells it better than I could.  https://www.youtube.com/watch?v=9K20e7jlQPA

That being said here's my notes about how I've seen this done at a few places in the past.  They all use catalog items to create either vtb_cards or scrum tasks.  It seems all these employers want to track how much work it is, how much work do we think it is, and how much work are we getting done but really what is done?  It's all working software when we deliver it so doe tracking the hours really make software better?  I am jumping off the tanget.

Here's the processes;;

I'd love to see how others do it too.

[Ryan S]

This is a fantastic question. There are so many ways to do this it'll be great to hear what people have done.

We've looked at idea/demand and I often tell people how ServiceNow rolled out the Idea Portal and the process behind those tickets. It's great to have a real example to show from the user perspective.

For one client, they are heavy on Agile so they use the rm_enhancement record. There's a way for the user to submit one from the portal or the team may create one off an incident or other generic request, should it be needed.

In the past I've also seen where it's just using any old tracking system, such as JIRA or the Agile module.

Ultimately it comes to governance. Make sure you have a clear governance model and defined process. Set expectations for users and provide transparency as you implement the work.

[chuckn]

Thanks for your replies, Jace and Ryan!

Jace, that video...it's got me questioning a lot of things now! 🙂

We use SAFe at my company for larger scale planning and my smaller ServiceNow platform team is very Agile focused.

I think a large part of what I'm charged as the team manager is prioritizing our backlog (not necessarily [ever?] first in first out) and setting/managing expectations with customers and management..."when will this new catalog item be ready," "when can we have this new feature," etc.

The front end for all of our work is catalog items with associated sophisticated workflows (eg multiple tasks for dev, test, deploy...creating standard CHGs for simple modifications):

• Create a Catalog Item
• Modify a Catalog Item
• Remove a Catalog Item
• ServiceNow Development (aka everything else)

We review/approve new requests every day. We create stories from the dev tasks and use the Agile board for daily stand-ups. We don't spend a lot of time estimating stories, but we do estimate points in order to put a plan together for bi-weekly sprints...to help manage expectations and to help the team focus on that set of work (as opposed to seeing the entire backlog every day, which was overwhelming and distracting). We do frequently add things to sprints as individuals have capacity to take on new work...and we do frequently move stories to the next sprint because we haven't quite finished them yet.

What initially prompted my question was measuring the average amount of time to complete those different types of requests and how often we have requests just waiting in the backlog because we only have so many people on our team (and therefore can only do so much at once). I was curious who might have other approaches that could differentiate between time pending in the backlog and actual development work...I don't have a good way to measure that at the moment.

Thank you for the conversation!

[dklimas]

One option to measure the Story state duration is to use Metrics.  I see an OOB Story metric definition for Story state called "Scrum: Story State Duration".