What's the best practice for creating Changes from Releases/Sprints/Stories

RussLaPlante
Tera Expert

‎06-19-2024 09:55 AM

A while ago my company began creating one change from a release and every story in that release became a change task (scenario 1 below).

This seems like a made-up process - not best practice, and I think we are losing significant benefits of the change process. However, I am having a difficult time finding the best practice for moving dev work into change.

I believe the best practice is each story should have a distinct change record (scenario 2 below).

I've read through quite a bit of doc looking for answers. Trying the community now.

RussLaPlante_0-1718816004513.png

Looking forward to your responses.

Russ

 

0 Helpfuls
  • 1,296 Views
1 REPLY 1

Lauri Arra
Tera Guru

‎07-03-2024 01:34 AM - edited ‎07-03-2024 01:38 AM

This is a very difficult topic and I would advise caution whenever someone suggests that they have the true best practice or that their approach has the least flaws and can be applied universally.

While I 100% agree that one should have the possibility for a more granular relationship between development objects and change requests, I don't think that making a strict 1:1 relationship with CR:Story is the right choice. Consider a scenario where you're renewing the user portal. Several stories are required to achieve all the required functionalities, yet none of them can be deployed independently - a story or two might be involved in setting up the basics such as user authentication and possible redirects and several stories describe the different use cases that the portal must provide. In this scenario, it is logical to bundle the stories to a release and connect the change request to the release, as the stories cannot be tested nor deployed independently.

On the other hand, you might have development which is hindered by the release management practicalities. An individual story can contain a change as minute as making buttons more round and of different colour. As this development is ready, it would only be logical that it is deployed to production so that the pipeline stays clean. Some stories might require two change requests - for example user or group syncs might require a change in ServiceNow and AD.

I would focus on identifying the minimum required controls for different changes and enable the dev team to submit their input to either release management or change management without having to go through unnecessary hoops. In release management, you would have development that has dependencies which require coordinated testing and communication for getting change approval. The smaller units of development, which can be implemented by individual or small team, could go through change management and be deployed without waiting for a major release.

Have you checked out the SN DevOps Change Velocity? https://docs.servicenow.com/bundle/washingtondc-devops/page/product/enterprise-dev-ops/concept/devop... 

The change automation might provide insights on how to consider the relationship between the development artifacts and change requests.