Rally Software Reviews

The linkages between artifacts, going from epic to feature, from feature to user story is very native and works very well. The in-built support for scrum, so having good parts on the side and the tasks go across works. We can't do that with Trello. We can do that with LeanKit.

I think as for scrum adherence, it's very mature because I think it started as a scrum tool, and you can kind of tell that. The support for scale works very nicely.

It supports the SAFe toolkit so that you can create artifacts and define a whole bunch of teams. So you have a project pull-down, you have all the teams, and then program layer, and then the portfolio layers, so you've got the features live at the program. There's a top layer and a middle layer and then the bottom layer. It supports it very well.

Being a Kanban team inside of SAFe, some of the fields that you have to fill out are a little awkward, because then you can't use the views the way you want to. You have to assign it to all the SAFe people, and that might not be a Rally thing, only a SAFe thing.

I think you can kind of tell that they started from scrum so the Kanban support kind of feels like an afterthought. I'd like to see more maturity around Kanban metrics. So, here's your cycle time, here's your lead time. But I'd like to know why was my lead time that. I want to drill in. I want more ability to drill into the data with analytics.

Deployment hasn't been an issue.

I haven't noticed any crashing or poor performance. It's pretty solid.

It's scaled fine for us.

I've not used it, so I don't have an informed opinion.

We've used Physical, we've used Trello, we've used Gyro, we've used LeanKit, and we landed on Rally.

I think I was very involved in LeanKit and less so involved on the Rally side.

Sign up for the demo and play around with it, as painful as it is to try to maintain both tools at the same time. If you have a tool and you want to try a different tool, you almost have to actually use it. You can play around with it, you can look at the demos, and you can look at the documentation, but until you actually use it, you're not going to see where maybe the pain points are.

There are multiple valuable features of this product and the most important for me is the section related to bugs. It helped me during this time to keep track of all the bugs that the app has, the status of each one and at the same time, we were able to keep notes for each element. In addition, the ability to add the concerned developer as a watcher, so in this way if the bug is not fixed, then they would be notified.

This product had helped my organization so much because it helped us keep everything tracked.

We are now able to predict each team member's capacity in a single click.

We use the report to see if we are going to reach our deadlines and we are able to easily make decisions thanks to the available reports.

I think the only area that needs improvement will be the front end. It is very good as is but I think it could be better as the colors are a little faded.

I have been using this solution for almost a year and a half.

There were no stability issues.

There were no scalability issues.

I have never contacted the support.

I have used multiple tools before CA Agile Central. I switched because in CA, everything was in the same platform and it is a pretty intuitive tool. I didn’t need any tutorial, as I did for the other tools.

The setup was pretty intuitive.

I don’t have a lot of information about the pricing because I had the IT team handle that for me.

Give it some time. It is very difficult to change this kind of tool, especially when you are in the middle of a project. However, I would advise people implementing it to take their time to check all the different functionalities and think about how to use it effectively.

It has everything that I need in my daily job routine.

We find the most value in the Release Tracking view. We use this view during draft plan review for our scrum teams. This view allows us to see which features each team is working on during a PI. We can easily see where stories for a feature are scheduled within or across sprints, and we can compare that to priority and any logical sequencing requirements. We can also see any interdependencies between teams. This view is also very useful during a PI to track progress using the burnup chart with its forecast based on empirical trend lines. We view these forecasts per team and also in aggregate for an entire release train.

The other features that we find valuable include the task board, which is useful sorted by team member for daily scrum; the iteration status for sprint planning; the team and iteration planning pages, which are useful for PI planning and draft plan review; and various Kanban views at the portfolio, program, and team levels.

The “follow” and “discussion” features are also very valuable for qualitative tracking of work items.

This product is a great fit for organizations using the Scaled Agile Framework. It follows and facilitates best practices for agile and scrum. In many instances, the built-in constraints of this tool have opened discussions about agile best practices, and the comprehensive documentation in the online help knowledge base has provided solid guidance for agile transformation where needed.

One example of this would be the question of what to do with unfinished work at the end of a sprint. Because the right action is counter-intuitive, this is an area of much controversy and contention across the industry; however, there is an established best practice, which the help section explains and which the tool facilitates. See Manage Unfinished Work: https://help.rallydev.com/mana...

