Que agenda uma reunião de
planejamento de sprint ideal deve seguir para ser
eficaz
A reunião de planejamento do sprint desempenha um
papel muito importante durante a implementação do
scrum. Ele precede a atividade real de corrida e é
atendido por:
O mestre scrum
Os membros da equipe de desenvolvimento
O proprietário do produto
As partes interessadas ou as pessoas que investem
recursos no projeto também podem participar da
reunião, se assim o desejarem. O encontro está
idealmente programado para durar oito horas. No dia
da reunião, o proprietário do produto chega à
reunião preparado com um backlog de produto bem
organizado e priorizado.
O backlog pode conter armazenamentos e tarefas de
usuários, como geralmente é a norma, mas também pode
conter apenas uma lista de requisitos conforme
decidido pelo proprietário do produto. O
proprietário do produto representa os interesses da
gestão e das partes interessadas, e possui
conhecimento sobre quais requisitos são mais
importantes e qual o peso que eles carregam em
termos de desenvolvimento. Ele ou ela prepara o
backlog do produto com base nas prioridades
associadas às histórias do usuário ou aos
requisitos.
Agenda da reunião de planejamento do sprint
A reunião de planejamento do sprint geralmente é
realizada em duas partes.
A primeira parte da reunião de planejamento do
sprint
A agenda seguida durante a reunião é simples e
direta - de acordo com as diretrizes especificadas
pelo guia do scrum. Poucas atividades simples, mas
importantes, são realizadas de acordo com a agenda.
Se o projeto for novo, ou se o sprint for realizado
pela primeira vez em relação ao projeto atual, o
scrum master apresenta os membros da equipe de
desenvolvimento e explica os papéis que eles
provavelmente desempenharão em relação à atividade
de desenvolvimento durante a corrida.
O proprietário do produto declara e descreve os
objetivos associados ao sprint e o que o sprint deve
realizar idealmente no final de sua iteração.
O proprietário do produto também pode oferecer
detalhes adicionais e explicar como as histórias de
usuários são importantes do ponto de vista das
partes interessadas e por que elas são tão
priorizadas.
Os membros da equipe têm a oportunidade de fazer
perguntas e buscar esclarecimentos sobre pontos
sobre os quais não estão claros. Eles também podem
fazer perguntas sobre as metas estabelecidas e podem
solicitar detalhes adicionais sobre os níveis de
aceitação e critérios especificados pelo
proprietário do produto e pelas partes interessadas.
O proprietário do produto revisa todo o backlog do
produto e discute as prioridades associadas às
histórias de usuários contidas nele.
Os membros da equipe podem fazer perguntas
relacionadas ao escopo de cada história de usuário.
Isso os ajudaria a segregar as histórias do usuário
em tarefas individuais mais tarde, quando
processassem o backlog do sprint para fins de
desenvolvimento.
Depois que o backlog do produto é cuidadosamente
explicado e todas as discussões relevantes são
realizadas, o proprietário do produto pode se
desculpar e deixar a reunião. A pessoa é, no
entanto, responsável por colocar-se à disposição
durante todo o dia para responder a perguntas e
fornecer esclarecimentos para dúvidas, à medida que
forem apresentadas pelos membros da equipe ou por
qualquer pessoa associada ao projeto e esteja
participando da reunião.
A segunda parte da reunião de planejamento do sprint
Durante a segunda parte da reunião, os membros da
equipe de desenvolvimento começam a processar o
sprint backlog. Um sprint backlog é o conjunto de
requisitos ou histórias de usuários selecionados
pelo proprietário do produto no backlog do produto.
O sprint backlog contém apenas as histórias que
devem ser desenvolvidas durante a atividade do
sprint. Normalmente, os membros da equipe se separam
ou segregam as histórias de usuários em tarefas de
desenvolvimento individuais.
Essas tarefas são posteriormente assumidas ou
aceitas por membros individuais da equipe por
motivos de desenvolvimento. No entanto, antes de
fazer isso, a equipe realiza atividades de
planejamento, e tenta chegar a estimativas adequadas
de quanto tempo cada tarefa levará, ou consumirá,
para ser desenvolvida em sua totalidade, ou seja,
quanto tempo cada tarefa levará para se desenvolver
completamente.
A equipe pode empregar qualquer um dos vários
métodos disponíveis sobre como o sprint backlog deve
ser processado para fins de desenvolvimento. Um dos
métodos mais comuns, também defendido pelo guia
scrum, é primeiro assumir tarefas que são mais
importantes e que carregam mais "valor", seguido por
outras tarefas que são de menor importância para os
stakeholders. A equipe tenta organizar ou completar
o sprint backlog de acordo com quantas tarefas cada
membro pode processar ou realizar durante o sprint.
É importante concluir com sucesso todas as tarefas
narradas no sprint backlog. Idealmente, nenhuma
tarefa deve permanecer pendente no final do sprint.
Os membros devem usar sua experiência enquanto
assumem as tarefas de desenvolvimento. Eles não
devem assumir tarefas adicionais que podem deixar de
concluir no final do sprint. Ao mesmo tempo, eles
não devem assumir menos tarefas, então eles ficam
sem "trabalho" durante a atividade do sprint.
É imperativo equilibrar ambos os aspectos - fazer
trabalho suficiente para que dure toda a duração do
sprint e concluir o trabalho na totalidade no final
do sprint. A tarefa e as histórias de usuário
desenvolvidas no final da iteração devem ser
"entregáveis" e ter um valor comercial associado a
elas.