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.

We are using Rally Software in our company for agile development. We also use it for software development using agile methodology.

Regarding my use of Rally Software, it was originally called RallyDev when I started using it in 2006. However, it was later acquired by CA and renamed Rally CA. One of our use cases for Rally CA was to support our business process automation (BPA) efforts and move everything to the cloud. When we first started using Rally Software, they did not have capabilities and strategic initiatives set up, and their features and ethics had disappeared. However, we soon discovered that their strategic initiatives were now referred to as Epics, and the capabilities module had replaced the features. Additionally, they had always had users.

Unfortunately, this breakdown did not translate well to the team I took over for, and I had to restructure all of the releases and tie them to function to ensure that we could use billing codes in the capabilities. We also had to create governance settings reports to catch errors and warn us about missing features or capabilities. This was important because it was easy to lose a step with Rally CA, and we needed to stay on top of things. As a result, we developed a workflow governance system that alerted us to any issues or discrepancies in our work. For instance, if we put the projected end date before the projected start date or if we had stories without capabilities, we would receive warnings.

I used Rally Software for the agile process in software and mechanical products. My previous company produced software for a machine, and I embedded the software.

I have a couple of individuals on my team that help manage the utilization of CA Agile Central to make sure that we are being as mature as we possibly can for Agile practices.

Performance has been good. It allows for a lot of customization, which has been very helpful, because we pull key metrics, report up to our unit CIO on certain areas.

We are promoting SAFe within our organization and we have a organization that actually follows the Scaled Agile Framework. We're using Agile Central right now to track our users' portfolio items, our product features, our product backlog, our iteration status, and to track metrics. That's what we're using it for right now.

It's been pretty good. We've been using it for the last two and half years. We've tried a couple other products in the past, before we moved on to Rally CA or Agile Central 2. So it has really worked out very well.

CA Agile Central is used for the lifecycle of Initiatives, Features, and User Stories, Defects: from concept through delivery

Release planning, test case writing.

It's performed plenty, I'm happy with the performance.

Organizing all of our Agile work load, and projects that we have in the pipeline.

It's been good. I don't know that it's best suited for Kanban which is the Agile style that we're using. It seems a little more focused on Scrum. So having some more Kanban methodology built into the product would be nice, but it does allow us to move our stories along the board, and have a good visualization of where everything is in process. 

We primarily use the solution to scale agile and for safety.

It is used to track any enhancements or new integrations. We have integrations from mainframe systems to RESTful services. We also have a few SOAP integrations. Essentially, we use the feature level of Rally to document what the interface is and then the engineers make the user stories within the feature to represent the tasks that they need to do to complete the interface, which includes everything from making the design document to the activities that they do in IIB, such as deploying the code to production. Our version has probably been updated within the last three months.

Software development and infrastructure.

Managing our development life cycle. In the ways in which we use it, it has been adequate.

Rally Software is typically used for dealing with all the scrum and agile principles and work orders. It keeps track of whatever workers do in the application development lifecycle before release.

We primarily use this solution for agile project management. We use it to work on some of the challenges we have, including test management. 

We use it move projects through the software development lifecycle.

It performs pretty well. It's nice that everybody throughout the whole process has access and is shown the relevant information to their part of the job, their part of the SDLC.

It helps us find our users stories and allows us to see what everyone on our team is working on, and if we have any blocks.

It's performed pretty well.

It's mainly about test cases and automation of data. I, as a test automation architect, collect all that data and show the metrics.

To manage our work in a common way.

In terms of performance, we're just getting started on it. No issues so far.

Primary use case is agile development and Mode 2 development.

It has performed really well. We have taken some teams that were non-Agile and tried to do a combined approach. This eliminated some of the heavy documentation that we were used to with waterfall. We have been able to deliver our integration between CA and HPE ALM in a period of time that is about half of where we were before. 

Most of our development teams are Agile, meaning they do development in two-week sprints. So they use Agile Central for the input of all of their user stories, all of their test cases. We just recently moved to Planview Enterprise so that we can actually start doing dependency mapping across features. 

But it's mainly a way for all of the individual teams to define all our user stories and keep up with the overall tracking of how they're doing, sprint by sprint. 

As a Scrum Master, helping the product group define feature stories, and portfolio management, and helping manage the teams, their scrum backlogs, their performance, and velocity.

It has performed well.

We run our team and enterprise with Agile Tool. At the team level we determined and managed capacity, created tasks, and assigned hours to the tasks.

We use it to track all of our work. We also manage our portfolio in it.

It works. It's a bit cumbersome to manage the Project Picker. As we sunset teams or projects close out - but we still have test cases tied to those teams or projects that are being used in other spaces - we have this monstrous list in the Project Picker that becomes really difficult to manage and find, and we can't clean that up ourselves. It would be nice if it was easier to do that and not lose your history.

We use Agile Central to record all our user stories, features, and then to track down the burndown, velocity, defects.

I was previously using it as a scrum monitor for the team. It helps with billing and the IT team used it, as well. I am very satisfied with this product. 

Planning for the scrum team.

It has performed excellently.

I use Agile Center mostly to do two things: 

1. To manage my requirements and I have hundreds of thousands of requirements. 
2. My teams uses it for their daily agile management. They describe their user stories and track the progress of their projects.

We are a former customer before it was acquired by CA. In that time, we were using just a fraction of what was there. This year, we started having more implementation and moving into the newest version. This has allowed us to use some of the high-end features like the label hierarchy, and it is good so far.

Execution of software development.

The entire application lifecycle from user story to the quality assurance for the testing. It has performed great. It has a great set of features which address the whole process.