Teaching AI Agents Process Discipline with Scrum

When I first started working with AI coding agents, I ran into a very specific frustration.

My agent could write excellent code. It knew React, Go, PostgreSQL, and pretty much whatever else I threw at it. But it had no idea how to work incrementally. It had no concept of a backlog, no understanding of WIP (Work in Progress) limits, and no instinct to swarm on a bottleneck rather than start something new. It felt exactly like pairing with a brilliant junior developer who had never worked on a software team before. It had tons of raw talent but zero process sense.

So I decided to fix that.

I wrote a collection of “skills,” which are structured instruction files that teach AI agents how to apply specific development concepts. These skills do not just replicate standard Scrum. Instead, they represent the core execution mechanics I fall back on most frequently.

The Four Core Skills

To keep things organized, I broke the process down into four distinct areas:

• Backlog Management: Figuring out what to build and in what order.

• Kanban Board: Visualizing and limiting work in flight.

• Definition of Done: Establishing what “done” actually means.

• Agent Collaboration: Managing how multiple agents or agents and humans work together.

1. Backlog Management: The Single Ordered List

The foundation of any solid development process is the product backlog, which is a dynamic, single-ranked, ordered list of everything needed to achieve the product goal.

This might sound trivial, but it is not. The discipline of maintaining a single ranked order with no ties and no “top 50 priorities” forces hard decisions. You cannot say that ten things are equally important. You must choose exactly which one thing matters most.

“If a product owner says these top 50 things are my highest priority, where do you start? Item number 1? Item number 50? Somewhere in between? That is not useful.”

The Backlog Management skill teaches agents several key concepts:

• Progressive granularity: Keeping small, fine-grained work at the top of the backlog and larger, chunkier work at the bottom. Work gets broken down only as it rises in priority, which avoids the waste of decomposing items you might never reach.

• Writing user stories: Drafted with clear acceptance criteria covering the happy path, edge cases, and error handling.

• Prioritization frameworks: Knowing exactly which item to pull next, always in strict priority order.

• Continuous refinement: Treating the backlog as a living system rather than a requirements document locked down through formal sign-offs. It changes constantly, and that is a good thing.

It also teaches a critical architectural distinction: the product backlog versus the sprint backlog. Bugs discovered during active development get fixed immediately because they are on the current sprint backlog. Bugs reported from production go onto the primary product backlog as new work to be prioritized. Different places, different rules.

2. Kanban Board: Visualize, Limit, Flow

Once you have an ordered backlog, you need to flow work through the system efficiently. That is where the Kanban Board skill comes in.

Grounded in the six core Kanban practices from David J. Anderson’s method, this skill gives agents a real board to work with:

• Practice

• What It Means for Agents

• Visualize the workflow. Make work and its status visible. Hidden work cannot be managed.

• Limit WIP. Cap the number of items in each column. Forces completion before starting new work.

• Manage flow. Monitor how work moves. Bottlenecks show up as items piling up in a column.

• Make policies explicit. Clear rules for each column, such as requiring a code review before moving to Done.

• Implement feedback loops. Review the board regularly to identify improvements.

• Improve collaboratively. Use metrics and experiments to evolve the process.

The key mechanism here is pull, not push. Work moves from one column to the next only when the target column has capacity under its WIP limit. If the Review column is capped at two items, a third item stays in In Progress even if a developer has free hands. This exposes bottlenecks immediately and forces the system to finish existing work before starting something new.

The skill tracks real, actionable metrics:

• Cycle time: How long it takes from “started” to “done.”

• Lead time: How long it takes from “requested” to “done.”

• Throughput: How many items are completed per week.

• WIP status: Which columns are currently at their operational limit.

It even includes a live terminal UI extension. Within my coding agent, I can type /kanban to see my board, metrics, and stuck work rendered in real time.

3. Definition of Done: The Quality Gate

This is where most teams, whether human or agent, tend to get sloppy. They say “done” when they really just mean “coded.” The Definition of Done (DoD) skill draws a hard line.

“If an item does not meet the DoD, it is not done, regardless of whether its specific Acceptance Criteria are satisfied.”

