Trabalhando com Scrum - Cerimônias

No post anterior, fiz a descrição de cada um dos papéis que compõem um time Scrum. Neste post, vou falar a respeito das cerimônias, descrevendo a definição do Scrum Guide e como eu costumo facilitar cada uma delas.

Posts da série:

• Trabalhando com o Scrum - Introdução
• Trabalhando com o Scrum - Papéis
• Trabalhando com o Scrum - Cerimônias
• Trabalhando com o Scrum - Artefatos
• Trabalhando com o Scrum - Exemplo de uma Sprint

Cerimônias Scrum

O Scrum prevê cerimônias para criar regularidade e minimizar a necessidade de reuniões não definidas pelo framework. Apesar de todas as cerimônias possuírem um timebox, elas podem acabar assim que o propósito é atingido, garantindo que o intervalo de tempo apropriado foi utilizado sem desperdício.

Timebox: intervalo de tempo definido para a duração da reunião

Cada cerimônia é uma oportunidade para inspeção e adaptação, não fazer qualquer uma delas resulta em falta de transparência. Particularmente, não gosto de ficar marcando reuniões extras para alinhar pontos que poderiam ter sido discutidos nas cerimônias previstas pelo Scrum. Depois que a cerimônia termina, espero que o time fique livre para trabalhar, sabendo que (no papel de SM) serei acionada caso necessário. Os produtos só serão desenvolvidos se o time possuir tempo disponível para produzir e, por isso, é tão importante reforçar com a organização a importância das cerimônias ágeis.

Apesar da definição dos papéis indicar que o SM facilita as cerimônias quando solicitado, gosto de assumir o papel de facilitadora. Na minha opinião, isso ajuda tanto o PO quanto o time de desenvolvimento a focarem no conteúdo e no objetivo das cerimônias, sem precisar se preocupar com o andamento das mesmas.

Sprint

A Sprint é o período de um mês ou menos onde um incremento de produto “Done”, utilizável e potencialmente entregável é criado. Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior e é formada por: Planning, Daily, trabalho de desenvolvimento, Review e Retrospectiva.

Em uma tradução direta, o Scrum Guide diz que a Sprint é um evento do Scrum. Traduzir “Scrum Events” como “Cerimônias do Scrum” é uma forma de manter os termos que utilizo no meu dia a dia. Dito isso, a Sprint é um evento do Scrum que contém todos os outros eventos, mas chamo de cerimônia somente os eventos contidos na Sprint.

Depois que uma Sprint inicia, a sua duração é fixa e não pode ser diminuída ou prolongada, mas ela pode ser cancelada antes do tempo previsto. Somente o PO pode cancelar a Sprint, mas essa decisão pode ser tomada por influência dos stakeholders, do time de desenvolvimento ou do SM. Cancelar uma Sprint é algo que deve ser feito somente quando o objetivo da mesma está obsoleto ou não faz mais sentido e de forma bem pensada e alinhada. O cancelamento da Sprint, além de ser traumático para o time, quebra uma rotina estabelecida e existe todo o trabalho de reunir o time novamente para revisar os itens que foram desenvolvidos e organizar o trabalho para a nova Sprint que será iniciada.

Stakeholders: são as partes interessadas no produto que está sendo desenvolvido.

Como citei anteriormente, dentro da Sprint temos diversas cerimônias. Segue a explicação de cada uma delas:

Planning

A organização do trabalho que será executado dentro de uma Sprint é realizado na Planning. Este planejamento é feito de forma colaborativa por todo o time. A cerimônia responde às seguintes perguntas:

• O que pode ser entregue como incremento de produto na próxima Sprint?
• Como vamos trabalhar para entregar esse incremento?

O timebox da cerimônia sugerido pelo Scrum Guide é de 8h para Sprints de 1 mês. O SM garante que a Planning será feita e que todos os participantes entenderão o seu propósito. Também é responsabilidade do SM ensinar o time a respeitar o timebox proposto para a cerimônia e isso pode ser atingido através da monitoria do tempo da cerimônia e de intervenções quando a discussão está desviando do objetivo.

Outro ponto que considero muito importante no papel do SM é o exemplo. Quem trabalha comigo sabe que respeito muito a pontualidade e sou incansável quando inicio com um time novo para que todos entendam a importância de estarmos disponíveis no horário.

