Agile 1.3.0

Welcome to the Agile app - created and maintained by Sascha Wildgrube.


Manage agile software projects and deployments.


Agile is NOT an officially supported ServiceNow product.

Agile does NOT come with any kind of warranty. If you use it, you own it!

System Requirements


  1. Create an account on GitHub - if not done already.
  2. Create a personal access token for your GitHub account.
  3. Add credentials to access GitHub - use "Basic Auth".
  4. Fork the repository
  5. Go to Studio and import the DevTools application from source control.
  6. Perform all installation steps for the DevTools application documented here: 
  7. Fork the repository
  8. Go to Studio and import the Agile application from source control.
  9. The InstallApp() function must be executed.
    Run the following script as a background script in scope x_snc_agile:
  10. x_snc_devtools.InstallApp("x_snc_agile");


  1. Assign groups or users the x_snc_agile.agilist role.
  2. Create a backlog.
  3. Specify the definition of ready and the definition of done.
  4. If applicable, specify the lead developer and the lead tester.
  5. Define components and associate them to the backlog.

Development process / Backlog item states

Please add the affected application names as a tags to the story.

  1. Draft / Need more info: The requirement description is being worked on or more information is required to implement the backlog item.
  2. Ready: The author of the item claims the item contains enough information to start development. A developer should be assigned to the backlog item.
  3. In Development: A developer works or is asked to work on the implementation of the backlog item in the DEV environment.
  4. Commited to repo: The developer has completed their work and committed their changes to the source code repository - which makes the backlog item part of a subsequent deployment to the TEST environment.
  5. In Test: The changes related to the backlog item has been deployed to the TEST environemnt and a tester is asked to test the result.
  6. Test Failed / Show Stopper / Back to development: A backlog item has failed the test and must be considered as a show stopper - so the current version on the TEST environment MUST NOT be deplyoed to the PROD environment. The backlog item is sent back to a developer who is now asked to fix issues. It is important to disiguish this state from "In Development" because the current deployment on TEST should not be deployed to the PROD environment as long as there are show stoppers. If a test failed but the issues are not considered as show stoppers, the version can be deployed to PROD and the state should be set to "In Development" which indicates that they do not represent a reason to delay deployment to PROD but still need to be worked on.
  7. Test Passed / Ready for PROD: The test has been passed and the backlog item is ready for deployment on the PROD environment.
  8. Review on PROD: Deployment to PROD environment has been completed. A final check should be done before the backlog item is marked as "Completed".
  9. Completed: The backlog item is finally completed.
  10. Cancelled: The backlog item will not be implemented or worked on any further.

Deployment Process

The following deployment process - no matter if performed manually or automated - should be applied to deploy applications (components).

From DEV to TEST

  1. Login to the DEV instance.
  2. Navigate to Studio.
  3. Switch to the application.
  4. Verify that the DEV branch is active.
  5. "Commit Changes" to DEV branch.
  6. Create tag
  7. Choose the tag name according to the application version (or an alternative naming schema - e.g. "YYYY-MM-DD_hhmm").
  8. Login to the TEST instance.
  9. Navigate to Studio.
  10. Switch to the application.
  11. Select "Apply Remote Changes" (this is necessary to update the list of available tags).
  12. Select "Create Branch".
  13. Choose the branch name exactly like the tag name.
  14. Select the corresponding tag and click on "Create Branch".
  15. Verify that the now current branch has changed to the just created branch.
  16. Navigate to "Studio" / "File" / "Settings" and execute the related link "Run Install Scripts".
  17. Mark backlog items associated to the application in "Commited to repo" as "In Test".

To PROD (roll-forward / roll-back)

  1. DO NOT PROCEED TO ROLL-FORWARD if there are stories "In Test" or in "Test Failed / Show Stopper / Back to development"!
  2. Login to the PROD instance.
  3. Navigate to Studio.
  4. Switch to the application.
  5. Select "Apply Remote Changes" (this is necessary to update the list of available branches).
  6. Select "Switch Branch".
  7. Choose the branch name that represents the version that should be deployed.
  8. If in doubt, stash changes and reapply them afterwards. However it SHOULD NOT be necessary.
  9. Verify that the now current branch has changed to the just selected branch.
  10. Navigate to "Studio" / "File" / "Settings" and execute the related link "Run Install Scripts".
  11. Mark backlog items associated to the application in "Ready for PROD" as "Review in PROD".


Configuration Options


UI Actions


Copyright 2022-2023 by Sascha Wildgrube

Licensed under the Apache License, Version 2.0 (the "License")

You may not use Agile except in compliance with the License.

You may obtain a copy of the License at:

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Release Notes

1.3.0 - 2023-09-07

  1. Backlog item number and state can no longer be edited in list views.
  2. Backlog items can now be marked as "Hotfixed in PROD" to indicate that a hotfix is already in place in production.
  3. In the backlog item list view, the referenced components are no longer cut off.
  4. The order can now be edited in the backlog item form.
  5. Added the "Prio 1" UI Action to set a backlog item to the top of the backlog.

1.2.0 - 2023-06-08

  1. Agile is now fully tested in Utah.
  2. DevTools 1.63.0 is now required.
  3. San Diego is no longer actively supported.
  4. Added the "Cancel" UI action to set the state of a backlog item to "cancelled".
  5. Initializing the backlog's default component on new backlog item now works properly.
  6. The backlog item's short description is now a mandatory field.
  7. Added the default DevOps user to the components list view.
  8. Added default component and owner to the backlog list view.
  9. Removed display value from the backlog item form view.
  10. Users with the x_snc_agile.agilist role were unable to add comments, edit the short description and description and assigned_to fields. This has been fixed.

1.1.0 - 2023-03-06

  1. Introduced Personas: Backlog items can now be associated with Personas.
  2. Backlog items can now turn into "Complete" state from "Done" - for tasks that do not require production deployment - such as documentation or exploration tasks.
  3. New backlog items are now added to the end (with the next highest order value) by default.
  4. Backlog items can now specify required other backlog items.
  5. Backlog item's display value now shows the number, the state and the short description.
  6. A backlog item's component, tester, developer and owner is now set if the values are missing - so the feature now also works if there are multiple backlogs.
  7. All user references in backlog items, components and backlogs now filter for the x_snc_agile.agilist role.
  8. Components now have a description field.
  9. Added menu module "New Item".
  10. Added menu module for items "In Draft" and refined the list for "In Development" and "In Test".

1.0.0 - 2023-02-08

First baselined version