Scrum: o primeiro Sprint a gente nunca esquece

Por Cesar Brod

Data de Publicação: 30 de Outubro de 2014

Quando uma equipe Scrum já está azeitada, trabalhando com produtividade extrema, a escolha de histórias do Product Backlog que serão trazidas para o Sprint Backlog é trivial. É pegar aquelas de maior prioridade em um volume compatível com a velocidade da equipe e pronto. Quando se trabalha com uma equipe Scrum recém formada, entretanto, mais importante do que pegar, na ordem, as histórias de prioridade alta, é permitir que a equipe adquira seu ritmo.

O elemento mais importante do Scrum, o que servirá como a base para todos os demais, é o ritmo. Os ritos, como a reunião diária, a duração fixa da Sprint e as reuniões de revisão e retrospectiva servem como marcações desse ritmo. O Scrummaster, ao garantir que os ritos sejam cumpridos, serve como o maestro para a equipe e remove os obstáculos que possam comprometer o ritmo.

Assim, quando da escolha das histórias que serão transformadas em tarefas durante as primeiras Sprints, o Product Owner deve permitir que a equipe escolha aquelas que tem um altíssimo grau de certeza de que possam ser concluídas, mesmo que elas não estejam no topo do Product Backlog. Essas histórias devem, entretanto, ser significativas, adicionar valor como um incremento do produto e serem demonstráveis.

Tarefas típicas para os primeiros Sprints são, por exemplo, a construção de interfaces de usuário que permitam ao cliente alguma interação, para que ele já tenha uma ideia do "jeitão" do que será desenvolvido e possa começar a colaborar com o seu desenvolvimento e com o aprimoramento do Product Backlog (Product Backlog Grooming).

Insisto que o Scrum tem a ver com atitude e que, no desenvolvimento de software, ele deve ser acompanhado de um método de engenharia como o Extreme Programming (XP). Em novas equipes Scrum, logo a partir da primeira Sprint, boas práticas do XP como a programação em pares e o desenvolvimento baseado em testes devem ser utilizadas.

É irreal achar que uma equipe Scrum será montada com a finalidade única de aprender o Scrum e o Extreme Programming e, só então, usar o conhecimento adquirido para começar a desenvolver algo. O que mais tenho visto é empresas decidirem dar uma chance ao Scrum usando equipes existentes ao iniciar um novo projeto - tipicamente depois que tiveram decepções ao não conseguir realizar entregas no prazo e com a necessária qualidade. Por isso, quase sempre, a adoção do Scrum é cercada de uma enorme expectativa.

Uma técnica que costumo usar com novas equipes em seu primeiro projeto é trabalhar com uma Sprint interna de uma semana e uma Sprint externa, composta de duas Sprints internas. Explico! Todos os ritos: Scrum Daily Meeting, Sprint Planning e Sprint Reprospective acontecem, regularmente, dentro de uma semana, com as devidas pontuações de histórias e anotações nos backlogs. Para os patrocinadores e clientes, porém, os incrementos funcionais são entregues a cada duas semanas, quando acontece a Sprint Review oficial. Isso garante o estabelecimento do ritmo, ao mesmo tempo em que dá confiança para a equipe ao concentrar, na primeira Sprint interna, desenvolvimentos e aprendizagens que, não necessariamente, terão que ser demonstrados aos clientes.

Tão rápido quanto possível, claro, não deve mais existir a diferença entre Sprints internas e externas. Esse artifício, porém, ainda que não seja uma prática oficial, provou-se eficaz em algumas ocasiões onde trabalhei com equipes formadas por novos desenvolvedores.