What is our primary use case?
We use it for our backlog and tasks within Scrum and Kanban. We use it based on epics, features, and user initiatives at various levels.
Our group is at a lower level, which focuses on features under epics and uses user stories further down. We try to break things down as much as possible, but legacy code sometimes requires estimations. Breaking down user stories is the hardest part. While Rally tracks sprints well with good note-taking, we have challenges.
Our team is a hybrid. We handle operational updates like server tasks, not strictly following scrum patterns but carrying tickets over sprints. There's no easy switch between Scrum and Kanban, so we adapt.
We also handle production issues, supporting developers and DevOps in their tools. It's customer-focused and keeps things running smoothly. That's primarily how we use the board.
What is most valuable?
I like the discussion and note-taking capabilities. It's great to keep everything connected to the story itself. A lot of times, tracking changes across features or Epics that change from TI to PI can be tricky, especially with prefixes or how you phrase things. Continuity can be lost.
That's why we use a common prefix for all things related to digital transformation, like "digital-," so we can easily search and find all relevant user stories. It's a kind of grouping mechanism, even though there might not be a dedicated field for it, like tags.
What needs improvement?
It is hard to track the changes. For example, we're in sprint 25, and then we have 26, 27, 28, and 29. Throughout that whole time, we're developing pipelines in Azure, moving to GitHub, creating pipelines, and working with teams. But sometimes, we need to revisit specific decisions made in previous sprints, like pipeline details. Maybe it's in our Azure Wiki, GitHub, or Teams, but it's not always consistent. I wish I could search for all tasks or stories related to that particular effort without needing to know everyone's individual stories or features.
So, I would like to see a tag system with prefixes like KBI for knowledge-based information or JC for Java Core to search and find relevant items easily.
It would be so much easier to search for everything related to KBI or the actual feature itself. I could even search within my group using a shared scrum team name, like "Snoopy's Developers," and then find everything related to JC or Java code.
Another pain point for us is managing our limited number of licenses with contractors coming and going. It's a constant struggle to figure out who's still active. We have to run reports to find people who haven't used Rally for x months, like logged in or whatever.
As an admin, wouldn't it be great if we could have an automated report emailed to someone, say another admin, highlighting users who haven't logged in for, like 12 months? That way, we could easily go in and deactivate or revoke the licenses. If someone hasn't logged in for eight months, why not have Rally automatically disable them?
So, easier license tracking would definitely be beneficial.
Those are my two main wish-list items. With the Description field, it can work for them; it's free. But they have to be diligent enough to remember to tag things there.
And even then, it's not always clear during stand-ups unless you specifically look at it. Someone is working on "admin" or "accessories" or whatever that "digital transformation" tag is. That kind of thing helps track progress at a glance.
For how long have I used the solution?
We have been using it for four years.
What do I think about the stability of the solution?
Generally, it has been very stable. When it is down, the folks in Broadcom contact us pretty quickly. There was an instance once, but they got it back up fast. I can't remember it being down for more than a few hours in our case. It might be different for others, but overall, it's relatively stable.
What do I think about the scalability of the solution?
We've never had any issues with scalability. We have teams come and go all the time. We have teams in India, America, Ireland, Poland, Italy, England... we are spread out everywhere! Rally is our key tool for scrum planning and our single source of truth, and it handles it all flawlessly.
How are customer service and support?
We didn't need to reach out because Rally has sent us trainers and support personnel for on-site classes before. They were very knowledgeable and helpful.
The support's speed is very good. I once had an issue finding a deleted record that I still needed, and they helped me figure out where it was and how to restore it. It wasn't a major issue, but I was short on time and didn't want to bother our scrum master.
How would you rate customer service and support?
How was the initial setup?
What about the implementation team?
Another team in our company handled the deployment of the product.
What's my experience with pricing, setup cost, and licensing?
Which other solutions did I evaluate?
My team and I did an evaluation comparing Azure DevOps and Rally back in the day. Anyway, we had Northwest come down from Seattle to chat with us, and we spent a week with them.
We were a team of folks from operations, development, and developer support. Initially, we thought since our code is in Git, we should go with Azure DevOps.
However, another group internally overruled us because of some missing interfaces in Azure DevOps. Now, we're facing a disconnect between Rally and Azure, and we're having to manually work on traceability and observability between them. It's not seamless like an out-of-the-box integration.
What other advice do I have?
There are a lot of tools out there, and it depends on what you're doing. For planning and managing at the project or program level, Rally is a good tool.
However, at the development level, down to individual user stories and features, it can be a bit Wild West-ish in a way.
I haven't encountered it myself by breaking things down too far. But it takes diligence to do things right at that level, just like with Jira. For program-level stuff, though, Rally does a good job.
Overall, I would rate the solution a seven out of ten.
Which deployment model are you using for this solution?
Hybrid Cloud