Status Report é o marco zero do Roteiro de Review

Eu chamo de ROTEIRO o artefato que implanto em equipes ágeis, construído por cada equipe ao final de cada sprint para nortear cada Sprint Review. O primeiro passo do roteiro é uma proposição de Status Report, que pode sofrer ajustes por adendos ou percepções dos presentes, quer positivas ou negativas.  \o/

Se você pratica o método SCRUM, cada sprint possui normalmente 2 semanas, inicia pela confirmação das histórias previstas para ele, momento em que a equipe recebe e entende melhor cada uma, quebra em tarefas, confirma e durante 10 dias úteis as constrói. Ao final faz a review ou demo, apresentando aos stakeholders o que foi feito e o que aconteceu neste período, terminando com a retrospectiva.

Vou aqui focar na Sprint Review, conhecida por alguns como Demo, uma reunião em que a equipe encontra-se com seus stakeholders para um realinhamento estratégico a partir da apresentação do momento do projeto e aquilo que foi feito neste sprint que agora encerra, ocorrências. Este ritual converge para um Status Report, em comum acordo entre todos os envolvidos, que pode e deverá ser enviado a aqueles que não puderam se fazer presentes.

Porque chamo de ROTEIRO? Chamo de roteiro porque é essencial que o time prepare-se para a REVIEW, normalmente os passos de 1 a 5, depois de 7 a 9, é de alçada colaborativa do PO, SM e/ou GP. Cada empresa possui seus padrões de status report, que são referendados pelo PMO, governança ou GP’s, de forma a haver uma comunicação de igual conteúdo e valor em todos os projetos.

Faça uma facilitação visual, com os quadros e métricas que serão apresentadas, mas também desde o início crie um quadro de TO DO List para aquelas tarefas que vão aparecendo, solicitações do cliente, endereçamentos, acionar alguém, providenciar algo, assuntos que são de outro fórum, etc 🙂

1. Boas vindas;
2. Quem está ali presente (e ausente);
3. Onde estamos? Qual o sprint e se cumprimos a meta;
4. Apresentação das histórias (*);
5. Apresentar eventuais métricas utilizadas;
6. Solicitar feedback e alinhar eventual status para report;
7. Agradecimentos e encerramento.

(*) O ítem 4 é a essência da REVIEW e onde o maior tempo é dedicado, pois é onde materializamos vários dos princípios ágeis e alinhamento de pressupostos e percepções entre todos os envolvidos. É preciso definir previamente quem vai apresentar qual história, para que cada um prepare-se minimamente e monte seu script de cenários a serem demonstrados.

É uma questão de RESPEITO com nossos stakeholders, somos ágeis e não jóqueis (go horse). É preciso preparar-se e testar os cenários que pretendemos apresentar, com todos os dados e detalhes relevantes, quer para não esquecer, como para não cometer gafes ou mesmo descobrir erros na frente do cliente.

É sugerido fortemente e acredito muito que cada história pode e deveria ser apresentada por um dos integrantes do time, quem mais se envolveu ou à escolha deles. É uma forma de intensificar o senso de pertença e responsabilidade sobre o que estamos construindo e entregando. O ítem 7 tem:

7. Apresentação das histórias:
7.2. Cada história é brifada na essência, com roteiro próprio;
7.3. O roteiro deve ter cenários, códigos e operação desejados;
7.4. Ao final confirmar o entendimento, dúvidas e sugestões.

Aproveito para relembrar o conceito de ciclo simples (mais afeito ao método kanban e equipes muuuuito pequenas), o ciclo duplo que valoriza ao máximo o conceito e compromisso de PRONTO, além do ciclo triplo em que testes ou aceitação ficam fora do sprint, gerando normalmente entregas incompletas.

Os três modelos podem funcionar, mas o ciclo duplo é o que mais estabilidade e conforto gera na construção de valor com qualidade dentro de prazos e custos, por isso mesmo me esforcei muito até encontrar uma representação gráfica que explicitasse categoricamente as fases concomitantes de discovery e delivery.

O entendimento do que é o ROTEIRO e o quanto ele subsidia e materializa colaborativamente o Status Report é essencial para um bom fluxo de informações para permanente alinhamento entre todas as partes envolvidas.

Minha recomendação é que o Status Report decorrente da reunião de REVIEW, 100% consequente do roteiro e as discussões proporcionadas por ele pode e deve ser enviado a todos as partes interessadas que se habilitaram ao seu recebimento após a realização da REVIEW, RETRÔ e SPRINT PLANNING seguinte.

Digo isso, porque são três timeboxes que acontecem uma após a outra em um intervalo de no máximo 8 horas úteis, assim evitamos enviar o Status Report após a REVIEW ou após a RETRÔ, sabendo que  haverá uma reunião tão significativa uma ou duas horas úteis a seguir e que pode gerar informações relevantes, confirmando ou contradizendo o que já temos, por pressa em algumas horas.