Hi All, I am struggling with a not so...

[Anon Anon]

Hi All, 

 

I am struggling with a not so unique issue that i KNOW must have a Rally solution.

 

My team's demand has grown so large that we are needing to manage 1 Product backlog across multiple customers. We need to be able to easily group stories by those that serve the needs of 1 customer, 2 customers, 3 customers, or more...

 

I just obtained workspace admin access so that I can create custom fields but I am wondering if anyone has found a better way of managing their backlog with a similar situation?

[Legacy User]

@CA Agile Central Subscription Admins any suggestions?

[Clint Roszelle]

Are work items for multiple customers being prioritized against one another?  Additionally, are you trying to commit a certain percentage of velocity to each customer?  A little more detail will help me provide some guidance (hopefully!). :)

[Anon Anon]

@Lauren Guenther If this scenario applies to a single team you could handle it using another project layer beneath the team project where the team has a sub-project for each customer's backlog. This allows the team to get scoped views of work for a single customer by selecting the customer project level or by moving project scope up a level to see all the work that team is doing across customers. If you have multiple teams supporting the same collection of customers the aforementioned approach won't give a view of all work for a single customer w/o writing custom apps. If you need to support this scenario and leverage OOTB functionality consider using a portfolio item layer as a "customer grouping" mechanism where the underlying stories can then flow to teams regardless of if the teams' project is in the same project hierarchy as the representative portfolio item. Online help has an example of this from a multiple product line support here: https://help.rallydev.com/set-your-project-hierarchy#advice. Near the bottom of this page click on the picture for org type: ISV/Product Company for teams who work on any or several product or programs at a time.

[Legacy User]

I personally would not add another project layer as that, to me, is breaking the team's one backlog into different backlogs.  Have you used Tags to denote the categories you want to use?  If you had Tags for # customers and another around another category, Tags would let you multiple select, too.  Then you could filter as you wanted on a page or create custom pages with their own filters to see sets of data from the same backlog.

[Anon Anon]

Would need to know more about your req't to "group stories" but a single backlog with either tag-per-customer or the (new!) multi-value dropdown might do the trick.   With the dropdown field, in a Custom List you could have a query e.g.   ((CustomerField = "customer X") OR (CustomerField = "customer Y")) as a way to view stories for a particular customer or subset of them and then have a few of those lists on a dashboard arranged by grouping.  ~HTH

[Anon Anon]

thanks for the feedback everyone! Our objective in categorizing in such a way is so that we can prioritize AND make teaming decisions based on utility. I suppose a custom field could do this but we would like to get to the level of where i can see is a utilitarian feature is mandatory for one customer and perhaps only needed as optional for another.

[Anon Anon]

@Clint Roszelle yes, they are being prioritized against OR upvoted if they are needed by many customers for example

[Anon Anon]

Additional attributes specific to a Customer (i.e. mandatory vs optional) makes sense for prioritizing.... interesting!....but not sure how to pull that off gracefully ATM.        This definitely sounds like loosely coupled meta data for the Story (artifact) and attributes or tags would provide the appropriate differentiation between 2 stories in a single backlog.  Trying to think how to 'weigh' a given customer from multiple assigned to a single story....

[Anon Anon]

One thing comes to mind....  if you use a dropdown field, the values are setup in the admin section and 'fixed' (but consistent!) and require admin access to create new ones for each customer.  Tags on the other hand are free-form & prone to typing error and long lists, etc.... but(!) can be added on the fly.    Depending on how many customers per story we're talking about, and given the outcome of needing to see meta data for prioritizing.... I might run an experiment with a working agreement to use tags with a format e.g.   #CustomerX-High or #CustomerX-Low.     Thoughts?

[Clint Roszelle]

You could add custom fields for your customers - 1 per - with drop down values for each that provides options that identify the value of the investment to that customer.  Naming the fields "Customer 1", "Customer 2", etc. would ensure grouping of the fields on the UI.  Then from the Backlog view and others you could add these custom fields to a custom view (or create a custom grid) that allows you view the value weighting of each customer in line to in-turn use this information to drive prioritization decisions.  Another option would be to extend WSJF to include Business Value dimensions for each customer that roll up to an overall COD for your customer base.

[Anon Anon]

You can try utilizing portfolio items to group work items

[Anon Anon]

We use a custom field without significant problems. Regarding the prioritization, I respectfully suggest your product managers re-think their strategy. If you start creating customer-specific paths without considering the costs, you will end up constantly fighting unnecessary priority battles. Instead, focus on core market requirements plus the "requireds" common to all customers. That is your "minimally releasable product" in Agile terms. Next release, add the "requireds" from specific customers. By then, the list of optionals from each customer will likely have changed enough that it would not have made sense to pursue them! If customers insist on earlier delivery of their specific requests, charge them for the customizations. Otherwise, you are losing the "opportunity costs" of losing your strategic focus.

[Anon Anon]

We have a similar situation and are struggling with a solution.  We have multiple ARTs working on different areas of a suite of products.  Some of the features being worked by various teams are important to one or more customers.  The release trains monitor and report on overall progress, but there are strategic project managers responsible for reporting progress of all features relevant to a specific customer, which requires reporting across release trains on only a subset of the work being tracked. We are currently using tags and custom grids to pull the information, which works fairly well.  It would be a huge improvement if more of the stock pages allowed you to filter by a feature-level tag (e.g. Release Tracking, Iteration Status, etc.)  This would allow a strategic project manager to quickly see the status of work related to the customer he or she is supporting.  Any others have a similar situation?  How is it being handled?

[RamaKopella1361744]

I believe Tagging is an interim solution.   We have taken a path to spend time on architecting the release trains, to put it in Dean's words, finding the kidney and then manage via Rally Portfolio.  As you may be aware Products can be managed via Portfolio/Program structure.  We have created Strategic Themes aligned to Corporate objectives at Portfolio Level and Capabilities at the Program level.  I guess higher level, the strategic theme maps to Product Suite that is aligned with an Investment goal  and the products can be mapped to capabilities.

[RamaKopella1361744]

How about making an use case and solving it?