A reunião de Sprint Planning é muito importante. Através dela, o time de desenvolvimento conhece o backlog e escolhe o que conseguirá desenvolver naquela sprint, gerando as tarefas necessárias para isso.
Para realizar essas ações, seguem algumas dicas percebidas ao longo de vários projetos realizados:
1. Apesar do Scrum Guide orientar que esta reunião, para uma sprint de 1 mês, possua 8h de timebox, sendo 4h para cada parte, sabemos que reuniões com essa duração podem ser improdutivas devido ao cansaço dos participantes.
Para minimizar isso, podemos implementar um gap de descanso entre cada parte desta reunião. Podendo ser esse gap uma pausa para o almoço, por exemplo.Dessa forma, podemos ter a primeira parte em 4 horas, das 9 as 13h, seguida do almoço. E na seqüência, a segunda parte da reunião, das 14 as 18h.
2. Realizar a Planning se possível no começo da semana. Motivo: com essa estratégia a equipe de desenvolvimento permanece com a explicação dos POs fresca na memória por mais tempo ao longo da semana, evitando consultas frequentes a documentacao. Lembrando que esse ponto vai de encontro ao fato natural de programadores não gostarem de ler documentacao. Fato!
3. Cobrar a participação ativa de todo o time durante a reunião.
Afinal, o comprometimento com a meta é de todos e não de um ou outro!
4. Para evitar distrações externas ao longo da reunião, podemos adotar a “caixa dos celulares“. Onde todos são depositados no modo vibração e retirados apenas após o termino da reunião.
5. Estimule a equipe a detalhar em conjunto cada Backlog escolhido, discutindo o esforço e a estimativa de cada tarefa. Isso permite q todos opinem e realmente entendam a dimensão de cada backlog.
6. Uma vez mapeadas, as tarefas devem ser escritas com as palavras do próprio time. Isso facilita o entendimento posterior do que a tarefa realmente significa.
7. A medidas que as tarefas forem emergindo, juntamente com suas estimativas, colha as mesmas em um repositório, algo como um excel ou o próprio Team System. Isso evita que tarefas se percam e que as horas produtivas da equipe sejam usadas ao máximo.
Related Articles:
- How to pass Professional Scrum Master I (PSM I) certification test in #6 steps
- Professional Scrum Master I (PSM) Simulated Exam Review
- Professional Scrum Product Owner (PSPO) Exam Simulator
- How to pass Scaled Professional Scrum (SPS) certification test in #6 steps
Permalink //
Eduardo!
Show de bola, esclarecedor… Mas tenho uma(s) dúvida(s):
No Sprint Planning o time está tendo contato com os itens do Backlog, ao estimar as tarefas é necessário um certo conhecimento do negócio para poder visualizar o esforço real necessário. Alguma documentação deve existir para auxiliar o entendimento do item do backlog?
Se sim:
Quais tipos de documentação são utilizados em uma abordagem ágil?
Em que momento essa documentação é produzida?
O time que produz a documentação está dentro de algum Sprint? Como ele é gerenciado?
É essa minha dúvida, meu time não consegue estimar correto no Planejamento da Sprint, pois o entendimento simplesmente não é claro neste momento.
Parabéns pelo blog, já estou seguindo!
Abraços!
Permalink //
Bom dia Eduardo. Vamos às respostas:
Sim, o SCRUM preve documentação para suportar o que deve ser desenvolvido. A documentação é essencial para o ciclo de vida do software, seja para permitir o correto desenvolvimento, seja para suportar os testes ou até mesmo para manter a regra de negócio do sistema atualizada em um documento.
1) O SCRUM prega que a documentação deve ser ágil no sentido de se criar somente os artefatos de documentação que realmente sejam necessários. Nada a mais ou a menos. Simples assim. Existem requisitos que podem ser explicados somente com user stories, outros podem precisar ainda de diagramas de sequencia, máquinas de estados, use cases e etc dependendo de sua complexidade.
2 e 3) Essa regra de Negócio deve ser colhida e gerada pelo Product Owner, que deve estar minimamente uma Sprint à frente da equipe de desenvolvimento, ou seja, enquanto a equipe está desenvolvendo a Sprint 01, por exemplo, o PO está escrevendo detalhadamente as user stories /requisitos que serão atacados na Sprint 2.
4) A primeira parte da reunião de planejamento da Sprint consiste no Product Owner (PO) explicar para a Equipe de desenvolvimento o que precisa ser desenvolvido. É neste momento que a equipe de desenvolvimento deve tirar todas as dúvidas possíveis sobre os requisitos antes de se comprometer com ele. Ainda na segunda parte da reunião de planejamento, onde o time detalha os requisitos em tarefas, o PO também pode participar para tirar possíveis dúvidas que ainda apareçam. Dessa forma garantimos que a equipe de desenvolvimento não terá dúvidas sobre regra de negócio ao longo da Sprint. E mesmo que isso ocorra, o PO deve estar 100% disponível para saná-las.
Espero ter ajudado com as respostas. Caso ainda exista mais alguma dúvida, por favor, não hesite em entrar em contato. E obrigado por se juntar à família GetScrum.com =). Abraços.
Permalink //
Olá,
Ajudou muito, fiquei apenas com uma ponta de dúvida:
Nosso analista de requisitos representa o papel do P.O. através do entendimento com nosso cliente ele cria os items de backlog e deverá fornecer a documentação necessária para o entendimento do time.
O fato dele estar minimamente 1 sprint a frente do desenvolvimento significa que ele está em alguma sprint? Por ex o desenvolvimento na sprint 01 e o P.O. na sprint 02?
Como devemos contabilizar as horas utilizadas com a produção de documentação e etc? Como é feito esse gerenciamento de esforço / entregas do P.O.?
Afinal ele faz parte do time, e seu trabalho faz parte de um esforço que soma ao prazo do projeto.
Abraços!
Permalink //
Boa pergunta, Eduardo.
O PO deve sempre focar em detalhar ao máximo os requisitos que serão atacados na próxima Sprint.
Sua missão é garantir que o time esteja trabalhando nos itens de maior valor de negócio e que também não faltem itens para o time desenvolver na próxima Sprint, ou seja, que o time não fique ocioso devido a falta de especificação.
Quando falamos de esforço, o Scrum trata essa variável somente em relação a equipe desenvolvimento, já que são eles quem de fato irão transformar os Product Backlog Items em Software Done.
De uma certa forma, o PO não deveria influenciar no prazo final do projeto, pois está sempre adiantado em relação ao time. Logo, teoricamente terminaria todo o seu trabalho, no mínimo, uma sprint antes da equipe de desenvolvimento.
Até hoje não vivenciei nenhuma situação contraria a isso. Mas já vivenciei projetos começarem a ser desenvolvidos somente após o PO estar com pelo menos uma ou duas sprints detalhadas. Dessa forma, caso o PO continue no mesmo ritmo, esse adiantamento deve ser mantido até o final do projeto.