Sprint report ou status report: como reportar projetos ágeis

Sprint report é o relatório que registra o que aconteceu numa sprint: a meta, o que foi concluído, o que ficou para trás e por quê. Status report é o relatório que diz a quem decide como o projeto está em relação ao que foi combinado. Em projetos ágeis os dois costumam ser confundidos, e o resultado é conhecido: o diretor recebe uma lista de histórias de usuário com pontos e um gráfico de burndown, e continua sem saber se o produto sai no prazo.

A pergunta certa não é qual dos dois usar, e sim para quem você está escrevendo. O time e o Product Owner precisam de um registro da sprint. O patrocinador e a diretoria precisam de uma leitura do projeto. São leitores diferentes, com perguntas diferentes, e cada um merece o seu formato.

O que é sprint report

O sprint report (relatório de sprint) é um registro curto, feito ao fim de cada sprint, com o resultado dela. Não é um artefato do Scrum: o Guia do Scrum não define relatório de sprint. Lá, a inspeção do resultado acontece na sprint review, em que o time apresenta o trabalho aos stakeholders principais e todos discutem o progresso em direção à meta do produto. O guia diz ainda que a review é uma sessão de trabalho e não deve se limitar a uma apresentação.

Por isso o sprint report funciona melhor como memória do que como substituto da conversa. Ele registra o que a review mostrou e decidiu, para quem não estava lá e para comparar sprints ao longo do tempo. Ferramentas como o Jira geram um relatório de sprint automático nos quadros Scrum, com o burndown e a lista de itens concluídos e não concluídos; esse relatório é a base de dados, não a análise.

O que é status report num projeto ágil

O status report ágil responde às mesmas perguntas de qualquer status report: estamos no rumo? O que ameaça o resultado? O que depende de quem lê? A diferença está na unidade de medida. Em vez de percentual de tarefas concluídas contra uma linha de base detalhada, ele fala de metas do produto, releases, marcos de negócio e da tendência de entrega observada nas últimas sprints.

Ele é escrito para quem não acompanha o dia a dia: patrocinador, comitê, diretoria, áreas parceiras. A periodicidade costuma seguir o calendário da organização (quinzenal ou mensal), não necessariamente o ritmo das sprints.

Sprint report x status report: as diferenças

Repare que muitos stakeholders do produto, como usuários-chave e áreas de negócio, acompanham as sprint reviews e se beneficiam do sprint report. Já a alta direção raramente participa da review. Quem é quem nesse grupo, e como engajar cada um, está em stakeholders em projetos ágeis.

Quando usar cada um

Use o sprint report quando:

• o time quer histórico para comparar sprints e discutir na retrospectiva;
• stakeholders do produto não puderam ir à review e precisam do resumo;
• a organização exige registro formal das entregas (contratos por entrega, auditoria, setor público).

Use o status report ágil quando:

• há patrocinador ou comitê que decide orçamento, prioridade entre projetos ou data de lançamento;
• o projeto depende de áreas fora do time (jurídico, infraestrutura, fornecedores);
• o projeto é híbrido, com parte ágil e parte em cronograma tradicional.

Em muitos projetos os dois existem: o sprint report alimenta o status report. Três ou quatro sprints viram um parágrafo e um gráfico no relatório executivo.

Modelo de sprint report

Copie e adapte. Cada bloco cabe em poucas linhas.

1. Identificação: produto, número da sprint, datas, time.
2. Meta da sprint: o texto da meta e se foi atingida (sim, parcialmente, não), com uma frase de explicação.
3. O que foi concluído: itens que atenderam à definição de pronto, agrupados por objetivo, não listados um a um quando forem muitos.
4. O que não foi concluído: itens que voltaram ao backlog e o motivo principal.
5. Incremento apresentado na review: o que os stakeholders viram e o retorno que deram.
6. Mudanças no backlog: itens novos, repriorizados ou descartados a partir da review.
7. Impedimentos: os que foram resolvidos e os que continuam, com responsável.
8. Próximo foco: a direção provável da próxima sprint, sem antecipar o planejamento.

Exemplo ilustrativo de bloco 2: "Meta: permitir que o cliente acompanhe o pedido pelo aplicativo. Parcialmente atingida: a consulta funciona, mas a notificação por push depende da liberação da conta do fornecedor, prevista para a próxima semana."

Modelo de status report ágil para a diretoria

1. Mensagem principal: uma frase com a situação e a tendência.
2. Semáforo: prazo da próxima release, escopo da meta do produto, custo e risco, cada um com o critério que define a cor.
3. Entregue desde o último relatório: o que já está em uso ou pronto para lançar, em linguagem de negócio.
4. Previsão: quantas sprints faltam para a próxima release, com faixa de incerteza, baseada na entrega das sprints anteriores.
5. Riscos e dependências externas: o que ameaça a data e quem pode resolver.
6. Decisões pedidas: o que, de quem e até quando.

Esse formato conversa com o status report executivo de uma página; a diferença é que a previsão vem do ritmo do time e não de um cronograma detalhado. Para outros formatos de relatório por tipo de leitor, veja os modelos de relatório de status para stakeholders.

Burndown no relatório: como usar sem enganar

O Guia do Scrum cita burndowns, burnups e fluxo cumulativo como práticas para prever progresso e lembra que elas não substituem o empirismo. No relatório, isso vale como regra de leitura:

• Burndown da sprint mostra o trabalho restante dia a dia. Serve ao time; para a diretoria quase sempre é ruído.
• Burnup da release mostra o trabalho concluído acumulado e a linha do escopo total. Quando o escopo cresce, a linha sobe, e o leitor vê na hora por que a data mudou. É o gráfico mais útil no status report.
• Comentário obrigatório: todo gráfico vai acompanhado de uma frase que diz o que ele significa. "O escopo da release cresceu 15% com os pedidos da área comercial; mantido o ritmo, a data passa de março para abril" (números do exemplo).

Dois cuidados: não compare pontos de times diferentes, porque cada time estima numa escala própria; e não transforme pontos em meta de produtividade, porque o número infla e perde valor como previsão.

Erros comuns ao reportar projetos ágeis

• Mandar a lista de histórias para o diretor. Ele precisa do resultado de negócio e da previsão, não do backlog.
• Fingir que não há previsão. "No ágil não tem data" não convence ninguém; uma faixa honesta baseada no ritmo real é melhor.
• Pintar de verde por sprint concluída. Sprint concluída não significa projeto no rumo, se o escopo cresce mais rápido do que o time entrega.
• Duplicar a review por escrito. O sprint report registra a conversa; não tenta reproduzir a demonstração.
• Esquecer as dependências fora do time. Elas são a causa mais comum de atraso e quase nunca aparecem no burndown.

Monte o próximo relatório pelos leitores

Liste quem recebe hoje algum relatório do seu projeto ágil e marque, para cada pessoa, se ela precisa do registro da sprint ou da leitura do projeto. Mande o sprint report para o primeiro grupo e um status report de uma página para o segundo. Para o relatório executivo, o gerador gratuito de status report da Projeto Diário monta os blocos de semáforo, avanços, próximos passos, marcos, riscos e decisões e exporta o documento pronto, sem cadastro. Para ligar tudo ao engajamento das partes interessadas, consulte o guia de gestão de stakeholders.