Table of Contents
Introduction
Team Foundation Server is a central component to Microsoft's Application Life cycle Management tool set. It is a very powerful and flexible tool that can be customized to adapt to your application development process. While Microsoft provides updates to TFS with new features and enhancements on a roughly quarterly cadence, it is not without its limitations. This article looks at some of these limitations and the methods used to overcome or work around them.
Overview
If you are familiar with editing Team Foundation Server process templates, and specifically work item templates, you know that a work item field's value can be copied from another source. The COPY rule can retrieve a value from another field, the current user, the system clock, or a provided value. But this is not a calculation. It can copy only one value. In fact there is, as of the writing of this article, no direct means of calculating a field value. So, to do this, we will have to get creative.
Scenario
Our process template uses Requirement work items. These work items include a T-Shirt size field with 11 possible allowed values ranging from X-Small to Epic X-Large. Executive management has identified an inconsistency in T-Shirt sizing of Requirements from
team to team. They have mandated the use of an REC score (Risk, Effort, Complexity) to set T-Shirt Size.
In order to meet this mandate, project managers have asked for 3 new fields, one for each element of the REC score, and a 4th field for REC Score. They want to set a value from 1 to 4 for Risk, Effort, and Complexity and have the sum of those fields displayed
in REC Score. They will then use the REC score value (3-12) to set T-Shirt Size to one of the 11 possible values where an REC score of 3 is a T-Shirt Size of either X-Small or Small and an REC Score of 12 is either Epic Large or Epic X-Large.
Working Through the Limitations
The limitations are the:
- Inability to perform any math operations in fields.
- Inability to use a WHEN rule within a WHEN rule.
- Inconsistency between the field values used in a WHEN rule and a COPY rule.
There will be more discussion on these limitation as we explore the solution.
Limitation: Cannot Perform Arithmetic Functions
The question to answer was “How can we add field values when no Arithmetic functions are available in TFS field rules?” That was an interesting challenge that would require creativity to solve. I considered several approaches. In fact, even today I continue
to consider alternatives to solutions posted in this article.
My first thought was to use a series of embedded WHEN rules to do the addition.
![]()
Limitation:
Cannot Embed a WHEN Rule in a WHEN Rule
That approach was doomed to failure. A WHEN rule is made up of two parts, the field condition and the rules to be applied when the condition evaluates to true. The problem is that WHEN is not an available rule in the Rules tab of a WHEN rule. So, you cannot
have embedded WHEN rules.
After a little more thought I realized that I could pre-calculate all of the possible values but it would require several additional hidden fields to do so.
![]()
Work-Around:
Controlling the Input Sequence of Fields
To limit the number of extra fields, I decided to restrict the order in which the fields could be set. Risk first, then Effort, and last is Complexity. In Team Foundation Server 2013, when a field is READONLY and it has no value it is hidden from view in the user interface. So, by setting a rule on Effort, WHEN Risk = [not set] apply rule READONLY, the effort field would be hidden until a value was set for Risk. I set a similar rule on Complexity so it would be READONLY while Effort had no set value and another on REC Score so it would not be seen until Complexity was set.
![]()
Work-Around:
Performing Simple Addition
I started by creating 4 additional fields, Effort1 through Effort4, one for each of the possible values of the Effort field. I used these fields to calculate the total value of Risk + Effort. These fields were not intended to be seen by the end user. They
were included in the work item definition only to facilitate a work-around for the limitations we found. For potential troubleshooting efforts, they were temporarily added to the UI but they were removed in the production release. These fields were also set
as non-reportable since the information they would hold would not be very meaningful outside of this process. The Effort1 field assumes that the value of Effort is 1, Effort2 assumes Effort is 2, and so on. Since there are four possible values for Risk as
well, I needed four WHEN rules applied to each of the hidden Effort fields. The first rule on Effort1 was WHEN Risk=1, COPY value 2. This adds the assumed Effort value of 1 to the Risk value, when it is 1, resulting in a total of 2. The next rule was similar.
WHEN Risk=2, Copy value 3. Then WHEN Risk=3, Copy value 4. Last, WHEN Risk=4, Copy value 5. A similar set of 4 rules were added to Effort2, Effort3, and Effort4 but instead of adding 1 to Risk, they would add 2, 3 or 4 depending on which of the hidden Effort
fields the rules were applied to. Adding 2 Fields - Stage 1 shows the results.
This performed the necessary addition for all allowed values of Risk and Effort but it did not identify which of the values should be used. Another hidden, non-reportable field, called RE Score, was created. RE Score included 4 WHEN Rules to identify and COPY
the value from the appropriate hidden Effort field. The first rule was WHEN Effort=1, Copy field Effort1. That was followed by WHEN Effort=2, Copy field EFFORT2 and so on. With this we had successfully performed addition of two field values in a TFS work item
template. Or did we?
Limitation: Inconsistency Between WHEN and COPY Rules
This is where I ran into another problem. The condition of a WHEN rule looks at the local value of a field, as expected. This is evident in "Adding 2 Fields - Stage 1", which is a screenshot of a new work item before it is saved back to the server. You can see that the Effort1 through Effort4 field values have been calculated, but RE Score was still empty. It turns out that the COPY rule works differently than the WHEN rule. When copying from a field, COPY retrieves the field value from the server. "Adding 2 Fields - Stage 2" shows the new work item after a save. Once saved, RE Score is able to retrieve its value from the appropriate hidden Effort field as determined by its WHEN rules.
Work-Around: Forcing a Save Between Populating Field Values
The only work around to this is to save between fields. The save would push the values of Effort1 through Effort4 to the server, allowing RE Score to copy the appropriate field's value when Effort is selected. While this is a less than optimal solution,
it is all the worse if users have to remember to save after setting each field.
To force the user to save between setting Risk, Effort, and Complexity values We needed to leverage the inconsistency itself. We created another hidden, non-reportable field called RiskServer. Because its value is set from the Risk field using a COPY command,
there would be no value in RiskServer until the work item was saved. I then modified the WHEN rule on the Effort field to WHEN RiskServer=[No value Set], READONLY. The combination of these two changes resulted in Effort remaining hidden until the work item
was saved. This had to be repeated for Complexity and, optionally, REC Score so a total of 2 or 3 new fields had to be created for "Server" values.
![]()
Work-Around:
Addition with a Third Field
Adding the value of the Complexity field was similar to the process described in "Performing Simple Addition" above. I created another 4 fields, Complexity1 through Complexity4. I could use the REC Score field in the same way as RE Score as long as I wanted
only to show the sum. "Adding 3 Fields - Stage2" shows that we decided to suggest a T-Shirt Size in REC Score so we added an REC field that would be hidden like Effort1 through Effort4 and Complexity1 through Complexity4. Complexity1 through Complexity4 fields
would need 7 rules each. Where I only had 4 possible values for Risk, thus 4 rules, there were 7 possible values for RE Score (2-8), thus 7 rules. These rules would be similar to the rules applied to Effort1 through Effort4. On Complexity1, WHEN RE Score=2,
COPY value 3 and so on through WHEN RE Score=8, COPY value 9. Likewise for Complexity2 through Complexity4. This left me once again with the decision of which of these 4 field values to use.
Just as before with RE Score, I applied a set of WHEN rules to REC. WHEN Complexity=1, COPY field Complexity1 and so on. Then it was a simple matter to apply a series of WHEN rules to REC Score to set its value based on the value of REC.
As can be seen in Stage 1, which is a screenshot taken after setting Complexity but before saving that change, The REC and REC Score fields are not set. This behavior was expected because REC uses the COPY rule to populate its value just like RE Score. REC
Score sets its value from REC so it was also not populated. Stage 2 shows the result after a save.
![]()
Final
State
There are pluses and minuses to this solution. I was disappointed for several reasons:
- It is relatively rigid, requiring that Risk, Effort, and Complexity be entered in a specific order.
- It requires 12 additional “hidden” fields to perform the desired arithmetic operations. The number of additional fields would have been more if there was no restriction on the sequence in which the Risk, Effort, and Complexity values are entered.
- It requires that the work item be saved after entering a value for each of the three REC fields.
The limitation of not being able to perform math functions in fields could be overcome using rules. The limitations on embedded WHEN statements could be overcome by adding more hidden fields and rules on those fields. Both of these are transparent to the
user but add difficulty to the maintenance of the solution. However, the inconsistency between where the WHEN and COPY rules get their field values from results in an impact on usability.
The “up” side is:
- It works. It successfully adds several field values together into another field.
- It can be scaled, although it is a complex solution.
- The individual techniques used can be applied to solve other needs as well.
However, in the end, the solution works. It performs addition of work item field values, which would otherwise not be possible. The solution includes several techniques that can be applied to other problems to help reach a successful conclusion.
Alternate Ending
As I mentioned, I was a little disappointed with the solution above so I stepped outside of the box I was provided. You see, the request was to add 4 fields to the Requirement work item as I described earlier. That was the box. When I stepped outside of
that box, I created a cleaner solution, although with different capabilities.
I created a spreadsheet that acts as an REC calculator. Rather than just doing the simple arithmetic as the original solution delivers, the Excel calculator would display a recommended T-Shirt Size for a given result. I hosted the spreadsheet in SharePoint
then added a Webpage control to the work item that was pointed to this SharePoint page. I was able to interact with it from within the work item in Visual Studio, however web access showed an error saying that the page could not be opened in an iframe. It
provided a link to open the page in a new window. This issue can be overcome with a custom page that does not use either SharePoint or Excel.
The Webpage control approach opens up a whole new set of options. Perhaps we can maintain a set of work item tools in similar webpages. I could add a Tools tab to my work items that presents a set of custom calculators and tools directly in the work item.