# Monday, August 17, 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>


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.



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

# Thursday, August 13, 2015

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.


Thursday, August 13, 2015 4:43:00 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]

# Monday, November 19, 2012


Introducing Team Foundation Server 2012 and Scrum V2.x

The combination of Microsoft’s latest Scrum process template and Team Foundation Server 2012 brings a host of new features and much improved user experience. Most of the interaction and administration of Team Projects moves into the web interface with only rare visits to Team Explorer required.

A “Backlog” view enables the team to refine the backlog, quickly adding new User Stories and reprioritising any story by simply dragging it up or down the order. A forecast function provides the ability to visualise sprint by sprint how the team might progress through the backlog at a specified team Velocity. Sprint Planning is well supported; the team simply drag candidate stories into the new Sprint and then as they add tasks to the stories there is automatic feedback of team commitment versus their capacity.

A “Board” view provides an interactive virtual team board with state swim lanes so that the teams can see exactly what each other are working on and how the sprint is progressing. The Board view can be narrowed down by team member to aid Scrum meetings and personal work management. The user experience of the board is excellent, with low impedance changes to task states, hours and assignments with an automatic background save.


What About Multi-team Support?

All this new functionality and user experience works nicely when you have a single team working within a single Team Project. It is common though, for multiple teams to work against a common Product Backlog which requires a single Team Project. Consider for example where multiple teams are collaborating to build a product or ecommerce system. Configuring a Team Project based on Scrum V2.x template to support multiple teams is certainly possible but the behaviour of the board and backlog views makes some assumptions and requires some working around.

