Como faço o status report de projetos ágeis? Quem nunca ouviu essa pergunta que ataque a primeira pedra neste post, rs…
Agilidade não é mais uma tendência ou moda, é um fato. As grandes corporações já aderiram ao ágil no caminho de aumentar o retorno sobre os produtos, diminuir a cultura do “monitoramento e controle” e aumentar a COLABORAÇÃO. Porém, geralmente não temos todos os níveis da organização “colando os post-its na parede” e é aí que pecamos na TRANSPARÊNCIA.
…”Tá tudo no quadro kanban, é só o pessoal dar uma olhada”…
Status Report em projetos ágeis
Diálogo comum por aí…
- Time diz: Podemos trazer esse pessoal pra entender o nosso quadro?
- PMO diz: Claro que podemos, seria perfeito, mas eles querem?
Ps.: usei o PMO como exemplo pois geralmente eles são os vilões dos status, né? Tomei a liberdade de brincar com isso pois eu sou uma ex-PMO com muito orgulho, rs…
A questão é que a gestão topa a transição ágil e está ansiosa pelos resultados, pois só ouve falar bem por aí, MAAAAAS será que eles toparam também ler o quadro kanban ao invés de receber o status? Normalmente, não. O foco deles está em “o resultado está garantido?” e não no “como você fez isso?” (refletido no quadro kanban).
Mas tudo bem, essa é uma boa oportunidade de mostrar para a gestão que temos outras formas de acompanhar o status de um projeto: sem cronograma, curva S, SPI, contador de change request, etc. E tem mais, é uma oportunidade de comunicar a inovação! Afinal, adianta fazer algo legal, mas ninguém ficar sabendo? Temos que sair da caverna e gritar para todos os lados: olha o que estamos fazendo! É legal! E isso vai ser bom pra vocês também!
Até aqui eu tentei convencer vocês, Scrum Master, Product Owner e Time, que é importante contar o que vocês estão fazendo no ágil, pois são vocês que vão disseminar a CULTURA e os processos.
Encapsulando o resultado do time
Agora, vamos falar de como encapsular os resultados que temos dentro do time para quem está fora do time:
1. Defina o público-alvo porque o conteúdo relevante pode mudar dependendo do público.
2. Entenda quais são as preocupações do público-alvo e do time porque são com elas que você terá as respostas certas. Ou seja, aqui entra a arte de entender os porquês (#loveTheProblem).
3. Pense simples porque o reporte terá uma periodicidade de divulgação e qualquer um do time poderá atualizar.
Na prática, a dificuldade está no Love The Problem (confira nosso podcast), pois quando falamos com o público, a resposta deles é uma solução (quero o cronograma, a projeção dos custos…) e nós precisamos descobrir quais são as preocupações atrás desses pedidos para montar uma solução junto com o time.
Algumas ideias que vocês podem testar:
Quando o prazo for uma grande preocupação
Podemos usar o burn-up + cone da incerteza:
Colinha para montar o gráfico acima no Power Point:
IMPORTANTE: na primeira vez que a gestão ver o reporte, faça uma introdução explicando o porquê e como ler os novos gráficos.
Quando a mudança de escopo for uma preocupação
Traga o backlog priorizado e categorizado:
Baixe o arquivo com o gráfico Burn-Up e o Cone da Incerteza
Quando a opinião do cliente é uma preocupação
Temos métricas específicas de produto. O Magno falou sobre elas no post “6 dicas para definir métricas de sucesso para seu produto”.
Quando dependências externas são uma preocupação
Traga um quadro com impedimentos e aonde impactou/impactará.
Vale lembrar que temos que ter cuidado com as métricas que utilizamos pois elas vão moldar o comportamento do time. O Avelino falou mais sobre isso no post Métricas: como medir a Agilidade do seu time! Entenda quais métricas usar de acordo com o objetivo que quer alcançar.
Ah! Não podemos esquecer da melhoria contínua né, galera! Alinhe com os envolvidos que essa é a versão inicial, ela é iterativa e incremental. Colha os feedbacks e melhore na próxima 
Quer saber mais sobre tema satus report? Veja os links abaixo:
- Veja mais práticas no nosso treinamento de Certified Scrum Product Owner (CSPO)
- Quer conhecer mais métricas ágeis? Métricas: Como medir a agilidade do seu time.
- Saiba que “Quando fica pronto?” não é a pergunta mais importante
- Leia também muitas outras dicas no Livro Scrum do Rafael Sabbagh
