The AI Could Analyze the Sprint. It Wasn’t Allowed to Touch It.

Five days, a live deployment, and one deliberate restriction that turned out to be the actual lesson.

Five days. A backlog. A sprint. A live deployment. An AI assistant that could see everything happening in the sprint — but was deliberately prevented from changing any of it.

That restriction was the real lesson of Week 5.

Building the delivery system

The week started with a private, team-managed Scrum project for the Gotto Job application, structured around one Epic: Improve Gotto Job UI discoverability & trust. Eight Stories came out of that Epic, each with acceptance criteria and a Fibonacci estimate, totaling 11 points.

Sprint 1 pulled 3–4 of those Stories into a sprint goal that wasn’t “close four tickets.” It was ship 2–3 visible UI improvements and show them live. Each Story broke into four sub-tasks: Build → Verify → Deploy → Screenshot. That last step mattered most. “I think it works” isn’t evidence. A live deployment and a screenshot are.

Where the AI came in

The more interesting part of the week was connecting Jira to Claude Code through the Jira MCP server — and then deciding what the AI should actually be allowed to do with that connection.

A reusable skill, /sprint-health, could pull the active sprint, inspect issues, calculate velocity, flag at-risk Stories, and produce a structured health report. But it was explicitly restricted to read-only Jira tools:

Read access: get_sprint, list_issues, get_velocity Write access — denied: create_issue, transition_issue, comment_issue

No creating, editing, commenting, or transitioning issues. That restriction wasn’t a limitation. It was the design.

The workflow followed a simple loop:

Gather → Analyze → Human Act → Verify

The AI gathers sprint state and analyzes it — flags risk, flags gaps. A person decides and edits the board. The AI checks again afterward to verify what changed.

A status change in Jira isn’t just a database update — it’s a decision about how the whole team understands the sprint. AI can supply the evidence. Humans stay accountable for the call.

What should I automate, and where should human authority remain?

That’s a different question than “how much can I automate?” Capability without boundaries creates risk. Capability with boundaries creates leverage.

The reality check

The retrospective surfaced something worth sitting with: some Stories showed as Done while their underlying sub-tasks were still incomplete. The board looked finished. It wasn’t. The fix meant going back and correcting individual sub-tasks — which is really just Scrum’s Inspection pillar and Courage value showing up in practice.

Don’t trust the status. Inspect the evidence.

That principle isn’t specific to Jira. It applies to deployments, monitoring, testing — and just as much to how I’d evaluate what an AI system tells me it did.

The takeaway

Week 5 didn’t just teach me how to run a sprint. It taught me where to draw the line around an AI system that’s fully capable of taking action but shouldn’t always be allowed to. Gathering and analyzing can be automated aggressively. The consequential decision stays human.

That’s a more mature question than “how much can AI do.” It’s “how much should it be trusted to do unsupervised — and how do I verify it anyway.”

P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: *Ginny Ibe — DMI Cohort 3 *· Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3