Por Que 2/3 dos Itens de Ação de Retrospectivas Morrem (E Como Resolver)

O Turno do Cemitério

Imagine a cena: É hora da retrospectiva da sprint. A equipe se reúne, seja pessoalmente ou espalhada em janelas de vídeo. Post-its voam. Alguém menciona o gargalo de deploy que está matando a velocidade. Outra pessoa fala da suíte de testes instável. Uma terceira sugere rotações de pair programming para disseminar conhecimento.

Ao final da sessão, você tem uma lista organizada de itens de ação:

• "Investigar paralelização de CI" — atribuído à Sarah
• "Documentar o fluxo de autenticação" — atribuído ao Mike
• "Configurar cronograma de rotação para revisões de código" — atribuído ao líder da equipe

Todos concordam. A retro termina. As pessoas se sentem bem. Progresso foi feito.

Duas semanas depois, mesma sala, mesmos rostos. Nova retro. E ninguém menciona o que aconteceu com aqueles itens de ação. Porque nada aconteceu com aqueles itens de ação. Eles morreram silenciosamente, em algum lugar entre o backlog do Jira e as boas intenções de todos.

Soa familiar?

A Matemática Desconfortável

Aqui está uma estatística que deveria assombrar todo scrum master: Uma pesquisa da comunidade PMI descobriu que quase dois terços das equipes implementaram menos de 25% das ideias de melhoria de sua última retrospectiva. Nenhum respondente disse ter implementado mais de 75%.

Leia isso de novo. Dois terços das equipes não conseguem nem executar um quarto do que se comprometeram.

Isso não é uma pequena ineficiência de processo. É uma crise massiva de credibilidade. Cada item de ação abandonado é uma pequena promessa quebrada. Empilhe o suficiente delas e você terá "fadiga de retrospectiva" — aquela vibe cínica e desengajada onde as pessoas param de levantar problemas porque aprenderam que nada nunca muda mesmo.

A cerimônia continua. A melhoria não.

Por Que os Itens de Ação de Retrospectiva Morrem?

Os itens de ação de retrospectiva morrem porque o sistema é projetado para o fracasso, não porque as pessoas são preguiçosas ou não se importam. Nada força a equipe a confrontar compromissos antigos, estados "em progresso" escondem abandono, itens esquecidos desaparecem sem uma decisão, e admitir uma promessa quebrada é desconfortável o suficiente para que ninguém mencione. Quatro problemas, um cemitério.

Problema 1: Nenhuma Função Forçadora

Itens de ação tradicionais vivem no Jira ou em um documento compartilhado ou nas anotações de alguém. Eles competem com o trabalho real da sprint por atenção. E adivinha o que vence quando o product owner está perguntando sobre aquele prazo de feature? Não é "investigar paralelização de CI."

Não há momento em que a equipe é forçada a confrontar o destino de compromissos anteriores. A retro foca no que aconteceu nesta sprint, não no que prometemos na sprint passada.

Problema 2: Teatro do Progresso

Muitas ferramentas permitem marcar itens de ação como "em progresso" ou "50% completo" ou qualquer porcentagem que faça você se sentir produtivo. Isso é uma armadilha. Um item de ação que está "em progresso" há três sprints não está em progresso. Está abandonado com passos extras.

O teatro do progresso permite que as equipes evitem o binário desconfortável: Fizemos isso ou não?

Problema 3: Esquecimento Silencioso

O destino mais comum para um item de ação não é conclusão ou fechamento explícito. É simplesmente ser esquecido. Ele desliza para o fundo da lista, substituído por compromissos mais novos e brilhantes. Ninguém diz "não vamos fazer isso". Simplesmente... para de existir.

Isso é morte por negligência, e é muito mais comum do que fracasso explícito.

Problema 4: Evitar a Vergonha

Sejamos realistas: admitir que você não fez algo a que se comprometeu é desconfortável. A natureza humana é evitar essa conversa. Então não mencionamos os itens de ação antigos. Focamos nos novos problemas. O ciclo continua.

A Solução Irritantemente Eficaz

Quando construímos o sistema de itens de ação no Simyl Flow, projetamos para ser intencionalmente desconfortável. Não cruel — apenas honesto. Veja como isso funciona:

A Verificação de Responsabilidade

A verificação de responsabilidade é uma função forçadora: você não pode iniciar uma nova retrospectiva sem primeiro lidar com seus compromissos antigos.

