Comunicação Ágil
Para um projeto ter uma boa comunicação ágil a informação precisa estar disponível para todos, ser de fácil acesso e simples. Manter as informações em um local visível, contribui com todos envolvidos ao projeto, mas principalmente ao time da Sprint.
Um dica muito útil é não duplicar a informação em diferentes relatórios, não crie um relatório para o Time da Sprint e outro para os stakeholders.
Mantenha uma comunicação única, transparente, simples e de fácil acesso!
Fazendo um único relatório você diminui os ruídos que possam existir, garanta que todos estão acompanhando as mesmas informações e você não terá a dor de cabeça de manter dois ou mais relatórios diferentes. Portanto, utilize os mesmos relatórios para comunicar-se com o time da Sprint e com os stakeholders do projeto. Foque nas informações, nos avanços conquistados e sempre comunique alterações no projeto.
Transparência é um item fundamental em projetos ágeis, para isso é importante que o Product Backlog esteja priorizado e com informações suficientes para que o time de desenvolvimento consiga entender o que deve ser feito e este é o nosso primeiro relatório, podemos chamá-lo de Taskboard.
O Taskboard é útil para dar visibilidade aos próximos itens a serem desenvolvidos, permite que a equipe se organize ou se prepare para a próxima Sprint.

O próximo item a ser utilizado na comunicação é o Burndown. Com ele é possível acompanhar diariamente se as ‘histórias de usuário’ estão sendo concluídas dentro do tempo definido para a Sprint.

Neste gráfico de Burndown, temos o total de pontos definidos para a Sprint (50 pontos), onde a quantidade de atividades restantes ideal por dia é representada pela linha azul e a linha laranja representa a situação real (realizado).
Este gráfico é geralmente enviado pelo Scrum Master a todo time da sprint. É importante que este envio seja feito diariamente para que todos possam acompanhar o andamento.
Faça o envio dos relatórios diariamente e preferencialmente antes da Daily Sprint
Por último e não menos importante temos o Release Burndown. Parecido com o Burndown, a principal diferença é que sua atualização ocorre ao término de cada Sprint.
Geralmente este relatório interessa mais aos stakeholders, pois oferece uma visão geral de todo o projeto.

Com base nos refinamentos realizados e a capacidade média da equipe é possível determinar quantas Sprints serão necessárias para entregar todos os recursos.
No modelo acima temos um total de 300 pontos para criar os recursos necessários e a equipe possui uma capacidade de queimar 30 pontos por Sprint, sendo assim, é possível determinar que serão necessárias 10 Sprints para que todo o trabalho seja concluído. Logo é possível sabermos a data de início e término do projeto.
Uma boa prática para acompanhar o projeto é a criação de marcos do projeto, também conhecido como milestones. Os marcos não são tarefas e não possuem duração, são criados como etapas que marcam a conclusão de parte do projeto.
Considere adicionar ‘milestones’ ao seu projeto, eles ajudam a determinar as etapas de forma simples e clara
Como está a comunicação do projeto dentro e fora da sua equipe? Se você faz algo diferente, coloque aqui nos comentários.
