TensorFlow – Your Solution for Story Estimation in ServiceNow

TensorFlow is the basic architecture used by SPOC dev team to develop a tool for the story estimation in the ServiceNow Platform. It’s an example of supervised machine learning, where the model is trained from the examples that contain labels. Before we walk through all tasks to solve this specific problem, let’s dive into the very algorithm and overall approach.

Neural Network algorithm (NN)

Neural Network algorithm (NN) is an abstract structure that tries to mimic behavior of elemental brain components – neurons. In general, each network is made up of many units that are able to communicate with neurons from the adjacent layers. The most basic type of NN is built with only 2 layers of neurons called “Input” and “Output”.

In our case, we also used 2 hidden layers that are located between “In” and “Out”. In some sense, the hidden layers are places where NN can store information about how important for a specific “out“ neuron is each previous neuron that was activated based on “In” signal. This knowledge is expressed via special values called “weights”.

Neural Network weights

Each neuron has as many different weights, as the number of neurons that may propagate signal to it. During the training process, NN tries to adjust how important for an end accuracy each weight is in context of a different combination of “In” signals and correlated with them “Out” values. This learning step is called back propagation.

Analyzing this structure in the context of our task, the number of neurons on “In” layer is equal to the number of defined words in the Dictionary set. The last “out” layer has only 8 elements that correspond with 8 different, possible answers interpreted as estimation value.

The NN that is the result of this step that has:

  • defined size of “In” and “Out” for each hidden layer,
  • selected proper activation functions (not discussed here to keep this article as simple as possible),
  • adjusted weights (trained weights),

and it’s called a model.

From a mathematical perspective, the model is more or less just an ordered set of matrices that can be written as:

tensorflow ServiceNow neural network algorithm matrix

Where:

  • x is a input vector,
  • f-s are different activation functions,
  • A-s are matrices where weights are stored,
  • B-s are vectors where biases are stored.

7-step story estimation with TensorFlow

The solution our dev team built using the above mentioned algorithm is called TensorFlow. It can be applied for estimating ServiceNow stories in terms of time and resources. Its architecture consists of the following steps.

STEP 1: Data preparation and preprocessing

Data prepared and preprocessed in our case are acceptance criteria and description from every story. We removed here the stories written in a language different than English, and also filtered out stories with estimate (which is our label) higher than 8 hours, to get proper training data set.

STEP 2: Dictionary development

Dictionary is built with the use of Natural Language Processing methods, and is meant to establish the occurrence of a certain word in the acceptance criteria and description of a story. The words are filtered based on the length (longer than 3) and a part of speech (nouns, verbs). The following NLP methods are used:

  • normalization,
  • tokenization,
  • lemmatization.

The output:

ServiceNow stories - Tensorflow dictionary keywords

STEP 3: Model development

The model is developed with the use of machine learning. In this step, it learns the structure of the training data set to make predictions about unseen data. This in turn requires the decision upon:

  • number of neural network layers,
  • number of epochs,
  • loss and gradient function,
  • selection of optimization algorithm.

STEP 4: Training loop

The training loop starts with each description and acceptance criteria being translated separately into binary vectors. The binary vectors represent a number of occurrences in the dictionary (see the picture below). They are processed by neural network together with labels (estimate value), and once the model is trained and “proven”, it’s ready to make predictions of unknown data.

ServiceNow stories - word weights probability Tensorflow

STEP 5: Value prediction

To start predicting values, again description and acceptance criteria are translated separately into binary vectors. Then the vector is processed by the neural network, and the vector of probabilities (numbers representing hours from 1 to 8) is provided.

STEP 6: Estimation

Then the final values (number of hours estimated by the TensorFlow) for acceptance criteria and description was chosen using mathematical approximation based on the neighboring values of elements with the highest probability. In order to calculate it the following formula was given:

ServiceNow - n-th element approximation Tensorflow

Where:

  • Pn represents the probability of the n-th element (1<=n<=8),
  • i is the position of the element with the highest probability.

STEP 7: Final value

The final value is obtained with the combination of both the values from acceptance criteria and description. It’s delivered with the formula below:

ServiceNow story final value - Tensorflow

The multipliers (0.6 and 0.4) are determined as a result of stories preprocessing.

Story estimation for your organization

If you face any challenges related to project estimation or incidents management, consider AI and our ServiceNow solution to:

  • estimate delivery time of your projects, epics and stories, from the onset to the final outcome,
  • automate incidents with classification, reporting and management tools and automatically assign them to a category, group, or a person responsible.

Our team is at your disposal.

Prototyping – build functional platform on ServiceNow

Prototyping is a development stage to enhance the development of your ServiceNow instance or any other piece of software with a visualization of a target feature, dashboard or entire system. Proved to do wonders in the automotive industry, it’s does the same in software development projects, where it helps to:

  • Define the business need that underlies your new development project (a new feature implementation),
  • Identify available fixes to the existing feature handicaps.

ServiceNow prototyping – when your feature needs it

ServiceNow features are a great example where prototyping comes in handy. Examples?

Case

Consider an organisation struggling to manage the process of recording time cards for employees. Their team is working from several locations on a number of different contracts or tasks. Historically, this business handled these on paper and manually.

Superficial improvements

As time and technology progressed, the company favored an Excel-based approach for collecting the data. The process required to calculate costs for the associated employee wages and/or customer invoices. Now a much more sophisticated solution is in place that integrates with the payroll system and CRM systems for invoicing.

The past process

