Parent Stories, Features, and OOTB Use

[Jim Smith]

We've been experimenting with various ways to properly use parent / child stories. 

In our current setup we intake project request through another system then create a parent story where a parent story translates to a project then various dependent teams then create a child story under the parent. While this got us off to a good start, it looks as if this may not be a good long run strategy as the Rally product continues to evolve. It is becoming more difficult to report back on company projects (parents). I've experimented in various ways to improve our approach but could use some confirmation to help align better to out of the box functionality. 

1. Is the intended OOTB functionality to leverage Features as a project (which would be equal to a parent) and supporting teams create children stories? I've setup a POC under the Portfolio Items screen where feature = project / parent story in our current process and it appears to make more sense to me as I compare that with past experience with other ALM or PPM tools. 

2. If Features could / should be leveraged as projects, is it safe to assume features would then belong to initiatives most of the time?

3. We don't use Release yet, just iteration for planning. If we were to grow into using the resource plans would the feature = project model align with the OOTB functionality? If that is the case, would resource plans be made at the story, feature, or initiative levels? Which is best and do they roll up to a top level? Can we easily report planned estimate vs. actuals?

4. What are some of the use cases or best practices for using a parent / child story? While team communication is critical, we find it very challenging when sibling stories move out an iteration don't have a system generated notification of a change to the sibling without trying to connect them via Dependencies and I'm not so sure that is the best approach.

 

[Terry Ginzburg]

Hi Jim,

In my experience, you want to either use the Portfolio (Features etc.) with one 'layer' of User Stories under them OR use parent-child User Stories without using the Portfolio items at all.  Mixing the two models can lead to messy data.  It sounds like using Features as your Projects with the child User Stories under them would work well for you.  You could tie the Features together under your next-level Portfolio Items (Initiatives?) if that helps.  Using Portfolio Items gives you the ability to view roll-up data to report on progress etc.

You would typically plan Features into Releases (these are not necessarily intended to represent Deployments but rather just a larger planning window, for example the Program Increment described in the Scaled Agile Framework).  Features are estimated using the Preliminary Estimate (XS - XL drop-down with associated points values configured within your subscription) and Refined Estimate (numerical field that can be used to add a more specific number, either story points or some other number depending on how your organization looks at capacity).  You can build a Release Capacity Plan based on your features, and then teams can build their more specific Sprint plans using just the points on individual stories.  If you use the Capacity Planning page to build a feature plan and publish it, you can see current progress toward that plan on the Plan Progression page.  The Release Tracking page also gives a great view of progress toward the features in the Release, with details showing which teams are working on which features in which sprints, what stories aren't scheduled yet, and any story-level dependencies within the Release.

If you're using the portfolio at all, I can't think of any use cases for using parent-child stories.  

I hope that helps!

------------------------------
Terry Ginzburg
------------------------------

[Nik Antonelli]

Hi Jim,

The concept of parent-child user stories was developed to deal with organising chunks of work together in a logical collection. Some organisations I worked with had multiple layers of parent-child relationships to represent ever decreasing chunk sizes.

This is exactly what Rally mimiced when creating the Portfolio Manager part of Rally. There is no direct rule that one particular level in the chunk size hierarchy should represent one particular thing (e.g. Project). The recommendation that I make to my customers is to have three levels or portfolio hierarchy and one level of user stories. The top most level or the portfolio hierarchy is usually the size of thing that a corporate decision will be made about, and often that is a yearly funding based decision.

So, if your company is still using projects terminology (not yet pivoted to products), then the three levels can be Feature, Initiative, Theme, as in the default settings for Rally. The Theme is then synonymous with a Project. An Initiative could be then used to cover the work done for a particular product department and then features can be farmed out to the development teams. You can then let the development teams create their own single level of user story to schedule into sprints.

Of course, if you are a relatively small organisation, three levels of portfolio items might seem too much and can be squeezed down into two.

You will find that most of the future enhancements in the Rally product are moving towards the concepts of Portfolio Items and the ways organisations can leverage them in a sensible, logical and straightforward way. The way that we can cross connect between work items means that even if the work is being done by completely separate parts of an organisation, we can still see the roll-up and all the inter-dependencies. #4 all but disappears as a problem in the scenario I recommend.

It sounds as if you might benefit from a chat with a local Rally Sales Engineer about best practice. If you would like, ping me privately and I will try to find the right person for you.

​

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