How to introduce improvements to work item templates without negatively impacting the artifacts created using old templates?
How do we introduce improvements to work item templates or other aspects of the process in a large enterprise without worrying about negatively impacting the child projects [projects that use the same process template as the master]?
Before introducing a change that impacts all projects, how do we test that change in a sandbox first and with a couple of projects on a pilot basis?
Is it is a good practice to maintain multiple versions of work item templates in a Master project so that we will "add" new versions of work item templates without actually modifying / replacing the earlier versions? For example to start with we may have the following work item templates in the master project area (let's call this version 1 / v1):
Work Item templates (V1)
Request v1
Epic v1
Feature v1
Story v1
when one project team wants to make some improvements to Request work item template, now, they have to 'break the link' from the Master Project and make changes to 'their' local version of Request work item and call that as 'Request v2'. Because this project has broken the link, it will not get any other improvements introduced in the master project in future automatically.
To avoid this, if we try to change the Request template in the Master project (from v1 to v2) and push the updates to all child projects, we will be 'surprising' and 'forcing' the other projects with the new version of Request. Also, the existing Request artifacts created using the old template (v1) may not 'show' up properly in the new template (v2) - if it is not designed to be 'backward' compatible.
One way to avoid these problems and still give freedom to child projects would be to offer BOTH versions of Request (v1 and v2) in the master project and thereby allow all child projects to have both versions (v1 and v2) available to them.
They can still view and work with the existing artifacts created using v1 template; they can also create new Requests using the new template (v2). For example, they will have TWO Request artifacts like this:
- Request ABC (created in the past using Request work item template v1)
- Request XYZ (created now using Request work item template v2)
Is this technically possible?
If so, is it advisable to have multiple versions of templates for a given work item type? [when users go to work item menu, they will see :
- Request v1
- Request v2 <<< New entry
- Epic v1
- Feature v1
- Story v1
Are there any built-in reports that don't work properly because of this change?
Assuming that there are no problems at all with this approach, is it possible to "hide" a given work item template locally within a child project?
For example, if team 'Apple' likes this new Request template (v2), can they 'hide' the old Request template (v1) [still in the system but not visible and thus not possible to create new Requests using v1 template].
And since v1 template is still present (but hidden), can the team view and use old Requests created using template v1?
Any help / guidance in planning / configuring project areas that allows us to introduce improvements / changes incrementally without impacting existing artifacts while still giving freedom to teams to choose any version of the template to create new artifacts is greatly appreciated :)
Pardon me for my long message :)
Best
Vijay
Vijay
“I didn’t have time to write a short letter, so I wrote a long one instead.” ― Mark Twain
Accepted answer
Vijay,
there is a good article on that topic on jazz.net: https://jazz.net/library/article/1077
Another approach is to use a generic master template and change behavior of work items and flows through integration with process management. Feel free to find and ping me on LinkedIn for more in depth information.
If this answer is helpful please mark it as accepted.
- Arne
Comments
Hi Arne
Thanks a LOT for sharing this info and offer to help further!!!
I will connect you on Linkedin.
I have a couple of quick questions :)
Q1. Impact on existing Artifacts: What happens to artifacts already created by different projects using the old version of work item templates when new versions introduced? would they still be usable? or should we design new templates in a way they are always backward compatible? (for example, if we remove few fields in the new version, will we still be able to see those removed fields in the old artifacts created using the old templates?)
Q2. Offering Multiple Versions of Templates: In large organizations where 100s of teams are using RTC, it will be difficult to align on ONE version of Epic, Capability, Feature, Story, etc. in a short period. One way to encourage innovation at team level and also spread that innovation (once found useful by one or two teams) to all other teams by "offering" vs. "forcing" new templates". So, is it possible to offer 2 or 3 versions of templates?