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? 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
Perguntas frequentes
Como apresentar o status report de projetos ágeis para a gestão?
A gestão raramente acompanha o quadro Kanban no dia a dia, pois foca no resultado final e não na execução. Para apresentar o status em projetos ágeis, é preciso traduzir as informações em um formato simples, sem gráficos tradicionais como curva S ou cronogramas rígidos, focando em responder às preocupações reais dos executivos.
Quais passos seguir para montar um status report no meio ágil?
Para comunicar os resultados de times ágeis para quem está fora, defina o público-alvo, entenda suas preocupações profundas e mantenha a solução simples. Mapear as dores dos stakeholders permite estruturar reportes periódicos que qualquer pessoa da equipe consiga atualizar facilmente, garantindo transparência sem gerar sobrecarga de trabalho.
Como informar prazos e mudanças de escopo no formato ágil?
Quando o prazo é a maior preocupação da gestão, utilize o gráfico de burn-up combinado com o cone da incerteza, fazendo uma breve introdução explicativa no primeiro envio. Caso a apreensão seja sobre mudanças de escopo, a recomendação é apresentar o backlog devidamente priorizado e categorizado para dar clareza aos envolvidos.
O que fazer quando o projeto ágil possui dependências externas?
Se dependências externas forem um ponto crítico no projeto, apresente um quadro detalhando os impedimentos e indicando onde houve ou haverá impacto. Alinhe com os interessados que esse relatório é iterativo e incremental, devendo ser aprimorado continuamente a partir do feedback recebido nas divulgações do time.
Pronto pra dar o próximo passo?
Conheça os cursos da K21 e leve essas ideias pra prática com quem vive agilidade todo dia.
Ver cursos K21