I work in the insurance and tax domains. The purpose of my using the tool is for user story creation and to have a traceability matrix for our development team and testing team.
The team I am working with was never into Agile before. We have a daily scrum-call and before that, we have to define all the tasks that we are going to work on for a number of sprints. For example, there is a Product Increment Planning meeting where we put all the user requirements into the product backlog. Then we put them back to the respective sprints.
A product increment consists of about five iterations, or five sprints. And we pull each of these backlog items to these particular sprints or iterations, so that it is easy for the development team to pick up, based on the priority. The backlog is set, and it is pulled into particular sprints, based on business priority.
So it helps the development team to take up and finish tasks within the required timeframe. It helps in productivity, traceability, and saves time.
In the case of a big epic, we are able to create it. Then, based on backlog creation, we will be able to create the user stories under that particular feature.
Also, defects can be traced in the solution.
The solution could be more user-friendly. For example, attachments could be icon-based to make it easier for the user to notice them. Overall, it would be nice, from the user-interface point of view, for them to improve it.
In terms of testing or defects, we are able to track it currently, based on each task. But if the testing team could have different access rights, that would really help.
The stability is very nice. Up until now we haven't faced any issues.
The scalability is good because access can be provided to multiple teams.
This is our first such solution.
The initial setup is straightforward. It usually takes two people to deploy. They work as administrators or on the development team. There will be one or two administrators on the client's side to maintain it.
I have seen ROI from implementing this solution in different organizations which I worked with. The return on investment was very good because it is less costly when compared to other tools on the market. For our current project, it might have saved some $2,000 to $3,000.
There are other tools in the market and our organization was using something, but I don't remember the name of the tool.
For us, the process of implementing it starts with getting in touch with one of our internal teams and giving a business case for why we are going to use this tool and what the users' rights will be: for example, edit or delete or whatever functionalities we require. They will register us for the solution. Once this is completed, it will trigger an email so we can start using the tool. First, we create the backlog.
I work on it from a business analyst perspective and I help the project management team to understand what all the backlogs are that we are maintaining for the upcoming versions. As a business analyst, I note the requirements for the respective backlogs, based on business priorities. Then we pull them into the particular sprints. It will then move to the development team to start looking at each of the user stories. They will divide these user stories into particular, technical tasks.
From the testing team point of view, they create, under the same user story, their tasks and start giving their descriptions, including the defects.
Once it is completed, we have a UAT done and we update the status of each of these user stories as completed, or in progress, whichever is applicable.
Deployment depends on the complexity of the application.
We have 25 to 30 people using it in the current project. In my previous organizations, the same tool was used by more than 125 to 130 people. There are different types of users. Business people are also involved, as well as technical testing people, project managers, etc. Different stakeholders are involved.
We are implementing it in many projects now. It was not being used as much, in practice, in the organization where I am working, but we are now scaling it up to multiple teams, so that everyone will get the benefits. To scale up to different teams may take another year. There are different service lines in the organization and each of them has to adopt this technology. They are slowly picking it up.
