"Proporção falar/fazer" é uma ideia direta, mas útil: de tudo o que a equipe disse que faria, quanto ela realmente fez? O problema é que é fácil medir isso de forma desonesta sem querer. Se "disse" for lido como tudo o que o sprint por acaso contém no momento em que alguém verifica, o escopo adicionado silenciosamente no meio do sprint acaba sendo contado como se fizesse parte do plano original, e uma equipe que assumiu trabalho extra e concluiu a maior parte dele pode parecer idêntica a uma equipe que se comprometeu honestamente e entregou tudo. O número só significa alguma coisa se "comprometido" estiver ancorado a um momento real no tempo, o início do sprint, e não redefinido depois do fato.
Por que a linha de base do primeiro dia é tudo o que importa
A confiabilidade do compromisso é o número de itens entregues e comprometidos dividido pelos itens comprometidos, onde "comprometido" significa tudo o que o sprint continha ao final do seu primeiro dia. Sem esse ponto fixo, falhas de entrega e aumento de escopo parecem a mesma coisa vistos de fora: um sprint que adicionou dez novos itens e concluiu oito deles, e um sprint que se comprometeu com oito itens e entregou todos eles, produzem a mesma contagem final de itens, mas são sprints completamente diferentes. O Agile Gauge lê o snapshot do primeiro dia a partir do próprio histórico de atribuição de sprint do Azure DevOps quando disponível, e o reconstrói reproduzindo o histórico de cada item quando não está: e informa claramente qual método usou, já que o método reconstruído pode ocasionalmente deixar passar uma movimentação em um sprint incomumente grande.
Em várias equipes: o KPI de Compromisso do sprint do Estado do fluxo
Para quem compara mais de uma equipe, a visão Estado do fluxo do Agile Gauge avalia o Compromisso do sprint como um dos seis KPIs independentes em um conjunto nomeado de equipes, sem uma nota geral combinada por cima. Cada equipe chega ao seu próprio status em relação a uma meta padrão de 80% ou mais, e o bloco traz uma frase simples como "3 de 6 equipes na meta", em vez de um único número que esconde quais equipes estão realmente com dificuldades. Clicar no bloco abre os itens exatos por trás do número para a equipe que você quiser conferir.
Uma equipe, um sprint: o mesmo número no Resumo do sprint
Quando a conversa é sobre um sprint específico, e não sobre um conjunto de equipes, o Resumo do sprint mostra o mesmo cálculo como um cartão de estatística de Confiabilidade do compromisso, ao lado de Transferência, Mudança de escopo, e tempo de ciclo para aquele mesmo sprint. Itens removidos completamente do Azure DevOps são excluídos de ambos os lados da proporção, então uma equipe não é creditada nem penalizada por um trabalho que o negócio retirou, e um item ainda conta como entregue se foi fechado até 24 horas após o término do próprio sprint: a maioria das equipes fecha o último item ou dois na manhã seguinte à revisão, e esse período de tolerância evita que o número penalize o momento normal do limite do sprint.
Como fica quando não há nada honesto para mostrar
Se nem o histórico direto nem a reconstrução conseguem estabelecer um snapshot real do primeiro dia para um sprint, a confiabilidade do compromisso e a transferência simplesmente não são exibidas: um painel explica o motivo em vez disso. A alternativa seria tratar os membros atuais do sprint como "comprometidos", o que faz a confiabilidade parecer próxima de 100% e a transferência próxima de 0%, não importa o que realmente tenha acontecido durante o sprint. Um número ausente é uma resposta mais honesta do que uma lisonjeira construída sobre uma suposição ruim.
Um número que pode ser manipulado se você só olhar para ele isoladamente
A proporção falar/fazer tem uma fraqueza bem conhecida: uma equipe que quer um número lisonjeiro pode simplesmente se comprometer com menos do que espera entregar, e então parecer confiável todo sprint sem realmente mudar nada em como trabalha. A confiabilidade do compromisso sozinha não consegue distinguir uma equipe que está genuinamente melhorando de uma que está sonegando esforço: ela precisa de companhia. Lê-la junto com o Escopo entregue (quanto de tudo o que foi concluído, planejado ou não, foi entregue neste sprint) e a Mudança líquida de escopo revela a diferença: uma equipe que se compromete a menos de propósito tende a mostrar muito escopo "extra" entregue além do que planejou originalmente, o que é um padrão diferente de uma equipe cujo planejamento é genuinamente preciso. O Estado do fluxo mostra os dois números lado a lado exatamente por esse motivo, em vez de apresentar o Compromisso do sprint como um número que pode ser lido isoladamente.
Definindo uma meta que sua equipe realmente aceitou
O padrão de 80% é um ponto de partida, não uma meta que alguém necessariamente tenha aceitado. Todo KPI que o Estado do fluxo avalia, incluindo o Compromisso do sprint, tem uma meta editável por conjunto de equipes nomeado, definida no próprio painel de Metas do Estado do fluxo e compartilhada automaticamente com o Resumo da retrospectiva para qualquer sprint visualizado sob esse conjunto. Uma equipe que quiser um padrão mais rígido ou mais flexível do que 80% pode definir um, e duplicar um conjunto antes de alterar suas metas é uma forma rápida de testar um limite diferente sem perturbar o que todos os outros estão vendo.
Chegando lá
A confiabilidade do Compromisso do sprint precisa do mapeamento dos estágios do fluxo de trabalho da sua equipe definido na Configuração, para que o Agile Gauge saiba quais estados contam como concluídos. Compará-la entre equipes também precisa de um conjunto de equipes nomeado: uma lista salva de até 12 equipes da qual tanto o Estado do fluxo quanto o Resumo da retrospectiva podem escolher. Uma vez que ambos estejam prontos, o número é lido ao vivo toda vez que qualquer uma das telas é aberta.
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.