Rally Software Reviews

The Kanban board is probably the most useful feature. It is very customizable and is great for somebody who doesn’t need to run the project with a scrum approach. The second most important feature is the overall ability to customize almost all of the solution’s features and work products such as user stories, defects, and features.

The product helped engage the business product owners by increasing both their view into the development cycle and their responsibility to assist in setting up work priorities.

The weakest part of this solution is its primitive report generator.

The report generator is very simplistic with a limited capability to filter, sort and group, and the designer is not WYSIWYG. The product would benefit from a more capable browser and a more compatible report builder.

It needs a UI that has a Crystal Reports-like design and WYSIWYG capability. Right now, it is an early 80s throwback.

We have not had many stability issues. It is a stable product, but in the past, CA has fixed some server-side issues or implemented an “improvement” without any patch notes. That is usually just frustrating but one time, an “enhancement” broke our link to TFS. It took us two days to re-enter all the users.

We have no scalability issues. We have 185 users. However, because we are a cloud product, we are at the mercy of the internet routers and traffic.

Technical support is good once you get their attention. What is critical to you might not be critical to them. As an example, we had a broken TFS connector. It took about six hours for them to understand the problem, and that they were the ones who broke it. Once that happened, they were very helpful.

We used Microsoft Project. At that time, it was very weak with agile projects. Prior to purchasing this solution, we created a vendor grading scorecard with the features that were important to my company. We started evaluating six products. We then eliminated three, re-compared them, and settled on this solution.

Since we bought the cloud option, there was no specific setup. There was, however, lots of customization that we have done since 2012. It is straightforward once you are familiar with the product.

We also purchased five days of CA Agile Central on-site training. It broke down like this: one day for developers, two days for project managers/scrum managers, a half day for product owners, and a half day for administrators.

CA seems willing to give deep discounts when you have 100+ licenses.

We evaluated five other options. They have changed so much since we evaluated them in 2012, so it wouldn’t be fair to name them.

Make sure you have adopted an agile methodology on a few small projects first and then work with IT and business colleagues to accept that methodology. We did that before we looked for a tool. That makes the purchase, acceptance, and customization of this tool much easier.

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.

The valuable features are:

• Tracking progress and other parameters.
• Allowing a better overall picture of activities.
• Facilitating the interaction between team members and teams.

The solution now offers visibility on each activity and its status.

I would like to see team masters have an easier way of managing the tasks/stories for their team members when creating default tasks in advance.

We have been using this solution for a year and a half.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

In order to improve the organization of your work, make sure you put real info/data into the product.

Defect tracking is the one feature that behaves most like I would expect and I have found a good way get it to work for me.

The features I use the most are the Test Planning, Test Set, Defect, and Defect Suite functionality. The Project Manager has stated multiple times that the reporting features of the User Stories & Sprint Planning work well for him. Though, like every other piece of the app, there are things that either do not make sense or have to be worked around to utilize the system as needed.

The Defect Tracking of CA Agile Central functions well enough with some severe limitations. I believe the intention is for you to put Defects in Defect Suites and Defect Suites in Iterations. You can put Defects in User Stories, but only one User Story at a time. So, if the defect crops back in, you either create a new defect or pull the defect from the previous sprint's User Story, thus changing history.

If you put them in Defect Suites you can add the same Defect to multiple Defect Suites in different Sprints. However, this also comes with some weirdness in removing a Defect from a Suite. You can't pull the Defect from the Suite directly, you have to go to the Defect and remove the Suite from there.

There is a Notes section for each of the Defects. Unlike JIRA there is no way to keep straight who made what comment when in the notes section. You have to manually add your name and date and time to the notes field making it so that if you have a back and forth about the root cause of the defect there is no ease way to facilitate this on the defect itself.

If one defect is causing failures in multiple Test Cases you cannot tag multiple Test Cases in the Defect. You either have to create multiple defects or note in the result that it failed because of the defect.

Test Sets & Test Plans, again, ALMOST function how you would expect. You can fairly easily lay out Test Cases in a Test Plan, unless you want to move a Test Case from one Test Folder to another, then you have to do so from within the Test Case rather than on the Test Plan page. You can move an entire nested Test Folder from one Test Folder to another. Deleting of a Test Folder orphans all the Test Cases making you have to hunt them down manually for deletion.