Segundo o Scrum Guide, as entradas da Planning são:

• Product Backlog;
• Último incremento de produto;
• Capacidade de desenvolvimento do time em uma Sprint (capacity);
• Performance passada do time de desenvolvimento

Como SM, costumo basear o capacity do time em horas considerando um dia de trabalho produtivo. Por exemplo, se os integrantes do time de desenvolvimento trabalham 8 horas por dia, considero o capacity de cada um como 6 horas. Isso significa que estou considerando que 6 horas serão dedicadas para o desenvolvimento e as outras duas horas estão descartadas porque fazem parte de reuniões, intervalos ou até mesmo horas improdutivas, pois ninguém trabalha as 8 horas com o mesmo rendimento. Essas horas podem e devem ser adaptadas para cada contexto. Já trabalhei em times com 7 horas no capacity que funcionavam muito bem e times com 6 horas no capacity que não conseguiram performar pelo excesso de reuniões.

A escolha do número de itens do Product Backlog que entram na Sprint é de responsabilidade do time de desenvolvimento. Pois somente ele pode avaliar o que pode ser desenvolvido no timebox da Sprint. Conforme descrito nos papéis, é responsabilidade do PO criar, manter e priorizar os itens do Product Backlog, mas somente o time de desenvolvimento é capaz de dizer o quanto consegue produzir. Sendo assim, o time avalia os itens de acordo com a ordenação que o PO apresenta. Se, durante a Planning, o PO entender que algum item de valor ficou de fora da Sprint e precisa ser priorizado, ele pode negociar com o time para remover um item de tamanho similar e inserir o item desejado no Backlog da Sprint.

Product Backlog: contém todos os requisitos do produto.

Backlog da Sprint: itens do Product Backlog que vão ser trabalhados durante a Sprint.

Para a Planning temos alguns pré-requisitos (que valem basicamente para todas as cerimônias):

• No papel do PO: o Product Backlog deve estar com os itens em “Ready” e devidamente priorizados;
• No papel do SM: a cerimônia deve ter sido previamente marcada, o time deve ter sido informado a respeito do propósito e condução da cerimônia e todos os insumos necessários para a facilitação devem estar disponíveis;
• No papel de um integrante do time de desenvolvimento: deve ter ciência da cerimônia que será realizada e, caso não tenha, deve procurar o SM para entender os objetivos. Também deve estar preparado para discutir os itens do Product Backlog que serão selecionados para a Sprint.

Além de cada integrante ter a sua preparação para a cerimônia, também é importante ressaltar que o momento será mais proveitoso se todos tiverem atenção plena ao que está acontecendo. Sendo assim, é bom evitar demandas paralelas durante qualquer uma das cerimônias descritas.

Ready: itens do Product Backlog que possuem informações suficientes para serem compreendidos pelo time de desenvolvimento.

Ao consultar o Scrum Guide, você vai notar que a facilitação da Planning que vou descrever a seguir difere um pouco da definição oficial. Mas tenho bons resultados com esse formato e ele nasceu a partir de diversas retrospectivas. Então, sempre que inicio com um novo time, gosto de propor um formato que segue os principais pontos de sucesso que atingi com os times anteriores.

A Planning inicia definindo o capacity do time, mesmo tendo o valor fixo de 6 horas acordado. O ideal é confirmar se todos os integrantes do time de desenvolvimento estarão trabalhando durante a Sprint. Férias e folgas devem ser consideradas na cerimônia, pois impactam diretamente na capacidade de desenvolvimento.

Para ter o plano do que será desenvolvido na Sprint, o PO, como responsável pelo Product Backlog, deve ter o mesmo atualizado e priorizado para que seja utilizado como o insumo de entrada da Planning. Ele inicia explicando ao time o item prioritário do Product Backlog, de forma que todos entendam o que deve ser desenvolvido para considerar o item como “Done”. Depois deste entendimento, o time debate a respeito de como será o desenvolvimento para a entrega deste item. Para isso, tarefas são mapeadas e estimadas, nada muito específico, mas com detalhe suficiente para que um integrante do time de desenvolvimento possa iniciar a tarefa sabendo o que deve ser feito.

