Projeto começando e precisamos planejar, mas por onde começar?

• Como é feito uma Planning do Scrum?
• Quem participa desse evento (cerimônia) e quanto tempo ela dura?
• É necessário ir com algo pronto para ela?

Muitas perguntas surgem nessa hora, é normal… Mas vamos contar um pouquinho como fazemos por aqui.

Quando iniciamos um projeto e vamos para a primeira Planning, precisamos de algumas primícias.

O Product Owner constrói o Product Backlog com as histórias de usuários (técnica de mercado usada para levantar os requisitos necessários de um produto) devidamente priorizadas de modo que agregue valor ao cliente. Geralmente, essa priorização é feita com um conceito de MVP (mínimo produto viável) e existem N técnicas que podem ser usadas para fazer essa priorização, por exemplo, Moscow, GUT, comparação, matriz de importância e conhecimento técnico, entre outros.

Após ter o Product Backlog (confira nosso artigo de como montamos um Product Backlog) montado e priorizado pelo Product Owner, ele juntamente com o Scrum Master e o time de desenvolvimento, fazem o refinamento (usa-se até 10% do tempo do time Scrum) de algumas histórias que entrarão na Sprint a seguir.

Esse refinamento pode ser feito de várias formas, afinal o Scrum não dita nem técnicas e nem ferramentas, mas por prática costumamos usar as 7 dimensões do produto (ator, ação, interface, dados / informações, regras de negócio, qualidade (critério de aceite) e ambiente que o produto vai executar (se analisarmos as histórias o “ator” e a “ações” nós já temos nas histórias, o que facilita esse processo).

Na Planning participa o Product Owner, o Scrum Master e o time de desenvolvimento, e ela é dividida em duas partes, O que fazer e o Como fazer.

O que fazer é decidido pelo Product Owner de acordo com o que ele priorizou no Product Backlog, e ele participa para que todas as dúvidas do time sejam sanadas.

O Como fazer é decidido pelo time de desenvolvimento e ninguém, nem mesmo o Scrum Master diz ao time como transformar o Product Backlog em incrementos de funcionalidades potencialmente liberável. Eles estimam as histórias que o Product Owner priorizou. Uma das formas para estimar é o Planning poker que é uma técnica que usa a sequência de Fibonacci e o time determina em pontos (1, 2, 3, 5, 8, 13, entre outros até mesmo uma carta (símbolo de infinito) que mostra que a história está impossível de mensurar, tem outra com a figura de uma xícara de café que é usada quando o time fica cansado e precisa de uma pausa e outra de interrogação, quando ainda restam dúvidas sobre o assunto abordado na história) que significa a complexidade para realizar cada história.

O Scrum Master faz um cálculo de velocidade (outra técnica de mercado) se baseando no tamanho da Sprint para saber quantos pontos a equipe é capaz de realizar naquela Sprint. Após isso, o time pega as histórias priorizadas até a capacidade que eles podem realizar e chegam em nível de tarefas, as quais normalmente são organizadas em um quadro para gestão a vista e o mais usado pelos times é o proto Kanban com as colunas que representam o processo que precisa ser seguido para entrega das tarefas feitas (geralmente encontramos quadros com as seguintes colunas: “A fazer”, “Fazendo”, “A testar”, “Testando”, “A homologar”, “Homologando”, “Impedimentos”, “Feito”).

Esse conjunto de tarefas determinadas pelo time é chamado de Sprint Backlog, e quem controla ao longo da Sprint é o próprio time de desenvolvimento, somente eles adicionam ou retiram tarefas, além de ninguém, nem mesmo o Product Owner e o Scrum Master dizer à eles como devem trabalhar.

Com base no Scrum Guide, uma Planning para uma Sprint de 30 dias tem duração de até 8 horas. Mas, você pode se perguntar, e para sprints menores?

O mercado adaptou e, provavelmente, você já deve ter visto por aí que as sprints são de 2 a 4 semanas, mas tudo isso surgiu porque na engenharia de software tem um estudo que diz que não é possível entregar nenhum incremento de valor com menos de 2 semanas. Logo, essa adaptação ficou da seguinte forma:

• Sprint de 4 semanas a Planning tem duração de 8 horas;
• Sprint de 3 semanas Planning de 6 horas;
• Sprint de 2 semanas Planning de 4 h.

Até mesmo as outras cerimonias ficaram proporcionais.

Ainda na planning, o time scrum determina qual é a Definição de Concluído (conhecida também como “Definition of Done”) para aquela Sprint e todos precisam chegar em um acordo para que no final não tenham problema onde o Product Owner pergunta: “E aí tá pronto?” e o time responde: “Tá pronto, só faltar testar”. Afinal, tá pronto ou falta testar? Essa definição é de suma importância para deixar todos alinhados.

Para finalizarmos este artigo, é importante saber que no final deste evento (cerimônia) é esperado dois resultados: o Sprint Backlog e a Meta do Sprint.

Obrigada por terem ficado com a gente até aqui.

Um abraço,

Amanna Monteiro