Test Sets are the method by which it appears you're supposed to keep execution results separate. Unfortunately, there is no way on the Test Plan to choose a Test Set to see the results. Test Plan only reports the latest results with no easy way to view historic execution results by Test Set. You also cannot view a Test Set's results independently. Further, adding Test Cases to a Test Set requires looking them up by Test Folder from the Test Plan. If the Test Folder has nested Folders, you can't search for the Parent Folder and add all Test Cases in the child folders. You can only create Test Sets in the Iteration, not in the Quality > Test Suites and then assign to an Iteration. Yes, It's called a Test Set and a Test Suite in the application.

I use this at a customer’s site. I cannot say for certain it is better than nothing, but I do not know what they were using prior.

Generally speaking, I can usually think of a product that functions better than CA Agile Central for the features that are utilized the most.

I have yet to see a section of CA Agile Central that could not benefit from improvement. As I tell people, it ALMOST behaves how you would expect. There are so many twitchy bits that require workaround for the business process to function. It’s ridiculous and feels almost like it gets in the way more than it helps.

For example, these problems come up when re-executing test cases. I have found no way to easily set up another testing cycle that reports the results independently and I’ve LOOKED. There is no way to assign a test case to multiple stories or a defect to multiple test cases. Associating a defect with a defect suite is easy. Removing it is hard; exceedingly so. Creating test cases in a test folder on the test plan page is easy. Moving those test cases around is exceedingly difficult. I could go on and on and on about how this product has let me down.

I have used CA Agile Central for one year.

Stability hasn’t been TOO bad. There are occasions that I have had to close my browser and start a session over. But what do you expect when using Adobe Flash instead of something more modern.

Opening new browser windows (middle-click) takes FOR-EV-ER, relatively speaking. While it is MUCH faster to just click a link in a given instance/tab, the general user behavior is to open new tabs and that takes WAY too long.

I have not had to utilize technical support.

I was not given the option to use a different solution, as this is the solution my client utilizes.

TestRail is my hands-down favorite test case DB to work with. It has every feature a tester needs to easily create and design test suites, add defects, and retest with multiple configurations. CA could learn a LOT from TestRail about how to manage test cases properly.

Choose a different product for your test case needs, and explore other options of managing of your agile processes, such as TFS.

We needed something that we could collaborate with and was easy to use, and easy to access for business analysts.

We are trying to be agile, but we still use waterfall for a lot of things. We are not working agile as much as we should. We don’t adapt as quickly as we should. The tools are all there; but we are not implementing it correctly and not enforcing the rules enough.

The most valuable features of CA Agile Central for us are:

• It provides organization.
• It's a good collaboration spacing unit.
• It does a really good job of tracking overall statuses.
• There's a ton of flexibility. I can use it for anything I can think of within the development lifecycle. So that's really nice.
• It is user friendly.
• It really helps us with tracking progress, so we can see where we’re heading.

It's tough to think of areas for improvement. I mean, I think it's all there. Making some of the features more obvious would probably make them more useful. Right now, there's a lot of power and flexibility; but it's not always obvious. There should be something in the way of best practices and suggestions, and to know what makes logical sense. You really need to have a good plan for it. I've seen how it can be mishandled and not implemented strongly to where it becomes more of a hindrance than a value.

For the most part, the stability is quite good. We haven't had a lot of issues. There are little tweaks and quirks, here and there. I think a lot of that is because the tool is so flexible and powerful; and it can do a lot of different things if you want it to. You can kind of corner yourself, where you’re doing something not really modular. It is not really a stability problem, but in some ways, you could have too much content to the point that it drowns out the rationale for using the system.

The scalability is incredible. It's not always straightforward and easy. It’s varied, but there is a lot of overhead in getting there. There is a lot of thought process that you need to put into it. People were already pressed for the work they already have. Asking them to set up entire systems to integrate and be flexible is quite a change.

I can’t think of any big enough issues, so we haven’t used a lot of technical support. I did contact them with a small issue that went away and then came back. I didn't really have a lot of direction on that. It was a flow issue.

Have a strong plan and clear requirements in advance for what you want to get out of the tool. You need to have strong leadership on the design: how you're going to use it, how you're going to set it up, what you expect out of it, what you might be integrated with, what you're angle is with the tool. If you just keep buying tools, you're not going to use them in the end; and it's just going to be a waste of money and a headache for people down the line using it.

The most important criteria when selecting a vendor depends on which group gets to select the vendor, unfortunately. Price is always something, especially if finance is making the decision. When it comes to IT, I like flexibility and use of the system. There has to be more gain than effort. If it's too hard to implement for too little gain, then it's not worth your time. You're really looking for balance across the board. The cost has be there. There has to be value to it; so return on investment, the ROI, ends up being the big deciding factor in the end for any software company.

