TFS: Performing Simple Addition Using Work Item Rules

아티클
1/17/2024

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

The content of this article is intended more as a reference, to inspire creative solutions to difficult problems. The scenario presented here occurred a while back and since then, other commercial and open source solutions have surfaced. One of those is linked below.

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. (WHEN Risk=1, execute (WHEN Effort=1, execute (WHEN Complexity=1, Copy value 3))). That is where I hit another limitation.

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.

Although WHEN rules cannot be embedded in other WHEN rules, it is possible use a stepped approach with multiple fields, each having their own WHEN rules. To add the values of three fields, each with 4 possible values, would required would require an additional 24 hidden fields. That is, unless I control the input sequence.

Work-Around: Controlling the Input Sequence of Fields

To limit the number of extra fields, restrict the order in which the fields can 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] execute READONLY, the effort field would be hidden until a value was set for Risk. Set a similar rule on Complexity so it will be READONLY while Effort has no set value and, optionally, another on REC Score so it will not be seen until Complexity is set.

Work-Around: Performing Simple Addition

Start by creating 4 additional fields, Effort1 through Effort4, one for each of the possible values of the Effort field. These fields will be used to calculate the total value of Risk + Effort. They are not intended to be seen by the end user but are included in the work item definition only to facilitate a work-around for the limitations we found. While developing the solution, you may wish to temporarily add them to the UI to facilitate troubleshooting but remove them in the production release. These fields should also be set as non-reportable since the information they hold is not 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, 4 WHEN rules are required on each of the hidden Effort fields to add the appropriate Risk value to the assumed value of Effort. The first rule on Effort1 is 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 rules are similar. WHEN Risk=2, Copy value 3. Then WHEN Risk=3, Copy value 4. And last, WHEN Risk=4, Copy value 5. A similar set of 4 rules are added to Effort2, Effort3, and Effort4 but instead of adding 1 to Risk, they will add 2, 3, or 4, depending on which of the hidden Effort fields the rules are applied to. The image at right, "Adding 2 Fields - Stage 1" shows a screenshot of the work item after setting Risk but befor saving the change to the server.

This performs the necessary addition for all allowed values of Risk and Effort but it does not identify which of these calculated values is correct for the selected values of Risk and Effort. That will require another hidden, non-reportable field, called RE Score. RE Score will implement 4 WHEN Rules to identify and COPY the value from the appropriate hidden Effort field. The first rule is WHEN Effort=1, Copy field Effort1. That is followed by WHEN Effort=2, Copy field EFFORT2 and so on. With this we have successfully performed addition of two field values in a TFS work item template. Or have we?

Limitation: Inconsistency Between WHEN and COPY Rules

The screenshot above, "Adding 2 Fields - Stage 1", shows the problem. While the Effort1 through Effort4 field values have been calculated, the RE Score was empty. The condition of a WHEN rule looks at the local value of a field, as expected, but the COPY rule works differently. 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 will 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 even 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 will leverage the inconsistency itself. Create another hidden, non-reportable field called RiskServer. Because its value is set from the Risk field using a COPY rule, there will be no value in RiskServer until the work item is saved. Then modify the WHEN rule on the Effort field to WHEN RiskServer=[No value Set], READONLY. The combination of these two changes will result in Effort remaining hidden until the work item is saved. This must be repeated for Complexity and, optionally, REC Score so a total of 2 or 3 new fields will be needed for "Server" values.

Work-Around: Addition with a Third Field

Adding the value of the Complexity field is similar to the process described in "Performing Simple Addition" above. Create another 4 fields, Complexity1 through Complexity4. You can use the REC Score field in the same way as RE Score as long as you want only to show the sum. "Adding 3 Fields - Stage1" shows a scenario where REC Score is used to suggest T-Shirt Sizes and a separate, hidden REC field is used to hold the sum of the 3 fields. Since the Risk field has only 4 possible values, the hidden Effort fields needed only 4 rules each. RE Score has 7 possible values (2-8) so the hidden Complexity fields require 7 rules each. These rules will 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.

Just as before with RE Score, create a set of WHEN rules on the REC field. WHEN Complexity=1, COPY field Complexity1 and so on. It is 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 in the "Adding 3 Fields - Stage 1" screenshot, the REC and REC Score fields are not set. This behavior is expected because REC uses the COPY rule to populate its value just like RE Score and REC Score sets its value from REC so it will also not be populated. "Adding 3 Fields - Stage 2" shows the result after a save.

Final State

There are pluses and minuses to this solution:

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 3 REC fields (Risk, Effort, Complexity).

The limitation of not being able to perform math functions in fields was overcome using rules. The limitations on embedded WHEN statements was overcome by adding more hidden fields and rules on those fields. Both of these solutions are transparent to the user but add difficulty to the maintenance. 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.

In the end, the solution works, sort of. 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. 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 another solution that would be easier to maintain and provided similar, but not identical, capabilities to the user.

I started a spreadsheet that acts as an REC calculator. I initially 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 which allowed me to use the solution, but it has an impact on usability.

There are a few potential solutions to this problem such as saving the spreadsheet as a web page and enabling interactivity, but that requires Excel 2003 or earlier. You could create a custom web page that performs the calculations. If you think about it, you will probably come up with several other solutions.

There are pluses and minuses to this approach as well. The downside is:

All of the data (Risk, Effort, Complexity, REC Score) is in an external application and cannot easily be added to TFS reporting warehouse.

The upside is:

Less effort to maintain the solution.
Most organizations that use TFS have an abundance of developers that might be leveraged to maintain the custom web solution.

It is possible to do a hybrid solution. The Webpage work item control accepts a URL and can include dynamic querystring parameters. Using that capability, you would set the URL to include querystring parameters for Risk, Effort, and Complexity, setting their values to the appropriate field's value. Something like:
http://MysServer/WITools.aspx?Risk=$(RECRisk)&Effort=$(RECEffort)&Complexity=$(RECComplexity)
You can also set the control to reload the target page automatically when a parameter field changes by toggling the "Reload on parameter change" checkbox on so no saves are required. Unfortunately, information can only move in one direction using the Webpage control, from TFS to the web page so we cannot dynamically update the REC Score field from the web page. REC Score still exists only in the custom application but it can be calculated in reports based on the information that is available.

CodePlex Solution

Codeplex has a cleaner solution that uses Windows Workflow to define rules that hook into TFS events that can perform field calculations like the addition we are doing here. TFS Event Workflows (See Also) will do much more than just calculations and it is not the only rules engine available for TFS. It is the only one mentioned here because it is free and it is on CodePlex. A search using your favorite search engine will return others that may deserve your consideration.

All of the tools of this type I have found will require installation on the TFS application tier which will require TFS administrative access and possible Server admin access.

Summary

Because of the limitations in the work item rules, a solution using only TFS fields and rules presents serious challenges to end users when you are adding more than 2 field values. The best user experience in this case will be realized using the Webpage control pointed to a custom page that takes Risk, Effort, and Complexity as querystring parameters and calculates the sum, presenting the user with suggested T-Shirt Sizes. This solution does not store the suggested values or the REC score in TFS so they must be calculated directly in your reports using the individual field values.

However, the rules approach exposes valuable information that can be applied to other, less complex solutions. If you only wish to sum 2 fields, this approach becomes more desirable since only 1 save is required to see the result and all values can be easily added to the TFS reporting warehouse.

다음을 통해 공유