LLM Wiki — Synaptic Lattice

triagem-e-priorizacao-de-backlog

Properties1
tagsvibe-coding, prioritization, founder, pm

Leitura de 3 min

Triagem e Priorização de Backlog

Definition

Triagem e priorização de backlog é a fase que decide o que entra em execução esta semana, o que espera, e o que nunca deveria ter entrado no backlog. Para um founder/PM não-técnico operando com agentes de IA, a triagem é o principal ponto de controle: o board (GitHub Project) funciona como autorização, não como registro — o agente só trabalha quando existe uma issue aprovada nele.

Key Points

  • Appetite (emprestado do Shape Up) substitui estimativa de horas por um limite de tempo que o founder está disposto a apostar em uma feature. Se a feature não cabe no appetite, é cortada ou reduzida — decisão tomada antes de começar, não depois de já ter investido tempo.
  • Três perguntas antes de qualquer feature nova: “Isso precisa existir agora?”, “Isso reduz risco?”, “Isso ajuda o usuário no fluxo atual?” — se qualquer resposta for não, a feature espera. É o filtro contra feature creep.
  • Limite de WIP (work in progress) de 2 issues ativas por vez. O argumento é psicológico: com 5 issues abertas, nenhuma parece urgente; com 2, ambas são prioritárias.
  • Estado do projeto vive só no GitHub (Issues + Project board + PRs) — nunca duplicado em planilha ou documento separado, porque duplicação sempre desatualiza.
  • Board minimalista: 3 colunas (Todo, In Progress, Done) até o volume justificar mais; 5 campos (Status, Type, Priority, Owner, Size); 6 labels (type:feature, type:bug, type:docs, prio:high, blocked, needs-info).
  • Um único board central, nunca um por área (features/bugs/infra separados) — a fonte argumenta que dividir o board impede enxergar os trade-offs de priorização entre eles.
  • Labels com automação simples transformam o board de passivo em ativo: por exemplo, uma issue marcada blocked há mais de 3 dias dispara notificação.

Implications

A triagem bem feita depende diretamente de especificacao-de-issues-para-agentes — só é possível aplicar appetite e as três perguntas de filtro a uma issue que já tem critério de aceitação e escopo definidos. Para o founder/PM, o board deixa de ser um artefato de status e passa a ser o mecanismo de controle de quando o agente pode agir — o que se conecta com o papel de “Juiz do Escopo” descrito em ciclo-issue-branch-pr-merge.

Open Questions

  • A fonte não distingue como esse modelo (WIP 2, board único) escala além de um founder solo operando um único agente — o que muda com mais de uma pessoa/agente trabalhando em paralelo?

Sources

Visão de gráfico

Backlinks