A lot of the reporting is very valuable to us. We really need to control certain releases and milestones, and so on. Being able to report and get statistics on all of that stuff is one of the features we really like, especially now that they're expanding that as well. We like that.

Honestly, it keeps us more organized. We have a lot of products and we ship them pretty fast. CA Agile Central is great for us because we can categorize all these different things. It really gives our top-level leadership visibility into what we're doing so that they don't pound down our door every two seconds. They can actually go into CA Agile Central and figure things out for themselves. They can make better decisions without really needing us.

I use it a lot. I don’t really have any complaints. There are a lot of alternatives out there. They are also useful, but I have no complaints with CA Agile Central or with CA in general. I don't find myself saying, “I wish it did this,” or ”It's really killing me here”. It has been a good experience.

As a release manager, what they’re coming out with now in terms of release automation is going to be very valuable to me. I think that with CI (continuous integration), as much as it is expanding and taking over most software shops anyway, I think that's the way to go. I think they're doing it right. As a release manager, I'm happy. CA is coming out with a lot of CI-type things, which is good.

It is stable. There are no issues there.

It is scalable. There are no issues there.

The customer support at CA is good; however, we haven’t had to use it, which is good. It's always there if we need it. That's also good.

I don’t believe we’ve needed technical support. It has been pretty stable. It fits our needs for what we need so far.

My company has been using CA Agile Central for as long as I’ve been there.

I've been at other companies where they're using different tools, like JIRA and stuff like that; but CA Agile Central is fine. At one of those companies, we weren’t using JIRA all the time. It was really too convoluted for what we needed.; so we didn’t use them. Sometimes you needed to dig for certain things that were not necessarily laid out flat like CA Agile Central is. Even though, in JIRA, you can kind of organize them in different ways; but only if you use them. Like I said, CA Agile Central fits our needs pretty well.

Our top reason for selecting an agile platform was needing to ship as fast as possible. Waterfall is good for new products coming out, but we have a lot of long-standing applications that have been out on the market for awhile. Getting releases together and shipping them as fast as possible is what we needed. It was kind of a no-brainer for us.

I would say our agile maturity is intermediate. We're still learning. There's so much you can do. Like I said, we are even coming out with new products, so we have to use waterfall sometimes; but we're still learning about it. We're trying to integrate as much as possible and tailor it to our company.

When we evaluate vendors, are most important criteria are the customer support, scalability, and availability. We've had problems in the past with some other vendors whose products’ availability was not what we needed. They would go down quite a bit, more times than you would think, honestly. That's a big deal for us, especially whenever we put so much into it. If a system goes down, the entire development department basically stops working. That's a big thing for us, especially as we keep putting more and more into CA Agile Central.

If a colleague of mine was evaluating this solution, I would advise them to keep it small. Simple is better.

Most valuable to us is being able to communicate without everybody having to be in the same room. Also the ability to capture information and distribute it to team members. We have people overseas or people working from home or in a different office building and they can all communicate via Agile Central.

I think it is an excellent tool for tracking agile scrum activities. It's one of the best tools on the market, if not the best.

Primarily, it has given us a more structured approach than doing some kind of scrum using white boards and other manual methods. It's a very helpful tool. The push for Agile Central came when we asked the company to go agile and do scrum. This required us to go ahead and purchase a tool to unify us across the company.

My personal agile maturity is about medium. Company-wide, some facets are medium to high and others are just starting. Our scrum masters also use it for coaching. Some of the best practices we use are keeping the tool updates timely and making sure stories are well defined and broken down in the right unit of work.

I would like to see greater ability to manage common teams that are working across projects and how that common team has tasks to do in both projects or in multiple other projects. I want to see more common services.

The project might require common services, but if I'm a common services team and I have tasks in all of these other projects, it’s better to manage the common services team itself and their tasks; because they have tasks in multiple other Agile Central projects.

As far as I can tell, it has good stability.

I can't comment about scalability.

I have not used technical support personally. I haven't had to, so that's good.

I was not involved in the initial setup.

I know of some people that were trying to use JIRA, but I don't believe that had near the capabilities that this does.

I would advise potential users to get in touch with CA and have a representative sit down and show them the tool and how they can use it.

We're using CA Agile Central to track project development status, including the whole process, starting from the initial plan, followed by testing, development, and bug tracking.

From my personal viewpoint, it helps make sure everything is on track.

I'd say our agile maturity is mid-level.

I think scalability is good.

I think initial setup was straightforward. The documentation was very clear.