In VS2012 the multi-team scenario is supported in part by an area path mapping per team that is intended to act as a filter for the backlog and board views such that the teams see their own subset of data. There are a number of challenges with this approach though:

  • The area path is no longer available for Product Backlog theming or categorisation which is a major setback for those of us trying to make sense of large backlogs.
  • The filtering by area path is too binary, providing one of these two options:
    • A team has visibility of the entire Product Backlog but their Sprint Backlog view is unusable as they can’t filter out other team’s backlog items
    • A team can’t see the entire Product Backlog (only those scoped to their area path) but their Sprint Backlog view makes sense. I suspect this is the intended option!
  • Lack of complete Product Backlog visibility degrades architectural decisions and ability to work with the other teams sharing the backlog.
  • The “Forecast” feature of the backlog view isn’t effective unless it applies to the entire backlog rather than just team subsets filtered by area path.
  • Teams can’t pull requirements into their Sprints until backlog items have been moved to the team’s area path by someone else.
  • The issues above drive early assignment of backlog items to teams, causing sub optimal scheduling and flow of stories.
  • One of the teams has to be the “Default” team which inherits its area path setup from the Team Project configuration and doesn’t appear as a named team in navigation lists.
  • New Product Backlog items inherit their area path from the default team path setting, so the “non-default” teams can’t see them
  • All teams share Sprint start and end dates – generally good practice but teams working from different countries often have different holidays requiring adjustment of sprint dates.
  • It is possible to use a custom field as a “Team” field but this approach shares similar challenges as above except that it does free up the area path for backlog categorisation.
  • The custom field approach requires the addition of a team field in all appropriate work items (e.g. Product Backlog Item, Bug, Task & Impediment.

Given the challenges outlined above I have spent some time exploring a number of alternative approaches to supporting multiple teams. Here are three different patterns that work reasonably well if you are prepared to live with a few compromises. There may well be other good patterns so please let me know if you discover them!


Multi-team configuration – Area Path Pattern

If your teams won’t miss the area path as a means of Product Backlog theming or categorisation and all the teams use consistent dates for their sprints then try this pattern. This approach uses the area path to split the team’s views of the backlog but uses an additional “virtual team” to provide the teams a way of interacting with the whole backlog.


In this example, I’m going to have two teams, Team A and Team B, working together against the same Product Backlog within a single Team Project, Scrum03.

I’ve created three teams, the two Scrum teams and then a third team, the Über Team, who will be the “Team of teams” and are set as the default team – notice the bold formatting of the team name in the screenshot below:


The Über Team is the key to working around many of the challenges listed earlier, providing our teams the visibility of the whole backlog for Product Backlog refinement activities and joint planning. All members of both teams are also assigned to the Über Team so that they can use the Über Team’s backlog view. I’ve used Windows groups as security containers for my 3 groups, hence why the view above only shows “1 member” for each team.


DefaultAreaPathThe area path configuration for the Über Team should be set to the root, with sub areas included to ensure that the entire backlog is visible, regardless of whether items have been assigned to a specific team:






The two Scrum teams provide filtered views via their area path setting so that Sprint Backlog and Board views show only those backlog items and tasks committed to by each team. The area path setting for each team should be configured to the specific team path.




DefaultIterationPathThe iteration path configuration is consistent across all the teams as they share the same Releases and Sprint cadence.







How to work with it

See the screenshot below that shows the backlog view from the perspective of the Über Team, with the entire Product Backlog visible. Notice that we have switched the Forecast to ‘on’ so that we see how the combined teams are likely to progress through the backlog Sprint by Sprint.


The teams can jointly assess which stories should be considered for the upcoming Sprint and how they should be split between the teams and pulled (just in time) into each team’s Sprint Planning meeting. They will need to set each story they are going to consider for the next Sprint to their specific area path so that it will appear in their backlog and board views. Until they do this, they will have empty views! See PB06 above, it has been moved into both the new Sprint iteration path and the team’s area path.

To pull a backlog item into Sprint 1 is easy enough; simply drag the desired item to the sprint. The backlog item has to be edited though to select the team who are going to take it into Sprint Planning:




Having used the Über view to select backlog items for planning, teams can then switch to their own view so that they just get their own backlog items to which they can add tasks. Switching between the different team views is shown in the partial screenshot opposite. I’ve added some red marking to indicate the teams we’re currently interested in. Observe that the Über Team doesn’t actually have a name as it is the default team so it just goes by the Team Project name of Scrum03. In this example we are moving from the Über Team’s view to Team A’s view.





In the team backlog view, we select the new sprint and our selected backlog items should appear. If they don’t then either the area path or sprint selection may have been incorrect. In the screenshot below, look for the ‘+’ button to the left of each of the Product backlog items that enable tasks to be added in Sprint Planning.

We’re looking at the “Contents” tab in this example but you’ll notice that there is also a “Capacity” tab that enables the availability of each team member to be set for the sprint. This is what drives the numbers and bar charts that appear in the “Work” section of the contents tab – see the area to the right marked in red. With this feature we can see whether our team still has capacity to pull more work into the sprint.


Having planned a backlog item and confirmed that we have enough capacity to commit to the item, we move the state of the backlog item to “Committed” – see the red marker in the centre of the screenshot above.

Once the team get stuck into the sprint they have their own interactive “board” that allows them to track their progress and synchronise their work:



Multi-team configuration – Team Field Pattern 

This approach is very similar to the previous pattern except that we use a custom field rather than the area path to indicate which team has ownership of a given work item. From a usability point of view it is a very similar experience but with the major advantage that we can now use the area path for backlog categorisation.

The major disadvantage to the previous pattern is the amount of work you need put in to the initial setup of a Team Project to get this to work.

I’m going to try and save this blog from being the longest ever by simply highlighting the differences between the Team Field and Area Path patterns – most of this being in the Setup.


In this example, we have two teams, A Team  and Dilberts, working together against the same Product Backlog within a single Team Project, ScrumDemo04. This approach also requires the “Team of Teams” model and here we have the “Online” team setup as default team to enable an overall view of the Product Backlog.

In summary, what we need to do is:

  1. Create a Global List look up for the team field
  2. Configure the Team Project to use a custom field rather than the area path to support team selection
  3. Setup a custom field type and associated UI configuration for each work item type that we will need to set the team ownership – at least the PBI and Bug
  4. Map the teams that your Team Project will use

1. Create a Global List look up for the team field

The simplest way to create the team Global List is with the Process Editor tool, part of the TFS Power Tools. If you can’t use the Process Editor then there is always the command line and witadmin, using exportgloballist and importgloballist options along with some xml editing.

Here’s the Process Editor method:GlobalList







2. Configure the Team Project to use a custom field rather than the Area Path to support team selection

Use the command line and witadmin with the exportcommonprocessconfig option to export the CommonProcessConfig.xml file and then edit the Team mapping from:    

<TypeField refname="System.AreaPath" type="Team" />

to something like:

<TypeField refname="RippleRock.TeamName" type="Team" />

"RippleRock.TeamName" is the custom field that will be added to each of the work item type descriptions to enable team selection from the teams in the Global List.

See the screenshot below:


After amending the team mapping and saving the file, re-import the updated CommonProcessConfig.xml using witadmin with the importcommonprocessconfig option.

3. Setup a custom field type and associated UI configuration

Use the Process Editor to add the team custom field type to each of the work item definitions that you care about and then expose the new field on the work item form so that it is visible in both Web Access and Visual Studio. Alternatively you can use witadmin from the command line and edit the xml directly if that makes you happy.

3.1 Adding the team field to the Product Backlog Item using Process Editor:



3.2 Set the Rules for the field so that it can only be populated from the Global List you setup in step 1:



3.3 Configure the layout or UI of the PBI work item to expose the Team field:



And here’s what the field looks like on the working PBI:



How to work with it

The screenshot below shows the backlog view from the perspective of the Online Team (the default team), with the entire Product Backlog visible and the Forecast option on. The only difference with the Area Path model is that we now have the team set by our custom field, while the area path is free to be used to categorise the backlog.

PB View w Forecast


The teams will still need to switch views between the Online team and their own as they move to Sprint Planning and update the Team field of those PBIs they pull into their Sprint. Just like the Area Path model except that we now use the Team field instead of the area path.

PB View Dilberts


Multi-team configuration – Iteration Path Pattern

If your teams can’t function without using the area path as a means of Product Backlog theming or categorisation or some teams need to have different dates for their sprints then try this pattern. This approach uses an extra level on the iteration path that allows both a holistic view of the product backlog but also allows the teams to view just their own items at the Sprint level. There is an Über team again but its only role is to support a combined forecast view of the overall backlog.

There is an issue with this approach however, the standard Release Burndown chart that ships with the template doesn’t seem to handle the extra level in the iteration path. It is fairly straightforward to use Excel Reporting to show a Release Burndown and there is an example shown towards the end of this paper. RippleRock are working on an alternative chart that will cater for this approach and works on a daily basis rather than sprint by sprint. We’re hoping to have this report available for on-premise TFS setups soon …



As in the previous example, we have two teams, The A Team and Dilberts, working together against the same Product Backlog within a single Team Project (ScrumDemo 01). In addition to the two Scrum teams, we also have the Online Team (like the Über team in the first example), who will be the “Team of teams”.

The major differences in this approach are in the area and iteration path configurations as we will see below.

AreaPathThe area path can be freely used to categorise the Product Backlog as per the example shown here.

This is the configuration for the whole online team. The team area path configuration can either match this or you can configure subsets for teams specialised to a part of the system. Obviously in Scrum, we encourage good cross-functional teams but in technologically diverse systems this is occasionally necessary.

Notice that with the area path selection, it can be configured such that sub-areas are included with the parent so that all the children are also accessible to the team. This functionality is not available for the iteration path.



TeamIterationPathThe iteration path has additional level for “Team Sprints” under each of the standard sprint nodes.

This enables individual sprint start and end dates and also provides the team filtered data we need to drive the backlog and board views.

By default, new Product Backlog items are created at the node set to be the “Backlog iteration” for the default team, or Über team in our models.

To scope backlog items for a release, simply move them to the Release iteration path node – Online MVP in this example.

We are looking at the A Team’s iteration path configuration and we can see that they are set to only be able to see their “Team Sprints”.


UberIterationPathHere we see that the team of teams view is configured to only see the parent sprints and not the individual team sprints. This is important as it will enable a nice combined team forecast on the overall backlog from the team of team’s backlog view








How to work with it

See the screenshot below that shows the backlog view from the perspective of the combined team of teams, with the entire Product Backlog visible. The Forecast feature is showing how the combined teams are likely to progress through the backlog sprint by sprint, based on the parent sprint nodes rather than the individual team sprints.



From the team specific backlog view we see only the sprints for that team but we also see the entire backlog. In the screenshot below, the team are dragging a backlog item into their sprint for planning.



The other team will also see the entire backlog, including those items that the A Team are planning – as you can see from the iteration path which is indicating which team has each item. Teams can pretty much stick with their own view for planning and working through the backlog and really don’t need to keep switching to the team of teams view as we did using the area path pattern.

As we can see from the A Team view of their planning, all the new backlog and board features work as Microsoft intended them:



The only wrinkle is that the Release Burndown report doesn’t cope with the team sprints. We will be making a day by day Release Burndown report available but it is really easy and quick to use the Excel Reporting capability of TFS to build one like this:





All three of these patterns are quite workable for supporting multiple teams within a single Team Project with a MS Scrum V2.x process template. My thoughts on each approach are:

  • The Area Path model is my least favourite as it sacrifices a key categorisation facility and also offers a clunky user experience.
  • The Team Model is a better model but it requires quite a bit of setup work and shares the same issue of user experience as the Area Path model.
  • My personal favourite is the final pattern as it frees up the area path, has great flexibility of sprint configuration and a better user experience around Sprint Planning.

I’d be very interested to hear your opinions and experience too.



Monday, November 19, 2012 1:44:04 PM (GMT Standard Time, UTC+00:00)  #    Comments [0]

# Thursday, May 31, 2012

The performance of software delivery teams is so often undermined by team members being shared with other teams or regularly borrowed for operational support and other emergencies.

We know that small, collocated, cross functional teams provide optimum performance. So why is it so difficult to have a small group (7 +/- 2) dedicated and focused on one project at a time?

One major reason is that organisations have too much Work In Progress – WIP. Just count the number of in-flight projects and then count the number of teams available to deliver them. If there are more active projects than teams then there is too much WIP. Reducing the number of active projects results in a dramatic increase in the rate of value delivered to customers.

Let’s explore why spreading people across multiple projects is so detrimental:

Switching Cost

it takes time to get our head around a problem domain and then find the relevant bit of the system to work on. The more switching of business and technical domains, the more loss through spin up time. There is much research and writing on this topic, here are a couple of references: 

In their excellent book, PeopleWare, Tom DeMarco and Tim Lister describe: "flow”, a state of deep concentration necessary for “high-momentum” tasks such as engineering, design, development, and other aspects of building software. It takes 15 minutes or more to achieve this state and only a moment to lose it. Every time a team member is interrupted, it costs the company fifteen minutes while they re-enter a productive flow of work.  SwitchingCostGraph

In another great book,
Quality Software Management: Systems Thinking by Gerald Weinberg, he estimates that there is a switching cost of around 20% for every project that a team member is shared across. The impact of switching cost on a team member’s available time is illustrated nicely by this graphic:



Solving complex problems requires close team work with swift collaboration. When a colleague switches to work with another team, any unfinished work they were involved with can block progress of fellow team members. In the worst case, the original team may have to wait for the team member to return before completing a highly specialist task. Over specialisation is another issue that drives organisations to share people across multiple teams but I’ll save that for a future blog.


It takes a focused effort to gain and retain a sufficiently deep understanding of a complex business and technical domain. Attempting to achieve this feat across multiple simultaneous projects, leads to a shallow veneer of knowledge and a poor basis for smart decisions and design.


Being shared across multiple projects erodes commitment by providing places to hide, and we hear this sort of thing: “Sorry I didn’t get my stuff done because I was working on the other project”.

Deployment Contention

In most organisations, fully live-like testing environments are rare and expensive resources that are vital to ensure the software is of sufficient quality to release to production. Like a crowd of people trying to get through a single small door, these environments become a bottleneck on a project’s journey to live deployment. The greater number of projects in-flight exacerbates this situation, leading to a queue of projects and delaying the delivery of value to customers.

Meeting Overhead

Very little software is actually developed in meetings so we try to minimise our meeting overhead to just enough and just in time. However, even with an Agile approach like Scrum it is necessary to spend some time in meetings; as much as 15.5 hours for one team member in a 2 week Sprint. The more teams a person is shared across, the less time they have to actually develop software – see the numbers below:

The numbers below are worked out assuming:

  • Scrum
  • Working time of 6 hours per day (minus breaks and non-project time)
  • 2 week Sprint
  • 60 hours available per person per Sprint


Meeting time per person per Sprint:
     Sprint Planning 4 hours
     Sprint Review 2 hours
     Sprint Retrospective 1 hour
     Backlog Refinement (10% max) 6 hours
     Daily Stand-up 2.5 hours
     Total 15.5 hours



Impact of meetings as numbers
of projects increase



Of course, all these problems tend to be cumulative. So for example, the reduced time for actual work caused by multiple projects is further compounded by the switching cost, leading to very little productive working time.

Organisations that accept shared team members as an inescapable reality, must also accept the reality that their teams are never going to perform as well as they would like.

So the bottom line; reduce the number of simultaneous projects and focus team members to one team and one project at a time to increase the flow of value delivered to customers.

Tags: Agile | Lean

Thursday, May 31, 2012 10:29:13 PM (GMT Daylight Time, UTC+01:00)  #    Comments [0]