Quando você abre uma nova retro, antes de ver o quadro, antes de qualquer um adicionar um único card, um diálogo aparece. Ele mostra cada item de ação aberto de retrospectivas anteriores. Para cada um, você tem exatamente três escolhas:

1. Marcar como Concluído — Você fez. Celebre. Siga em frente.
2. Levar Adiante — Você não fez, mas ainda quer. Ele é transferido para esta retro com um contador.
3. Não Fazer — Você está conscientemente decidindo não fazer isso. Você tem que dizer por quê.

Sem quarta opção. Sem "em progresso". Sem "vamos falar sobre isso depois". Você deve decidir.

type ActionDecision = "done" | "carry_forward" | "wont_do" | null;

É isso. Três estados. Resultados binários com uma saída de emergência que requer explicação.

O Contador da Vergonha

Aqui é onde fica interessante. Quando você leva uma ação adiante, incrementamos um contador.

Esse contador é visível. Quando um item de ação mostra "Levado adiante 2x" naquele badge âmbar, todos podem ver. Não são metadados ocultos. É um sinal público que diz "já adiamos esse compromisso duas vezes agora."

Isso é um pouco desconfortável? Sim. Esse é o ponto. O desconforto cria pressão para fazer a coisa ou conscientemente decidir não fazê-la. Ambos são resultados legítimos. Negligência silenciosa não é.

Vimos equipes onde uma ação atingindo "Levado adiante 3x" dispara uma discussão automática: "Ok, isso continua sendo adiado. Realmente queremos fazer isso, ou devemos apenas fechá-lo?"

Essa conversa é progresso. Essa conversa quase nunca acontece sem o contador visível.

Não Fazer É uma Funcionalidade, Não uma Falha

A maioria das ferramentas trata fechar um item de ação como completá-lo. Nós separamos explicitamente os dois.

Quando você fecha algo como "não fazer", você tem que fornecer um motivo. "Não é mais relevante" está bem. "Prioridades mudaram" está bem. "Percebemos que era uma ideia ruim" está bem. Mas você tem que articular.

Isso não é marcar caixas burocráticas. É forçar a equipe a tomar uma decisão explícita. Fechamento consciente é infinitamente melhor que abandono inconsciente. Uma decisão de não fazer algo ainda é uma decisão. Uma decisão cria aprendizado ("tentamos nos comprometer com X mas não conseguimos seguir adiante por causa de Y").

Esquecer não cria nada.

Concluído ou Não Concluído

Deliberadamente não implementamos conclusão percentual ou estados de progresso. Um item de ação está aberto ou concluído. Esse é o modelo de dados:

export type ActionItemStatus = "open" | "done"; // Simplified - done or not done

Essa foi uma escolha consciente de design que deixa algumas pessoas desconfortáveis. "E se eu estiver na metade?" Então está aberto. "E se eu comecei a pesquisa?" Aberto. "E se eu escrevi um rascunho?" Ainda aberto.

A única pergunta que importa: Você fez a coisa a que se comprometeu?

Esse enquadramento binário elimina completamente o teatro do progresso. Não há meio-termo confortável onde você possa reivindicar crédito por intenções. Você entregou ou não entregou.

Suas Ações Te Seguem

Construímos um painel pessoal — a página "Minhas Ações" — que agrega todos os seus itens de ação em todas as equipes das quais você participa.

Isso cria uma superfície de responsabilidade pessoal. Seus compromissos não ficam espalhados por diferentes quadros de retro e projetos Jira de equipe. Eles estão todos em um só lugar, encarando você.

O efeito psicológico é sutil, mas real. Quando suas ações abertas estão visíveis no seu painel pessoal toda vez que você faz login, elas são mais difíceis de esquecer. Elas não estão enterradas em um backlog de equipe. Elas estão na sua cara.

Confiança É Medida, Não Presumida

É aqui que o sistema fica sério. A taxa de conclusão de itens de ação alimenta diretamente nossas métricas de Dinâmica da Equipe — especificamente, o Score de Confiança.

function calculateActionScore(
  completed: number,
  total: number,
  config: TeamDynamicsConfig,
): number {
  if (total === 0) return 50; // No actions = neutral
  const rate = completed / total;

  // Use config threshold
  if (rate >= config.healthyActionItemCompletion) return 100;
  if (rate >= config.healthyActionItemCompletion * 0.7) return 70;
  return Math.max(20, rate * 100);
}