Na minha experiência, se a cada item do Product Backlog o PO explicar o que deve ser feito e o time quebrar em tarefas e estimá-las é bem mais benéfico do fazer somente algumas tarefas na cerimônia e deixar os restante para a Daily (definição do Scrum Guide). No post com o exemplo de uma Sprint, pretendo explicar melhor como facilito cada uma das cerimônias, mas já deixo adiantado que dá tempo de fazer a Planning dentro do timebox com um planejamento detalhado o suficiente para rodar a Sprint inteira. Gosto desse detalhamento porque times com pessoas com diferentes níveis de especialização (júnior, pleno e sênior) conseguem desempenhar o seu trabalho sem maiores problemas durante a Sprint.

Ao definir e estimar todas as tarefas de um item do Product Backlog, o PO explica o próximo item na lista de prioridade, o time define e estima as tarefas e assim por diante. Isto é feito até que se tenha todos os itens suficientes para uma Sprint definidos. Com as tarefas estimadas em horas, essa métrica é feita com a comparação do capacity total do time versus o total de horas estimadas nas tarefas.

Tendo feito a estimativa de todos os itens que “cabem” em uma Sprint dentro do período disponível, podemos considerar que a Planning está finalizada. Mas quando atingimos o objetivo e temos bastante tempo de sobra, gosto de estimar alguns itens a mais (caso tenha disponível). Não costumo usar todo o período da Planning nesses casos, mas tendo alguns itens extras estimados evitamos que o time fique parado caso termine o desenvolvimento dos itens antes do final da Sprint, sem ter que se reunir novamente para debates e estimativas.

Depois de ter todos os itens da Sprint definidos e estimados, o time define qual é o objetivo da Sprint. O objetivo é definido a partir do conjunto de itens selecionado para a Sprint, ou seja, qual é o incremento de produto que vai ser entregue ao final da Sprint. Com o objetivo definido, a Planning está concluída. Assim, nós temos um plano com o trabalho que está previsto para ser entregue ao final da Sprint e como este trabalho será desenvolvido.

Daily

Segundo o Scrum Guide, a Daily é uma cerimônia de 15 minutos que acontece em todos os dias da Sprint. A colaboração e a performance do time é otimizada através da inspeção do trabalho feito desde a última Daily e da previsão do trabalho a ser feito até a próxima Daily. Tudo isso focado no objetivo da Sprint. Um exemplo de perguntas sugeridas pelo Scrum Guide para facilitar a Daily é:

• O que eu fiz ontem que ajudou o time de desenvolvimento a atingir o objetivo da Sprint?
• O que eu vou fazer hoje para ajudar o time de desenvolvimento a atingir o objetivo da Sprint?
• Tenho algum impedimento que me impede ou impede o time de desenvolvimento a atingir o objetivo da Sprint?

Estas perguntas são somente uma sugestão do Scrum Guide. É possível fazer a Daily com um outro conjunto de perguntas ou até mesmo como um debate do time a respeito do trabalho em direção ao objetivo da Sprint.

Note que as perguntas são todas direcionadas para o objetivo da Sprint. A intenção não é microgerenciar as atividades da Sprint, mas sim garantir que o trabalho está sendo feito na direção correta. Com o time tendo o conhecimento de todas essa perguntas, ele pode iniciar a Daily sabendo o objetivo da cerimônia e cada integrante tem a oportunidade de fazer uma participação efetiva. A dinâmica previamente combinada é uma forma de aumentar a efetividade da reunião dentro do timebox.

Com 15 minutos, todos mantêm a atenção na cerimônia e é muito importante que todo o time tenha a escuta ativa. Também é tempo suficiente para que cada integrante possa fazer a sua contribuição na cerimônia. Assuntos que demandam mais tempo devem ser deixados para um pós Daily, envolvendo somente as pessoas necessárias.

Como comentei na definição da Planning, faço a quebra e as estimativa das tarefas na própria Planning. Nesse caso, a Daily pode ter questões como:

• A tarefa definida na daily não faz mais sentido;
• Estimamos tarefas extras;
• Faltaram tarefas.

