Continuing with my series on using Scrum methodology to improve your ITSM system.
Last time we covered some of the key roles that we need to identify to get started with our improvements as well as some terminology and concepts.
We talked about:
- The Product Owner(s)
- The Scrum-master
- The Development team
- Stories
- Epics
- The Product backlog
- The Release and Release backlog
- The Sprint and Sprint backlog
Now it is time to start to build some data structures in our ServiceNow environment to support all of these concepts.
I'm using Aspen Patch 2 in my screenshots here so you could follow along on your own instance or on demo.service-now.com
By the end of this blog post you will have created a hierarchy of Scrum objects that looks like this
You will be writing Stories that describe functionality that users want, assigning them to Releases and Sprints and getting ready to start writing these features.
Creating your Products
Lets start by creating Products. A Product groups together features that relate to a particular process. In fact you might create a one-to-one mapping of ITSM processes to Scrum products.
You could also get away with creating a single product for all of your ITSM enhancements but a key design decision is this:
Who are your Product Owners? You associate Product Owners to Products.
In the last post we describe the Product Owner as someone who can translate business requirements to features. He/She would also be responsible for prioritising those storys and the overall quality of the product.
So if your organisations is large enough to have different Product Owners for each of your ITSM processes you should create multiple products.
To create this locate the Scrum application in your instance
A Product looks like this.
The Number, Short Description and Description should be self-explanatory to you seasoned ServiceNow administrators.
The Configuration Item is helpful when using Scrum software product development role. You would use this field to point the Product to a CMDB CI record representing your companies software product. We don't need this field in the context of ITSM process enhancement.
Once you have saved your Product go and edit it again to look at the related lists.
In my example below I have created 4 Products for the processes that my project is going to enhance.
IMPORTANT: To follow this article, and for general best practice you should now add 2 related lists to the Product form. The Epic->Parent and Story->Parent related lists are needed to build your Product Backlog
Creating Epics and Stories
As a reminder both Epics and Stories contain a description of a feature desired in the application by a user.
A Story is a unit of work that could be completed by a single developer or perhaps a pair of developers. It describes how the feature should work from the users point of view.
An Epic is simply a story that is loosely defined. Perhaps it describes a bigger piece of functionality, or is a container for multiple stories. You could say an Epic is a coarsely defined Story.
Essentially we need to know that we are going to take Stories and place them into a Release, and we cannot do that with Epics. So use Epics in one of two ways:
- Use Epics for lower priority features. When they become higher priority create stories and add more detail
- Start your specification with an Epic, planning to break this down into Stories later on when you have more detail
- Use Epics to group together similar stories
When writing Stories a certain style is traditionally used. We care about features that matter to users and so we normally write the story (or describe the feature) using language that the user would use.
For example our story might read:
As an Incident Owner I am able to view the remaining Response SLA as a percentage value on the form.
When it's time to develop your system to complete this story you will have a good idea of who the feature is for and what that person wants to achieve.
It's much better than describing the feature using language that is only relevant to the Development Team.
Lets create a Story that is associated with the Incident Mgmt product we created above.
Edit the Product and use the Story related list.
The story looks like this:
And an Epic looks like this.
Let's skip ahead and assume that you've written up a number of stories against each Product.
Creating your Release
A Release is a container that binds all of the features we want to deploy (Stories in the Release Backlog) and the effort and time involved in developing those features (Sprints)
It also provides focus around the other aspects of enhancing your ITSM processes - the communication, the training, testing, documentation and scheduling of maintenance.
When we communicate about the progress of the project to our customers (the users of the system) we generally talk in terms of release dates and functionality we'll be introducing.
A release looks like this.
IMPORTANT: There are a couple of related lists that you will want to add here also. Add the Story->Parent and Epic->Parent related lists to your release form.
The first thing you'll want to do after creating your release is associated all of the Themes you created earlier using the related list.
Creating your Sprint
A Sprint is a time-boxed period of time in which developers work on stories.
Typically a sprint would be two weeks long, so depending on how often you intend to release feature on your ITSM system you might have two or more sprints in a release. You need at least one.
Having multiple sprints in a release is good as it gives the team a time to stop and check on progress. You might also want to show your Product Owners the progress that has been made so far and at the end of a Sprint is an elegant time to do this.
You might want to spend the first sprint in a release simply building prototypes to ensure that you are planning the right thing. Also you might want to spend the last sprint in your release simply running UAT tests and fixing little bugs and defects that are found by your testers.
There is no set way of doing this apart from the requirement that you should have at least one sprint in your release.
Create a Sprint by editing the Release and using the related list.
Putting it all together
Now we have all of the components needed to describe some features and when they will be scheduled and released
Let's revisit the graphic I showed above with the relationships between all of the records.
Now that you understand the different types of objects it's easy enough to create the objects so that they relate together.
- Create a Product
- Create Epics from the Product
- Create Stories from the Epic
- Create Stories from the Product
- Create a Release
The last thing we need to do is organise our backlogs. We have a Product Backlog (All Stories that aren't assigned to a Release yet), a Release Backlog (Stories associated to a Release) and a Sprint Backlog (Stories associated to a Sprint)
The Product Backlog is automatically populated by creating Stories and Epics. We should invite the Product Owner to contribute new stories and epics to the Product Backlog in order to capture all requirements. We can also take Process Enhancement Requests from the system that we talked about in part 1 of this...
Lets start to associate Stories to Releases to form the Release Backlog.
You do this within the Release Planning Board. Go to the Release object and see the related links.
In the Release Planning Board you can move stories into a release to start to schedule them.
Its the same drag and drop concept for the Sprint planning board. You take stories from the Release backlog and schedule them into a specific Sprint
Phew - that was a lot of screenshotting but it's actually quite a simple set of concepts and hierarchy.
In summary
In this blog post we covered groupings of records that help define what we are going to do with our ITSM enhancement project (Themes, Epics and Stories) and when we are going to do it (Releases and Sprints).
Next time we'll be talking in more detail about stories and estimating the effort involved in completing them
EDIT: Unfortunately when I first published this post on Monday 26th March I used some incorrect screenshots that displayed some form layouts not available in Aspen. This post was updated/rewritten on Wednesday 28th to correct those screenshots. Apologies for anyone confused by the original post
Photo Credit
6 Comments