The discussion feature should be front and center when opening any work item type. The description and acceptance criteria can become irrelevant as soon as work begins. Those areas are better suited to being buried back in a tab rather than the discussion area. The adaptive changes should be the primary focus once work is underway. Updates, questions, decisions, and suggestions should all be the first thing seen when opening a work item. This is implemented well in tools like Asana.

It should be possible to assign an epic or feature as the parent of a defect. Many organizations struggle to use defects because they do not roll up in the hierarchy to specific features and epics.

Kanban boards should allow local exit criteria. Currently, the policies are set and viewed globally.

I have used Agile Central for two years.

Stability has been an issue at times. We have seen an unacceptable amount of system downtime. This has improved over the last year.

The product team has been somewhat unresponsive to popular community requests for feature enhancements. Technical support has been responsive, and customer service has been acceptable.

We have previously used Team Foundation Server and we have evaluated JIRA. This product was chosen because it was a good fit for Scaled Agile Framework.

The initial setup is relatively straightforward compared to other products.

This was implemented through a vendor team. Because this tool is so flexible and can be used in so many ways, we do not recommend attempting the implementation without outside consultation. It is easy to have the configuration fall victim to local anti-patterns.

Efficiency and effectiveness in our processes have improved by 10 percent with this tool. At scale, and across multiple release trains, this gives us a 15X return on our investment.

Do not try to implement this product if you are not using agile at scale. There are simpler, more elegant and intuitive tools.

• Requirements management
• Development team planning
• Tracking progress against plans
• Linking strategy to execution

We now have a more holistic view of how development teams are executing against the enterprise’s strategic roadmap. This improves our ability to prioritize work and to manage our risks and dependencies.

• Defect and test case management
• Executive-level reporting capabilities
• Project management functionality (financials, EVM, resource planning, etc.)
• Lacks the ability for non-coders to create custom app/widget charts

I have been using Agile Central for eight years.

We haven’t had any stability issues. We’ve experienced reliable uptime and few defects.

I’m currently working for a large Fortune 500 company and we haven’t any issues with scalability.

Technical support is excellent; however, some of our users find it a little confusing as to how to submit a case/help ticket.

We previously used a home-grown solution and wanted to switch to a more scalable solution.

The initial setup is fairly straightforward but there are certain best practices as to how to configure Agile Central. Typically, the CA Agile Central account manager will provide guidance as to how to best configure Agile Central and will be available to answer ongoing questions as they arise.

You can negotiate prices, technical services, and professional services if you need a large amount of seat licenses.

We looked at VersionOne, Pivotal Tracker, and Trello.

Work with your CA Agile Central account manager to determine the best way to implement and configure Agile Central based on your needs. Put together a basic usage policy, training document, and training presentation for users. Limit the number of administrators to a small handful of people. Integrate Agile Central with your other SDLC tools.

The most valuable features are user story tracking and team status management, including capacity and burndown. Allows for creation and scheduling of detailed user stories including attachments, assigned tasks, discussion, child stories, and revision history. Also allows association of defects and test cases, though I have not used these features as we use HP Quality Center for that purpose.

This product has helped to organize team effort and keep the team on track by providing a burndown chart and team status breakdown at the task level. Additionally, the ability to create child stories and track discussions throughout the lifetime of a user story, and its children, removes the need to maintain additional external documentation.

The UI can be slow to respond at times and difficult to navigate initially.

The home dashboard can be very slow to load. Individual user stories can be slow to respond when navigating from the Iteration Status page, as well as being slow to respond when estimates or status are updated.

The difficulty in navigation relates to the learning curve of the application. There is a help page with a great deal of information about the various features and processes which does help demystify the application a bit. But even that page can be cumbersome to navigate.

I have used Agile Central for 4 years.

This application is rarely unstable. Scheduled maintenance is conducted with ample warning.

We have not had issues with scalability.

I have not contacted technical support.

I was not involved in the initial setup.

I am not involved in the licensing of this tool.

Good estimates give the burndown chart its value. If your burndown looks bad, first look at your estimates for team capacity and user story/task effort estimates. Then look at the members of your team.

I like that you can link user stories and tasks to the features and the initiatives. This allows us to see how much were investing in people and effort. Mainly, I like the simplicity of it.

We can very easily run a report that clearly shows the amount of effort we’re investing in initiatives and features. It is very straightforward.

