ServiceNow becoming SAFe

ServiceNow becoming SAFe


In its previous releases ServiceNow has taken the necessary steps to introduce a unified agile development environment for release, and/or project-based delivery (via Scrum or waterfall development) which strives to give more insight into the software development lifecycle.

In the ”Helsinki” release Agile Development (formerly named SDLC) was introduced, mainly focusing on the Scrum methodology. Subsequently the “Jakarta” release introduced its successor Agile Development 2.0, which refined the first scrum release to improve usability. As ServiceNow is always improving current functionality and at the same time adds new modules into its releases, the question was raised within various agile communities: How do I work multi-team, how do I scale and can ServiceNow support SAFe?

By Panagiotis Alexakis & Angela Senior

Luckily there was an answer to that as well… In the latest “London” release the Scaled Agile Framework (SAFe) was introduced with a SAFe module and made a lot of people curious to see what it had to bring. So, we will try to shortly explain what ServiceNow has to offer with its new SAFe plugin. 

Currently ServiceNow has introduced the “Essential SAFe” configuration which is only the basic implementation. In future releases this will be enhanced to include more advanced configurations: the portfolio and large solution levels. 



SAFe in in ServiceNow

To go into more detail, we would like to give some insights on how SAFe Essential is structured within ServiceNow. To begin with, the following modules have been introduced:


The SAFe Board is basically the best place you should be working from. All other modules are lists that you can use to administrate certain facts like who is in your team, how long your sprints are and when they start. The lists are basic starting points but when you start working you will always turn to the SAFe Board.
The SAFe board consists of two levels: ART (Agile Release Train) and Team. Both contain sub-modules to realise different aspects of the SAFe process.

Agile Release Train

Looking at the ART level of the SAFe Board, it is possible to monitor various parts of the agile release train consisting of multiple teams working on features within program increments (PIs). The ART level of the SAFe Board contains the following sub-modules:

  • Board
  • Backlog
  • Program Increment Planning
  • Big Room Planning

Next, these sub-modules will be explained in further detail and we will give our opinion on the functionality that has been provided.


The Board sub-module makes it possible to visually track all features part of a specific agile release train:


  • This view is ideal to track the progress of all your features per ART. It is possible to interactively plan and track these per state. The states have been adopted straight from the SAFe Program Kanban but is also possible to change or add specific states based on your requirements.
  • The only part that is slightly confusing is the Add Task button underneath the columns. This button enables you to add a feature, not a task. This seems to be default in ServiceNow as the team board view has the same issue. 


The backlog view is a prioritised list of features per ART that have not been deployed or released yet:


  • The drag and drop functionality enables you to change the priority. It also shows you which epic the feature is part of and the ‘weighted shortest job first’ score that a feature has based on the values used as input. Again, a nice flexible interactive view which enables feature prioritisation.


Program Increment Planning

The program increment planning view contains the aforementioned backlog but also enables you to allocate the features to the pre-defined program increments. This view should be used to prepare program increment planning events to determine which features can be realised in the next PI and administratively closing the previous one.


  • Considering the fact that this view also shows the backlog and has minimal added functionality compared to the previous backlog view you could state that due to the program increment planning view, the backlog view can be deemed unnecessary.


Big Room Planning

The big room planning view helps teams during a PI planning event to determine which features they will be able to deliver within a PI. Per team it is possible to see or add user stories per feature and to plot them in the different sprints per program increment. It is also possible to add story dependencies which are visualised on the board.


Compared to other tools this is probably the standout piece of functionality. Other tools that have added agile functionality to their core systems have backlogs at story, feature and epic level with list and board overviews, but this view with stories per team per sprint is very specifically beneficial to companies that are working in accordance to SAFe.


The team level contains anything that SAFe prescribes when it comes to working at the team level and has three sub-modules:

  • Backlog
  • Sprint Planning
  • Sprint Tracking



The backlog contains a list of prioritised user stories per team per program increment which have not been completed yet. You can see the amount of story points that have been allocated to the story and which feature it contributes to. You can click on the story to find or add more information. The backlog view enables product owners to change priorities through easy drag and drop functionality.


Sprint Planning

As is the case in the ART views, the sprint planning view also contains the aforementioned backlog but enables you to allocate the user stories to the pre-defined sprints. This view should be used by scrum teams when planning their next sprint and administratively closing the previous one.


  • If you have added an average velocity to your team (or group capacity as it is called in ServiceNow) this view will try to help you to fill the sprint in accordance to your team’s velocity. Whether a scrum team can meet its velocity depends on many factors, for example whether the people within your team are actually available throughout the sprint. Showing this metric can be useful as long as teams are truly multidisciplinary and keep in mind factors that can influence their average velocity while planning a sprint instead of aiming to get a 100% score.


Sprint Tracking

The sprint tracking view is a board view that can be used in the day to day dealings of a scrum team. Within the current sprint it shows the user stories that the team has committed to and the phase it is in. Anybody within the scrum team can use the drag and drop functionality to update the status of the user stories on the board. This view can be particularly useful during the daily stand-ups.


  • From a practical point of view there are a number of things missing in this view. Per user story it is possible to add tasks in the backlog and sprint planning views, but it is not possible to track and view these tasks in the sprint tracking view. From a theoretical point of view this makes sense, SAFe does not use tasks within their framework. For a team it can be useful to divide a user story into smaller tasks which can be in different phases of completion. Visualising and tracking this can be useful, the user story level can be slightly too high.
  • Tracking iteration progress at team level looks different in SAFe than in ServiceNow. The phases defined in ServiceNow are draft, ready, work in progress, ready for testing, testing, complete and cancelled. In SAFe the phases are not started, development, test and accepted.
  • Another thing that seems to be missing is a decent overview of the acceptance criteria of a user story. When clicking on a user story in the sprint tracking view you get a different story view than in the backlog or sprint planning view. You can add acceptance criteria in the previous views but you cannot see them in the current view. You can add them as a checklist item, but it does make you wonder why the two ways are not aligned.



ServiceNow has made a significant step to support multi team agile environments with the introduction of Essential SAFe functionality. The flexibility and the given user interaction that comes along with the delivered functionality is one of the strong positive outcomes of our analysis. It contains all elements in order to support the Essential SAFe configuration. On the other hand, there are some minor things that can be improved in the future releases. Let’s recap:

Positive Outcomes

  • The SAFe Essentials have successfully been translated to ServiceNow.
  • Easy drag and drop functionality makes the interaction with the tool faster and enables the user to easily track and monitor work and supports decision making. 
  • The Big Room Planning view enables teams to plan stories per sprint during PI planning events.


To be Improved

  • At the Team level the Sprint Tracking view do not provide certain functionality that can practically be of use to a scrum team: o Lack of task tracking per user story per sprint o Lack of acceptance criteria definition within the user stories in the sprint tracking view. o Different phases defined in ServiceNow compared to SAFe (this can easily be changed though)
  • Due to the standard setup of ServiceNow some terminology is confusing e.g. “Add task” which results in the creation of a new feature or user story instead of a task. 
  • The backlog views mostly provide the same functionality as the planning views without added value.

To conclude, we think that ServiceNow can definitely be of added value to someone who wants to use Essential SAFe in combination with a tool. It has all the necessary functionality to support the framework. At program level it seems like the functionality completely supports the processes, at team level there are some practical improvements to be made which will help teams to fully adopt the tool into their scrum process.

For more information about anything related to Portfolio Management, ServiceNow or the Scaled Agile Framework please contact one of our consultants.

By Panagiotis Alexakis & Angela Senior | October 12, 201