Last week I blogged about Improving your ITSM system in a release driven way.. The idea is to control the backlog of requests for enhancements to your ServiceNow system and get them into production with the minimum risk, fuss and delay and with the maximum of testing and quality assurance.
As we go through the series of blog posts we are going to talk about the Scrum product backlog, moving enhancement requests into releases and sprints. For the moment we are still thinking about the best way to take requests from the business and order them in a sensible way.
The previous blog post recommended getting the stakeholders (referred to in future posts as the "Product Owner(s)") to express how beneficial and urgent each enhancement is.
A typical backlog of ServiceNow enhancements would include requests from HR, Facilities, the Servicedesk as well as other functional technical teams. The requests might relate to new processes, reporting, form changes, new notifications and new integrations. There is a lot to consider.
By getting the business to rank their changes by two factors - Benefit to the customer and urgency - allows each individual enhancement to fall into one of four categories on our "Do When" chart.
- Do Now - High benefit, High urgency
- Do Next - High benefit, Lower urgency
- Do Later - Lower benefit, High urgency
- Do at all? - Lower benefit, Low urgency
You may struggle to think of examples of enhancement requests that are "Do Later - Lower benefit, High urgency". I do too, but this is a rough sorting mechanism to visualise each enhancement in relative terms to each other.
One question we had when using this method at ServiceNow is what does "Do Now" mean? When do I get my enhancement?
When using this system it's important to reveal the entire process, including the concept of promoting a Process Enhancement Request to a Scrum Epic, scheduling into a Release and Sprint. "Do Now" is a rough sorting system, whether the enhancement is deployed this afternoon, tomorrow or next month depends on the complexity and available resource. Don't make time committments based on this "Do When" chart.
This blog post describes an implementation of a Process Enhancement Request system in ServiceNow. Attached is an update set that you could take and verify on your sandbox, dev, UAT and possibly, eventually your production ServiceNow instance.
The update set comes with 3 warnings:
- It is a potentially risky process to take Update Sets from anyone (including ServiceNow) and trust that they won't break your system. Please make sure that you test this update set in a non-production environment before actually using it.
- The XY chart is generated using direct calls to jFreeChart (which is included in your ServiceNow instance). Charting is normally done through an abstraction layer of Script Includes. Basically there is a slightly higher chance of this chart breaking between upgrades if jFreeChart ever changes, but we'd hit that problem before you would 🙂
- You need the Custom Charts plugin loaded before applying the update set. To follow the entire Release Driven approach you also need to have the SLDC - SCRUM plugin loaded.
If you were to use the attached Update Set you would find a new table called u_process_enhancement which is a child table of task. This means that you get all of the regular useful fields such as Assigned To, Assignment Group and so on.
The table is accessed via a module in the Self Service application called All Process Enhancement Requests.
The module is restricted to users with the itil role, but you might choose to let all users have the ability to log requests. You could also have a Record Producer to make submitting requests a little more user friendly. In the Update set only the itil role has read access to the table, so if you open up the permissions remember to change the ACL too.
When a new record is created the user is prompted to complete the following information:
- Due Date: Is there a certain date when the enhancement must be deployed
- Primary Contact: A reference to the User table.
- State:
- Requested
- Work In Progress
- Closed Complete
- Closed Skipped
- Business Group: Who the enhancement is for. Also used to build different "Do When" charts
- Change Request: A reference to the Change Request table
- Assignment Group: A reference to the Group table. Useful if you have multiple teams developing on ServiceNow
- Short Description:
- Description
- Work Notes
Internally we also ask the requestor for a Business Case etc. There is a form section for you to add more fields if applicable to you. I've left our requirements capturing fields in the Update set, you may wish to remove them.
Once the request is entered a UI action appears inviting users to Prioritise Enhancement. If users wish they can subscribe to the "Process Enhancement Request created" subscribable notification.
Each user can prioritise an enhancement once only (that is they can edit their own rating, but can't vote twice) and the scores they submit are averaged out and kept in the Benefit Rating and Urgency Rating fields on the Process Enhancement Request record.
So if you have a Process Enhancement Request record that is rated by 2 people:
- Alice rates it 6 for Benefit and 4 for Urgency
- Bob rates it 8 for Benefit and 6 for Urgency
The averaged rating of the request will be 5 for Benefit and 7 for Urgency putting it just into the Do Now quadrant.
Enhancement requests are plotted into the "Do When Matrix". This graph shows all enhancement requests for the Business Group. Note - the idea is to show the relative Urgency and Benefit when compared to other requests for the same Business Group.
Having the data "sliced" into Business Groups stops the graph getting too busy, with too many data-points.
Lastly, in the Related Links section there is a link to Create Scrum Epic which is the subject of the next blog. This link is only available to users with the process_enhancement_manager role.
Creating a Scrum epic indicates that the group responsible for ordering the process enhancement requests have ranked it accordingly and are happy that it should proceed.
In summary, the Process Enhancement Request table is an area for the Business to enter their requests, and a mechanism for them to rate the requests by Benefit and Urgency.
Next time we'll look at the Scrum objects involved in organising your enhancement backlog.
[EDIT]: I forgot to mention once gotcha with the update set! Some of the data points on the chart will be a very similar colour to the green background, making them hard to see. I have that on my list of things to fix. ~sm
8 Comments
