Automatic Roll-up/Update of Portfolio Fields

[shabid.ali]

Hello Team

Consider the below scenario involving Portfolio Items:

A Feature (FEA300)  has 3 Team Features​ (TF1000, TF1001, TF1002).

Planned End Date for TF1000 is Dec 17, 2019.
Planned End Date for TF1001 is Jan 07, 2020.
Planned End Date for TF1002 is Dec 31, 2019.

Can Rally Software be enhanced so that these data be automatically rolled-up and
'planned end date' can be automatically populated as 'Jan 07, 2020' for FEA300?

Thanks,

[Mitch Goldman]

I must be missing something here.  How are you parenting features to other features.  I cannot see how that gets done.  It's possible to do this with user story->user stories, but (as far as I know) not with features.

[shabid.ali]

@Mitch Goldman It's quite simple. For simplicity, in the image below, Replace 'Initiative' with 'Feature'  & Replace 'Feature' with 'Team Feature'.

 ​

[Eric Nash]

Hi Shabid;

The odd nomenclature of your portfolio levels (Feature being a parent of Team Feature) aside, as you've observed Rally does not set planned end dates for a parent item based on the planned end dates of its children. This is for a good reason; consider the case where we create a parent Epic (the more common level above Feature) and set its planned end date based on the judgment of the Epic owner before all of the child features are created. You can easily observe cases where the dates don't align logically by looking at the Portfolio Timeline or the new Timeline page releasing on 18 November.

If you'd like to propose a change to this behavior as an enhancement then the right place to do that is in the Rally customer voice portal, Idea Manager. You can find that portal at ideas.rallydev.com. Once you've proposed the idea you can post it here and ask other users to vote it up if they agree with you. 

Hope that's helpful, thanks.

------------------------------
Eric Nash
Principal Agile Consultant
Enterprise Studio by HCL Technologies
------------------------------

[shabid.ali]

@Legacy User Sure, The nomenclature might be looking odd for you, just think of Parent and Child portfolio items in that case.
And coming to the issue here: Parent Portfolio Item owner obviously need to set the planned end date only after looking at child  ​Item planned end dates.
Currently, all this is being done manually, which is prone to errors, obviously.
Also, you may note that 'planned end date' is only just one example of one such field.

Thanks to your suggestion, I will place this in customer voice portal.

[Matt Seitz]

Eric:  I think this points up an inconsistency in the Rally data model for "End Date".  Based on your explanation, it seems that what the "End Date" represents depends on whether you are the parent or the child:

Parent:  End Date = DESIRED end date
Child:  End Date = PREDICTED end date

Or, maybe put another way

Parent:  End Date = ORIGINAL predicted end date
Child:  End Date = CURRENT predicted end date

It is this inconsistency that leads to the kind of request being made here:  if the child's end date represents the "current predicted" end date, then shouldn't the parent's end date also reflect the "current predicted" end date?

Yes, one can use various tools to compare the end date of all the child items to the end date of the parent item.  But it might be convenient to have that information available as a field on the parent item.

