Inconsistencies in RPM hierarchy scoping

Question

I am working to create an RPM tree that can be used to select leaf stories from different levels of the RPM hierarchy.

I was able to get close to the desired functionality by using the method described here, however there appear to be some inconsistencies in the number of leaf stories being returned at each level of the RPM.

The following Image shows the tree (Project names covered for privacy purposes). The yellow badges show the number of leaf stories found below that level of the RPM hierarchy. As you can see from the image, the numbers are inconsistent. (Below the Initiative shows 23 leaf stories and below one of the Rollups shows 44.) There are in fact 44 leaf stories below that Rollup so the problem appears to be from querying at the Initiative level.

enter image description here

Here is the function I wrote which is intended to return an array of all the OIDs for leaf stories below the selected RPM node:

                   function getDescendants(OID, callback) {
                        Ext.create('Rally.data.lookback.SnapshotStore', {
                            autoLoad: true,
                            pageSize: 1000000,
                            fetch: ['ObjectID'],
                            filters: [
                                { property: '_ItemHierarchy', value: OID                       },
                                { property: 'Children',       value: null                      },
                                { property: '__At',           value: new Date().toISOString()  },
                                { property: '_TypeHierarchy', value: 'HierarchicalRequirement' }
                            ],
                            listeners: {
                                load: function(model, data, success) {
                                    if (data && data.length && success) {
                                        var descendants = [];
                                        Ext.Array.each(data, function(story) {
                                            descendants.push(story.get('ObjectID'));
                                        });
                                        callback(Ext.Array.unique(descendants));
                                    } else {
                                        callback([]);
                                    }
                                }
                            }
                        });
                    }

Mark Smith · Accepted Answer · 2013-01-10T20:09:58.760

That query looks correct to me. I think you've encountered a known defect that existed in the data stream to the Lookback API. The problem in the stream has been corrected, but the work to go back and correct the faulty history is still in the team backlog. If you want to track its progress with Support, the defect has ID DE15647.

The workaround (since you're only querying the current data) is to un-parent and re-parent affected items.

Sorry.

Edit: Some more detail on the problem - For a period of time, whenever a PortfolioItem (Strategy, Theme, Feature, Initiative) was created and had its parent set at the same time, the Lookback API service didn't get notified of the new PortfolioItem's parent. This problem is now resolved, but the old data is still to be fixed. You could search for PIs that potentially have this problem by looking for ones in that _ItemHierarchy with a null Parent field.

To get the PIs with null parents (potential orphans):

fetch: ['ObjectID', '_ValidFrom', '_ValidTo'],
filters: [
    { property: '_ItemHierarchy', value: OID }, // only include this if you're limiting to a sub-hierarchy
    { property: '_TypeHierarchy', value: 'PortfolioItem' },
    { property: 'Parent', value: null },
    { property: '__At', value: 'current' }
]

For each of these 'orphans', check for a parent that has it as a child:

fetch: ['ObjectID'],
filters: [
    { property: 'Children', value: currentChild.ObjectID },
    { property: '_TypeHierarchy', value: 'PortfolioItem' },
    { property: '_ValidFrom', operator: '<=' value: currentChild._ValidFrom.toISOString() },
    { property: '_ValidTo', operator: '>' value: currentChild._ValidFrom.toISOString() }
]

For each one, if you find a parent that's claiming the child (at the time the child was created), you know you've a snapshot affected by this problem and can fix it by clearing its parent in ALM, saving, then resetting its parent and saving again. I included __At: 'current' in the first check, since there's a chance the orphaned PI had a different parent assigned later and you wouldn't want to overwrite that. Hope this helps.

That's a real bummer, although it answers my question of why some stories were affected and others weren't. Thanks for filling me in. — Conner Reeves, Jan 09 '13 at 21:25
Quick question... Do you mean unparent-reparent the RPM levels, the User Stories, or both? — Conner Reeves, Jan 09 '13 at 21:28
You just need to reparent the RPM levels, as it's those that didn't get their parent set in the stream to Lookback API. — Mark Smith, Jan 10 '13 at 19:20
Is there any quick, or automated, way of doing this? We currently have about 300 nodes in our RPM structure. Doing this by hand would take quite a while. — Conner Reeves, Jan 10 '13 at 19:22
I've updated my answer with more detail on the cause and how to identify affected items. You should be able to automate it if you call out to WSAPI to save the affected ones with the missing Parent. — Mark Smith, Jan 10 '13 at 20:10

Inconsistencies in RPM hierarchy scoping

1 Answers1