Trabalhando com Scrum - Exemplo de uma Sprint

Nas últimas semanas, postei uma sequência de artigos a respeito do trabalho com o Scrum. Para finalizar esta série, vou tentar explicar como funciona uma Sprint na prática, unindo todas as informações anteriores. A ideia não é explicar tudo no detalhe, mas sim mostrar um resumo de como as cerimônias se relacionam com os artefatos e qual é a atuação de cada papel durante a Sprint em um único exemplo. Informações mais detalhadas podem ser encontradas nos posts anteriores da série.

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

Exemplo de uma Sprint

Para este exemplo, imagine o sistema de cadastro de clientes. Considere que já foi feita a Sprint 0, onde todos do time se conhecem e os ambientes de desenvolvimento estão devidamente configurados e prontos para que se inicie o trabalho. Na verdade, podemos imaginar que este exemplo está em qualquer Sprint do nosso produto, pois todas têm o mesmo objetivo: entregar um incremento de produto.

Antes da Sprint

Antes mesmo da Sprint iniciar, é necessário algum esforço para que seja possível que o time inicie as atividades da mesma. O SM deve ter todas as cerimônias agendadas com antecedência, o que permite que os integrantes do time possam se organizar para participar de forma satisfatória. Com isso, o time de desenvolvimento tem a visibilidade do andamento da Sprint e o PO pode estar preparado para apresentar o Product Backlog devidamente refinado na Planning.

Início da Sprint

A Sprint se inicia com a Planning, sendo assim, o PO deve apresentar o Product Backlog priorizado e refinado para o time de desenvolvimento, que vai tirar as dúvidas a respeito de cada item. Para o sistema de cadastro de clientes, podemos pensar em vários exemplos de itens para o Product Backlog, como:

1. Cadastro manual de cliente
2. Cadastro de cliente utilizando dados de redes sociais
3. Criação do banco de dados que persistirá os dados de clientes cadastrados

Assim que cada item é esclarecido, o time de desenvolvimento define e estima as tarefas necessárias para concluí-lo e considera-lo “Done”. Se o item 1 está sendo apresentado pelo PO, o time deve ser capaz de definir as tecnologias que serão utilizadas, se todos os pré-requisitos para criar o cadastro manual já foram desenvolvidos e quais são os passos necessários para atingir os critérios de aceite deste item.

Assim que todos os itens que cabem no período de uma Sprint foram debatidos e esclarecidos, é possível definir o objetivo da Sprint. Com o objetivo da Sprint e os itens selecionados, temos o Backlog da Sprint: uma estimativa do que será entregue ao final da Sprint.

Durante a Sprint

Durante a Sprint, o time de desenvolvimento se concentra em desenvolver os itens que foram selecionados na Planning. Para inspecionar o trabalho que está sendo realizado, o time se reúne diariamente para a Daily e verifica se os esforços necessários rumo ao objetivo da Sprint estão sendo feitos. Possíveis impedimentos e mudanças nas tarefas estimadas podem surgir e devem ser sinalizados.

O SM deve se manter atento aos impedimentos que são sinalizados pelo time de desenvolvimento. Grande parte do trabalho do SM envolve permitir que o trabalho possa fluir, tendo como responsabilidade do seu papel a remoção de impedimentos com o menor envolvimento possível do time.

Enquanto o desenvolvimento acontece, o PO deve ser manter disponível para tirar eventuais dúvidas. Mas durante a Sprint, o principal trabalho torna-se validar se o Product Backlog se mantém atualizado e com itens que farão o produto evoluir junto com o mercado.

Pensando na Sprint seguinte

Enquanto a Sprint está em andamento, o PO pode ser apoiado pelo time para refinar o Product Backlog. Porém, isso deve ser feito de forma que não atrapalhe o trabalho da Sprint atual. Refinar os itens do Product Backlog junto ao time permite que todos estejam alinhados com o trabalho que está previsto e antecipa problemas que poderiam acabar removendo o item da próxima Planning por falta de tempo ou conhecimento para esclarecimento.

Final da Sprint

Ao final da Sprint, é feita a Review, onde todo o trabalho desenvolvido é apresentado. A cerimônia deve dar a visibilidade de todos os itens em “Done” e também de todos que não foram concluídos. O feedback da entrega é baseado no resultado atingido pelo time, por isso até mesmo o que não foi finalizado deve ser apresentado.

Para finalizar, é feita a Retrospectiva, onde o time avalia todos os pontos positivos e negativos da Sprint que está sendo encerrada. É muito importante conferir se o plano de ação gerado na Sprint anterior foi posto em prática e, baseado nisso e nas discussões geradas, criar o plano de ação para a Sprint seguinte.

Depois de todas as cerimônias concluídas, é hora de iniciar uma nova Sprint, ou seja, um novo ciclo de desenvolvimento, inspeção e adaptação para gerar incrementos para o produto. Enquanto o produto estiver sendo desenvolvido, as Sprints seguem rodando e o Product Backlog segue evoluindo, direcionando este desenvolvimento.

Esta série foi, em grande parte, uma tradução do Scrum Guide. Mas a minha intenção foi a de trazer práticas do meu dia a dia em paralelo com as definições do framework. Espero que tenha sido um material esclarecedor e que ajude quem está iniciando ou até mesmo dê uma nova perspectiva para quem já conhecia.

Como sempre, deixo a caixa de comentários aberta e o meu contatos para sugestões.

Até a próxima!

Copiar link