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 the COPY command.
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 FieldsTo 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 tyhrough 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. These fields were also set as non-reportable since the information they would
hold would not be very meaningful outside of this process. Each of these fields had 4 WHEN rules, one for each of the possible values of Risk. The first rule on Effort1 was WHEN Risk=1, COPY value 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. This effectively added the value of Risk to the value of Effort assuming Effort was equal to 1 (thus the name Effort1). 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 field the rules were applied to.
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. The purpose of the WHEN rule is to make decisions like this. Another hidden, non-reportable field, called RE Score, was
created to hold the correct value. RE Score included 4 Rules. The first rule was WHEN Effort=1, Copy field Effort1. That was followed by WHEN Effort=2, Copy field EFFORT2 and so on. I had just successfully added 2 fields in a work item! Or did I?
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. While working in the UI, as soon as I set a value for Risk, Effort field was available. I also saw that Effort1 through Effort4 were
being correctly populated however after selecting a value for Effort, 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. Since I had not
yet saved the work item, this work item did not exist on the server so there were no values saved for Effort1 through Effort4 and RE Score remained empty.
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 me to copy the appropriate field's value into RE Score when Effort was selected. While this is a less than optimal solution,
it was all the worse if users had to remember to save after setting each field.
Another field and a change to the WHEN rule that was applied to the Effort field earlier, that set it READONLY, would solve this issue. I created another hidden, non-reportable field called RiskServer. RiskServer had a COPY rule getting its value from the Risk
field. I then modified the WHEN rule on the Effort field to WHEN RiskServer=[No value Set], READONLY. Since RiskServer would have no value until a value was saved for Risk, this enforced a save in order to set the next field. This had to be repeated for Complexity
and REC Score so a total of 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. 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 Score. WHEN Complexity=1, COPY field Complexity1 and so on.
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.