A story’s Acceptance Criteria might state that a user must receive a reset link within 30 seconds. The DoD, however, states that all unit tests must pass, code must be reviewed, integration tests must succeed, and documentation must be updated. Both must be satisfied for the item to be considered complete. You cannot ship code that works but lacks a review, and you cannot declare victory because the tests pass while the docs are missing.

The skill provides example criteria across five categories: Code Quality, Testing, Observability, Documentation, and Deployment. It also includes a verification script (verify-dod.sh) that walks through every criterion before any item can move to Done on the Kanban board.

The DoD serves as the definitive gate between In Progress or Review and Done. Nothing moves forward without passing that checklist.

4. Agent Collaboration: From Handoffs to Swarming

The fourth skill ties everything together. Once you have a backlog, a board, and a quality gate, you need agents that actually collaborate instead of just passing work serially from one to another.

The Agent Collaboration skill is grounded in the five core Scrum values of Commitment, Focus, Openness, Respect, and Courage, backed by operating rules that make collaboration the path of least resistance.

The most important shift here is moving away from serial handoffs and toward swarming. When work gets stuck on a complex bug, a testing bottleneck, or a blocking dependency, the team converges on it together instead of leaving one agent to struggle alone. The core mindset shifts from “that is not my job” to “how do we get this over the finish line together?”

Traditional Scrum events like Sprint Planning, Daily Scrums, Sprint Reviews, and Retrospectives are defined as functional workflows but adapted for AI agents. There are no scheduled meetings and no rigid two-week sprint cadences. Agents work continuously, sync via shared markdown artifacts (DAILY_LOG.md, DECISIONS.md), and swarm on bottlenecks immediately. The underlying Scrum values remain intact, but the calendar-based events are unnecessary when agents can coordinate instantly.

How the System Fits Together

The four skills have clear structural boundaries:

Backlog Management       →   WHAT to build and in what order
     ↓
Kanban Board             →   HOW work flows through the system
     ↓
Definition of Done       →   The GATE that work must pass
     ↓
Agent Collaboration      →   HOW the team works together

- Backlog Management <·> Kanban Board (Pull-based from backlog)
- Kanban Board <·> Definition of Done (DoD is the gate to Done)
- Agent Collaboration <·> All three (Swarming, Three Amigos, WIP limits)

Each skill explicitly links to the others. The Backlog Management skill points to agent collaboration for swarming rules. The Kanban Board skill requires running verify-dod.sh before moving items to Done. The Definition of Done skill relies on the Kanban board for its gate mechanism. They are designed as an interconnected system rather than a collection of standalone tricks.

The Results

Since I started using these skills with my coding agent, three things have changed noticeability:

1. No more context-switching chaos: WIP limits force my agent to finish what it started before pulling new work. The Kanban board makes bottlenecks visible instantly, so I can see exactly where work is piling up and clear it.

2. Done actually means done: Before adding the Definition of Done skill, my agent would call work complete the moment the code compiled. Now it runs a thorough verification checklist covering tests, reviews, documentation, and deployment before marking anything complete. This stopped the habit of shipping half-baked features.

3. The agent manages itself: I used to spend a lot of time micromanaging the steps, telling it what to do next or reminding it to test. Now, I give it a product goal. The AI builds the backlog, and once I review and approve it, I simply tell it to start. It pulls work in priority order, respects WIP limits, logs its own decisions, and asks for help when it gets stuck. I focus on what to build, and it handles how to execute it.

Try It Yourself

All four skills are open source and available on skills.sh:

# Install the full set
npx skills add kane-mar/skills

# Or install individually
npx skills add kane-mar/skills --skill backlog-management
npx skills add kane-mar/skills --skill kanban-board
npx skills add kane-mar/skills --skill definition-of-done
npx skills add kane-mar/skills --skill agent-collaboration

They work with any coding agent harness that supports reading files and running shell commands without requiring any specialized tooling.

If you use pi, these skills activate automatically based on keywords in your conversation. Mentioning “backlog” loads the backlog management skill, while mentioning “WIP limit” triggers the Kanban board behaviors.

Building software is hard enough. Your AI agent should know how to do it with discipline, not just brute force.

The repository is hosted at github.com/kane-mar/skills. Contributions and feedback are always welcome.