O básico sobre Sprints no Scrum
O Sprint é um dos eventos do Scrum. Na verdade ele é a essência do Scrum e é o que o diferencia de outras metodologias como o Kanban, que tem um um fluxo de tarefas mais puxado e contínuo. O Sprint é um time-boxed determinado, de até um mês, onde o time vai executar suas tarefas, que no final será um incremento para o produto, entregando valor para o usuário.
Um novo Sprint é iniciado logo imediatamente a conclusão do Sprint anterior. Logo, não há um gap de tempo entre um Sprint e outro.
Cada uma das Sprints são compostas por alguns eventos: sprint planning, dailies, sprint review e retrospectiva da Sprint. Cada Sprint tem um objetivo específico, claro e que precisa ser acordado com o time de desenvolvimento. Durante o Sprint, não é permitido que alguma mudança possa colocar em perigo o objetivo do Sprint. Isso é feito para que o time não perca o foco no objetivo. O objetivo vai levar valor para o cliente e se desviar dele quer dizer que o usuário, muito possivelmente, não receberá um valor perceptível no produto.
O Objetivo do Sprint é tão importante, que o escopo pode ser renegociado com o Product Owner e o Time de Desenvolvimento conforme eles aprendem sobre as histórias que estão sendo desenvolvidas, para se adequarem melhor com o objetivo proposto pelo P.O.
O sprint pode ser cancelado?
Essa é uma dúvida muito, mas muito recorrente. Muitos acham que o Sprint é sagrado, que ele não pode ter alterações e principalmente não ser cancelado. Isso é mito. Já vimos que o escopo das tarefas do Sprint podem ser renegociadas com o P.O., e somente o Product Owner tem o direito de cancelar o Sprint. Por isso, se o objetivo decidido não tiver mais sentido, se surgir uma nova tecnologia que poderá ser aplicada no produto, se o mercado der uma reviravolta ou for descoberto um novo perfil de usuário etc etc etc… ele poderá descartar esse objetivo e definir outro. É por isso faz bastante sentido fazer Sprints de curta duração, para diminuir o risco de mudanças de planos repentinos.
É comum por aí ter Sprints de uma ou duas semanas. Acho que duas semanas é um tempo interessante.
Reuniões do Sprint
Como o Scrum é um processo empírico, ou seja, você precisa analisar o passado e as experiências vividas para tentar concertar os problemas e fazer melhor, num ciclo contínuo, existem uma série de reuniões de análise e descobertas, para que o time consiga entender o que fizeram de errado e quais as oportunidades de melhora.
As reuniões tradicionais, que estão descritas no manual são as seguintes, e devem acontecer nessa exata ordem:
- Revisão da Sprint passada
- Retrospectiva da Sprint da Sprint passada
- Reunião de Planejamento da próxima Sprint
Você não precisa fazer todas as três reuniões separadas, por que você vai perceber que elas podem representar momentos de uma mesma reunião. Nosso time aqui na firma faz a revisão e a retrospectiva da Sprint antes do Planejamento. Separamos uma hora para esses dois momentos, sobrando mais tempo para o Sprint Planning, que é o grande momento e o mais difícil dessas reuniões.
O pior entrave é a capacidade do time de estimar e quebrar tarefas grandes em tarefas menores, que caibam no tempo da Sprint. Talvez esse seja o maior exemplo de processo empírico que o Scrum pode trazer. Estimar tarefas nunca foi o forte dos desenvolvedores. Até mesmo desenvolvedores experientes tem dificuldades em dizer quanto tempo, mesmo que aproximado, quanto e qual o tamanho de uma determinada tarefa.
Estimar é opinar a respeito de algo de que não se tem certeza. O time não precisa saber exatamente o dia que determinada tarefa estará pronta, mas precisa saber aproximadamente, baseado na sua experiência passada. Quando alguém pergunta o prazo, não é a hora de agradar ninguém, é hora de dar uma data confortável para o projeto que talvez seja suficiente para execução da tarefa. É opinar sobre os problemas e tentar identificar as armadilhas daquela tarefa. O time não precisa ter certeza de quanto tempo uma tarefa custará se eles nunca a executaram nada parecido. A ideia de estimar é realmente esta: opinar uma data mais próxima possível da realidade. O time vai errar a maioria das vezes, pelo simples de que eles não tem uma bola de cristal.
Mas depois de algumas dessas reuniões, o time precisa saber quando uma tarefa está grande demais e precisa ser quebrada em partes menores.
O importante dessas reuniões, lembrando, é o processo empírico da evolução do time e do produto. Você precisa não cometer os erros do passado para que haja uma evolução do time, e que os incrementos do produto levem realmente valor para o usuário. O que é valor para o usuário? Só é valor se o usuário perceber esses incrementos? Aí é outra história, outro estudo, outro artigo.