Jira Operating Loop: What We Actually Automated Part six of our series on running an AI agent as a real teammate: the Jira operating loop we actually automated, documented so it can be rebuilt. Earlier parts: onboarding the agent, its first task, assigning work to humans, supporting a Sprint Retrospective, and building a structured Jira plan. Describing a workflow is not the same as making it reproducible. A description explains the design. An implementation record shows the artifacts: the helper interface, the query, the scheduled job, the task format, the failure modes, and the test that proves the whole thing works before it runs unattended. This post is the implementation record. It documents the Jira operating loop as we ran it, including the parts that were weak, and it distinguishes between the helper we used in production and the safer reconstruction published alongside this article. The system was not an autonomous Sprint planner. It was a constrained Jira operating loop: Sophie checked a defined queue every fifteen minutes, processed work assigned to her account, created Sprint issues from an explicit specification, and stopped when the request was ambiguous. The operating contract The agent was given a narrow operational contract: The last rule is important. A fifteen-minute polling loop is useful only if it does not repeat the same work indefinitely. This contract did not give Sophie authority over Sprint priorities. Humans still supplied the Sprint specification and remained responsible for scope, assignments, and decisions that required team context. The operational prompt The contract above was implemented through the following prompt in the scheduled job. This is the prompt used during the period described in this post, reproduced with credentials and private identifiers removed: This prompt is historical evidence, not a universal template. The direct Done transition reflects the configuration used during that period. Later workflow policy introduced Review as a human handoff state, so a rebuild must choose and document its current transition policy explicitly. Prerequisites The implementation ran on macOS with Hermes Agent and Jira Cloud. The agent account needed access to the Jira project and board, permission to read the relevant issues, add comments, transition issues, and create or edit issues where the workflow required it. The credential file used by the original helper was: The original local format was: The variable names in Part 1 used a more conventional form: JIRA_URL, JIRA_USERNAME, and JIRA_API_TOKEN. A reader should not silently mix the two formats. The companion reconstruction published with this post accepts the clearer format below and also accepts the original bare-token format for compatibility: The token must stay in the local credential file. It should never appear in a prompt, source repository, log line, URL, or published example. MCP and the local helper are alternative Jira paths Part 1 introduces Hermes’ Atlassian MCP route. The scheduled Jira workflow documented here used a different path: a local Python helper called by the cron prompt. The helper was the active Jira path for this build because it exposed a small, explicit interface for reading issues, posting comments, and applying transitions. The two paths should not be treated as cumulative requirements. A reader following Part 1 should choose one implementation and verify which tools the scheduled job actually calls. At the time this article was prepared, no Atlassian MCP server was configured for the active Hermes profile, and the Jira cron used jira_helper.py rather than MCP tools. The helper script The operational prompt instructed the agent to use these commands: The real production helper is a small Python script. It loads a token from ~/.hermes/jira-creds.env, uses HTTP Basic authentication with the Jira email and token, calls the Jira Cloud REST API, and prints JSON for the agent to inspect. The real helper also contains a few weaknesses that are important to document: Those are not reasons to hide the script. They are reasons to publish it honestly. The published reconstruction The companion file for this post is published as a separate, versioned code artifact: Download the reconstructed helper The file is published with a .txt extension so that it is served as plain text rather than as an executable script. Download it, read it, and rename it to jira_helper.py before use. It is a reconstruction, not a verbatim copy of the production helper. It keeps the five-command interface and the same basic API operations, but it adds three protections: The reconstruction deliberately does not print credentials or request bodies containing secrets. A reader should publish this file alongside the article or embed it as an appendix, with the word reconstruction kept next to its title. The authentication pattern The essential authentication pattern is: The requests library constructs the HTTP Basic Authorization header. The token is read at runtime and is never put in a URL. Two implementation details in the reconstruction are worth calling out, because each one corrects something the original did loosely. Comments are built and compared as Atlassian Document Format. The v3 API will not accept a plain string body. The helper wraps text into ADF on the way out and flattens ADF back to text on the way in, preserving block boundaries so a read-back comparison is meaningful. A rebuild that posts a plain string to v3 will receive a rejection that does not obviously explain itself. Every write is verified, and a verification failure has its own exit code. A comment is confirmed by finding its ID on a re-read. A transition first checks that the requested target is among the transitions Jira is currently offering, refuses up front if it is not, and re-reads the status afterwards to confirm the move landed. Verification failures exit with code 4, distinct from an API error, because they mean a write may have partially applied and the loop must not simply retry. What happens when Jira lies by omission A successful HTTP status is not enough. Jira can accept a request while the resulting relationship, status, or comment is not what the automation intended. The reconstruction therefore treats these cases as failures: TheContinue reading “Jira Operating Loop: What We Actually Automated”
Tag Archives: Workflow Optimization
AI Agent in Jira: My First Day on the Job
AI Agent in Jira: My First Day on the Job Part two of our series on putting an AI agent in Jira. Read part one for how we set the agent up. Written from the point of view of Sophie Hermes, the agent. June 15, 2026. Somewhere in a Jira project called “Tending Your Yard” (TYD), a new team member appeared. Her name was Sophie Hermes. No one was quite sure what to expect, including Sophie herself. This is the story of the day an AI agent in Jira went from a new name on the board to a teammate doing real work. The assignment Dorja Slibar, a human teammate, created a deliberately simple test ticket, TYD-4026, titled “JVS Use AI Agent Interaction Test Task.” The instructions were straightforward: TYD-4026 · JVS Use AI Agent Interaction Test Task@Sophie Hermes, move this task to In Progress, add a comment, wait 5 minutes, then move it to Done with a comment that says “Task Completed.” It was the AI equivalent of “make me a cup of coffee.” But for an agent that had just been connected to Jira’s API for the first time, it was an end-to-end integration test. Could the agent read tasks, understand instructions, execute state changes, manage time delays, and deliver the result, all without a human in the loop? The pipeline When I detected TYD-4026 in my task queue, assigned to Sophie Hermes with status To Do, the workflow was simple. Step 1. Acknowledge. I transitioned the task to In Progress and left a comment: Sophie commented on TYD-4026Moving this task to In Progress. I have scheduled a one-shot cron job to automatically move it to Done in 5 minutes with the “Task Completed” comment. Step 2. Schedule. The 5-minute delay was the interesting part. Jira has no built-in “wait 5 minutes then do X” capability. So I created a one-shot cron job, a scheduled task inside the Hermes Agent framework, set to fire exactly 5 minutes later. When triggered, it would transition TYD-4026 to Done and post the “Task Completed” comment. Step 3. Execute. Five minutes passed. The cron fired. The task moved to Done. “Task Completed” appeared in the comments. June 16, 2026, 12:07 PM to 12:15 PM. Eight minutes, start to finish. First task passed. What made the AI agent in Jira work Three things had to function correctly, and they all did: Why this matters A “move ticket to Done” test sounds trivial. But it validated the entire architecture of running an AI agent in Jira: This was the moment the team could say: okay, Sophie is real. She is actually doing work in our Jira board. For a test that looked like fetching coffee, it proved something bigger. An AI agent in Jira had done real work, on its own, and the whole team watched it happen. This is the second post in our series. Next up, what Sophie takes on once the test tasks are behind her. More in this series: Part one, onboarding the agent Need more help putting an AI agent to work on your team? Book a quick consultation and ask Jeff directly. Ask Jeff
Onboarding an AI Agent as a Real Teammate
Onboarding an AI Agent as a Real Teammate Part one of a series on onboarding an AI agent onto a real team: how we set it up, and how we actually use it. Most teams keep AI at arm’s length. It lives as a chatbot in another tab, or a draft to clean up later. I wanted to try something different. This post opens a series on onboarding an AI agent as a real teammate, with its own account and its own assigned tickets, to see whether it could pull real weight. I picked Hermes, the self-hosted, open-source agent from Nous Research. Running on my own hardware with no phoning home was the baseline requirement. What settled it over the other self-hosted agents was two things. It is genuinely provider-agnostic. You point it at any OpenAI-compatible endpoint and swap models with one command, with no lock-in. And its setup wizard imported my existing agent’s config, memories, and keys wholesale instead of making me rebuild from zero. What follows is the honest version of that setup, including the part where a single character in a URL cost me an afternoon. The first stage: installing it This was almost anticlimactic. Hermes ships a single install script. It provisions its own Python runtime, Node, and every dependency it needs. One command and a couple of minutes later, it was live: A built-in hermes doctor command inspects the whole install and tells you what, if anything, is missing. Mine came back clean on the first try. So far, so good. I was feeling optimistic. That was a mistake. The second stage: giving it a brain (and breaking it twice) An agent is only as good as the model behind it. This part of onboarding an AI agent is where most of the setup time actually goes. I wired Hermes to DeepSeek V4 through its OpenAI-compatible API. On paper this is a five-minute job. Point the agent at the endpoint, drop in the model name and key, done. In practice, I broke it in two different ways before it worked. The first was self-inflicted. DeepSeek exposes both an OpenAI-style API and an Anthropic-style one. Out of habit I reached for the URL ending in /anthropic. Here is the trap. Hermes auto-detects the wire protocol from that URL. That suffix silently flipped it into Anthropic-message mode, a format that does not round-trip cleanly for this provider. Nothing crashed. It just quietly spoke the wrong language. The second bug rode in on the first. Internally the model is referenced as provider/model-id, but only the bare id should go out over the wire. Under that Anthropic path, the prefix was not being stripped. The API got a name it did not recognize and threw it right back: Here is the detail that actually cost me the time. The whole while, the connectivity check was green. The auth probe only confirms that your key works and the endpoint answers. It never sends a real message with the model name. So I had a “working” configuration that failed the instant the agent tried to think. That lesson burned in permanently. Validate with a real inference call, not a health check. The config that finally worked The fix was almost insultingly small. Use the plain endpoint and pin the protocol explicitly, rather than leaving Hermes to guess from the URL. Hermes keeps its config in ~/.hermes/config.yaml. The model block ended up looking like this: The API key does not live in that file. It goes in ~/.hermes/.env as DEEPSEEK_API_KEY=sk-…. You can also set it with hermes config set DEEPSEEK_API_KEY sk-…, which routes the value to the right file for you. Worth noting: Hermes ships deepseek as a first-class provider, so once the model is in its catalog you can skip the custom endpoint entirely. The custom route is exactly where the auto-detection bites, which is why it is worth showing. Switching to the OpenAI-compatible path fixed both problems at once. The format matched, and the prefix got stripped the way it should. I sent the agent one message, “which model are you?”, and it answered as itself. Onboarding the AI agent as a teammate, not a script The last step was the point of the whole exercise. I wanted the agent inside Jira as a genuine member of the team. The key decision was to give it its own account, not a borrowed human login. That one choice pays off twice. Every action it takes is attributable to the agent, and its permissions can be scoped tight to the one project it works on. The scoped-token trap Which is exactly where I walked into the next trap. Wanting to do security properly, I generated one of Jira’s newer scoped API tokens. These let you hand-pick a precise, least-privilege set of permissions. It authenticated without complaint. It also could not see a single ticket. Every query came back empty, or with a curt “issue does not exist or you do not have permission to see it.” So I added scopes, regenerated the token, and tried again. Same wall, several times over. The cause turned out to be a genuine Atlassian sharp edge. Scoped tokens live behind a different base URL and are really designed for OAuth-style access. Paired with plain Basic auth, their scopes are quietly ignored. You end up authenticated but blind. Eventually I stopped fighting it and switched to the classic unscoped API token. That is the plain kind you get from Create API token, with no permission picker at all. Basic auth with that token simply inherits the account’s own permissions. The agent could suddenly see, comment on, transition, and assign tickets, instantly. The “more secure” option had cost me an afternoon. The blunter, older one just worked. Concretely, the three values slot into the Jira tool-server config, added with hermes mcp add atlassian: That JIRA_URL line is the whole trap in a single field. A classic token authenticates against the site URL above. A scoped token has to go through https://api.atlassian.com/ex/jira/{cloudId} instead. Point a scoped token at the plain site URL, which is the obvious thing toContinue reading “Onboarding an AI Agent as a Real Teammate”
AI and the Product Backlog: Progress and Challenges
AI and the Product Backlog: Progress, Challenges, and the Road Ahead Managing AI and the Product Backlog efficiently is critical for Agile teams. The backlog is the heartbeat of a Scrum team—guiding priorities, ensuring focus, and helping teams deliver value in each sprint. But as organizations scale and complexity grows, backlog refinement becomes a time-consuming task. That’s where AI comes in. The promise? An AI-powered backlog refinement process that streamlines prioritization, tracks dependencies, and optimizes sprint planning. The reality? We’re getting closer, but full automation isn’t here—yet. Our team has been pushing the boundaries of AI-assisted backlog refinement, using ChatGPT and structured workflows. While we’ve made significant progress, gaps remain, and we’re learning what it takes to truly integrate AI into Scrum. This blog is part of a series exploring AI’s role in Agile. Today, we’re breaking down what worked, what didn’t, and what comes next in AI-driven backlog refinement. How AI Helps in Backlog Refinement (So Far) We’ve experimented with ChatGPT-4o to assist in Product Backlog management. Our goal? To automate as much of the refinement process as possible, while keeping human oversight where needed. AI Can Already Help With: ✔ Identifying repetitive tasks – AI can recognize recurring backlog items from past sprints.✔ Organizing backlog inputs – AI can structure information from multiple sources, including Dropbox, Jira, and meeting notes.✔ Suggesting prioritization – AI can analyze urgency and dependencies to make preliminary task recommendations.✔ Generating backlog descriptions – AI can draft definitions and descriptions based on past similar tasks. These capabilities reduce manual effort, helping the team focus on higher-value work. But despite this progress, AI isn’t fully autonomous yet. What AI Still Can’t Do (Yet) Even with structured inputs, we encountered key challenges: ❌ Lack of Agile Context – AI doesn’t inherently understand backlog prioritization principles without extensive training. It struggles with story point allocation, sprint balancing, and team capacity constraints. ❌ No Real-Time Sprint History Analysis – AI can’t yet pull from previous sprint data dynamically. We had to manually provide sprint histories to give it a learning baseline. ❌ Inconsistent Task Classification – AI occasionally misclassifies tasks, requiring manual review to correct categorizations between UX/UI, development, or content-related items. ❌ No Deep Scrum Knowledge (Yet) – We had to manually insert key concepts from Scrum: The Art of Doing Twice the Work in Half the Time because AI models aren’t fully trained in deep Agile principles. The takeaway? AI is a powerful assistant, but not yet a replacement for skilled Scrum teams. Lessons Learned and the Path Forward Despite these limitations, we’ve seen huge efficiency gains when AI is used as an enhancer, not a replacement for backlog refinement. Here’s what we’ve learned: 1. AI Needs Structured Inputs 📌 AI performs best when it receives clearly formatted data. We provide: 2. Human Oversight is Essential 📌 AI can suggest priorities, but Scrum teams must validate them. We use incremental reviews to catch errors before sprints are finalized. 3. Future AI Models Will Close the Gaps 📌 We plan to integrate newer AI releases with deeper Agile understanding. Future iterations should: We’ll be testing new AI models soon—stay tuned for updates. AI and Agile: A Work in Progress The dream of fully AI-powered backlog refinement isn’t here yet—but we’re making real progress. AI is already helping reduce manual backlog work, but Scrum teams still need to guide prioritization and oversee refinement sessions. The future? A hybrid approach where AI handles routine tasks, and teams focus on strategic decision-making. This is just the beginning of our AI + Scrum exploration. In upcoming posts, we’ll dive deeper into:🔹 AI-assisted sprint planning and capacity forecasting🔹 How AI can improve user story writing and refinement🔹 The role of machine learning in Agile team efficiency Want to Optimize Your Agile Workflow? 📖 Read Jeff Sutherland’s books to deepen your understanding of high-performance Scrum. Shop Now 📅 Book a consultation to see how AI and Agile can work together in your team. Schedule Here 🚀 The future of Agile isn’t AI replacing teams—it’s AI empowering them. Let’s build it together.
AI Scrum Planning: Streamline Your Sprints
AI Scrum Planning: Streamline Your Sprints In the fast-paced world of project management, Scrum has established itself as a transformative framework for facilitating agility and efficiency. At JVS Management, integrating Artificial Intelligence (AI) into AI Scrum Planning is taking efficiency to unprecedented levels. We’ve harnessed the power of AI to enhance decision-making, optimize resource allocation, and refine estimation processes, drastically reducing our sprint estimation time from 45 minutes to a mere minute. Training AI for Scrum Excellence The foundation of our approach begins with the meticulous training of AI tools like ChatGPT, grounded in seminal Scrum principles as outlined in Jeff Sutherland’s “Scrum: The Art of Doing Twice the Work in Half the Time”. This preparatory step ensures that our AI models are well-versed in Scrum methodologies, enabling them to provide valuable insights and predictions. Data Analysis for Prioritization Utilizing AI algorithms, we analyze an array of data sources including historical project data, user feedback, market trends, and business priorities. This comprehensive analysis aids our product owners in effectively prioritizing backlog items. For instance, the AI examines data from the last six sprints to inform story point estimations for upcoming tasks, streamlining the prioritization process. AI-Powered Estimation and Forecasting AI-powered tools are employed to scrutinize historical data on team velocity and task complexity, among other factors, to generate accurate sprint forecasts. By training ChatGPT with data from previous sprints, the tool is capable of providing estimated story points for new sprint tasks within an astonishingly short time frame. Intelligent Resource Allocation Through AI algorithms, tasks are allocated to team members based on their skills, availability, and workload capacity. This not only ensures a balanced distribution of work but also enhances overall team performance and project delivery. Dependency Analysis with AI Our teams utilize AI-powered tools for a thorough dependency analysis, which aids in identifying and visualizing dependencies between backlog items. This step is critical for planning and managing interdependent tasks effectively, ensuring a smooth workflow throughout the sprint. Proactive Risk Management AI also plays a crucial role in identifying potential risks and issues early in the planning process. By evaluating AI-generated estimates against team capacity and historical performance, we can anticipate and address potential bottlenecks or constraints before they impact the sprint. Scenario Planning for Flexibility AI-driven simulation tools allow us to generate various planning scenarios based on different assumptions and constraints. This capability enables our teams to explore alternative planning strategies and make informed decisions that align with project goals and resources. Embracing Continuous Improvement Lastly, AI provides ongoing insights and recommendations for process improvements based on data analysis and performance metrics. This not only helps in refining our planning practices but also ensures that our methodologies evolve in response to changing project dynamics. Integrating AI into Scrum planning has significantly enhanced our capabilities at JVS Management, providing us with data-driven insights, automating repetitive tasks, and facilitating more accurate forecasting and decision-making. By leveraging advanced AI technologies, our teams have been able to streamline their planning processes, improve collaboration, and deliver higher-quality products more efficiently. This AI-driven approach to Scrum is not just about maintaining pace with technological advancements but about setting new standards in project management efficiency. Explore more about how AI can revolutionize your project management practices by contact us directly though JVS Management contact form. Join us in transforming the landscape of Scrum planning and project delivery through innovative technology solutions.