Context Points: estou criando um Scrum pra agentes de IA

Hoje o papo é diferente: vou falar de algo que estou construindo. O nome é Context Points, um Scrum adaptado pra times de agentes de IA, e ele acabou de virar um projeto open source no meu GitHub. Confesso que estou animado e nervoso na mesma medida (acontece rs).

Deixa eu contar de onde isso veio. Há um tempo eu venho tocando um projeto pessoal usando um time inteiro de agentes de IA no lugar de um time de desenvolvedores: um Product Owner, um Scrum Master, devs, QA, cada um sendo um agente com seu papel. E sabe o que eu descobri? O Scrum que a gente usa com gente simplesmente não encaixa em agente.

O que é o Context Points (e por que Scrum de gente não serve pra agente)

No Scrum tradicional, o recurso escasso é o tempo. Sprint de duas semanas, daily de 15 minutos, tudo gira em torno do relógio. Mas agente de IA não tem agenda cheia nem pega trânsito. O que limita um agente é outra coisa: o contexto, aquela “memória de trabalho” que ele consegue segurar de uma vez sem se perder. E tem um segundo recurso escasso que quase ninguém fala: a atenção do humano que revisa o que os agentes produzem. No caso do meu time, essa atenção é a minha, e ela acaba rápido, né? :'(

O Context Points parte daí. Pensa no contexto como a mala de viagem do agente: não importa quantos dias a viagem tem, o que importa o que cabe na mala. Se você tenta enfiar roupa demais a mala não fecha e amassa tudo que está dentro. Com agente é igual: tarefa grande demais não apenas “atrasa” como ela sai amassada.

A pergunta não é mais sobre quanto tempo leva, mas sim se cabe na mala.

Story points viraram orçamento de contexto

Aí entra o primeiro dos três conceitos centrais, o que dá nome ao projeto. No Context Points, story points não medem esforço nem tempo: medem se uma história cabe numa sessão de trabalho sem o agente perder o fio da meada. É literalmente um orçamento de contexto. História estimada acima do orçamento não entra na sprint; ela volta pra ser fatiada até caber na mala.

O segundo conceito é o planning poker com isolamento. No meu time, Product Owner, Dev Senior e QA estimam a mesma história separadamente, cada um em um contexto limpo, sem ver a estimativa dos outros. Quando os números vêm muito diferentes, isso não é briga de opinião: é sinal de que a especificação está ambígua (se 3 pessoas/agentes entenderam diferente, o problema está no texto).

E o terceiro: a Definition of Done virou uma lista de comando. Nada de “código limpo e bem testado”. É teste passando, linter sem reclamação, build verde, diff confinado aos arquivos combinados… Coisas que dá pra verificar rodando um comando, sem muita discussão.

Se não dá pra verificar com um comando, não é critério, é desejo.

Como isso funciona na prática

O projeto empacota tudo isso de um jeito bem concreto: são cinco papéis definidos como subagentes (Product Owner, Scrum Master, Dev Senior, Dev e QA) e seis rituais como comandos, cobrindo refinement, estimativa, planning, checkpoint, review e retro. A metodologia completa está documentada no repositório, que é a fonte de verdade, e já existe um adaptador pronto pra usar como plugin no Claude Code.

Mas aqui vai um ponto que fiz questão de deixar na base do projeto: a metodologia é genérica. Ela não é do Claude, não é de ferramenta X ou Y. A espinha dorsal está em Markdown puro, pra qualquer modelo ou ferramenta de agentes conseguir usar. O plugin é só a primeira porta de entrada, porque foi onde eu testei.

Se você já brinca de rodar vários agentes em paralelo (falei um pouco disso no artigo sobre git worktree e vibe coding), o Context Points é a camada que estava faltando por cima: o combinado de como esse bando de agentes trabalha junto sem virar bagunça.

Como testar o Context Points no seu projeto

O repositório está em github.com/soaresfellipe/context-points, com licença MIT, ou seja, pode usar, adaptar e até vender em cima, fica à vontade. Tem um guia de início rápido na pasta de documentação, e quem usa Claude Code consegue instalar o plugin e sair testando os rituais direto.

Agora, vou ser sincero: isso é uma versão 0.1.0, calibrada em poucos projetos (basicamente nos meus). Então o pedido que eu faço não é estrelinha no repositório, é contraexemplo. Testou e funcionou? Ótimo. Testou e quebrou feio? Melhor ainda, abre uma issue e me conta onde a mala não fechou. É assim que a coisa amadurece.

Metodologia boa não nasce pronta, nasce apanhando de projeto real.

Perguntas frequentes

O que é o Context Points?

É uma metodologia open source que adapta o Scrum pra times de agentes de IA supervisionados por um humano. A ideia central: o recurso escasso dos agentes não é tempo, é contexto, e os rituais do Scrum foram reescritos em torno disso.

Preciso do Claude Code pra usar?

Não. A metodologia é genérica, escrita em Markdown, e serve pra qualquer modelo ou ferramenta de agentes. O que existe hoje pronto é um adaptador em forma de plugin pro Claude Code, mas nada impede você de levar a especificação pra sua stack.

Isso substitui o Scrum do meu time humano?

Não, e nem tenta. O Context Points é pra equipes DE agentes, com um humano revisando. Se o seu time é de pessoas (com ou sem IA ajudando), o Scrum de sempre continua sendo o caminho.

O projeto é pago?

Não! É open source com licença MIT, de graça mesmo. Se quiser retribuir, o melhor pagamento é feedback de uso real, principalmente os casos em que a metodologia falhou.

Abraços, Fellipe Soares

Leave a Reply

Your email address will not be published. Required fields are marked *