Maybe it would be better to have 2 separate date fields, one field for the desired end date (wouldn't roll up from children to parent) and one field for the currently predicted end date (would roll up from children to parent).

[shabid.ali]

@Matt Seitz Can't agree more. I myself noticed this data inconsistency a number of times.

[Nik Antonelli]

Hi Matt,

I think there might be a flaw in your logic. Even for a child, the only way to know 'a predicted' end date is to know the rate at which work is being done and how much work there is left to do. Otherwise, the child's enddate is still just someones guess.

To help answer some of these sorts of questions, I developed two apps. The first give you a burnup/burndown for portfolio items. The burndown gives a desired (green line) and a calculated prediction line (grey dashed) as long as the work rate being completed is faster than the rate of work being added (else you can predict diddly-squat).

The second app will look at the current delivery rate of your past portfolio items and give you metrics on how well you are predicting and how long a new project might take you (from your initial size guesses).

Have a look here:
https://github.com/nikantonelli/WorkItemsForInitiative
https://github.com/nikantonelli/ForecastAccuracy

There is a third app that you might also find useful as it will highlight for you where you have child dates outside the range of the parent dates.
https://github.com/nikantonelli/PortfolioItemTimeLine/tree/With-Stories

BTW, it may be that the Product Manager schedules a parent and a Product Owner (or even Scrum Master) schedules the child. If you can see any scheduling errors, then you can initiate conversations as to why the two people think differently rather than just masking an issue by automatically updating the parent - the Product Manager has a possiblitiy of not seeing the update.

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[Matt Seitz]

"Even for a child, the only way to know 'a predicted' end date is to know the rate at which work is being done and how much work there is left to do. Otherwise, the child's enddate is still just someones guess."

Yes, that's why I mentioned that one way to look at the current model is:
Parent:  End Date = ORIGINAL predicted end date
Child:  End Date = CURRENT predicted end date

I looked at the apps you mention, and they look similar to the Timeline apps that @Legacy User mentioned.  But my users prefer to work from a table, not a graph.  They want a quick way to compare the Parent "End Date" to the last Child "End Date", and to export that data to a CSV file.​  That's why a "Last Child End Date" field would be a useful addition.  It would also be useful to have an OPTION to easily update the Parent "End Date" to match the "Last Child End Date".

[shabid.ali]

@Nik Antonelli The problem here is NOT about how to find an end date. Finding end date in Software Development is NEVER a calculation based on rate of work alone. Leaving that discussion aside, ​coming back to current inconsistency, the issue here is when Child end dates are entered, the same need to be rolled up to Parent level else which could be left in an inconsistent state, if not manually re-adjusted. Again that's just one field. There are #N number of fields like that. ​

[Nik Antonelli]

Hi Shabid,

Let's envisage an imaginary scenario: an large organisation has four, maybe five levels of portfolio hierarchy: Feature, Business Outcome, Initiative, Portfolio Objective, Strategic Objective and the dates get automatically rolled up and changed whenever a lower level item is updated as per your idea.

Maybe, this organisation has feature teams and the scrum master schedules the features and works with the team to initiate user stories, etc.

The CTO has worked out that a Strategic Objective (top level) needs to be completed on for a (corporate) business need. The work gets broken down into parts and farmed out to bits of the organisation as required.

Somewhere at the lowest level, a Scrum Master realises that they haven't got the capability to deliver a feature, so moves it out by a few months without realising the full impact on the business. The completion date of a Strategic Objective suddenly (because you have automatic roll-up) gets moved out because a person who doesn't have a grasp of the bigger picture.

CTO goes mad because his/her careful planning of a delivery to an important client has just been trashed.

I think I would rather not have automatic roll up. I would rather have an app so I can see the exceptions and have a conversation about priorities.

The problem with automatic rollup is that you also need automatic notification of changes and then you would need a process of approval of changes to deal with the situation that someone might miss the notification (human error is constant). Sounds very hard to manage and keep everything in check.

------------------------------
Nik
Rally Sales Engineer
Rally Software
------------------------------

[shabid.ali]

@Nik Antonelli

First of all thanks very much for coming up with very nice example.

Let me give few comments on this:​

#1. Yes, possibly, somewhere some team realizes they can't deliver in the original timeline planned, which usually happens.
And their work is part of a parent item obviously which is in trouble now as it can't respect the timeline.
Just because there is no automatic roll-up, will the entire scope of parent item gets delivered? No, right.
And without automatic roll-up parent's owner might realize it very late that it's not possible to deliver the entire parent work as planned.
Is that a good thing? I see actually this is THE case CxO will go mad because the tool is concealing the reality.

#2. Yes, tool is expected to alert the parent owner when data is inconsistent.
But first it should at least show that there is such inconsistency, right?
Just because we don't have the facility of alerting, should the tool be allowed to show inconsistent data?

Summary:

These issues of child extending planned end date and thus impacting parent delivery date is quite common in the real world.
While there are numerous solutions for that, We do understand that Rally is just a Tool,
which is not expected to solve the actual issue of extended delivery date of parent by any means.
What we are expecting is only that is Rally to show consistent data, if not an alert system in place.


Finally:

An idea to show case inconsistent data could be display of "Warning Symbol" at that field even without actually rolling-up.
This will force the owner of the parent item to recheck related data of all the children and to re-adjust the parent data, as needed.