O primeiro dia de 90 minutos de nosso Sprint começa com o Planejamento do Sprint, ou Sprint Planning. Na dinâmica proposta no Capítulo 20, a equipe conheceu o Product Backlog e o que deve ser desenvolvido como MVP. Agora a equipe deve destacar quem é o Scrummaster – o mestre servidor da equipe, o removedor de obstáculos para o Sprint – e, a seguir, escolher quais as histórias que deve levar para dentro desse Sprint de quatro dias.
A equipe sabe que sua ferramenta de trabalho será o protótipo de papel e já estimou o esforço para o desenvolvimento de cada história do MVP. Agora, durante 35 minutos ela deve selecionar quais histórias, efetivamente, será capaz de desenvolver durante os quatro dias do Sprint. Não necessariamente serão todas as histórias do MVP.
Uma vez escolhidas essas histórias, o Scrummaster somará os pontos delas e iniciará o Burndown Chart. Vamos supor que a equipe escolheu as seguintes histórias, devidamente escritas em notas adesivas:
Como dono de um pet, desejo visualizar em um mapa as possíveis moradias (casa ou apartamento) em locais que aceitam pets para que eu possa me mudar para lá com o meu animalzinho – 8 pontos
Como dono de um pet, ao selecionar uma possível moradia, desejo poder selecionar uma distância específica (entre 0,5 e 2 Kms) nos quais posso visualizar os serviços disponíveis para meu pet – 8 pontos
Como prestador de serviços, desejo cadastrar meu estabelecimento para que ele seja encontrado por donos de pets – 5 pontos
TOTAL: 8 + 8 + 5 = 21 pontos
Em discussões anteriores, ficou decidido que, para o MVP, o Product Owner já forneceria uma lista de imóveis pré-cadastrados, ficando a história relativa ao cadastro por parte das imobiliárias para uma versão posterior. O Scrummaster desenha o Burndown Chart em uma folha de flipchart, no eixo vertical colocando os pontos e no vertical os dias, como na Figura 21.2.
Figura 21.2 – O Burndown Chart no primeiro dia do Sprint
Repare que o Scrummaster também traça uma “reta ideal” (tracejada) que irá nos orientar, na evolução dos dias do Sprint, o quão próximos ou distantes estamos de acertar nossa estimativa.
Agora a equipe dá uma pausa de 10 minutos e, nos 35 minutos seguintes, mão na massa! Antes disso, porém, vamos montar nosso quadro do Scrum, ou KanBan, para acompanhar a sequência das histórias no Sprint. Você já leu sobre esse quadro no Capítulo 6 e, para efeito dessa dinâmica, ele será feito em papel mesmo. Para Sprints de até uma semana (cinco dias úteis), assim como para essa dinâmica, eu gosto de arranjar uma parede na forma mostrada na figura 21.3.
Figura 21.3 – O burndown chart após o final do primeiro dia
Bem à esquerda, coloco os Storyboards, o Product Vision Board e, imediatamente à direita destes, o Product Backlog com o MVP em destaque (coloque todas as notas adesivas com as histórias, em um flipchart, já priorizadas, circulando com um marcador aquelas que compõem o MVP).
A seguir, monto um quadro, que pode ser composto por uma ou mais folhas de flipchart, com as colunas Sprint Backlog (nosso “a fazer”), Fazendo, Feito e Entregue.
Fazendo – é onde estão as histórias em desenvolvimento pela equipe. Ainda divido essa coluna de acordo com os dias do Sprint. Em nossa dinâmica, Dias 1, 2, 3 e 4. Essa divisão ajuda na ideia de ritmo e mostra, graficamente, o quanto de tempo uma história permanece vagando pelo Sprint (ver o quadro Casca de Banana, nessa sessão).
Feito – para essa coluna vão as histórias que passaram pela Definição de Pronto da equipe (a Definição de pronto, que pode ser desenvolvida dentro dessa dinâmica, é colocada na parte inferior dessa mesma coluna – leia mais sobre ela no Capítulo 10).
Entregue – as histórias vão para essa coluna depois de aceitas pelo Product Owner durante a Revisão do Sprint (ver o Capítulo 6).
No tempo restante, inicia-se a criação do protótipo de papel. É hora da criatividade correr solta. A equipe deve passar do Sprint Backlog para o primeiro dia da coluna Fazendo as histórias com as quais começou a trabalhar. Se houver algum impedimento para a sua realização, uma pequena nota adesiva vermelha deve ser colocada na história e, imediatamente, comunicada ao Scrummaster, que deve tratar de resolvê-lo (em um desenvolvimento com protótipo de papel, pode faltar cola, mas também pode ter ficado alguma dúvida a ser esclarecida com o Product Owner ou testada com um potencial usuário).
Ao final do tempo concedido lembre a todos que não há horas extras em métodos ágeis e encerre o primeiro dia.
