Archives: August 17, 2015

Enabling an ROI Field with TFS Rippler

Why have an ROI field in the Product Backlog

The goal of a Product Owner in a Scrum team is to derive the maximum benefit from the team’s time, in other words to maximise the Return On Investment (ROI). Where the “Investment” is the cost of running the team and the “Return” is the value of the Product Backlog Items (PBIs) that the team turn into working software.

To help the Product Owner achieve this aim, they need to understand the relative business value per unit effort for each of the backlog items, so that they can guide the team to work on the items that will realise the most value for the lowest team effort. This is why it is common practice for Product Backlogs to have an ROI field which is calculated by taking the estimate of business value and dividing it by the estimate of the required team effort to implement the PBI. We then use this field as guide to order the backlog so that the higher value items, per unit effort are towards the top – allowing the team to deliver greater value in their Sprints.

PBI value-effort


Enabling an ROI field in TFS

By default, a PBI in the standard Microsoft Scrum process template does not have an ROI field so the first thing we need to do is add the field to our Team Project.

Here’s a view of a PBI in the standard Scrum process template, showing just the Effort and Business Value fields highlighted in red.

PBI- NoROIfield

Add an ROI field to your PBI workitem definition and set is as type Double and configure it as Read Only in the Team Explorer form as it will be calculated by dividing the business value by the effort field. Something similar to this should do the trick in the Workitem Type Definition XML:

Field Definition

<FIELD name=”ROI” refname=”RippleRock.ROI” type=”Double” reportable=”measure” formula=”sum”>

   <HELPTEXT>Story ROI based on Business Value/Effort</HELPTEXT>


Form Definition:

<FIELD name=”ROI” refname=”RippleRock.ROI” type=”Double” reportable=”measure” formula=”sum”>

   <HELPTEXT>Story ROI based on Business Value/Effort</HELPTEXT>


The result should look something like this:

PBI- WithROIfield

The next problem to solve is how to automatically calculate the ROI value.

The standard way of calculating the ROI field is by using an Excel view of the backlog via a workitem query, recalculating the ROI every time the value or effort changes and then manually publishing back to TFS. Not a great solution!

Step-up TFS Rippler. This add on service for TFS has a number of useful capabilities, performing field calculations is one of them. For more information about what TFS Rippler can do and how to install it, have a look at the dedicated website or other related blogs.

We can setup a couple of XML rules in TFS Rippler’s TransitionRules.xml file that will instruct it to automatically recalculate the ROI field whenever the effort or value fields change.

An example of a one of the required XML rules is annotated in the image below:


When workitems are changed, TFS Rippler executes the instructions in rules that match the workitem change event. This example matches against changes to the Effort field in PBIs that are in the eligible states listed, and then updates the ROI field in the same PBI. We need a similar rule that triggers on changes to the Business Value field.

The complete set of XML for driving the automatic updates to the ROI field are shown below:



Some things to check:

ü  We recommend testing out your changes on a test collection & project first.

ü  Backup your rules files before you set about modifying them.

ü  Remember to match the workitem and field names in the rules to the names defined in your process template!

ü  Also pay attention to where you place the rules within the TransitionRules.xml files to ensure that the rules are in scope for the given Team Collection and Team Project.

For more information on TFS Rippler checkout the website.

Getting More Out of TFS with TFS Rippler

TFS Rippler is an add-on for Microsoft’s Team Foundation Server (TFS) that runs as a background service, providing some key benefits that you don’t get out of the box with TFS. TFS Rippler automatically and efficiently updates workitems based on a set of customisable rules, triggered by changes to workitem fields or states. Here are few examples of what TFS Rippler can be used for:

  • Populate an ROI (Return On Investment) field in your Product Backlog Item or Feature calculated by dividing the Business Value by the Effort field.
  • Aggregate values from child workitems up to a parent, for example calculating the Total Work Remaining to complete a Product Backlog Item, calculated from the remaining work on its Tasks.
  • Provide a Feature’s percentage completeness,  based on the Remaining Story Points effort versus the Total Story Points required to complete the feature, aggregated from its child Product Backlog Items.
  • Automatically moving a Product Backlog Item to In Progress as soon as any work starts on its Tasks

Here’s an example Excel Feature Dashboard that is driven by a number of TFS Rippler capabilities, working in combination to show a great overview of Feature progress for all stakeholders:


Outlined in Green we have the percentage complete calculated for a Feature by a calculation that compares the Remaining Story Points against the Total Story Points required to complete the feature (calculated using TFS Rippler’s aggregation facility).

In Pink outline we have the Total Story Points for a feature calculated by aggregating all the Effort estimates for the related Product Backlog Items – this total figure is then in turn used to help derive the Percentage Complete and ROI for the feature.

Outlined in Blue we have the ROI for the feature calculated by dividing its Business Value by the Total Story Points required to implement it.

In the next few blogs I’m going to show how to make all this work and delve into a lot more detail. For more information on TFS Rippler checkout the website.