Assim, a Daily também ajusta o que foi estimado na Planning, mas como todas as tarefas já foram discutidas, temos um ponto de partida para qualquer adaptação necessária. O envolvimento de todo o time para identificar estes desvios permite que o time se mantenha auto-organizado, trabalhando de forma colaborativa.

Esta cerimônia é feita por e para o time de desenvolvimento, mas o SM deve garantir que ela aconteça, deve apoiar o time na manutenção do timebox de 15 minutos e deve impedir que pessoas de fora do time desvirtuem a cerimônia. Como SM, costumo participar de todas as dailies, mas também deixo claro para o time que ela deve ser iniciada no horário independente da minha participação. Impedimentos levantados na cerimônia podem ser enviados posteriormente para mim e vou trabalhar neles durante o dia, a ausência do SM não pode ser usada como uma desculpa para não fazer essa cerimônia.

Review

De acordo com o Scrum Guide, a Review é feita no final da Sprint para inspecionar o incremento de produto e adaptar o Product Backlog, se necessário. O time de desenvolvimento colabora com os stakeholders a respeito do que foi feito na Sprint e todos os participantes da cerimônia colaboram para escolher o que pode ser feito em seguida para otimizar o valor gerado. A apresentação do incremento tem como intenção receber feedbacks e fomentar a colaboração. O timebox sugerido é de 4 horas para Sprints de 1 mês e é responsabilidade do SM garantir que ela aconteça.

Elementos da Review:

• Os participantes são o time e os stakeholders chave;
• O PO explica quais itens do Product Backlog estão em “Done” e quais não estão;
• O time de desenvolvimento discute sobre o que ocorreu bem durante a Sprint, quais problemas foram encontrados e como estes problemas foram resolvidos;
• O time de desenvolvimento faz a demonstração do trabalho feito e responde dúvidas a respeito do incremento de produto;
• O PO apresenta o Product Backlog atual. É feita uma projeção de entregas e datas prováveis com base no progresso atual;
• Todos colaboram a respeito do que deve ser feito em seguida, assim a Review gera valor para a próxima Planning;
• Revisão de como o mercado ou o potencial uso do produto pode ter mudado e qual é o item com maior valor que deve ser feito em seguida;
• Revisão do cronograma, orçamento e mercado para os próximos lançamentos de funcionalidades do produto.

Esta lista elenca todos os elementos esperados na Review de acordo com o Scrum Guide. Na minha experiência, diversos destes elementos são alterados ou, até mesmo não são considerados. É uma prática o time de desenvolvimento apresentar o incremento de produto e nem sempre temos apresentações, pois o incremento não é palpável para o negócio no momento da entrega. Mas achei importante elencar todos, a título de conhecimento.

Uma ótima dica que recebi de uma Agile Coach foi o uso de uma apresentação. Parece algo muito simples, mas ter um template para organizar a apresentação dos itens em seus diferentes status, ao invés de utilizar as telas da ferramenta de gestão fez muita diferença para mim. Não precisa ser nada muito complexo, uma apresentação de slides apresentando o objetivo da Sprint, os itens do Product Backlog em “Done” e os itens que não estão em “Done” já passa informação suficiente para os participantes. Costumo incluir também a lista de itens que estão previstos para a Planning da próxima Sprint e uma seção para iniciar os feedbacks. Caso nenhum feedback tenha sido fornecido durante a apresentação, o espaço fica aberto para as considerações de todos a respeito do incremento entregue.

Se algum item do Product Backlog que não está em “Done” não faz mais sentido para os stakeholders, ou até mesmo itens que estão previstos para Sprints futuras precisam ser priorizados para a próxima, esta cerimônia é uma oportunidade para que o PO possa receber essas informações e utilizá-las para rever o conteúdo e a priorização do Product Backlog.

Retrospectiva

O Scrum Guide define a Retrospectiva como uma oportunidade do time se inspecionar e criar um plano de melhoria a ser implementado na próxima Sprint. A recomendação é que a cerimônia tenha a duração de 3 horas para Sprints de 1 mês.

É papel do SM garantir que a cerimônia será feita e que os participantes entendam o seu objetivo. O SM também garante que a cerimônia é positiva e produtiva e a sua participação é como a de um membro do time, responsável pela qualidade do Scrum.

