We sell "appliances"; each appliance consists of multiple massive databases, dozens of customized third-party tools, hundreds of applications and daemons, a customer-facing GUI with hundreds of pages, a customer-facing API with hundreds of functions and objects, etc.

Due to the nature of our product, our sales strategy, and the limits of our QA and support, we have determined that we must support between 2 and 4 major versions (or "trains"), and for each of these, we must release incrementally at daily or weekly granularity.  That's just how it is.

Rally seems to assume that QA can magically take the code that they need at any given point in time and test it.  However, we work strictly by creating branches for any new development and never commiting into a communal "trunk"; instead, we have a "production" branch that is managed by QA and mirrors, exactly, the things that a customer would receive.  This methodology cannot change at this point in time.

With this in mind, we come to the following decription of what we are working on:

Legacy Version: Only critical bugs will be addressed here; customers are strongly encouraged to upgrade to the "Maintenance Version".

Maintenance Version: All bugs are aimed to be addressed in this version.  No new features or enhancements are scheduled ever.  A customer with training for this version will never have any issues with using it.

Early-release Version: In this version, in addition to addressing any and all bugs, we also release entirely new features, drastically update or augment existing features, remove deprecated or outdated items, etc.

Our development is mainly focused around the Early-release version (with focus on the Maintenance version as bugs are reported).  The Early-release version is usually very intense; drastic changes happen all the time as components are replaced or re-written or moved.

In Early-release, each new and independent feature (and there are a lot) are developed in separate branches off of the "production" version of the Early-release train.  Any time there is a release to the Early-release train, all active projects ("branches") must merge in the latest changes and/or incorporate their spirit into the newly-developed code in the branch.

So far, so good.  No issues yet.

We are aggressively attempting to use User Stories to describe the product fully such that all Defects that come in can (and must) be associated with a User Story in order to handled (if there's no User Story saying how it's supposed to work, then how can a Defect be filed?).  Each User Story is amassing a series of Test Cases that demonstrate its accuracy.  Each Defect must associate with one of those Test Cases (if it doesn't exist yet, we are required to create a new Test Case for the User Story, further defining its scope--kind of like the Supreme Court).

Here's where the problems come in:

1. We have hundreds of User Stories; our appliances can do quite a number of things, each with intricate details that we are continually enhancing.
2. We have hundreds of Defects (ranging from "The border color on this particular box should be darker" to "This mystical combination of actions cause something to break").
3. We have, at any time, tens of "Releases" available for QA test.  Once they fully test something (it goes through many stages--note that Rally does not manage this process well, if at all), it is "released" as a patch to the system (and all applicable work items are marked as "Accepted" at once).
4. We have, at any time, tens of "Releases" available for development to work on.  These are scope-confined to facilitate (1) ease of development and compartmentalization, (2) ease of testing and scope, and (3) risk-mitigation by not grouping dangerous features and changes that may conflict or be impossible or have to be halted for whatever reason.

The big problems that we have are mainly work-flow related; these usually come down to some aspect of Rally either missing or not being easy enough to use in our case.

I shall now list the workflow problems that we have (and our current "solutions", which are somewhat acceptable).

Problem: I have no idea what to work on.

Problem: I have no idea what to give my team to do

Problem: I have Test Case results with no meaning.

Problem: Discussion on items is almost meaningless.

Problem: Associating things is difficult.

Problem: QA/Developer communication is weak (notifications?)

I would like to use the C# API to set the tags for test cases. I found this post which seems to give directions on how to use this functionality for the Java API. However, the C# API doesn't have methods for setTag for either the TestCase or Defect objects. I may be missing an import, but at the moment I can modify all other aspects of the TestCase and Defect objects as needed.

Problem accessing /slm/user/edit/createAndNew.sp. Reason:

    NOT_FOUND

I get this when I try to create a user, also when I try to edit a user

Unable to attach a file to a test case.