0

Is there a way in Rally to do a general search for an exact text match? My specific example is that I searched for the word windows but the results include items which only have window. I've tried putting the search word in quotes, which has no effect. How can I narrow this down to the exact term?

I have of course tried a web search for this information, but it was not productive. (Possibly I am just not sure where to look for info being somewhat of a novice to this tool!)

GUI search field

2
  • 2
    I get why this was closed by the community, as it reads a little like a RTFM question. However, the underlying question seems on topic as a PM tool usage question, and the product documentation is perhaps a little less clear than it could be on the topic. I've re-opened the question, but would consider re-closing it if it veers too far into localized product support territory.
    – Todd A. Jacobs
    Jan 16 '20 at 17:08
  • 1
    @ToddA.Jacobs thank you for the feedback, I'm new to this particular Stack Exchange (obviously). It appeared to be on topic although the precise boundaries for what tool questions are allowed seemed to have some gray area in the "asking help" section. As far as the RTFM - well, I did and found little. I generally haven't found the Rally docs to be very helpful, but clearly missed what docs they do have. Jan 16 '20 at 18:57
2

Fun with Word Stemming

Search is always a little idiosyncratic between applications, so documentation can be invaluable. Rally's documentation isn't easy to find online, but the topic is covered even though it's not really as clear as it could be.

Confusingly, Rally doesn't do substring matches, but it does do word stemming and provides no way to disable it. The search documentation says:

+------------------------------------+------------------------------------------+
| Tip                                | Description                              |
+====================================+==========================================+
| Search for phrases and similar     | Keywords enclosed in double quotes       |
| matches by enclosing them in       | are treated as phrases, and displayed    |
| quotation marks.                   | together in search results. The search   |
|                                    | returns exact matches of what you typed, |
|                                    | plus various forms of the phrase, based  |
|                                    | on the stems of each word. For example,  |
|                                    | a phrase of "test search" returns        |
|                                    | results for "testing search", "testing   |
|                                    | searches", "test searching" and so on.   |
+------------------------------------+------------------------------------------+
| Partial string (substring) matches | Example, if you search for *arm*,        |
| are not supported.                 | you will not get results for *charm*,    |
|                                    | *army*, or *alarm*.                      |
+------------------------------------+------------------------------------------+
| Matching occurs on expanded forms  | The search finds work items containing   |
| of keywords.                       | various forms of the keywords you enter  |
|                                    | in the Search field. Examples: *edit*    |
|                                    | returns results for *edit* or *editing*  |
|                                    | or *editor*, *child* returns results for |
|                                    | *child* or *children*.                   |
+------------------------------------+------------------------------------------+

The triple net here is that, even with quoting, you can't easily differentiate between terms like window and windows. You'll probably need to use a more useful phrase like "Windows 10", or a specific field like Tags:windows to get the behavior you're looking for.

Rule Out Potential Bugs

While I believe your problem to be related to word-stemming, there's also the possibility of other issues that can only be addressed by your software vendor. For example, on December 13th CA Agile Central had a known search issue:

We are aware of and researching in-app text searches which are not returning results or complete lists in Rally.

Even if this isn't directly relevant to your current search problem, it's another avenue to explore for related issues you may experience in the future. Especially when using a SaaS solution, it can be very helpful to rule out transient issues first.

Additional Data Cleansing and Support Options

As a commercial product, Rally comes with a support contract. If you're still unable to get the behavior you need, you should contact your vendor's support team to go over your options within the dual constraints of your data and the vendor's product.

If your data isn't structured to be easily retrieved through the available search tools, then that's a problem you'll need to take up with your team (from a process/workflow perspective) or with the vendor (from a tooling perspective). Data cleansing and data quality management are large topics, but ones that you should certainly look at if you're relying on a particular tool that doesn't suit the way your project expects to track or retrieve data.

1
  • Word stemming certainly explains it; seems crazy to me that they don't provide a way to disable it by choice, that would have seemed like an obvious requirement to me especially when people are likely entering technical "keyword" oriented information. Though it sounds like its not a bug per se I'll be sending them feedback. Jan 16 '20 at 19:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.