Iteration story rank changes Feature story ranking and visa versa

[Jason Spotswood]

I have been noticing a problem recently where when I change the order of the story rank in a feature, that the iteration priority ranking is changed. This occurs the other way as well where changing the iteration story rank, impacts on the associated feature's story rank.

The two should be independent as often multiple people can be working on multiple feature stories in an iteration.

Thus I can have the ideal order for stories to be done against a feature, and then another ordering with an iteration focus based on a number of different activities (and features) going on at once.

Is this a bug, or a new feature that is required to be able to support this?

Thank you.

[Karen Gwynn]

I agree 100%. I use features two ways and when I want to have the stories within the feature ranked, I really hate that things change when I move them into my sprint. I agree that they should be independent. Annoying that they are not.

[Nancy Failla]

This functionality is by design. I'm not sure I am understanding the "why" behind wanting feature stories in an iteration ranked differently than they are within the feature. Are you able to provide more color?

------------------------------
Nancy Failla, Agile Coach
Broadcom/Rally
------------------------------

[Jason Spotswood]

Hi Nancy

For my use case, we work on many features at the same time and provide a priority order within the iteration for each team member. For the feature, I want to be able to see the ideal ordering of stories. For the iteration, I want to be setting priorities for each team member based on our iteration objectives. For instance, I may have someone helping out on some lower priority stories in an iteration for feature A, which for another person the associated feature A stories are their top objective and thus their stories from feature A are ranked higher in the iteration. We routinely have 5 to 7 features being worked on via their associated stories in an iteration.

I hope that helps to illustrate, why these two rankings should be independent.

[Karen Gwynn]

Our situation is very similar, with two or three initiatives/features being worked on at the same time. The sprint has a combination of stories from these different initiatives. For example, we might have Initiative 1 with 6 features and 10 stories in each feature. We've put those stories in priority order relative to completing the respective feature and initiative. In parallel we have Initiative 2, with its features and stories. Those stories are prioritized in respect to the overall feature/initiative. When working in a sprint, Initiative 1 is the top priority, but we also have stories from Initiative 2, 3, etc. The order in the sprint is relative the the work assigned for the time period, not the order that the work needs to be completed for any one initiative. When I put a story into a sprint, and place it in relative order, it gets moved in the relative order of the feature. If I put the feature back in order, my sprint is all tangled up.

[tcopelan]

My $0.02: I see this case as an "off label" use of ranking in the portfolio. From my (Agile PjM) perspective, the ranking of stories in a feature represents the team's assumptions about how that will come together, while the ranking once it gets to planning is a true reflection of reality. That reality is what I want to show up in my features, since it should drive good conversations about the assumptions we made in planning.

One workaround I can think of is to create a custom "planning rank" or "business priority" field on your portfolio items to allow you to fix the initial ranking while allowing for the standard global rank to work normally. With this solution you would be able to compare the plan versus reality at any time.

[Jarrod Reed]

As @Nancy Failla said the way it works is by design.  @Karen Gwynn and @Jason Spotswood if things were redesigned to work in the manner you describe how would use the new data?




​​​​​​​​​​​

[Karen Gwynn]

Thanks for asking Jarrod.

In my untrained way of thinking, the high-level planning artifacts (Initiatives and Features) define our current roadmap. The individual items are ranked relative to each other. when I start with the highest level and as I successively drill down, I am looking at my plan of attack to get the big picture completed (how do you eat an elephant ...). This work will take several iterations to complete.

When I start putting work items into an iteration, I am no longer working within the bubble of the feature/initiative model. I now have to contend with all the competing priorities and requirements to get two or maybe three initiatives/features moving forward, minor bug fixes/enhancements, and on-going infrastructure improvements.

Because we are a small team with a lot of work to do, we work in small silos (I know, not agile, but for now at least, it's our reality). So when we plan our iteration, we are looking at the top two or three stories for each of the different "threads" we are working (roadmap initiatives and the ongoing smaller enhancements/improvements). The priority for the work items in the iteration is a combination of overall priority for a given sprint as well as the relative priority for the different initiatives. As the items get loaded into the iteration, Rally puts them into some order (I think it is based on their position in the backlog). While this is fine for traditional agile approaches, for us, we end up moving things around in the sprint so each person/group sees their work items grouped together. As a result of this rearrangement, when the management team looks at the bigger picture by going to the Initiatives/Features views, the stories in each feature are now ordered relative to where they are in their respective iterations.

BTW, I also order the Backlog in a combination of overall priority (stories for Initiative 1 are higher priority than Initiative 2. Parallel in priority, but listed afterwards, are top priority bug fixes/enhancements and infrastructure items (lowest priority, but something that needs to be done over time). As the backlog and the iteration is rearranged, the stories in the Feature are now in a different order.

For us, this is more of a minor inconvenience, since I can explain why the order looks different in those higher level views. But to get to your actual question ... what it would look like if Rally would change things: Somehow allow for the Rank to be relative to the view you are looking at and if a story is moved in one place, it doesn't get changed/moved in another. Have no idea how this might work, although I did like someone's suggestion that we use custom fields to set ranks for the Features. That would probably work.

My 2 cents (with a lot of extra info just for fun).

thanks again for asking

[Jason Spotswood]

@Jarrod Reed I would use this capability to plan stories based on the realities of the team makeup (eg skill silos) and situation during the iteration, while still having the ideal flow of stories shown in the feature.

Karen has summed up the reasons for needing this capability quite well.​

It would be great to have these two rank order data sets decoupled.
​

[Nancy Failla]

Great conversation around this topic, and the feedback and insight is much appreciated. Hopefully, more to come on this!

------------------------------
Nancy Failla, Agile Coach
Broadcom/Rally
------------------------------