Best Practices for converting portfolio item ranking to user story ranking

[LarrySkowronek1340198]

I am trying to determine an efficient method for transferring the ranking of portfolio item features to the user story backlog.  I have the features ranked just how I need them.  Each feature has several user stories that implement it.  If the features are ranked A, B, C, D, and E, and then in the portfolio view I rank the user stories for each feature properly in the context of that feature, how to transfer that implied ordering of the user stories to the user story backlog?  In other words, I want the user stroy backlog to at least start off ordered as A1, A2, A3, B1, B2, B3, C1, C2, D1, D2, D3, etc.

 

Basically, how do I insure that the backlog at the user story level reflects the feature level prioritization?

[Anon Anon]

Have you tried a custom board with a Feature Portfolio Item swimlane?

[Legacy User]

@Expert Tips and Tricks

[LarrySkowronek1340198]

Tried the custom board idea, but cannot see how it can help.  The custom board widget does not order the swimlanes by any method I could discern (they would need to be in priority order), but even if they were, the columns are not meaningful.

[Anon Anon]

I believe the stories in the custom board should display in relative rank order for the feature such that the story highest in the column is ranked higher than any story lower in the column. But, as you can see when you're talking about ranking it gets complicated quickly. Is a story in a later state ranked higher than a story in a prior state? Is the story for a feature in a earlier state ranked higher than a story on a feature in a later state, but when the story is in a different state? eeek!  What does the relative ranking really do for us here? One question you can ask to help yourself is "why does this matter"? Ranking is useful for determining what to work on next when similar items are vying for the same capacity, and that happens less frequently than I used to imagine. So having everything ranked against everything else isn't all that useful in the greater scheme of things. As someone who is Observant, Careful, and Deliberate (OCD) I love to put things in order and have them all sorted just so, but when it comes down to it I've learned that ranking everything has diminishing value as the set of things being ranked gets larger and less related. Could I reframe your question by asking, "What problem are you trying to solve?"

[LarrySkowronek1340198]

Right, the issue you highlight with the board is the same issue as with the portfolio items page(s).  Everywhere there is a hierarchy, all ranking/prioritizing work done at the higher level has no impact on the ranking/prioritization at the level(s) beneath it. The problem I am trying to solve is I need to insure that all of the user stories for a feature are ranked together and after the user stories for the next highest ranked feature and the before the user stories for the next lowest ranked feature.

[LarrySkowronek1340198]

What would work is a field that displays the current rank of the parent object.  That way, the person responsible for the prioritizing of the user story backlog has the information in front of them about how the parent features were prioritized.  It seems somewhat inelegant, but I cannot think of anything else.

[Anon Anon]

"What would work is a field that displays the current rank of the parent object." -- yes, I want this, too!!!

[Anon Anon]

What is the purpose of ensuring all stories from one feature cannot be ranked higher than a story from a lower ranked feature?

[Anon Anon]

Dennis, for me, this is not about restricting a sub-item of parent2 from having higher priority than sub-item of parent1 when parent2 is ranked lower than parent1. It's for when I'm initially trying to consolidate dozens of backlogs from various teams into a centralized workspace to do top-down portfolio wide prioritization. I'm finding that the ranking of many of the sub-items need to be adjusted based on the ranking of their parents (and their parents). So, it's more of an initial default that I'm after here. And perhaps it could be optional in that when I rank parent2 above parent1, I would be asked if I want to "adjust the lowest rank child of parent2 to be above highest rank child of parent1" to which I can click [Yes] or [No].

[LarrySkowronek1340198]

Lawrence, what you describe is exactly the situation and process we are in. I have gone ahead and created a custom field called "Parent Rank" and in the (tedious and time consuming) process of setting the "Parent Rank" filed to the current rank of the objects parent.  I did that for the two highest levels of our portfolio and it highlighted prioritization problems immediately!  In other words, I had a high-ranking strategy item with many child "initiatives."  When I then reviewed the Portfolio at the Initiative level, a quick review showed that several of the child initiatives were ranked very low, when actually they are of high importance.  I had never noticed that before.  This allowed me to see it and fix it easily. The issue with this method, of course, is the work to manually assign the rank of the parent to the custom field of each of the children and, more importantly, the work to manually keep that up to date when the ranking in the parent level changes.

[Anon Anon]

@Lawrence Liu - hopefully Larry's response is helpful. I don't want to be tedious here with all my questions, but I still don't understand your "consolidate dozens of backlogs from various teams" process or why this is necessary. This is probably a good discussion to have with the Solution Architect assigned to your account using a whiteboard in a conference room. :-) It is still not clear to me why the ranking of the lower level stories and portfolio items matters with respect to the items higher in the item hierarchy as long as they are ranked relative to each other at each level. In other words, if a story related to your highest ranked feature is ranked lower than story related to a lower ranked feature, why does that matter?

[Anon Anon]

