Retro da sprint com evidências

Vou facilitar a retrospectiva do meu squad e quero que a conversa comece pelo que realmente aconteceu, não por quem fala primeiro. ## Contexto - Squad: [squad] - Sprint que acabou de terminar: [data de início] a [data de fim], comparada com a sprint anterior (mesma duração). O DevStats devolve o nome e os totais de cada sprint, não as datas, então elas precisam vir de mim. - Unidade: [issues | story points] - Os dados abrem a conversa. Não a encerram. O time decide o que eles significam. - Se eu deixei algo entre [colchetes], mantenha o que for um padrão (um período, um número de dias, a primeira de várias opções) e me pergunte o resto de uma vez só, antes de puxar qualquer dado. - Escreva tudo, inclusive o entregável, no idioma deste prompt. ## Puxe estes dados do DevStats (as duas sprints, mesmos filtros) 1. Sprints e Planning Accuracy — comprometido vs concluído 2. Throughput — PRs abertos e mergeados 3. PR Cycle Time com a quebra em coding / pickup / review / deploy 4. Issue Cycle Time 5. Code Review — tamanho dos PRs, comentários por review, PRs mergeados sem review 6. Work Breakdown — código novo vs refactor vs retrabalho 7. Issue List resolvidas na sprint, ordenada por cycle time decrescente, limit 20, campos key, summary, issue_type, project, story_points, cycle_time_formatted, history ## Como analisar - Comece por plano vs resultado. Concluído bem abaixo do comprometido não é um problema de entrega até você saber quanto trabalho entrou no meio da sprint. Bugs e hotfixes resolvidos na sprint são a fonte habitual de carga não planejada. - Leia o histórico de status das issues mais lentas. Uma issue que voltou de review ou QA para in progress é retrabalho. Várias delas formam um padrão: critérios de aceite pouco claros, feedback tardio ou PRs grandes demais para revisar bem. - Parcela de retrabalho subindo no Work Breakdown junto com mais comentários de review aponta para clareza de requisitos ou de design, não para habilidade de codificação. - Veja o que as cinco issues mais lentas têm em comum: mesmo projeto, mesmo tipo, mesma dependência. Um traço compartilhado é um tema. Cinco histórias sem relação são só cinco histórias. - Encontre uma coisa que deu certo e que aparece nos dados. Uma retro que só mostra problemas deixa o time na defensiva. - Três temas no máximo. Uma retro que tenta consertar sete coisas não conserta nenhuma. - Fale do sistema, nunca de indivíduos. Nenhum nome em lugar nenhum do resultado. ## Entregue Um roteiro de facilitação a partir do qual eu consiga conduzir a reunião: 1. **A sprint em cinco números** — comprometido, concluído, PR cycle time, issue cycle time, parcela de retrabalho, cada um com a sprint anterior ao lado. 2. **O que deu certo** — um ou dois pontos, com a evidência. 3. **Três temas** — para cada um: o que os dados mostram, uma pergunta de abertura neutra para o time e o que os dados não conseguem explicar. 4. **Experimentos** — um candidato por tema, pequeno o bastante para rodar em uma única sprint, com a métrica que vai dizer se funcionou. 5. **Conferir na próxima retro** — os números a olhar primeiro daqui a duas semanas.