Status Report também pode ser um artefato Ágil

Vamos supor que você adotou SCRUM, realiza de forma consistente o framework e algumas boas práticas do XP e Kanban, executa com sucesso técnicas de visão, release mapping, gera seu product backlog, sprint planning, usa um bom quadro de tarefas e faz suas diárias, review e retrospectivas.

Aos poucos o Product Owner, Scrum Master e equipe de desenvolvimento vão pegando o jeito, entregando valor em ciclos iterativos-incrementais, há um esforço em disseminar boas práticas nas outras áreas da empresa, tudo vai bem, mas alguns stakeholders não estão confortáveis com a mudança.

Ao contrário de vocês, eles não estão no dia-a-dia, talvez nem consigam participar das reviews conforme gostariam e é preciso levar em consideração as pesquisas internacionais que indicam como sendo o maior temor dos executivos perder o aparente “controle” que eles achavam que detinham nos seus projetos.

Status Report

Esta introdução é para contextualizar a legitimidade em prover um artefato gerencial relevante, que mantenha os envolvidos e interessados informados do andamento do projeto. Fácil, recorra aos princípios do plano de comunicação sugerido pelo PMBOK, quem precisa ou gostaria de acompanhar cada projetos.

A partir desta definição, em uma grade tão viva quanto qualquer artefato ágil, posto que novos envolvidos ou interessados podem surgir ou trocar no transcorrer do projeto, enviaremos um status report pré-acordado, passível de melhorias de valor, a cada novo sprint.

Os melhores momentos são após o exercício de Visão, Release Plan e a cada Sprint Planning. Mas porque após o Sprint Planning e porque não relacionei a Review? Simples, porque o tempo que separa uma Review de um Planning são algumas horas úteis, normalmente na manhã do dia seguinte.

Assim, ao realizar a Review no final de cada Sprint há presumidamente um realinhamento entre os envolvidos, apresentação do que foi feito e contexto do último sprint, previsão do que será feito no próximo Sprint e um realinhamento estratégico e tático geral do projeto – datas, riscos, oportunidades, dúvidas, …

No dia útil seguinte realizamos o próximo planning e pactuamos o Sprint Backlog a partir das User Stories selecionadas pelo Product Owner, a equipe as entende, estima e confirma o que é possível fazer. Ao encerrar é possível enviar um Status Report com a revisão feita na última Review e já contendo uma perspectiva realinhada e pactuada para o próximo Sprint.

ciclo - status report

O conteúdo de um Status Report é um resumo claro e cumulativo, evolutivo a cada Sprint realizado, contendo datas, pontos de esforço e/ou horas mapeadas no início do projeto, repactuadas a cada novo Sprint Planning e entregues ao final de cada Sprint. A seguir o exemplo de um projeto recente (distorci alguns nomes e dados):

status report censurado

Temos relacionados os nomes do Time e key-users, uma grade contendo o planejamento de releases e sprints conforme planejado inicialmente e execução, gerando com estes dados um ou mais gráficos, além disso temos um relato assertivo de cada nova Sprint (este exemplo é o último Status Report enviado).

É simples, fácil e ágil, cumulativo, a cada Sprint é preciso incrementar apenas alguns dados atualizados e um relato resumido sobre o sprint que encerrou e se algo mudou para o próximo … se você não faz, experimente fazer, você vai ficar surpreso com os resultados em termos de alinhamento e melhor entendimento.

Posta aqui comentários dizendo se valeu a dica ou não … se você já pratica, aceito dicas de outros formatos, se você acha que isso é heresia, coloca teus argumentos. Boa sorte!

Anúncios

9 Respostas para “Status Report também pode ser um artefato Ágil

  1. Concordo e muito Jorge. Hoje rodamos SCRUM aqui. Quando o projeto é interno, a comunicação flui tranquilamente. Mas temos projetos que são modelo serviço. Nesse caso, sempre tem um cliente/stakeholder que não pode viver o dia a dia do projeto, e algumas vezes precisamos do status report que acaba mudando um pouco a dinâmica do nosso processo.

    Eu ia pedir, se não for muito, para colocar uma imagem com maior resolução. Ficou um pouco difícil de entender a segunda imagem.

    Abraço.

  2. Concordo com o comentário do Bruno, também não consegui ver a imagem!
    Abraços!

    • Coloquei ao final do post uma imagem maior, após censurar as informações, pois são de um dos projetos. A formatação é fruto de uma negociação sobre dados, forma e nomenclatura a serem utilizadas. Espero que seja útil.

  3. Muito bom artigo Jorge. Visibilidade é muito importante em um projeto. Principalmente, para o alto escalão de uma organização. Parabéns!

  4. Baita artigo Jorge.

    O Status Report é uma ótima ferramenta para se ter visibilidade e comunicação entre a equipe do projeto e os stakeholders que não conseguem participar ativamente no cotidiano da equipe, mas que precisam ter dados/resultados que demonstrem a evolução do projeto, para que seja possível justificar a manutenção ou maior investimento do projeto.

    Parabéns.
    Abraço!

    • É uma necessidade que fica mascarada no esforço do PO em manter os stakeholders ausentes nas reviews devidamente informados … acaba resolvendo de forma elegante, vários interessados e não envolvidos acabam por pedir que sejam copiados, ajudando na afirmação do método e boas práticas de GP.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s