O planejamento de Sprint sempre se apoiou em uma premissa silenciosa: a capacidade é o número de pessoas multiplicado pelo time box. Você estima o trabalho, compara com o que a equipe concluiu no ciclo anterior e assume um escopo que cabe.
Coloque Agentes de codificação com IA na equipe e a equação deixa de descrever a realidade. Um Agente pode assumir uma Tarefa no momento em que ela fica pronta, trabalhar em paralelo com todos os outros Agentes e voltar com um diff e resultados de testes antes da daily em que você pretendia discuti-la. A capacidade de execução se infla drasticamente. A resposta tentadora é assumir mais escopo, e as equipes que fazem isso normalmente descobrem o modo de falha ao final do primeiro ciclo: a Sprint fecha com bastante código pronto e uma parede de mudanças não revisadas que ninguém teve tempo de aceitar.
É esse o argumento deste post: com Agentes na equipe, a execução deixa de ser a restrição da Sprint e a revisão humana passa a ser a restrição da Sprint. Planeje em torno da vazão de aceitação, não de quanto código pode ser produzido. Vamos usar as Sprints no Sharkly como mecanismo concreto e manter o argumento de planejamento claramente separado dos fatos do produto.
TL;DR
Uma Sprint no Sharkly é um conjunto de Tarefas com time box, pertencente a um único Space; as Tarefas continuam sendo a fonte de execução e discussão, enquanto a Sprint acrescenta cronograma, escopo e relatórios. As Sprints são opcionais e operam em um de dois modos: cadência Automática, em que o Sharkly mantém o cronograma e leva adiante o trabalho não concluído, ou Manual, em que as Pessoas criam, iniciam e concluem Sprints explicitamente. Os relatórios cobrem escopo, trabalho iniciado e concluído, taxa de conclusão, capacidade e histórico de burnup. Para equipes híbridas de humanos e agentes, a mudança no planejamento é esta: os Agentes inflam a capacidade de execução, mas a aceitação continua com as Pessoas, então o compromisso honesto de uma Sprint é limitado por quanto trabalho concluído seus revisores conseguem aceitar, não por quanto seus Agentes conseguem produzir.
O que é uma Sprint no Sharkly
Uma Sprint é um conjunto de Tarefas com time box, pertencente a um único Space. Ela ajuda a equipe a planejar um escopo focado, acompanhar o progresso e decidir o que acontece com o trabalho não concluído quando o time box termina. As Tarefas continuam sendo a fonte de execução e discussão; a Sprint acrescenta cronograma, escopo e relatórios por cima disso.
A documentação usa o termo Sprint, e ele significa o que a indústria entende por isso. O Guia do Scrum descreve Sprints como contêineres de duração fixa nos quais ideias se transformam em valor, e a versão do Sharkly mantém essa linhagem. O que o Sharkly muda é quem executa dentro da janela.
Três limites mantêm o conceito limpo:
- Uma Sprint pertence a exatamente um Space. Colocar uma Tarefa em uma Sprint não altera sua propriedade.
- As Sprints são opcionais, habilitadas por Space. Um Space que pensa em fluxo contínuo pode nunca ativá-las.
- Uma Sprint não é um Projeto nem uma View. Use uma Sprint quando a pergunta é o que deve ser concluído em um determinado time box. Use um Projeto para um resultado que pode abranger várias Sprints ou Spaces. Use uma View para uma forma salva de inspecionar Tarefas.
Essa última distinção faz um trabalho real em uma equipe híbrida: o Projeto detém o resultado, a Sprint detém o compromisso de curto prazo e as Views detêm os recortes que cada pessoa precisa no dia a dia.
Cadência automática ou modo Manual
Ao habilitar Sprints para um Space, você escolhe um de dois modos de ciclo de vida. A escolha altera o comportamento do ciclo de vida, não a propriedade das Tarefas.
A cadência Automática entrega o calendário ao Sharkly. Você configura a duração da Sprint, um cooldown opcional, o dia da semana de início, quantas Sprints futuras manter, o fuso horário e regras que adicionam Tarefas automaticamente quando elas entram em determinadas categorias de status. O Sharkly então cria Sprints futuras, inicia e conclui cada uma conforme o cronograma e leva adiante o trabalho não concluído. Iniciar uma Sprint futura antecipadamente conclui primeiro a atual e transfere o trabalho não concluído dela para a Sprint que está sendo iniciada.
O modo Manual deixa o controle do ciclo de vida com a equipe. As Pessoas criam Sprints planejadas quando necessário, iniciam-nas sem alterar as datas configuradas, mantêm mais de uma Sprint ativa em paralelo e escolhem para onde vão as Tarefas não concluídas na conclusão. A criação automática, a transferência de pendências, o cooldown e as regras de adição por status permanecem inativos no modo Manual.
| Cadência automática | Modo manual | |
|---|---|---|
| Cronograma | O Sharkly cria, inicia e conclui Sprints em um ritmo configurado | As Pessoas criam, iniciam e concluem Sprints explicitamente |
| Trabalho não concluído | Transferido automaticamente para a próxima Sprint | Encaminhado na conclusão: sem Sprint, para outra Sprint ou para uma nova |
| Sprints ativas em paralelo | Uma Sprint atual por cadência | Mais de uma Sprint ativa permitida |
| Entrada de Tarefas | Regras por categoria de status podem adicionar Tarefas durante a janela | Tarefas adicionadas pelas Pessoas via planejamento, listas ou campo Sprint |
| Ideal para | Uma cadência constante que a equipe quer manter sem cerimônia | Ciclos irregulares, janelas orientadas por releases ou esforços sobrepostos |
O par de decisão honesto: use a cadência Automática quando sua equipe segue um ritmo constante e quer que a mecânica seja mantida por você. Use o modo Manual quando seus ciclos são irregulares, quando são os releases, e não os calendários, que definem suas janelas, ou quando você precisa de duas Sprints ativas ao mesmo tempo. Mudar para o modo Manual mantém as Sprints existentes, mas interrompe o agendamento automático. Desabilitar as Sprints por completo conclui as ativas, remove as futuras e mantém os dados concluídos para relatórios.
Como as Tarefas entram, saem e pulam Sprints
As Sprints aparecem em cinco estados de exibição: Atual, Futura, Planejada, Concluída e Cancelada. Sprints concluídas e canceladas vão para o arquivo do Space, em vez de poluir a lista de planejamento ativo.
Você adiciona ou move uma Tarefa pelo seu campo Sprint, a partir de uma lista de Tarefas ou durante o planejamento da Sprint. Duas regras importam mais do que parecem.
Primeiro, uma Tarefa pode não ter Sprint alguma. Esse é o lar natural do trabalho no Backlog e de Tarefas não comprometidas com nenhum time box.
Segundo, adicionar uma Tarefa a uma Sprint não altera seu status. Essa é a regra que equipes híbridas precisam internalizar, porque no Sharkly a categoria de status Backlog é um estado de estacionamento: criar uma Tarefa ou atribuir um Agente enquanto a Tarefa está no Backlog não inicia a execução. Mover a Tarefa para fora do Backlog, para um status pronto, é o que pode iniciar o Agente atribuído. Assim, o planejamento da Sprint e a liberação da execução são duas alavancas separadas. Você pode planejar a Sprint inteira na segunda-feira, com os Agentes já atribuídos, e nada roda até que cada Tarefa seja deliberadamente movida para um status pronto. Automações de mudança de status podem então assumir as transições que você quer padronizar.
Mais uma regra protege seu histórico: apenas Tarefas concluídas podem ser adicionadas a uma Sprint anterior. Isso permite correção histórica sem nunca colocar trabalho não concluído em um período fechado.
Quanto às datas, o início e o fim de uma Sprint planejada são editáveis, enquanto o início de uma Sprint ativa é fixo, mas seu fim pode ser alterado.
O que os relatórios de Sprint revelam
Os relatórios de Sprint incluem contagens de Tarefas e, quando o Space tem estimativas habilitadas, totais de pontos de estimativa em seis leituras: escopo, trabalho iniciado, trabalho concluído, taxa de conclusão, capacidade e histórico de burnup.
A capacidade merece uma análise mais atenta, porque é o número no qual as conversas de planejamento se ancoram. O Sharkly a deriva da velocidade recente de Sprints concluídas quando há histórico suficiente e, caso contrário, recorre a uma estimativa baseada no tamanho do Space. A documentação diz para tratá-la como insumo de planejamento, e não como garantia, e, para uma equipe híbrida, essa ressalva não é formalidade: a velocidade medida em uma coorte apenas humana deixa de prever qualquer coisa na semana em que você adiciona três Agentes. O histórico de burnup costuma ser mais revelador. Se o escopo é concluído em uma explosão inicial e depois a linha se achata, seus Agentes terminaram a execução e seus revisores passaram o resto da Sprint correndo atrás.
A restrição da equipe híbrida: planeje para a revisão, não para a execução
Tudo nesta seção é um argumento de planejamento, não um recurso do produto. O Sharkly oferece a mecânica de Sprint descrita acima; como você carrega a Sprint é uma decisão de julgamento.
Comece pela divisão do trabalho. Agentes pesquisam, executam, testam e relatam. Pessoas definem a direção, concedem autoridade e aceitam o resultado. Na codificação agêntica, tudo entre a direção e a aceitação pode ser delegado, mas a aceitação permanece humana. Um Agente que conclui uma Tarefa não a concluiu em nenhum sentido que sua Sprint deva contar: o diff, os resultados de verificação e os limites conhecidos voltam para a Tarefa, e uma pessoa ainda precisa lê-los e aceitar, solicitar mudanças ou decidir o merge.
Agora faça a aritmética. Suponha que uma equipe de cinco pessoas adicione Agentes e a vazão de execução triplique. A vazão de revisão não triplicou; as mesmas cinco pessoas a sustentam, e cada mudança aceita custa atenção real. Planeje a Sprint com base na capacidade de execução e o excedente não se tornará valor entregue. Ele se tornará uma fila de trabalho não revisado, e uma mudança não revisada é estoque, não progresso. Pior ainda: uma Sprint se aproximando do fim empurra os revisores exatamente para o atalho que torna o desenvolvimento com muitos agentes perigoso: aceitar a saída sem lê-la.
Então inverta a pergunta de planejamento. Em vez de perguntar quanto trabalho a equipe consegue executar em duas semanas, pergunte quanto trabalho concluído dos Agentes suas Pessoas conseguem aceitar em duas semanas. Na prática, isso muda quatro hábitos:
- Estime o custo de revisão, não apenas o custo de construção. Uma Tarefa trivial de executar para um Agente ainda pode ser cara de aceitar.
- Limite o trabalho concluído, mas não aceito, em paralelo. Decida quantas Tarefas cada revisor consegue realmente aceitar por Sprint e pare de planejar além da soma. Isso é um acordo de trabalho, não uma configuração do Sharkly, mas as métricas de conclusão vão mostrar quando você ultrapassou o limite.
- Libere a execução de forma deliberada. Como o Backlog estaciona a execução, você pode escalonar os inícios para que o trabalho concluído chegue em um ritmo que os revisores consigam absorver, em vez de tudo de uma vez no segundo dia.
- Leia a taxa de conclusão como um número de revisão. Quando o burnup se achata enquanto os Agentes ficam ociosos, a restrição se anunciou. Esse é um sinal para adicionar revisores ou assumir menos escopo, não para adicionar Agentes.
Nada disso desacelera os Agentes. Isso os direciona. Uma Sprint planejada em torno da vazão de aceitação entrega tudo o que assume e nunca pede que uma pessoa aprove um código que não teve tempo de ler.
Planejando uma Sprint híbrida, passo a passo
- Habilite as Sprints para o Space e escolha um modo. Um ritmo constante de equipe sugere cadência Automática; trabalho orientado por releases sugere o modo Manual.
- Modele o escopo. Puxe Tarefas candidatas para a próxima Sprint por meio do planejamento de Sprint ou do campo Sprint. Mantenha o trabalho não comprometido sem Sprint.
- Atribua as duas metades de cada Tarefa. O Sharkly separa a responsabilidade humana da execução do Agente: as Pessoas entram no conjunto de responsáveis, e um Agente ou Crew entra no único slot de execução. Alterar um nunca altera o outro.
- Escreva Tarefas sobre as quais um Agente possa agir. A descrição deve conter o objetivo, as restrições e os critérios de aceitação de que uma pessoa nova ou um Agente precisaria para prosseguir.
- Libere o trabalho no ritmo da revisão. Mova Tarefas para fora do Backlog conforme a capacidade dos revisores se libera.
- Encerre com intenção. No modo Manual, escolha para onde vai cada Tarefa não concluída. Na cadência Automática, verifique o que foi transferido e pergunte se o escopo era grande demais ou se a revisão foi lenta demais.
A disciplina mais ampla de conduzir o trabalho dessa forma está no nosso pilar sobre gerenciamento de projetos com agentes de IA; a Sprint é a fatia com time box desse sistema.
Se suas Sprints vivem no Jira hoje
Você não precisa reconstruir seu processo para experimentar nada disso. A integração do Sharkly com o Jira pode importar dados de Sprints do Jira e, quando a importação de Sprint está habilitada, o Space de destino pode ser alternado para o modo Sprint do Jira, de modo que a cadência que sua equipe já segue é transportada, em vez de começar do zero. O passo a passo sobre atribuir um chamado do Jira a um Agente de IA mostra a mesma ideia no nível de um único chamado, e a documentação do Sharkly cobre a configuração de Sprints e a integração com o Jira em profundidade.
Comece menor que uma migração: habilite as Sprints em um Space, planeje uma janela de duas semanas com base na capacidade real de aceitação dos seus revisores e compare o burnup com o seu último ciclo apenas com humanos.
FAQ
Sou obrigado a usar Sprints no Sharkly?
Não. As Sprints são opcionais e habilitadas por Space. Um Space que prefere fluxo contínuo pode deixá-las totalmente desativadas e, mesmo com as Sprints habilitadas, uma Tarefa pode não ter Sprint alguma, que é o estado normal do trabalho no Backlog.
O que acontece com as Tarefas não concluídas quando uma Sprint termina?
Na cadência Automática, o Sharkly conclui a Sprint conforme o cronograma e leva o trabalho não concluído para a próxima. No modo Manual, o fluxo de conclusão pergunta para onde as Tarefas não concluídas devem ir: sem Sprint, para outra Sprint ativa ou futura, ou para uma Sprint recém-criada.
Os Agentes podem trabalhar automaticamente nas Tarefas da Sprint?
Um Agente ou Crew definido como responsável de execução de uma Tarefa pode realizar o trabalho, mas a participação na Sprint por si só nunca inicia nada. O Backlog é um estado de estacionamento, então atribuir um Agente a uma Tarefa no Backlog não inicia a execução; mover a Tarefa para um status pronto é o que pode iniciar a execução. Essa separação permite planejar uma Sprint inteira primeiro e liberar a execução no ritmo que seus revisores conseguem absorver.
Como o Sharkly calcula a capacidade da Sprint?
A capacidade usa a velocidade recente de Sprints concluídas quando há histórico suficiente e, caso contrário, recorre a uma estimativa baseada no tamanho do Space. A documentação recomenda tratá-la como insumo de planejamento, e não como garantia, o que importa em dobro para equipes híbridas, nas quais a velocidade mede o sistema inteiro, e não o gargalo de revisão dentro dele.
Posso adicionar uma Tarefa a uma Sprint que já terminou?
Apenas Tarefas concluídas podem ser adicionadas a uma Sprint anterior. Isso permite correções históricas, como creditar trabalho concluído dentro da janela, mas nunca registrado, sem jamais colocar trabalho não concluído em um período fechado.
