Rally Software

 View Only
  • 1.  Looking for feedback/best practices: How do you use Rally for...

    Posted Mar 04, 2015 10:21 AM
    Looking for feedback/best practices: How do you use Rally for management of multiple teams, with separate projects?  I want the ability for each project to have it's own product backlog, but if a user crosses multiple projects, ability to see their "assigned work".


  • 2.  Re:

    Posted Mar 04, 2015 12:08 PM
    @Portfolio Management


  • 3.  Re:

    Posted Mar 04, 2015 07:59 PM
    Hi Stephanie, We define our Scrum Teams as Rally "Projects" with some minimal organization hierarchy, and define Project Epic User Stories at the top level of "Project".  Each story can be assigned to any team/member, while rolling up to the appropriate project.  This layout has served us very well and Rally seems to support it without fallout.


  • 4.  Re:

    Posted Mar 05, 2015 09:17 AM
    Hi Stephanie, see Johns' answer to my question which gives a good example of how you might set up your projects Do I need to be able to see another track to link dependencies to their user stories?


  • 5.  Re:

    Posted Apr 23, 2015 02:11 AM
    Highly recommend adopting SAFe practices for managing the portfolio!  Multiple Agile Release Trains are the way to go.


  • 6.  Re:

    Posted Apr 27, 2015 08:01 AM
    We have a Parent Project that is call "Product A" then we have child projects for the many teams that do the work developing and maintaining Product A, I think we have 10 child projects.  This allows us roll-up to all work that is happening and allows team members to view all the work.


  • 7.  Re:

    Posted Aug 02, 2015 06:40 AM
    Hi Stephanie, This is a critical question and one you can't easily change on the fly later so be very clear about what you are trying to do before doing it. you can technically make those changes but it's potentially a lot of rework... we use the following: - top level: company - child level1: value stream - child level2: Team: Ops ...  for kanban teams - child level2: Team: ART ... for dedicated release train teams (scrumXP) - child level1: Team: ART... for shared component teams delivering against multiple value streams (not ideal but does exist for us!) another key dimension is the planning and delivery cadence for those "levels" - company and value stream: quarterly "Releases" defined as Financial Year quarter - Team: Ops: same quarterly "Releases" defined as Financial Year quarter - Team: ART ... a quarterly "releases" cadence that may be different to the cadence above as the execution doesn't necessarily benefit from being completely aligned (and sometimes not possible if defined by external service providers for example). it's easier if you can fully align though. hope this helps,


  • 8.  Re:

    Posted Aug 03, 2015 09:56 AM
    @Expert Tips and Tricks


  • 9.  Re:

    Posted Aug 03, 2015 12:40 PM
    Similar to Wendy's structure, we define the company-wide set of projects as Epic User Stories defined on a company "team" (or to confused things, what Rally defines as "Project") which is good for the fiscal year, then we define the "teams" as all the Scrum Teams within some light organizational structure (groupings of teams).  This provides you with a team/project matrix which gives you multiple views of your stories.  It is relatively easy to add/move teams as your company changes.  We are in the 6th year of this structure and have little complaint.  The relatively new Portfolio module gives you further structure to plan/manage work as a Portfolio or Product manager where the Epic "Project" Story moves over to the "Initiative" story with User Stories rolling up to Features, Initiatives, and then Portfolios.  We are still experimenting on the Portfolio structure and use.


  • 10.  Re:

    Posted Aug 03, 2015 05:24 PM
    We found the hierarchy model works very well and I echo Anthony's description with - top level: company - child level1: value stream - child level2: Team: Ops ... for kanban teams - child level2: Team: ART ... for dedicated release train teams (scrumXP) - child level1: Team: ART... for shared component teams. We use the Track/Team Status to know how people are loaded and the individuals see tasks across multiple teams.  Prioritization is evaluated during the PI planning process when multiple ARTs might have/need dependencies. All the above lends itself to better portfolio management where we follow the kanban process for managing initiatives and feature state changes.