Visualising a sprint as a delta to a software component diagram? [closed]

It depends on the purpose of the diagram:

• Visualizing the goal of a sprint for a project with many components delivered by different teams can help for making sure that everybody understands the interdependencies in the architecture, and that every team can prioritize the stories of their own components in view of the big picture.
• If it is for long term documentation, this makes no sense: most of the components will be created in the early sprints, since the goal is to deliver working software soon and frequently. So after a couple of sprints, most of the components will be brown, and then it will only be an administrative overhead to change the component color between brown (changed) and grey (unchanged). It could however help to visualize the regression risks and could be helpful to identify needed end-to-end tests (but if you have a rich automated test suite, this diagramming would not help either).

This kind of usage of a component diagram (althoug coloreless) is promoted by Scott Ambler who explains here that it can be a good way to stimulate conversation in a team:

My most successful use of component models was with a team where we drew a diagram (...) with over twenty components, on a whiteboard. This whiteboard was situated in the team work area where everyone could see the board. We developed the diagram early in the project and updated it as required throughout the project. We kept it on the board because it provided a high-level map of the architecture of our software, a map that we used from time to time as we worked and more importantly engendered many interesting conversations regarding the overall system design

Most modelling tools allow to change background color of modelling elements in the diagram. If you haven't a tool yet, choose one by putting the change of element color in your requirements.

It doesn't make much sense to me to relate work in a Sprint to architectural diagrams. It's not clear to me when you would even make the relationship between a work item and the architectural diagram. Would you do it during refinement activity, where you take an educated guess at what component(s) of your architecture would be affected by the work? Would you do it at Sprint Planning, where you highlight the parts of the system most likely to be changed during the Sprint? Do you do it as work is complete? There are problems with all of these, mainly that they add additional overhead with little value to stakeholders. They aren't consistent with principles such as elimination of waste or doing the work as late as feasible.

I think that there are ways to ensure that your diagrams are updated as the Sprint goes on. Automate the generation of diagrams as much as possible based on the code. Make documentation updates part of your Definition of Done. If you use textual forms that generate graphical diagrams, submit those updates with the same code reviews as the code and tests for review. However, I wouldn't necessarily color-code components - consider that changes would either be visible at the level of abstraction of the documentation or not, and additions or removals would be apparent by comparing to the previous version.

The use of color and text formatting is about as good as you can get. I wouldn't mention sprints in the diagrams. Put the diagrams under version control. It would be fine to mention a sprint in the revision message.

Showing changes to a component using color or text formatting is a great visual way to communicate change. It is a tool for development, not a museum artifact that should be perfected before it is shown.

Unfortunately there is no industry standard here. The important aspect is communication. If it communicates the intended message then it is useful, and you should use it.

For certain I would not mention a sprint, date or release in the diagram. This ties the change to a date or event, and things come up. Priorities change. You shouldn't need to update a component diagram just because a production defect came up, causing this change to move to another sprint.