It brought transparency and clarity to our work. We can see from one place everything the engineering team is working on, in a very simple way using a very simple interface.

I would like to see improvements in these areas:

• Integration with Git is not very good. It should integrate more seamlessly with the other tools that we use.
• The ability to inexpensively add custom reports.
• Ability to easily add features, such as saving views, that we need to add to these reports.
• Ability to specify required fields per project and not per workspace.
• Some competitors offer much more flexibility.

JIRA, for example, has much more flexibility in terms of defining your own states, your own workflows, and even when you're in the same work space. Whereas, with Agile Center, you have to decide whether share a workspace with other teams; then you must all comply with the same configuration. For us this is a problem, because many business units are sharing the same workspace even though they have different processes and different flows. So you can either all agree on the same one or move to your own. But in that case, you lose the transparency of everybody being in the same workspace, which is part of the value and core reason why we want to use the tool.

We have had issues with custom reports that were dependent on an internal Agile Center API, but they crashed often. These are now fixed, and other than these, it's been okay.

Technical support is very responsive we were happy with them.

The solution we had just didn't work and required too much time from the engineering team, which I was highly against.

Initial setup was pretty straight forward.

Agile Center was already used in my company by other business units, so it was supported internally. Also, we heard that technical support was good. Since are heavily invested in Bugzilla for bug tracking, integration with Bugzilla was a plus.

We are not expert at Agile. We use a different tool for each development model; Eternity WaterFall and Agile. I think that that's one of the advantages.

In a vendor, we look for good support by people that have a lot of product knowledge. We don’t want to have to wait a long time before new features and customer feedback are integrated into the next release.

It is a very good tool is well suited for Agile methodology, and lends itself to user story management. With the introduction of test case management and defect management, it has really boomed and it is at par with some of the existing systems, apps, test management tools such as HP ALM. I really like Agile Central.

It is a single platform that your Agile team can talk about. If you talk about a user story management, then you can talk about it as well. If you want to do test case management, you have all the QA team and developers who can work on it. It's a single tool that works with all team members in a scrum team. Before any communication, you don't want to go on another systems, but rather use a single system; a one-stop solution that solves it for you.

We wanted to have a hub, a faster time to market, high quality, and we wanted to move from Waterfall to Agile. I’m an intermediate user. We use this tool for coaching. In terms of best practices, we have certain guidelines that you need to follow. For instance, with Agile maturity, you should have your acceptance criteria selected when you have user stories and the test case results present. You can then attach your proof of testing. This tool supports these best practices.

You should have the ability to run various automation tools, irrespective of their organizations. Some of the teams are using HP products, or other products, such as open source producst. If your tool can run those products, that would be great. If you are able to run those tools from Agile Central, then it would make sense and be a good improvement.

It is pretty stable and it's fast also, compared to other products, like HP ALM. It's fast and performs well.

Scalability is good. I have not faced any issues so far.

We have a team which connects directly with Rally. You have a help feature where you can raise requests and they can be solved. We have support available from CA.

I would say a thumbs up to the solution. It's pretty good and you should leverage it and try to use it. CA Agile Central gives you flexibility performing custom quoting on top of the solution. This makes it interesting and you can achieve many things with this tool.

It has most benefited me because as a release manager, it helps me know and mitigate the risk going into production so I can reach out to the different teams. I can, at anytime, pull up a report to show me where the status of a candidate for release is and I can reach out to those teams. Based on the report, we can then decide whether we need to allocate more resources to ensure we're able to release on a certain date.

It helps us track our development life cycle for our development teams. They can keep track of the progress of their user stories and features, from the intake process all the way through deployment and into production. This can be done in tandem with test results, and we have a substantial team with various applications.

The reporting functionalities need improvement. Also, there's too much lag, but they're fixing that.

We're at 13,000-plus companies. We have lots of applications, lots of different teams with upstream and downstream dependencies. Different teams have different maturity levels in terms of how they are using Rally. Some are just getting on board, and some have been using it for a long time. So we're trying to consolidate that.

The technical support with Rally is going pretty well.

I can't even give you off the top of my head how many licenses we have with them, but it's user-based licensing and we have quite a few of them.

I think it's a great tracking tool. There are similar tools out there, but for us it's convenient, it's intuitive.