"Você pode montar um relatório de sprint?" geralmente significa que alguém quer saber, em termos simples, se a equipe fez o que disse que faria. Essa é uma pergunta mais restrita do que parece: a maior parte do que acaba entrando em um relatório de sprint é ou um gráfico de burndown que ninguém lê com atenção, ou uma lista de tópicos digitada de memória na manhã da revisão. Nenhum dos dois realmente responde "entregamos o que nos comprometemos a entregar", que é a pergunta que vale a pena responder.
O que um relatório de sprint realmente precisa
Reduzindo ao essencial, um relatório de sprint precisa de cinco coisas: o que a equipe se comprometeu a fazer no início do sprint (não o que ela acabou tendo: são números diferentes assim que o escopo se move); o que realmente foi entregue; o que foi transferido e por quê; o quanto o escopo mudou depois do primeiro dia; e alguma noção de quanto tempo o trabalho entregue realmente levou, não apenas quanto trabalho havia. Um relatório que pula a linha de base do primeiro dia e mostra apenas o conteúdo final do sprint não consegue distinguir uma falha de entrega de um aumento de escopo: os dois parecem idênticos vistos de fora, a menos que o snapshot do primeiro dia tenha sido mantido.
Resumo do sprint: uma equipe, um sprint
É essa a estrutura da visão Resumo do sprint do Agile Gauge. Ela escolhe um sprint, o atual, se tiver atividade real, ou busca entre os últimos seis sprints concluídos por um que tenha, e mostra Confiabilidade do compromisso, Entregue, Transferência, Em andamento, Mudança de escopo, e o tempo de ciclo mediano e do percentil 85 para os itens concluídos daquele sprint, cada um como um cartão de estatística clicável.
De onde "comprometido" realmente vem
A confiabilidade do compromisso só significa alguma coisa se "comprometido" for medido honestamente. O Resumo do sprint o define como tudo o que o sprint continha ao final do seu primeiro dia: lido a partir do próprio histórico do Azure DevOps quando disponível, e reconstruído reproduzindo o histórico de atribuição de sprint de cada item quando não está (comum em dados importados de outros lugares). A página informa claramente qual método foi usado. Se nenhum dos dois métodos conseguir estabelecer um snapshot real do primeiro dia, a confiabilidade do compromisso e a transferência simplesmente não são exibidas, em vez de recorrer silenciosamente ao conteúdo atual do sprint: um número construído a partir de "o que está no sprint agora" ficaria próximo de 100%, não importa o que realmente tenha acontecido, o que é pior do que nenhum número.
Itens entregues e comprometidos divididos pelos itens comprometidos dão a confiabilidade do compromisso em porcentagem; itens removidos completamente do Azure DevOps são excluídos de ambos os lados, já que uma equipe não deve ser creditada nem penalizada por um trabalho que o negócio retirou. Um item ainda conta como entregue se foi fechado até 24 horas após o término do próprio sprint, já que a maioria das equipes fecha o último item ou dois na manhã seguinte à revisão. A mudança de escopo é (itens adicionados após o primeiro dia mais itens removidos após o primeiro dia) dividido pelo total de itens: um item que foi adicionado e depois removido novamente não conta em nenhum dos dois grupos.
Respaldando cada número com os itens reais
Um número de relatório de sprint que não pode ser questionado na sala não vale a pena ser mostrado. Cada cartão de estatística no Resumo do sprint abre os itens exatos por trás dele, Comprometido, Entregue, Transferência, Em andamento, e os grupos Adicionados e Removidos da Mudança de escopo separadamente, e cada item nessas listas se aprofunda ainda mais em seu próprio tempo de ciclo, sua jornada pelos estágios de fluxo de trabalho mapeados da sua equipe, e um link direto para o Azure DevOps. "A transferência foi alta neste sprint" se transforma em uma lista real de quais itens foram transferidos e por quê, em vez de um número que alguém precisa aceitar por fé.
Quando o relatório é para uma reunião, não apenas para uma tela
O Resumo do sprint foi criado para ser lido na tela, trocando um sprint de cada vez em um seletor. Quando o relatório precisa ser apresentado em uma sala: uma revisão de sprint, uma retrospectiva, a visão Resumo da retrospectiva do Agile Gauge cobre um terreno semelhante com seis KPIs avaliados em relação a metas definidas pela sua equipe, além de um layout de impressão dimensionado para caber em poucas páginas, em vez de uma apresentação de slides feita à mão. As duas visões compartilham os mesmos cálculos subjacentes, então um número não muda dependendo de qual tela alguém usou para abri-lo.
O que isso não cobre
O primeiríssimo sprint de uma equipe, ou uma equipe sem nenhum histórico de sprints, mostra "nenhum sprint ainda" em vez de números inventados. Um sprint muito grande, reconstruído a partir do histórico de itens em vez de lido diretamente do Azure DevOps, pode ocasionalmente deixar de recuperar algumas movimentações, o que pode fazer a confiabilidade parecer um pouco mais generosa do que deveria: a página informa quando usou o método reconstruído, então essa ressalva permanece visível em vez de escondida. E cada número na página é pré-filtrado pelos tipos de item de trabalho que sua organização configurou para contar nas métricas; até que isso seja definido, todos os tipos são incluídos.
Chegando lá
O Resumo do sprint precisa de uma coisa configurada primeiro: o mapeamento dos estágios do fluxo de trabalho da sua equipe na Configuração, para que o Agile Gauge saiba quais dos seus estados contam como iniciados e quais contam como concluídos. Uma vez definido isso, o Resumo do sprint lê o histórico do seu Azure DevOps e monta o relatório no momento em que você abre a tela: nada para exportar, nada para digitar duas vezes, e nada que fique desatualizado entre uma revisão de sprint e a próxima.
O Agile Gauge começa em $20 por mês para até 2 usuários. Comece uma avaliação gratuita de 14 dias: todos os recursos, sem cartão.