The 22-Minute Feature

The demo was going perfectly.

I was showing a new team lead a tool we'd built to bridge the gap between Request Tracker (RT) and Jira. For the first time, we could visualize the inefficiencies and inconsistencies with the current process. He was nodding. He got it.

I asked him what features he'd seen from other implementations that he would like to see here.

And then he asked for something completely different. "This is great for pulling data out," he said. "But what about the reverse? Can we take a Jira ticket and push it into RT?" Two years ago, I know exactly what I would have done. I would have opened ChatGPT, asked it to write some code, copied it into VS Code, ran it, watched it fail, pasted the error back into ChatGPT, and spent three hours in copy-paste hell. Eventually, I would have worked endlessly to get it working, only to back-burner it until I could get it right.

Today? I didn't wait. I didn't backlog the idea.

I closed Teams. I opened Cursor. And twenty-two minutes later, I sent him a screenshot of the feature working.

The 22-Minute Sprint

I want to show exactly what happened in those twenty-two minutes. Not to brag, but to show a workflow that simply didn't exist for people like us until right now.

My code isn't messy. It follows structured architecture patterns, which is why it worked in twenty-two minutes.

New branch. Chat opened with Claude Code 4.6 in Cursor. Usually, I'm a fan of the Vomit Prompt—just rambling into the mic and letting the AI sort out the chaos. But this was a specific use case. Logic. Data mapping.

I decided to write it out.

I typed the use case: We need to take data from an existing Jira ticket and create a Request Tracker ticket. Generate some Acceptance Criteria while you're at it.

Then I added the most important instruction you can give an AI: "Ask me clarifying questions before you generate anything."

The Research Loop

While Cursor was "thinking," I didn't just sit there waiting for the magic. I searched Google, found the RT API documentation, and looked for the specific API specifications we needed. Gemini gave me a pattern that looked promising, so I copied it.

When Cursor came back asking about field mapping and authentication, I didn't guess. I pasted that research right into the chat. No hoping. Just data.

I wasn't trying to unlock a cheat code. I was practicing Agentic Engineering - feeding the tool real context instead of hoping the right prompt would magically work. Cursor digested the docs, validated the plan, and confirmed: "Yes, this structure works."

A ten-step plan. Then the code. All built on top of the API connections I'd already wired up.

"Real English" Debugging

When I ran the new feature, it didn't work exactly as I'd expected. The description was missing. The summary was truncated. It looked amateur.

In the past, after those 3 hour sessions, that's where I would have quit. But this time, I didn't touch the code. I just typed in the chat: "The summary is too short, and we missed the description field completely."

Feedback received. Revisions came back.

We ran it again.

Boom. Ticket created in RT, populated perfectly from Jira. And linked back using existing mechanisms.

I looked at the clock. Twenty-two minutes since the demo ended.

The Credibility Crisis

I wrote recently about the Scrum Master Credibility Crisis. We're being asked - rightly - to prove our value beyond "hosting meetings." Twenty-two minutes of building answers better than any slide deck.

The job used to mean "helping others do the work" - facilitating events, inviting conversations. But tools like Cursor let us help by building. We aren't creating production code to ship to customers. We are creating tools to ship to our teams, instruments that help us see the work.

I used to think my value was external to the process. Today, I know my value is when I'm in the process, helping the team get to "Done."

The Challenge

It's easy to read this and think, "Good for you, Fred. I'm not technical." Neither was I. I don't have a Computer Science degree. I was just professionally curious, and I've been professionally curious for years.

Try this Monday:

Next time you observe some friction in yours or your teams process (a manual copy-paste, a spreadsheet update, a missing bridge), stop. Don't just ask the team how might we fix it or open a ticket for someone else to fix it three months from now.

Ask yourself:

Could this be automated?

Could AI do this for me?

Open an IDE.

Give yourself 30 minutes.

See if you can build the first inch of the solution.

You might fail, or you might get frustrated.

But for thirty minutes, you won't be a spectator. You'll be a builder.

Stop facilitating the request. Start building the solution.

---

Continue Your Journey

AI Builder Foundation Course: Learn to build tools like this JIRA-RT bridge even if you've never written code.

The Vomit Prompt: The voice-first protocol I use for 90% of my inputs.