# Monday, 17 August 2015

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>

</FIELD>

Form Definition:

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

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

</FIELD>

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:

AnnotatedROItransition

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:

ROIxmlBorder

 

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.

.

Tags:

Monday, 17 August 2015 14:46:13 (GMT Daylight Time, UTC+01:00)  #    Comments [0]