Week 5 of the DevOps Micro Internship moved me out of servers and shell scripts and into something I'd read about far more than I'd actually done: running an Agile team. Not studying Scrum theory — running it. Setting up the board, writing the stories, estimating the work, shipping something real inside a sprint, and then closing the loop with a retro. All five assignments this week built toward one thing: proving that "I ship using Scrum" isn't a resume line, it's a rhythm you can point a mouse at.
I did this in Solo Mode — no team, so I played every role myself: Product Owner, Scrum Master, Dev Lead, and DevOps Lead. That constraint turned out to be the most useful part of the week, because there was nowhere to hide. If the backlog was vague, I was the one who'd suffer for it in Sprint Planning. If the acceptance criteria were sloppy, I was the one who'd have to guess what "done" meant later.
Part 1 — Getting Jira-Ready
Before touching a single ticket, the first assignment was just about the workspace: creating a Jira Software Cloud account, verifying identity, filling out a professional profile (name, role, short bio), and exploring the dashboard, Board, and Backlog views without creating or editing anything. It's a small thing, but it's the same discipline as reading a new codebase before you commit to it — orient first, act second.
Part 2 — Standing Up the Board
Assignment 2 was where the actual Scrum machinery got built, using the DMI website as the subject. I created a private, team-managed Scrum Space, then built the full hierarchy: an Epic (Polish DMI Website UI & Deploy) → six Stories under it, each with a description, Gherkin-style acceptance criteria, a Fibonacci point estimate, and a workstream label (frontend or devops). Two of those stories — a button-color refresh and a footer with version/date — got broken down into four execution sub-tasks each: Edit HTML/CSS, Test locally, Deploy to EC2, Verify and screenshot.
Then I created and started a one-week Sprint 1, pulled 2–3 low-risk stories in (about 3–5 points), set a Sprint Goal, filtered the backlog by label to prove the taxonomy actually worked, and opened the Burndown Chart. Nothing shipped yet in this assignment — it was pure scaffolding — but it's the scaffolding that makes everything after it possible. A sprint without a goal is just a todo list with a deadline.
Part 3 — The Five-Day Mini-Sprint
Assignment 3 is where planning turned into a real, repeated delivery loop against my live portfolio site on EC2. The story was small on purpose: add a footer showing version and deploy date. But the point wasn't the footer — it was running five consecutive days of the actual Scrum cadence against it:
-
Day 1 — implemented the footer on a
feature/footer-v1branch, committed, deployed, verified on the live URL, posted a Daily Scrum comment on the ticket. - Day 2 — made the deploy date generate automatically instead of being hardcoded, documented the approach in the README, redeployed.
- Day 3 — polished spacing and contrast, and actually checked it at both desktop and mobile widths instead of assuming it was fine.
- Day 4 — swapped the homepage tagline for a real call-to-action linking back to the DMI website.
- Day 5 — recorded a short demo video, wrote a retrospective (what went well, what to improve, one DevOps pillar observed), posted the final Daily Scrum update, and closed out the Burndown Chart.
Five days, five commits, five deploys, five Jira comments. What stuck with me here is how much a Daily Scrum comment changes your relationship with your own work — writing "here's what I did, here's what's next" every single day makes half-finished work embarrassingly visible, in a good way.
Part 4 — Gotto Job: A Full Sprint, Start to Finish
Assignment 4 was the week's centerpiece: take a template job-board app called Gotto Job and run one complete Scrum cycle against it — backlog refinement, estimation, sprint planning, execution, and retro — all inside a 90-minute timebox.
I created a Team-managed Scrum project (Gotto Job – Team 2), an Epic (Improve Gotto Job UI discoverability & trust), and refined it into eight value-ranked Stories, each estimated in Fibonacci points with a one-line justification — things like a hero tagline rewrite (1 point, trivial text change) up to job-card typography and a REMOTE badge (2 points each, since they touch layout across breakpoints or need conditional logic). Writing the "why" next to every estimate is a habit I want to keep — it turns story points from a guess into a documented decision someone else (or future me) can audit.
Sprint Planning pulled four of those stories into Sprint 1 (6 points total) under a single Sprint Goal — ship 2–3 visible UI improvements and show them live — and each selected story got broken into Build → Verify → Deploy → Screenshot sub-tasks. That structure earned its keep almost immediately: I opened the Burndown Chart, shipped the smallest story (the hero tagline change) end-to-end — committed with Git, deployed to the live EC2/Nginx instance, verified in the browser — and moved it to Done on the board.
The retro is where the exercise actually taught me something. I'd initially marked stories Done at the Story level without updating their underlying sub-tasks, which left the board showing an inaccurate 0/4 completion state even though the work was finished. I caught it, corrected each sub-task individually, and wrote it up as the retro's "what to improve" — next time, update sub-task status as each step completes, not after the fact. That's Inspection, one of the three Scrum pillars, actually happening: not a checkbox, but catching your own board lying to you and fixing it in the open.
Part 5 — Teaching Claude the Boundary: Read, Never Write
The last assignment was the most interesting one technically. I connected Claude Code to my live Jira board through an MCP server — same pattern as connecting it to GitHub back in Week 2, but this time over uvx instead of npx, which turned out not to matter at all: Claude Code talks to any MCP server over the same protocol regardless of what language it's written in. The Jira site URL, my account email, and an API token went into .claude/settings.local.json (gitignored, token never screenshotted); the server registration itself — no secrets — went into the shareable .mcp.json.
With /mcp confirming jira: connected, I built a /sprint-health skill scoped to exactly four read-only Jira tools plus Read — disable-model-invocation: true, no Write, and every mutating tool (create, update, transition, comment, assign) explicitly banned in the skill's own instructions. Running it pulls the active sprint, calculates velocity, flags at-risk stories, and lists anything missing an estimate or acceptance criteria — then stops. It never touches the board.
I proved that boundary held the only way that actually counts: by manually dragging a card to Done in the browser myself, then re-running /sprint-health and watching the report update to reflect a change the skill had no ability to make. That's the same Gather → Analyze → Human Act → Verify loop from Week 3, except this time the "Human Act" step wasn't optional scaffolding — it was the whole point. A Scrum Master's tooling touches the entire team's system of record, not just one person's ticket. If it could also act — quietly marking something Done, transitioning a stale card — it would be making the exact judgment calls that are supposed to stay with the team, and a board no one can fully trust is worse than no board at all.
What I'm Taking Away
The technical parts of this week — Epics, sub-tasks, MCP servers — are learnable in an afternoon. The harder skill is the discipline underneath: writing acceptance criteria specific enough that "done" isn't a debate, estimating with a one-line reason instead of a vibe, and building an AI helper that's genuinely useful precisely because of what it refuses to do. Backlog refinement creates clarity. Sprint planning creates focus. Shipping and verifying creates evidence the work actually happened. None of that is automatable away — and it shouldn't be.
Live Gotto Job increment: http://51.21.196.210/
P.S. This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. You can follow my graded progress throughout the cohort. Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-blog&utm_campaign=cohort3
Top comments (0)