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
------------------------------
Original Message:
Sent: 12-27-2019 10:38 AM
From: Jim Smith
Subject: Parent Stories, Features, and OOTB Use
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.