O propósito da Retrospectiva é:

• Inspecionar como a última Sprint foi em relação às pessoas, relacionamentos, processos e ferramentas;
• Identificar e ordenar os principais pontos positivos e as potenciais melhorias;
• Criar um plano para melhorar a forma como o SM faz o seu trabalho.

O SM deve encorajar o time a melhorar dentro do processo do Scrum, no seu processo de desenvolvimento e nas práticas para tornar a próxima Sprint mais efetiva e agradável. A cada retrospectiva, o time planeja formas de incrementar a qualidade do produto através da melhoria do processo de trabalho ou adaptando a definição de “Done”.

Existem diversos formatos de retrospectivas possíveis, mas costumo iniciar com os times utilizando o formato que analisa os pontos positivos, pontos negativos, sugestões de melhoria e elogios para os integrantes do time. Cada um destes itens é disposto em 4 colunas e os integrantes podem incluir as suas considerações em cada um deles, que são debatidas uma a uma.

Este formato de Retrospectiva é apenas uma sugestão de facilitação. Outras sugestões de facilitação podem ser encontradas no site FunRetrospectives e são tantas opções que acredito que consultar este material é a melhor forma para aprender sobre.

A Retrospectiva é uma ótima oportunidade para construir a confiança do time e isso é atingido considerando todas as sugestões que surgirem durante os debates. Toda ideia deve ser experimentada se o time estiver de acordo, mesmo que mude alguma definição do Scrum.

Claramente o parágrafo anterior expressa a minha opinião a respeito da cerimônia, mas acho válido reafirmar. Não podemos nos prender ao framework se algo evidentemente não está funcionando. Se o time confia na condução do SM e expõe o que não está funcionando, o mínimo esperado é que o SM esteja disposto a aplicar tudo o que for necessário para melhorar o dia a dia do time.

Ao final da cerimônia, é importante expor o plano de ação que será aplicado durante a Sprint seguinte para ter o acordo e ciência de todo o time. A partir da segunda Retrospectiva, podemos utilizar o plano de ação da Retrospectiva anterior para discutir se o plano de ação foi seguido e se todas as ações executadas foram efetivas.

Extra

O Product Backlog Refinement está dentro da descrição de artefatos no Scrum Guide. Ele é definido como o processo de adicionar detalhes, estimar e ordenar os itens do Product Backlog e é um processo contínuo durante a Sprint. Mesmo assim, costumo marcar reuniões com o time para a Backlog Refinement, como cerimônias mesmo. Assim, o PO tem um momento para conversar com o time a respeito do que está priorizado para as próximas Sprints e refinar o que está no roadmap do produto.

Roadmap do produto: plano com a evolução do produto.

Para a facilitação dessa cerimônia, eu sigo um formato muito parecido com o da Planning. Os itens do Product Backlog são apresentados e o time deve fazer as suas considerações a respeito do entendimento e viabilidade de cada item. E se algum pré-requisito é identificado, o PO tem tempo hábil para rearranjar o Product Backlog antes da próxima Planning.

Timeboxes em uma Sprint de 2 semanas

Geralmente trabalho com Sprints de duas semanas, então quando inicio com um time novo, que não tem calendário definido, gosto de iniciar com uma agenda padrão. Para definir essa agenda, considero as sugestões de timebox propostas pelo Scrum Guide, a ordenação das cerimônias e espaços na agenda para que o time tenha bons períodos livres para fazer o trabalho de desenvolvimento.

Os timeboxes para a Sprint de duas semanas são os seguintes:

• Planning: 04:00
• Daily: 00:15
• Backlog Refinement: 01:00 cada
• Review: 02:00
• Retrospectiva: 01:30

Esta agenda é somente uma sugestão, que você pode utilizar para guiar uma organização inicial com o time e também para visualizar como as cerimônias são ordenadas, de acordo com as orientações do Scrum Guide.

Esta foi a terceira parte da série a respeito do Scrum. Espero que os meus comentários a respeito das cerimônias tenham te ajudado a entender como funcionam as reuniões na prática ou a conhecer uma forma de facilitação diferente.

Espero que gostem e fico no aguardo dos comentários com críticas e sugestões!

Copiar link