I work with our business units and they hand over a project to me. Then, I break it down and dissect it at the project level and break out all the features. Then, for each one of the features, I write all the user stories. Then, I coordinate with my software development team to get the work done for all of the user stories.
We take it through the entire process from the conceptual stage to the business of getting the work done and showing the business that we got it done.
I guess the main thing is that it allows us to pull all of our user stories and manage our agile process together for our agile team.
It enables us to document our epics and features and user stories all the way down to a fine level.
I'd say that there are a few things to improve.
On the main screen, I think it's called the Team Planning screen, it should be able to run a backlog. For example, if I have 300 stories in my backlog, it would be nice to be able to filter those out by project because that's the main place that I look at them and my team looks at them, and you get 300 stories out there for numerous projects for our team, because we work on 85 different applications. There are five or six primary ones, but the rest are back-end components.
We've got some technical stories for back-end stuff and we've got some continuous improvement items for our assisting applications. Within that backlog, to be able to have some type of filtering mechanism so that if I want to see all of the stories for a certain project, I can pull them out and view them, would be useful.
Right now, I have to scroll down through 300 stories and try to group them all together and find them and then, by the time I go and group them together, somebody's going to ask me to group them another way. Then somebody's going to say, "All right, well, can we prioritize them in that backlog?" Well we can, but then I've got to change all my groupings.
All this takes time. Basically, what I end up doing is just pulling those out, either copying, pasting or exporting them into a spreadsheet and then I'm back to managing them on a spreadsheet rather than in the tool and it's just time consuming.
There are certain things that I think I would like to add that would make my job or my function easier. One example is that they have different levels of access within the system and I do not have the highest access, so there are certain things that I can't do. There are other people within our organization that can modify the system or make certain changes, but I can't.
Also, for each one of the user stories, you can throw different tags on them so you can do searches or filters by those tags. Everybody can add a tag, and you can create new ones, but I'd like the ability to go in and modify and clean up those tags.
I've asked to get that access and they said I don't have the right level of security so then, it's a matter of working with somebody back and forth to try to get everything cleaned up.
For example, we have an internal system that we do a lot of work on. It's called Service Desktop. Well, there are about 10 different tags out there for Service Desktop; one of them is "Service Desktop", another one is "SD", another is "SERV D", etc.
Because we have multiple people working on this and they've created their own tags for their own stories on different things but they all mean the same thing, so, to me, it makes sense to have only one so that everybody is on the same page with that same one.
I would like to get it all cleaned up, so that when I do some sorting or filtering or running different reports and I'm basing it on a tag, I want to make sure that I've got everything and I don't even know all the different tags that are out there for Service Desktop.
If I had those abilities to make these changes or create some of the modifications or to build some of the panes and windows that I would like to see, I guess I would probably give the solution a higher rating.
I have not encountered any stability issues.
I have not encountered any scalability issues. We typically pull in 15 to 25 user stories every sprint so maybe 100, 125 stories for a specific PSI, and it has no issues meanwhile.
I have never called the technical support in over three years.
We switched because in my organization we have multiple teams. I'm just on one team, we probably have another 12 to 15 teams that are working on projects, and this is just one centralized repository across our organization.
We have multiple sites, so everybody could use the same thing to put their work efforts into rather than individual spreadsheets where nobody could get access to them.
When we originally got the product, I basically had to take my workload and transfer it into CA Agile Central at the beginning and that took me a few days to get done, but after that, we just built everything right from there.
At my level, I didn't do the evaluating. One of our staff within the organization did. I had no idea if they looked at other options or not but I think they chose CA Agile Central because of the versatility and the ability to handle multiple teams in multiple locations. It seemed to work out to help all of us transform to the agile methodology.
Have a good plan, an overall plan, of the goals that you're trying to achieve. For those organizations that are going into CA Agile Central or going into agile or if you're currently doing agile, then do the following.
- Go through a process of learning the system or having a handful of people learn the system so that they know it well.
- Get the system customized because that's one of the strong aspects of CA Agile Central. We have a couple of CA experts within our organization and they connect directly with the folks at CA and make changes from time to time within the system.
- Get all of your modifications and everything done up front and then start inputting the details and all of your teams and individuals and work efforts.
- Just start using it!
To me, it was very simple. A very simple type of tool to use.
Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.