[null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://www.codewrecks.com/blog/Storage/MVP_H.png", "src": "http://www.codewrecks.com/blog/Storage/MVP_H.png", "formatted_filename": "MVP H", "alt_text": "Mvp Logo"}, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://www.codewrecks.com/files/mvb.png", "src": "http://www.codewrecks.com/files/mvb.png", "formatted_filename": "mvb", "alt_text": "Most valuable Blogger"}, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/image_thumb.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/image_thumb.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 479, "rendered_height": 209}, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/image_thumb_2.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/image_thumb_2.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 331, "rendered_height": 131}, null, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/image_thumb_5.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/image_thumb_5.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 698, "rendered_height": 153}, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/SNAGHTMLc37265_thumb.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/a767ea96c8c5_E621/SNAGHTMLc37265_thumb.png", "formatted_filename": "SNAGHTMLc thumb", "alt_text": "SNAGHTMLc37265", "rendered_width": 497, "rendered_height": 292}, null, null, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_1.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_1.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 361, "rendered_height": 246}, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_2.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_2.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 466, "rendered_height": 189}, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_3.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_3.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 485, "rendered_height": 245}, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/SNAGHTML73c1ca_thumb.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/SNAGHTML73c1ca_thumb.png", "formatted_filename": "SNAGHTML c ca thumb", "alt_text": "SNAGHTML73c1ca", "rendered_width": 564, "rendered_height": 103}, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_5.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Stati-e-transizioni_5CF3/image_thumb_5.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 303, "rendered_height": 125}, null, null, null, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Personalizzare-i-Work-Item-di-TFS_AFA7/image_thumb_2.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Personalizzare-i-Work-Item-di-TFS_AFA7/image_thumb_2.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 501, "rendered_height": 173}, null, {"document_url": "http://www.codewrecks.com/blog/index.php/tag/process-template/", "unformatted_src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Personalizzare-i-Work-Item-di-TFS_AFA7/image_thumb_3.png", "src": "http://blogs.ugidotnet.org/images/blogs_ugidotnet_org/rgm/Windows-Live-Writer/Personalizzare-i-Work-Item-di-TFS_AFA7/image_thumb_3.png", "formatted_filename": "image thumb", "alt_text": "image", "rendered_width": 289, "rendered_height": 212}, null]
I’ve dealt on How to enable the new work Item in TFS 2017, and you could have noticed some differences from Visual Studio Team Service Work Item layout, or even with new Team Projects created after the upgrade. In Figure 1 you can see in the left the detail of a PBI on a Team Project that exists before the upgrade to TFS 2017, in the right the PBI on a Team Project created after the upgrade. Figure 1: Differencies of Work Item Form between Team Projects

This difference happens because the script that upgrade the Process Template to use the new form, does not add some part that are indeed present in newer Process Template. In the end you can be annoyed because new Team Project have different layout than existing ones. The solution is quite simple.

First of all install the Team Process Template Editor Extension for Visual Studio 2017, this will easy the process because will avoid resorting to command line. Now, as you can see in Figure 2, you should be able to use the menu Tools –> Process Editor –> Work Item Types that contains two commands: Import WIT and Export WIT. Figure 2: Commands to import and export Work Item Definition of a Team Project directly inside VS

Process Template Editor will save you some command line details

With these two command you can export the definition of Work Items from a Team Project to your local disk (Export), then you can modify the definition and upload modified version to Team Project again (Import). If you choose Export, it will made you connect to a Project Collection, then choose the Team Project you want to use, and finally choose the Work Item Type, in my situation I’ve choose User Story Work Item Type and saved it to disk. When the export asks you to include the Global Definition List, please answer no.

It will be a good idea to save everything to a source controlled folder, so you can verify how you modified the Work Item Definition during the time.

After you downloaded the Work Item Definition of the Team Project you want to fix, Export the very same Work Item Definition, from a Team Project that was created after the upgrade to TFS 2017. It could be simpler instead to download the entire process template definition from the server and look for the Work Item Definition you need. Since I need to modify several Work Item Type definition, not only User Story, I decided to download the entire Process Template for the Agile definition Figure 3: How to download an entire process template directly from Visual Studio.

The menu Team –> Team Project Collection Settings – > Process Template Manager will do the trick; this command will open a dialog with all the Process Template Definition and I simply grab the Agile (default) and download to a source controlled folder.

Now you should have two file User Story.xml, the first one of the TP that was upgraded (the one that missing the Development and Related Work UI Section) and the other is the one of the Process Template Definition, that contains the sections you miss.

You can just compare them with whatever tool you prefer. The result is that the two files usually are really different, but we do not care for now about all the differences, we can just scroll to the bottom to find the definition of the layout of the new UI as you can see in Figure 4. Figure 4: Different UI definition section between existing and new Team Project

In the left we have Status and Planning section, while on the right we have planning and development, the two missing parts we want to see in our new Work Item Form Layout are instead on the new definition. Now you only need to adjust the layout on the left to make it include the missing two section. In Figure 5 is shown how I modified the file. Figure 5: Modified Process template

You can rearrange the form as you like, as you can see I’ve made it equal to the one of the latest version of the Process Template, except that I left the Story Point in the Planning section.

Once you are done, you can use the Import WIT function from Visual Studio 2017 to upload the new definition to the Team Project you want to modify. If you made errors the Work Item Definition will not be imported, so you do not risk to damage anything.

If the import went OK, just refresh the page in the browser and you should immediately see the new layout in action, Development and Related Work section are now visible. You can also rearrange the UI if you like to move information in a way that are more suitable to your needs.

Now repeat the very same procedure for Features, Epics, Task and whatever Work Item Type that miss some section respect a newly created process template.

If you need to do this procedure for more than one Team Project, you need to repeat all the steps if the other Team Project is based on a different template (Agile, SCRUM, CMMI) or it contains different customization.

It is always a good procedure to always export the actual definition of a Work Item before starting to modify it, to avoid messing up the template.

If you did a good work and stored all customization into source control, you still need to export the definition from the template, to verify if the definition was changed from the latest time you modified it. Even if you are sure that the latest customizations are in source control, remember that when you upgrade TFS it could be possible that Process Template Definition was upgraded to enable new features (as for the new Work Item Layout Form).

Gian Maria Ricci Figure 1: Adding a new Field Definition to store Original Estimate Figure 2: Adding the new field in the Ui layout Figure 6: Final configuration of the process. 

You can download Powershell script and the customized build here.

Gian Maria. 

Now that we know how to add information to a Work Item definition, it is time to deal with “state” management. Each Work Item has a field called Status that is completely different from any other field, because has an associated workflow that manages transactions from various allowed status values. Having a workflow to manage State of a Work Item is a really powerful concept, because permits a more accurate modeling of your process. As an example suppose that in your process each bug enter the system in a status called Triage, because is new and need to be examined by someone before a developer could actually work to its resolution.

This concept comes from Emergency Room in hospitals, all people that comes in ER are set to a Triage status and someone determines priority code, do understand witch of the patients need to be examined first by a doctor. For bugs the situation is the very same, usually the bug moves from Triage to Active (Someone should fix it) but we can also choose not to fix for various reason; as an example we are not able to reproduce the bug, or simply it is too complex to fix and it is really not so important that we can postpone the fix in the next release. We can have tons of reason to immediately close the bug bypassing the Active state and surely one of the most important is The bug is duplicated. Having a duplicate bug is cause of a lot of problem so it is perfectly legal that a bug never reach the Active status. If our bug definition has no Triage concept we can customize the process template to adapt it to our way to work, thanks to concept of State and Transitions.

States represent logical states of a Work Item and is simply a list of various status string, each one identifying a valid state for the Workflow. A Transition permits to move from one state to another and we can change status only if there is a valid transition in the workflow definition. All these information can be edited with the Process Template Editor that has a good graphical editor to give us a visual image of States and Transitions.

In Figure 1 we can see the graph related to the Msf For Agile bug definition Figure 1: State and transition of Bug definition of the MSF For agile process.

To add a new valid state we need to drag and drop a new state from the toolbox to the diagram, in Figure 2 I simply dragged a new state and changed its name in Triage. Figure 2: A new state called Triage was added to the workflow.

Since this will be our new initial status, you should change the default transition. To do this simply right click on the transition, choose the “Open Details” menu item and you will see the Transition editor form (Figure 3), now you should simply change the To field that identify the destination of the transition. Figure 3: The form to edit a transition, as you can see you can simply choose from and to state with a combo.

As you can see the From value is null, to identify this as the default transition so Triage will be the new default initial status of a Bug. The second tab called Reason contains the reasons that could move the bug from the original status to the destination status and contains also the list of valid reasons (enlisted in the reasons tab of the editor). This is a powerful concept, because you can always look at the Reason field an have a clue of the reason why the Work Item is in this status. In Figure 4 you can see the list of reasons associated to Bug insertion in the system. Figure 4: Reasons associated to this transition.

For the initial status the reason represents why the bug is in the system, I decided to have three reason, the default one is signaled by tester and identify the standard bug source, a tester found a bug and inserts it into the system. But we can have bug signaled by the build system when a build fails and finally we can have bug signaled by customers (usually they have higher priority for triaging).

Now I can close the Transition editor form, right-click on the editor and choose “validate” to validate my new workflow. Actually it is not valid, and the error is:

State Active cannot be reached from the start Transition.

This happens because the default transition now points to Triage and the Active state is unreachable. You should now drag Transition objects from the toolbox to the workflow to add transition between Triage to the Active and Closed state, finally you should reach the situation of Figure 5. Figure 5: Iâ€™ve added transition from Triage to other status, now the workflow is valid again.

After this new workflow is saved, when we create a new bug we can only specify the Triage state and one of the Three allowed reason for the default Transition (Figure 6). As you can verify the default reason is “signaled by tester” Figure 6: The new workflow permits only the Triage status on inserting.

When you save the bug, the field Reason become Read-Only, because this field can be changed only during a change of state. Since the bug is now in the Triage status, we can change status to Active or Closed; if you choose Closed as a new status, the Reason combo become active again and shows the available reasons associated to this transition. (Figure 4 and Figure 7). If you change the new status to Active the Reason combo immediately changes to enlist the valid reason of the transition from Triage to Active. Figure 7: Changing the status to Closed activate again the Reason field that shows only the reasons associated to the transition from the current status (Active) to the new status (Closed).

State and transition are powerful concepts that permit to implement complex workflow to model the lifecycle of various types of Work Items. I strongly suggest you to adapt the definition of your template of choice to your current process, especially for Bug and Requirement types of Work Item. 1 â€“ Customize Tfs Process Template
2 â€“ Basic of TFS Process Template Customization
3 â€“ Adding Field to a Work Item Definition
4 â€“ Customize Work Item Fields with Rules

In fourth chapter we familiarized with Rules and how you can customize a Work Items adding rules to it. You can find a complete list of Rules at this link, but I want to show you the most useful ones (at least in my opinion).

Since you already know the ALLOWEDVALUES you should know the ALLOWEXISTINGVALUE a rule without parameter and is used to specify that we want to maintain a value even if it is not in the list of allowed values. This rule is useful if you change the list of available values (called PickingList) but you want to maintain old values, even if they are no more in the picking list. If you change the PickingList and you edit a work item that has an invalid value in a field, you are forced to specify a valid value to save again the element.

Another rule related to the PickingList is the PROHIBITEDVALUE that lists a series of values that are not allowed to be used in a field. As you see in Figure 1 the field is edited with a normal textbox, but if â€œblablaâ€ is a prohibited value an error is shown. Figure 1: Error value for a field that contains a prohibited value.

A third rule related to PickingList is the SUGGESTEDVALUES that contains a series of suggested values, but you can insert any value you want. When you apply this rules the editing field of the Work Item is a combo that contains all suggested values, but you can type any value you want.

The rule CANNOTLOSEVALUE states that a field once you set a valid value, could not be set to null anymore.

Another really interesting rule is called DEFAULT that permits to specify the default value of a field and it is really flexible  . Figure 2: Specify a value taken from another field as DEFAULT.

In Figure 2 I showed a very specific situation, I choosed field in the from combo, this specify to TFS that I want to use the value of another field as DEFAULT for the field this rule is applied to. Then I choosed the System.ChangedBy field and saved the rule. Now I create another Bug based on this template, did not write anything in the new field ("Revision noteâ€) and simply press save to save the WI. Since the Revision Note contains the rule DEFAULT that states that the default value is taken from the field ChangedBy the value is updated accordingly as shown in Figure 3. Figure 3: The content of Revision Note was automatically filled with DEFAULT value, taken from the ChangedBy

Clearly you can specify a constant for DEFAULT, you should choose value for the field combo, and simply specify a constant value in the value textbox (Figure 4) Figure 4: This is a â€œclassicâ€ default value, when the user creates another WI based on this template, the field contains this constant value.

You can use currentuser and clock as source of the default value.

Very similar to DEFAULT is the rule COPY, it is used to copy a value from a field to another during transition (Iâ€™ll speak about transition in subsequent posts).

Finally another useful rule is the MATCH, used to specify a pattern to check the validity of the content of the field..


Tags: Tfs ALM