The use of a technological solution doesn’t mean that the process is efficient and effective:

  1. The individual employees use excel to record the hours worked,
  2. A data analyst inputs this information into an application for assigning the hours to the relevant contract,
  3. Once complete, the finance department gets an email with the hours for the worker’s wages that require processing,
  4. They’re always waiting for the input, putting pressure on each department. There is too much room for human error and dependency on individual people. In addition, the excel sheets become incorrectly formatted and version control is often difficult to manage.

On the way to a new solution

The organisation wants to streamline and automate this process. After gathering the requirements and understanding the existing process, the project team starts to get a clearer picture of the AS IS and the TO BE processes. The gap in the middle is going to be the project for a new solution.

The challenge

The team seems to have an understanding of this gap and the requirements, but they don’t know exactly how the new solution should look like and how it will perform.

The solution – prototyping or PoC

A prototype or proof of concept (PoC) can be a suitable way to communicate this to a customer. By creating an interactive and clickable visualization of the system based on the the requirements, the project team can demonstrate how it can look like, how users interact with the interface etc.

This visualization means that the customer will find it much easier to provide feedback. The suggestions shared will be a recipe for a better end product.

Prototyping pros & cons in the ServiceNow environment

Prototyping is an additional stage to include in your delivery process and takes time and costs. However, this one is only a superficial cost, and as at the end of the day prototyping facilitates the development process, helps reduce the number of iterations, prevents nonfunctional delivery and poor user experience.

Yet, either in the ServiceNow environment or any other, prototypes don’t suit every project or business objectives. Here are pros and cons of using this tool.

PROS
  • Great for visualization,
  • Effective for finalizing UI design,
  • Useful if stakeholder’s requirements are ambiguous or vague,
  • Support brand-new concepts,
  • Smaller investment to test if an idea is worth an investment,
  • Demonstrates the solution possibilities.
CONS
  • Requires additional resources,
  • Its limited functionality could alter the perception of the finished solution,
  • Can increase expectations for the project delivery schedule (Users see something working after a few days, so they expect the implementation to follow the same pace),
  • The project team can focus too much on one aspect and miss the main objective, or the bigger picture.

Prototype ServiceNow features or not

Overall, prototyping is a useful stage to assist a project team during the design phase. It can be very effective for the agreement of the design elements. The added layer of visualization is perfect for showing users what they can expect from a new solution. However, it shouldn’t be automatically included for every project as it can absorb unnecessary time and budget.

If the requirements are functional and clearly understood, it’s useless to spend additional time on prototyping. One of the advantages of developing on a platform like ServiceNow, is the configuration and time spent producing a prototype isn’t wasted. This work can often be reused and just extended during the main project.

ServiceNow project requirements – why gather them & how to do it well

The goal of gathering requirements for ServiceNow project, or any other software development project, is to review:

  1. What is done as of now, also known as “the as is”,
  2. The vision of where the system needs to be, also referred to as “the to be”.

The requirements constitute the area in between these 2, and specifies existing issues and/or areas for improvement. In the case of new projects and innovations, “the as is” will be a blank canvas.

The system should support people, processes and the very business. And your requirements should reflect these. Examples in the IT, can be Incident or Request Fulfillment; in HR, we can look to new hires, leaves etc.

How to define ServiceNow project requirements

1 of the issues is that requirements can sometimes be elusive. A stakeholder may want something, but isn’t able to define what it actually is or how it looks like. To succeed in their definition:

  • Expressions must be clear, eliminating ambiguity,
  • Statements must be precise, not too general,
  • Project vision must be common for all stakeholders.

That’s the foundation.

What do good requirements look like

  • Precise – not open to interpretation,
  • Complete – all the connected information is present. Answers to the questions ‘what next’ or ‘what if’ are vital to understand the full scope,
  • Atomic – aim for 1 actor, 1 task, 1 time per a requirement. The indicators that a particular requirement might require a split into next one(s) are 2 words “and” and “or”. It’s not always the case, but it’s always worth some investigation,
  • Traceable – each requirement has its author and justification why it’s needed.

Requirement collection process

An analyst can use various techniques and approaches to collect requirements:

  • 1 to 1 interviews,
  • Workshops,
  • Observation,
  • Prototyping,
  • Questionnaires.

Once the stakeholders have provided their input, it requires analysis and further validation to confirm it’s fully understood. At each stage, full understanding is the key to a successful project delivery. So ask questions until there is no doubt. These steps will help refine the deliverables for the project.

Why gather requirements

The collection of requirements is a cost, yet only provisionally. This cost allows you to optimize budget in the later stages of the ServiceNow project, turning into a saving tool. The analysis at the start of the project is most often less expensive than the replacement or repair of the issues arising if you don’t gather requirements beforehand.

Businesses often rush through this process. They don’t perceive it as a value added and almost never want to invest time and resources in the process before defining scope and setting up budget. The order should be different, starting from gathering requirements that allow to effectively manage both scope and budgets.

ServiceNow project retrospective

The aspects being subject to retrospective assessment of a ServiceNow (or any other) project are:

  • The success / failure to deliver benefits and its triggers,
  • How the system meet / didn’t meet the real business need,
  • The number of bugs to fix.

The requirements collection and definition process should be built into the project delivery plan. Plan for it carefully to make the most of this provisional cost and to turn it into a project gain. It’s as important stage for the delivery as the setup of budget, timeline and resources.

If you need any assistance in your ServiceNow project delivery, don’t hesitate.