Today’s post is a bit different: I’m going to talk about something I’m building. It’s called Context Points, a Scrum adapted for teams of AI agents, and it just became an open source project on my GitHub. I confess I’m excited and nervous in equal measure (it happens, lol).
Let me tell you where this came from. For a while now I’ve been running a personal project with an entire team of AI agents instead of a team of developers: a Product Owner, a Scrum Master, devs, QA, each one an agent with its own role. And you know what I found out? The Scrum we use with people simply doesn’t fit agents.
What Context Points is (and why human Scrum doesn’t work for agents)
In traditional Scrum, the scarce resource is time. Two-week sprints, 15-minute dailies, everything revolves around the clock. But an AI agent doesn’t have a packed calendar and never gets stuck in traffic. What limits an agent is something else: context, that “working memory” it can hold at once without getting lost. And there’s a second scarce resource almost nobody talks about: the attention of the human who reviews what the agents produce. On my team that attention is mine, and it runs out fast, you know? :'(
Context Points starts right there. Think of context as the agent’s suitcase: it doesn’t matter how long the trip is, what matters is what fits in the suitcase. If you try to stuff in too many clothes, the suitcase won’t close and everything inside gets wrinkled. Same thing with agents: a task that’s too big doesn’t just “run late”, it comes out wrinkled.
The question is no longer how long it takes, but whether it fits in the suitcase.
Story points became a context budget
That’s where the first of the three core concepts comes in, the one that gives the project its name. In Context Points, story points don’t measure effort or time: they measure whether a story fits into a single working session without the agent losing the thread. It’s literally a context budget. A story estimated above the budget doesn’t make it into the sprint; it goes back to be sliced until it fits in the suitcase.
The second concept is planning poker with isolation. On my team, the Product Owner, the Senior Dev and QA estimate the same story separately, each in a clean context, without seeing each other’s numbers. When the estimates come back wildly different, that’s not a clash of opinions: it’s a sign the spec is ambiguous (if 3 people/agents understood it differently, the problem is in the text).
And the third: the Definition of Done became a list of commands. None of that “clean, well-tested code” talk. It’s tests passing, linter with zero complaints, green build, diff confined to the agreed files… Things you can verify by running a command, with little room for debate.
If you can’t verify it with a command, it’s not a criterion, it’s a wish.
How this works in practice
The project packages all of this in a very concrete way: five roles defined as subagents (Product Owner, Scrum Master, Senior Dev, Dev and QA) and six rituals as commands, covering refinement, estimation, planning, checkpoint, review and retro. The full methodology is documented in the repository, which is the source of truth, and there’s already an adapter ready to use as a Claude Code plugin.
But here’s something I made a point of baking into the project’s foundation: the methodology is generic. It doesn’t belong to Claude, or to tool X or Y. The backbone is plain Markdown, so any model or agent tool can use it. The plugin is just the first door in, because that’s where I tested it.
If you already like running several agents in parallel (I wrote a bit about that in my article on git worktree and vibe coding, in Portuguese), Context Points is the layer that was missing on top: the agreement on how that bunch of agents works together without turning into a mess.
How to try Context Points on your project
The repository is at github.com/soaresfellipe/context-points, MIT licensed, meaning you can use it, adapt it and even sell things built on top of it, be my guest. There’s a quick start guide in the docs folder, and if you use Claude Code you can install the plugin and start testing the rituals right away.
Now, let me be honest: this is version 0.1.0, calibrated on very few projects (basically mine). So what I’m asking for isn’t stars on the repo, it’s counterexamples. Tried it and it worked? Great. Tried it and it broke badly? Even better, open an issue and tell me where the suitcase wouldn’t close. That’s how this thing matures.
A good methodology isn’t born ready, it grows up taking punches from real projects.
Frequently asked questions
What is Context Points?
It’s an open source methodology that adapts Scrum for teams of AI agents supervised by a human. The core idea: the scarce resource for agents isn’t time, it’s context, and the Scrum rituals were rewritten around that.
Do I need Claude Code to use it?
No. The methodology is generic, written in Markdown, and works with any model or agent tool. What exists ready-made today is an adapter in the form of a Claude Code plugin, but nothing stops you from taking the spec to your own stack.
Does this replace Scrum for my human team?
No, and it doesn’t try to. Context Points is for teams OF agents, with a human reviewing. If your team is made of people (with or without AI helping), good old Scrum is still the way to go.
Is the project paid?
No! It’s open source under the MIT license, free for real. If you want to give something back, the best payment is feedback from real use, especially the cases where the methodology failed.
Cheers, Fellipe Soares