Qual a quantidade de tempo em que são feitas as reuniões do Scrum e qual o ciclo de iteração para a realização de um Sprint?

No último artigo abordamos os papéis do SCRUM, a importância de cada um respectivamente, o que faz e o que não faz e o que é e o que não é cada um. Agora, vamos iniciar uma sequência de quatro artigos abordando individualmente os 4 eventos do Framework Scrum:

No artigo de hoje veremos o primeiro Evento (ou Cerimônia ou simplesmente Reunião - a nomenclatura fica a gosto do leitor). Trata-se da Sprint Planning.

A primeira coisa que devemos entender é o que é um Sprint.

Para a utilização adequada do Framework Scrum, os projetos são divididos em ciclos curtos de no máximo quatro semanas, os quais denominamos de Sprints.

A Sprint é um espaço de tempo (fixo - não pode ser alterado no decorrer da Sprint) no qual atividades previamente acordadas devem ser executadas e concluídas.

Contudo, na prática, o que vemos é que os Times Scrum são mais inclinados a adotar Sprints mais curtas, optando por períodos de uma ou duas semanas.

MAS AFINAL DE CONTAS, O QUE É UMA SPRINT PLANNING, OU SIMPLESMENTE UMA REUNIÃO DE PLANEJAMENTO DA SPRINT?

Durante a Sprint Planning o Time Scrum produz um Backlog do Sprint que seja viável, o qual determina as histórias de usuários e as tarefas que o time irá implementar até o final deste Sprint, ou seja, o Incremento do Produto.

Uma Sprint Planning é composta de duas partes, a saber: “O que” e “Como”. Obviamente, como os nomes já sugerem, enquanto a parte do “O que” objetiva no que será desenvolvido no escopo, a parte do “Como” é direcionada em como o escopo será implementado.

Durante a Sprint Planning, imperativamente o Product Owner deve estar presente e ser ativo. Assim, ele pode responder questionamentos do Time Scrum e trazer esclarecimentos acerca dos requisitos e seus respectivos critérios de aceitação.

As partes interessadas, como usuários finais ou gestores, podem participar da Sprint Planning apenas como simples ouvintes para visualização. Em hipótese alguma eles podem influenciar o fluxo da Sprint Planning.

E QUAL É O OBJETIVO DE UM SPRINT?

O Product Owner define o objetivo da Sprint. Ele deve ser conciso e realista acerca do que o Sprint deve alcançar para os negócios, usuários finais e sistemas de TI. O objetivo da Sprint não deve ser técnico nem detalhado.  Queremos iniciar com um objetivo de alto nível do que queremos realizar e, em seguida, explorar as especificidades do que isso significa em termos de trabalho real. É imperativo termos em mente que o componente mais crítico de iniciar cada nova iteração é definir uma meta específica que o Time Scrum espera realizar no Ciclo de Trabalho que vamos iniciar.

A CAPACIDADE DA EQUIPE

A capacidade total do Time Scrum pode sofrer variações de uma Sprint para outra. Para fazer compromissos realistas, o Time Scrum precisa conhecer sua capacidade real para o próximo Sprint. Não existe “Vou tentar”, “Vamos ver”. Ou você faz ou você não faz! O Time Scrum imperativamente não deve prometer aquilo que sabe que não vai cumprir. No Framework Scrum, assim como na Abordagem Ágil, não existe espaço para heróis! Não basta fazer rápido. Tem que fazer certo e com qualidade para ser ágil!

O Time Scrum precisa considerar férias, feriados, tempo investido em Eventos Scrum e disponibilidade de tempo do profissional. Afinal, nem sempre podemos nos dar ao luxo de ter um profissional Full time no projeto. As tarefas do dia-a-dia precisam ser consideradas e, assim adicionar uma pequena gordura para os imprevistos, de modo a propor uma capacidade razoável (e realista).

A capacidade, o objetivo e o escopo são as três principais vertentes (condições) que devem ser equilibradas para que uma Sprint seja bem-sucedida.

Uma meta excessivamente ambiciosa pode forçar um Time Scrum a exceder sua capacidade.  E, da mesma forma, uma capacidade reduzida pode impossibilitar o alcance total dessa iteração.  O objetivo principal da Sprint Planning deve ser resolvê-los para criar um plano de Sprint que seja viável, eficiente e eficaz.

A PARTE DO “O QUÊ”

Uma Sprint Planning começa pelo “O quê” e requer um mínimo de preparação:

As responsabilidades dos papéis do Scrum durante o decorrer da parte “O quê” da Sprint Planning são os seguintes:

A PARTE DO “COMO”

O objetivo da parte do “Como” é abastecer o Sprint Backlog identificando as tarefas concretas necessárias para implementar histórias de usuários comprometidas para o Sprint. Essas atividades geralmente incluem, dentre outras, análise, design, desenvolvimento, teste, pacote de compilação de software e documentação.

Após identificarmos as atividades a serem concluídas, o Time Scrum estima essas tarefas. A unidade para esta estimativa pode ser pessoa-hora. Com base nessas estimativas, neste momento a equipe possui um direcionamento acerca de quanto tempo cada história de usuário consumirá de tempo para ser entregue.

SUGESTÕES PARA A REALIZAÇÃO DA SPRINT PLANNING DE UMA FORMA MAIS ADEQUADA

✅ Todos os eventos do Scrum imperativamente devem ser realizados dentro de um período de tempo pré-determinado, e a Sprint Planning, obviamente não deve fugir a regra. O Sprint Planning tem um prazo máximo de oito horas para um Sprint de um mês. Para Sprints mais curtos, a duração deste evento obviamente é mais curta. Como em tudo referente a abordagem ágil, as durações dos eventos são flexíveis. É fortemente recomendado a utilização do bom-senso.

✅ Em hipótese alguma devemos incluir mais entregas do que o time é capaz de executar durante a Sprint Planning. Uma vez que o Sprint Backlog é a priorização das ações a serem feitas dentro da próxima Sprint, devemos ter em mente que o nosso tempo é limitado e, consequentemente, não conseguimos entregar “tudo”. É imperativo que sejamos realistas na nas nossas previsões.

✅ Para diminuir o tempo investido para essa reunião, é fortemente recomendado o refinamento regular e efetivo do Backlog. Essa ação reduzirá exponencialmente o tempo dispendido no Planejamento da Sprint.

CONCLUSÃO

O objetivo de qualquer reunião de planejamento do sprint deve ser minimizar o tempo necessário para retransmitir e concordar com as informações necessárias.  É isso.  Nem mais nem menos.

Se a equipe for capaz de fazer isso e encontrar um ritmo rápido em que todos entendam e antecipem qual papel eles precisam desempenhar no processo de planejamento, isso se torna uma segunda natureza.  A equipe pode entrar, sair e voltar ao trabalho.

O planejamento de sprint não precisa ser difícil – nem demorado.

Mas, a equipe também deve resistir à tentação de interromper a reunião apenas por conveniência.  Essa é uma parte crítica de qualquer ciclo de desenvolvimento de software e define o ritmo e a expectativa para as próximas semanas.  Vale a pena investir um pouquinho mais de tempo para garantir que acertemos o mais príximo do alvo possível.

Com o plano e a abordagem mais adequados, podemos ter reuniões de Sprint Planning melhores, mais inteligentes, mais eficientes e mais rápidas sem preparar a equipe para um fracasso!

Grande abraço e até a próxima!

Qual o tempo da reunião de planejamento da Sprint?

Qual a duração máxima da reunião de planejamento Scrum?

Qual é a duração máxima da reunião de Sprint Review?

Quais são as reuniões do Scrum?