Wow, that is a really good question. Clearly there is not any one way to answer this or even a right or wrong answer.  I think I read once that any documentation is better than no documentation. For us, I don’t think we’ve yet found a consistent and formal way of doing this, but I can tell you the direction we are moving on this.

First, let’s clarify the type of environment changes that you may be talking about. I’m guessing that you’re referring to configuration changes. This could be as simple as adding a new Page Three attribute to a subclass to creating a brand new subclass.  The company I work for has many process extensions (PX) within Agile.  In many cases, the way those PXs behave are based on Agile Document items that we use as configuration objects.  Without them, the PX does not function, so it is indeed important that we document how to recreate these objects and what purpose they serve.  Personally, one of my favorite tools to document most anything was a free app called ClarifyIt. I still have it and use it, but unfortunately it is longer available. It is just a convenient tool to do screen captures and add headings and text to those screen captures. But honestly, you can do the same thing with Microsoft Word.

We now use Azure DevOps for source control and to keep up with Features and tasks assigned to Analysts and developers. We have started to create UI configuration objects within DevOps to also document these Agile Configuration objects and changes to them. Within those, it’s descriptive text and images.  That’s really all it boils down to… any documentation tool where you can describe what you’ve done and add screen shots to provide clarification. How formal the documentation is a decision only you and your company decide on.

It is possible that I’ve misunderstood what you’re asking for. It may be that you’re wanting some tool that extracts data from the system both before and after config changes.  I can’t make any recommendations on that, because I’m not aware of any such tool. That said, this has given me an idea. I have a database view that I created that shows subclass properties.  I could see running this each I make changes and then saving the output of this as part part of my documentation.  I may consider sharing this view at some time in the future.

Steve LaLonde