How Claude AI Became My JIRA Assistant
I recently anointed Claude as my new JIRA assistant. As I am also a manager he is by extension my team’s JIRA assistant. I’ve learned that he is a pretty damn good one at that. This blog post is to highlight how I’ve been using Claude as my JIRA assistant, how I’ve incorporated him into my processes, and how I’d like to use him in the future.
First some context with one of my team’s struggles: user stories and acceptance criteria. This has been a persistent challenge for my team. Our stories rarely follow any set of principles to emphasize quality such as INVEST. Instead they are pithy two sentence descriptions that assume a deep knowledge of the products, underlying software, and existing architectural definciencies. In an effort to increase story quality I’ve employed Claude as my JIRA assistant. So far he’s kept me honest when creating tasks and I’m hoping he also keeps my team honest in the future. Here are some lessons I’ve learned so far.
Give Claude direction and context
The more direction you give Claude for what you want the better the results are. This is a general principle with AI but I’ve found it particularly helpful in this instance. For example:
- Follow INVEST principles.
- Provide Claude with context as to your user base. Who are the users? What is the goal of your software?
- Provide Claude with context of your supported products. What is the goal of the software? How does it help the user base?
- Tell Claude to prompt you for needed clarification. Don’t let it try to one shot in this scenario. If it doesn’t know how to write acceptance criteria, force it to prompt YOU for information.
- Do you want Acceptance Criteria in a specific format? If so, tell it.
Create, Fix, Evaluate, Fix, Create
Claude rarely delivers perfect results on the first go. But I’ve found that it is really good at identifying gaps in requirements, thinking, and risk mitigation. It is often times able to identify gaps and risks that I originally overlooked. Because of that I’ve followed a typical Crossfit workout pattern of a buy-in and buy-out when working with Claude. Have it do something, fix what I don’t like or provide details where lacking, have Claude evaluate it, react to Claude’s evaluation, then have Claude create the JIRA (or unit test, class, etc.). This pattern of thinking helped me unlock Claude as a coding tool and general assistant. Claude as a way of “seeing around corners” has really unlocked it as a critical tool for me.
Story evaluation
Every JIRA ticket that gets created, either by product or engineering, now gets a grade. If the grade is a C or below the engineering team does not accept it into the sprint. The important part here is training Claude to evaluate user stories how you want them. Ask questions like “what is it that I really care about?” and use Claude as your gatekeeper. Claude is an objective third party here that keeps our product teams and engineers honest when creating stories.
Story creation from FIGMA designs
Claude can create user stories from FIGMA, or screenshots of FIGMA designs. It is surprising to me how adept it is at it. It is able to identify component triggers and requirements that I initially missed. In fact, Claude can now not only create user stories from my team’s FIGMAs but can also scaffold UI components and corresponding unit tests. We’re also exploring utilizing this same pattern for E2E testing of our web and mobile applications. We are just getting started here and I’m excited to see where we end up in 2026.
Doing all of this from Slack
The Slack integrations are great. In early 2026, I want to get to a point where actually using JIRA for ticket creation and editing is a thing of the past. As we discuss bugs and stories in Slack I want to simply create the story/bug from that thread, prioritize, and go on about my day.
Improvements to our process
Claude has improved our JIRAs essentially acting as a gatekeeper. He is objective, and as an objective 3rd party I can tell product that we do absolutely nothing on a story unless Claude grades the ticket a B or higher. Then and only will we intake and work the ticket. It also slows myself and product down when creating tickets. If something isn’t clear, it prompts us. It helps identify gaps in thinking and risks we may not have considered. In essence it has been a more intelligent rubber duck and in that way I’ve found it an essential tool for my team’s agile processes.