O planejamento de Sprint para uma equipe de humanos e agentes funciona quando você planeja em torno da capacidade de revisão, não da velocidade de execução. Os agentes podem assumir e concluir mais Tarefas do que seus revisores conseguem aceitar, então o limite real de um ciclo é quantas alterações finalizadas uma pessoa consegue inspecionar e mesclar, não quanto código é escrito. Este guia percorre o método de planejamento passo a passo, nomeia o modo de falha em cada etapa e termina com uma checklist que você pode executar antes do próximo Sprint.
O planejamento de Sprint clássico parte do princípio de que o recurso escasso são as horas que os engenheiros têm para escrever código. Adicione agentes de código e essa premissa deixa de valer. Claude Code, Codex e Gemini CLI podem cada um pegar uma Tarefa e retornar um diff funcional enquanto você ainda está lendo o anterior. A execução deixa de ser o gargalo. A aceitação passa a ser.
Essa mudança arruína silenciosamente um plano normal. Você dimensiona um ciclo de duas semanas em dias de desenvolvedor, os agentes consomem todo o backlog em três, e uma fila de alterações finalizadas mas não revisadas se acumula atrás de uma ou duas pessoas que conseguem aceitar o merge. O Sprint parece rápido e termina devagar.
O Sharkly é o workspace no qual este guia planeja. Você já tem agentes de código; o Sharkly os transforma em uma equipe mantendo cada Tarefa, seu progresso, bloqueios, resultados e a revisão humana em um único lugar compartilhado, em vez de espalhados por terminais. Um Sprint no Sharkly é um conjunto de Tarefas com prazo definido e pertencente a um Space. O método abaixo é o mesmo, seja executado em um quadro branco ou no produto, mas os modos de falha são mais fáceis de detectar quando o trabalho retorna a um quadro compartilhado.
O que muda quando os agentes fazem a execução
O planejamento de Sprint para uma equipe de humanos e agentes é a prática de definir o escopo de um ciclo em torno de quanto trabalho finalizado de agentes uma pessoa consegue revisar e aceitar, e não de quanto código a equipe consegue produzir.
Os agentes pesquisam, executam, testam e relatam. As pessoas definem a direção, concedem autoridade e aceitam o resultado. Essa divisão é todo o problema de planejamento. A capacidade de produção dos seus agentes é elástica: você pode executar três ou dez. Sua capacidade de revisão é fixa, determinada pelo número de pessoas que conseguem ler um diff, executar a alteração e decidir se ela será entregue. Consulte os cálculos de capacidade de revisão para entender por que um salto de 5x na produção dos agentes raramente significa 5x mais trabalho entregue.
Portanto, o primeiro número com que você planeja não são story points. São as vagas de revisão: quantas Tarefas concluídas cada revisor consegue aceitar por dia, multiplicado pelo número de revisores, multiplicado pelos dias do ciclo. Todo o resto precisa caber sob esse teto.
Planeje o Sprint passo a passo
1. Defina primeiro o teto de revisão. Estime quantas Tarefas concluídas um revisor consegue realmente aceitar por dia; uma revisão de verdade de uma alteração não trivial leva de 30 a 60 minutos. Multiplique pelo número de revisores e pelos dias do Sprint. Modo de falha: pular essa etapa, planejar pela capacidade dos agentes, assumir compromissos demais e terminar o ciclo com uma fila de revisão maior que o próprio Sprint.
2. Dimensione as Tarefas pela revisão, não pela execução. Divida o trabalho de forma que cada Tarefa produza um diff que uma pessoa consiga manter na cabeça. Modo de falha: um agente retorna alegremente uma alteração de 2.000 linhas em nove arquivos, ninguém consegue aceitá-la dentro de uma única vaga de revisão, e ela apodrece no fim do quadro.
3. Escreva os critérios de aceitação antes de atribuir. Cada Tarefa precisa de uma definição de pronto testável: o que construir, como é o “correto”, o que não mexer. Modo de falha: escopo vago faz o agente adivinhar, o revisor devolve a Tarefa, e uma única Tarefa consome duas vagas de revisão.
4. Atribua a um único Agente ou a uma Crew, de propósito. Use um Agente para trabalhos pequenos e bem definidos. Use uma Crew quando um Agente líder precisa interpretar o objetivo, trazer outros membros e reunir os resultados deles em uma única Tarefa. Modo de falha: recorrer a uma Crew em trabalho trivial adiciona peças móveis que você depois terá que revisar.
5. Limite o trabalho em andamento. Estabeleça um limite de quantas Tarefas podem ficar na coluna “em revisão”, do mesmo modo que os limites de WIP funcionam no kanban. Modo de falha: sem limite, os agentes inundam a coluna de revisão mais rápido do que os humanos conseguem esvaziá-la; o gargalo permanece invisível até o último dia.
6. Deixe uma margem de folga. Reserve vagas de revisão para retrabalho e para os pedidos de alteração que você vai devolver. Modo de falha: planejar 100% e a primeira rodada de “por favor, corrija” não tem onde caber.
Onde uma planilha ou uma configuração só de tickets para de escalar
Você pode executar o primeiro Sprint em uma planilha. Uma aba de Tarefas, uma coluna de responsável, uma coluna de status. Isso se mantém enquanto uma pessoa executa dois agentes em um repositório.
Para de funcionar no momento em que execução e acompanhamento se separam. A execução do agente, o diff, a saída dos testes e a discussão ficam no terminal; a planilha guarda um “em andamento” desatualizado. Alguém atualiza a linha manualmente, ou ninguém faz isso. Adicione um terceiro agente em um segundo repositório e o quadro se afasta da realidade em um dia. Então você não consegue responder à única pergunta da qual o planejamento depende: o que foi concluído e o que está esperando por mim?
Um quadro de tarefas criado para isso mantém a execução e o registro juntos. Trabalho, progresso, bloqueios e resultados retornam à Tarefa em vez de desaparecerem em sessões privadas. No Sharkly, um Agente assume uma Tarefa pronta, executa em uma worktree isolada para que alterações paralelas não colidam, e seu resumo de alterações, resultados de verificação e limites conhecidos retornam à linha do tempo da Tarefa para uma pessoa aceitar ou devolver. Essa é a diferença entre um status que você mantém e um status que se mantém sozinho. Isso também entrega à sua próxima sessão de planejamento dados reais: qual trabalho os agentes concluíram no ciclo anterior e para onde foi o tempo de revisão.
Limite honesto: se você executa um agente em um repositório e revisa à medida que avança, não precisa de um quadro de tarefas nem do Sharkly para isso. Um único terminal e uma checklist bastam. A equação muda quando você planeja com vários agentes, Tarefas, repositórios ou pessoas, que é exatamente o ponto em que uma planilha se transforma em um segundo emprego. O Sharkly foi criado para esse segundo caso; baixe-o quando a planilha começar a mentir para você.
Uma checklist para executar antes do próximo Sprint
Execute isto antes de fechar o plano:
- [ ] Calculei o teto de revisão (revisores x aceites por dia x dias) e o tratei como a capacidade real do Sprint.
- [ ] Cada Tarefa é pequena o suficiente para ser revisada dentro de uma única vaga.
- [ ] Cada Tarefa tem critérios de aceitação testáveis e um limite claro de “não mexer”.
- [ ] Cada Tarefa é atribuída a um único Agente ou a uma Crew de propósito, não por padrão.
- [ ] Existe um limite de WIP na coluna “em revisão”.
- [ ] Há folga reservada para retrabalho e pedidos de alteração.
- [ ] Uma pessoa é responsável pela decisão de merge e release de cada Tarefa.
- [ ] Progresso, bloqueios e resultados retornam a um quadro compartilhado, não a terminais privados.
Marque todas as oito e a execução dos agentes permanece dentro de um plano que a equipe consegue concluir. Deixe a primeira de fora e as demais não vão salvá-lo.
Perguntas frequentes
O planejamento de Sprint ainda é útil quando os agentes escrevem a maior parte do código? Sim, mas a restrição se desloca. Um Sprint deixa de ser um contêiner para horas de engenharia e passa a ser um contêiner para revisão e aceitação. Planeje o ciclo em torno de quanto trabalho finalizado as pessoas conseguem inspecionar, e os agentes o preencherão. O Guia do Scrum ainda define a cerimônia; só os cálculos de capacidade mudam.
Como estimo a capacidade de uma equipe de humanos e agentes? Comece pelos revisores, não pelos agentes. Conte quantas Tarefas concluídas uma pessoa consegue honestamente aceitar por dia e multiplique pelo número de revisores e pelos dias do Sprint. O número de agentes só importa até passar desse teto; depois disso, mais agentes apenas aumentam a fila.
Os agentes devem escolher suas próprias Tarefas durante o Sprint? Deixe-os assumir Tarefas prontas que já tenham critérios de aceitação, para que o trabalho paralelo avance sem um despachante. Mantenha os humanos na direção, na autoridade e no merge. Isso deixa o humano no loop onde o julgamento é necessário e automático em todo o resto.
Como isso é diferente do gerenciamento de projetos normal? As cerimônias parecem iguais; o gargalo, não. O gerenciamento de projetos com agentes de IA planeja em torno da capacidade de revisão e do isolamento de alterações, em vez da disponibilidade de desenvolvedores, porque a execução não é mais o recurso escasso.
Preciso de uma ferramenta nova ou posso estender o Jira? Você pode manter o sistema que sua equipe já entende. A lacuna é que ferramentas de tickets acompanham um status que um humano digita, não uma execução que uma máquina realiza. Consulte alternativas ao Jira para equipes de humanos e agentes para saber onde essa lacuna começa a doer.
