We've already seen how Rovo Chat agents fit into the Atlassian ecosystem — and how an AI agent can turn messy inputs into structured, developer-ready outcomes. This follow-up goes one level deeper: What happens when you try to deploy AI agents on a large, real project — with multiple Jira projects, strict permissions, and a lot of day-to-day "small but expensive" routine.
Today, we're talking with Valerii Staryk about how to embed Rovo Chat into project processes and achieve real benefits. We tried to address two problems: analysing and structuring requirements/comments, and logging time in Jira.
Background & experience:
Valerii has over 10 years of experience in software engineering and technical leadership, helping organisations solve complex challenges from ideation to product delivery.
1. Let's start with time logging. What did it look like before automation, and what's the Jira setup you're working with?
Valerii Staryk: We use a client's Jira, and there's an expectation to log time for every task—bugfixes, small tickets, anything. The problem is that in a day, you can collect 10–15 small tasks, and then you still have to go back and log time into each one. Over a month, it becomes a very time-consuming process.
The setup makes it harder, too. We have roughly 20–30 Jira projects we work in, and tasks are scattered across them. Even if you work in one repository, your tickets can live in 3–4 different Jira projects. For example, cybersecurity issues go to a separate security project. That makes searching and time logging even harder.
2. So you decided to automate this with an agent. What does it do, and how automated is it in practice?
VS: At the end of the day, it pulls all tasks that were "in progress" for me and logs time into them. It looks at the task history, sees how long a task stayed in progress, and proposes that duration as the time to log. It can also display filtered views, such as high-priority tasks, tasks assigned to me, and more.
Ideally, you schedule it for a specific time and let it run automatically. In practice, there's a key nuance: the agent needs admin-level permissions in every Jira project it operates in. That turned out to be the main obstacle, as not every project owner wants to grant permissions. The security department, for example, doesn't want to give access.
Right now, it's semi-manual: you trigger it yourself. Full automation is possible, but only if you can obtain the required permissions.
3. Does it work across all those projects simultaneously?
VS: Yes, when it works fully, it goes across projects. That's the whole point. Dashboards are difficult because different Jira projects have different workflows and statuses, so a single universal dashboard doesn't work for our case. The agent helps you retrieve exactly what you need without having to build separate dashboards for each project.
4. You mentioned a second problem: requirements analysis. What's happening there?
VS: Ticket descriptions and comments are often too long and cluttered, including many business comments, links to other documents, and input from security stakeholders. Analysing it manually is time-consuming
We created another agent that goes through the ticket, comments and builds a structured output. It creates a separate subtask so we don't rewrite the original Jira issue or break the initial "raw" discussion. The new task is structured into blocks: problem statement, requirements, risks, and acceptance criteria. Then the team can take it into delivery. And because the format is standardised, we can reuse it downstream, including using other artificial intelligence tools to help with implementation.
5. How much control do you have over what data the agent uses? And did it ever just make things up?
VS: In most cases, the agent handles it on its own, but for specific cases, it helps to constrain the data source. If I want it to use only Jira and not read Confluence, or the opposite, I explicitly tell it. That acts as a filter, improving accuracy. Our documentation is in Confluence, and tasks are in Jira. It works great across both — surfacing requirements, tickets, bugs, and other hard-to-discover items, even when labels or components are inconsistent.
We haven't seen any hallucinations so far. The model stays grounded in the available data rather than inventing details, which is precisely what you want from a tool like this. Feed it small, well-defined tasks, and it delivers consistently. If you need more complex logic, you'd want a different setup, maybe with custom integrations or a more advanced model. But for routine automation, the built-in system works just fine.
6. Did your process change as a result, beyond just saving time?
VS: Yes, and in ways we didn't fully anticipate. If you don't update statuses properly, you end up with many "in progress" tasks, which makes the agent ineffective. Then you either stop using the agent and waste time again, or you build a habit of keeping Jira statuses clean. The agent effectively enforces good hygiene.
The same is happening with documentation. Previously, different architects documented in different styles, and it was hard to find anything quickly. Now, because work flows through shared agents and templates, tickets and documentation come out more consistent and structured across the board.
7. Can non-technical people actually use this without extra setup?
VS: Yes, even a non-technical person can create an agent just by writing a prompt and saving it. At this point, architects and business analysts on our projects are already writing their own agents, helping format Jira tickets, create Confluence documentation, and link things properly. It also helps managers quickly capture context: find relevant tickets and documentation, check statuses, understand where development is happening, and even identify who to contact without having to keep everything in their heads.
Related insights
The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.
Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.
ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.