Por que a conclusão de ações se relaciona com confiança? Porque cumprir é confiar. Quando uma equipe entrega consistentemente seus compromissos — mesmo os internos que afetam apenas a equipe — isso constrói confiança. Por outro lado, um padrão de promessas quebradas (mesmo pequenas, como itens de ação de retro) corrói a confiança da equipe em si mesma.

Uma equipe que não pode confiar em seus próprios compromissos terá dificuldades com todo o resto.

A métrica não é punitiva. Uma equipe que não cria itens de ação recebe uma pontuação neutra. Uma equipe que cria alguns e completa a maioria é recompensada. Uma equipe que cria muitos e completa poucos é sinalizada — não como "ruim", mas como um sinal de que algo está errado. Talvez as ações sejam muito ambiciosas. Talvez não haja tempo reservado para trabalho de melhoria. Talvez o problema seja sistêmico.

A métrica cria a conversa. A equipe decide o que fazer a respeito.

A Filosofia

Tudo o que construímos aqui vem de uma crença simples: decisões explícitas superam negligência implícita.

• Dizer "não vamos fazer isso" é melhor do que esquecer silenciosamente.
• Dizer "vamos levar isso adiante" é melhor do que fingir que não nos comprometemos.
• Dizer "fizemos" (quando você realmente fez) é melhor do que "fizemos algum progresso".

Não estamos tentando envergonhar equipes. Estamos tentando criar um sistema onde a honestidade é mais fácil do que a evasão. Onde o caminho de menor resistência leva à clareza em vez de ambiguidade.

Ferramentas tradicionais facilitam esquecer e tornam desconfortável confrontar. Nós invertemos isso. Nosso sistema torna esquecer impossível (a verificação de responsabilidade) e o confronto gerenciável (três opções claras, cada uma legítima).

O resultado não são taxas de conclusão de 100%. Isso seria irrealista e provavelmente indicaria que as equipes estão se comprometendo apenas com ações seguras e fáceis. O resultado são equipes que conhecem o destino de cada compromisso que fizeram. Isso é algo muito diferente, e é muito mais valioso.

O Que Temos Visto

Equipes usando o padrão de verificação de responsabilidade relatam algumas mudanças consistentes:

Menos Ações, Melhores Ações

Quando você sabe que será confrontado com seus compromissos, você faz menos deles. Mas os que você faz têm mais probabilidade de serem coisas que você realmente fará. O padrão de "vamos colocar isso na lista de itens de ação para fazer as pessoas se sentirem ouvidas" morre rápido.

Decisões de Não Fazer Mais Rápidas

As equipes ficam melhores em reconhecer quando algo não vai acontecer. Em vez de deixar isso se arrastar por três sprints, elas vão fechar em um ou dois. "Dissemos que faríamos isso, não fizemos, não vamos fazer — vamos fechar e parar de fingir."

Mais Conversas sobre Confiança

Quando o score de Dinâmica da Equipe reflete o cumprimento de itens de ação, isso se torna dados para a própria retrospectiva. "Nosso score de confiança caiu neste sprint. Um fator: completamos apenas 2 de 7 itens de ação. O que está acontecendo?"

Essa meta-conversa sobre a capacidade da equipe de cumprir compromissos é frequentemente mais valiosa do que qualquer item de ação individual.

Experimente Ser Desconfortável

Se seus itens de ação de retro continuam morrendo, o problema não é motivação. É design de sistema. Você precisa de:

1. Uma função forçadora — Algo que torna confrontar compromissos antigos obrigatório, não opcional.
2. Resultados binários — Feito ou não feito. Sem se esconder atrás de porcentagens.
3. Rastreamento visível de avanço — Um contador que torna o adiamento repetido visível.
4. Fechamento legítimo — Uma opção "não vamos fazer" que requer uma razão, mas é tratada como válida.
5. Superfícies de responsabilidade pessoal — Seus compromissos te seguem, não apenas a equipe.
6. Métricas que refletem a realidade — O cumprimento afeta os scores de saúde da equipe.

Construímos tudo isso no Simyl Flow porque nos cansamos de ver boas ideias de melhoria morrerem no espaço entre reuniões. A verificação de responsabilidade é um pouco irritante. O contador de avanço é um pouco desconfortável. O status binário é um pouco rígido.

Esse é o ponto. Conforto é como itens de ação morrem.

Fontes

1. Bondale, K. (2022). "Why hold retrospectives if ideas don't get implemented?" — PMI "Easy in theory, difficult in practice" blog
2. Wolpers, S. (2024). "Ditch the Unfinished Action Items – How to Make Retrospectives Lead to Real Change"