A primeira métrica que eu gosto de olhar e ir atrás é justamente sobre o nível de qualidade que temos dentro dos nossos produtos, ou seja, saber quantos bugs (principalmente os conhecidos) nós temos em produção e depois que pegarmos essa informação, analisar juntamente com a área de negócios/produto, ou até mesmo com o pessoal do suporte/customer-care e darmos assim "nomes e valores" para cada um dos bugs, classificá-los e mantermos esses números sempre disponíveis para que todos possam ter ciência do tamanho do nosso "problema".
Uma dica sobre buscar essa informação é ter transparência e o mais importante, deixar claro que ter essa informação não é para expor ninguém, e sim para que com esses números, todos possam contribuir para melhorar a qualidade daquilo que fazemos e melhorar o sentimento dos nossos utilizadores.
Ainda as pessoas carregam o peso da desconfiança nas costas, então chegar e falar que vai pegar métrica disso e daquilo pode causar um mau estar entre as pessoas, então, para que esse mau estar não aconteça, seja claro com o objetivo de colher as métricas.
Vamos entrar em um ramo interessante e que precisamos ter cautela lembra (deixar claro que é pra ajudar na qualidade do produto), que é ter analisar as nossas entregas x a quantidade de bugs, mas o que eu faço por exemplo é não analisar se o bug é oriundo de uma entrega, porque pode deixar a gente meio retardado atrás de informação, mas o legal de analisar entregas x bugs é analisar o trabalho de uma perspectiva transversal, ou seja, no primeiro sprint tivemos 5 bugs em produção, e já no segundo sprint houve 4 bugs, ambos com 10 user stories, e assim vamos comemorar, pois diminuimos 20% da taxa de bugs do segundo em comparação ao primeiro e assim buscar uma meta, de reduzir a zero bugs por sprint, e assim conseguimos melhorar a nossa participação no processo de desenvolvimento e essa é uma maneira de motivar o time.
E lembrem-se que é necessário dar visibilidade a essas métricas =).
E então, conseguimos dar um pouco mais de previsibilidade.