@Larry Skowronek, we're about to use a different approach to accomplish similar objective. I created a custom "FY16Q3 Rank" field that would be used to set a preliminary rank of respective child items in a list of parent items. Since the parent items are already prioritized, we use the custom grid hierarchy view and expand each parent to see its child items, and then we set the Rank for the parent1's child items as 101, 102, 103, 104, 105, for parent2's child items as 201, 202, 203, 204, 205, and so on. We don't set more than 5 child items per parent because anything ranked lower mostly likely wouldn't get implemented anyway within the quarter. Next we switch to a flat list view of all child items (about 600) with the "FY16Q3 Rank" field added, and then we drag-n-drop items to set their true built-in Rank accordingly. We plan to go through this exercise every 3 months top-down to realign any radical bottom-up changes to prioritization of the child items.

[Anon Anon]

@Dennis Elenburg, "if a story related to your highest ranked feature is ranked lower than story related to a lower ranked feature, why does that matter?" - it matters because we want to try to get the higher ranked feature to market sooner than the lower ranked feature. :-) And to complete a higher ranked initiative (with all of its child features) sooner than a lower ranked initiative because the former initiative likely delivers greater business value. Of course, there are exceptions, which is why it's great that Rally allows independent ranking of respective levels of work items.

[Anon Anon]

If you're using the new team planning page and the group by feature filter, then you will see those stories in such a way that when you do your iteration planning they are appropriately displayed in the backlog by rank, and can be committed to the iterations in your release. I understand what you're trying to do, but it still seems like unnecessary effort. I'd have to learn more about how your teams do release planning, and that is probably beyond the scope of this chat forum. It sounds like you're doing a lot of grooming that is typically done by teams, and without knowing what your scaling framework looks like I really cannot comment further. Our engineering team uses SAFe, and you could talk to your Solutions Architect about how we do this in our shop. I also have several large customers running 9+ release trains in a single department, and I've never been asked about this, so I was interested in understanding your scenario. Thanks for sharing.

[Anon Anon]

Team Planning page is okay for release planning at the team level. I'm dealing with a top-down business planning initiative that spans 2000+ people across 20+ locations for dozens of products/services. This is HIGHLY SCALED agile that we're attempting with Rally tool. I'm a Certified SAFe Program Consultant (took the course last October taught by Rally SPCTs) and trying to apply SAFe models and practices as well as whatever else can help. Ultimately, our objective is to have top-down _AND_ bottom-up planning connected within the same tool (Rally) so that everyone can see items/relationships from strategy to development to deployment and across the entire organization.

[Anon Anon]

@Lawrence Liu Lawrence, we have very similar planning scenarios as you describe and this is an issue I presented to my Rally account team recently.  The SAFe rolling-wave portfolio planning for a 6-month period aligns the Initiatives and child features with the business strategies.  This comes from the business and marketing teams.   When features are decomposed to child User Stories, the stories need to align with the parent's priorities as a starting point.  We currently address this in the pre-PI planning sessions, since the Features and child stories are already pointed, so out-of-sync stories are rather visible.  It would be awesome if the tool could highlight that by design in a visual way.   Now that our Product Mgmt team plans out 6 months - 1 year out (in Rally), the priorities for initiatives do not shift as radically as in the past.  I build an excel MoSCoW worksheet to indicate when features should be completed, based on ROM of the preliminary estimate. Jumping to a "how" strategy, the Child needs to "inherit" the parent's priority.  The tricky part will be for which 'period', since Features are continuously being re-prioritized as they near their time for execution.  Rally already uses an  inheritance model when a Release or Iteration periods are pushed into sub projects.  Another is the User security by project that inherits from parent project user access. So inheritance isn't a foreign concept, and could be leveraged when conducting SAFe rolling wave planning.   We currently have to export the Feature & Priority and compare user story priorities.   The Rally Portfolio Release Tracking sort of helps, only when dependencies are defined. Exceptions would be if/when team members don't have enough work, however, pulling in work early creates Kanban WIP limit challenges.  Experience is showing that pulling in work early just to keep teams fully booked creates further refactoring and defect work later.  The Lean principles around setting Kanban WIP limits is well worth consideration.  In many cases, it might be better for idol team members to work on tech debt rather than pull in something too early.

[Anon Anon]

I concur with my fellow customers, and will add the wrinkle that this is even more important for us at the higher levels of the portfolio hierarchy. Say a team has the skills to do either of two features/epics in the next release. The first question is, which parent "Program" is the higher priority? You can't tell by looking in the epic; you have to look elsewhere. Not a big deal, but... Now multiply that exercise by eight teams with overlapping but not identical skill sets, five programs in flight, and multiple epics per program.

[Anon Anon]

Glad to see that we're not alone in having challenges with Rally to achieve our goal of "bottom-up execution management integrated/aigned with top-down planning." Alas, our workaround of using a custom "FY16Q3" field to manually set the "top-down prioritization context" of a child item is only half the solution because when all the child items are view in a flat list, there's no easy/quick way to reorder a bunch of items together. It's very tedious to move just 1 item at a time!