Antes de começar esse terceiro dia de 90 minutos, diga às equipes que sua interferência apenas ocorrerá, agora, no caso de alguma dúvida. Os membros das equipes devem começar com a reunião diária descrita na dinâmica anterior e aproveitar, agora que já têm mais familiaridade com o produto em desenvolvimento, para olhar as demais histórias que estão no Product Backlog e refiná-las junto ao Product Owner. Aproveite, também, para dar algumas dicas sobre a Definição de Pronto, mesmo que as equipes estejam desenvolvendo um protótipo de papel (por exemplo, as histórias foram testadas por alguém que não as desenvolveu?). Lembre-as de que no quarto dia terão que reservar tempo para a Revisão do Sprint (deixaremos a Retrospectiva para uma dinâmica à parte, ainda que, idealmente, ela deva acontecer no último dia do Sprint).
Ao final da reunião diária o Scrummaster já sabe que, além da história já iniciada, a equipe trouxe para o terceiro dia as demais histórias do Sprint Backlog, que agora somam 15 pontos (dois que faltaram da primeira história e mais 13 das demais histórias). A conversa a seguir é travada:
Scrummaster:
Com relação à história “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”, para a qual haviam sobrado dois pontos, qual o sentimento de completude com relação à ela?
Equipe:
Como decidimos trazer as demais histórias para o desenvolvimento, levamos um tempo discutindo como executá-las e acabamos por não tocar nessa primeira história. Assim, ainda restam os mesmos dois pontos.
Scrummaster:
Muito bem, com relação à segunda história então, de oito 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”, qual o sentimento de completude com relação à ela?
Equipe:
Ao avaliarmos essa história junto com a primeira, nós vimos que deveríamos trabalhar melhor em um padrão de tela comum para a exibição dos mapas de localização e, por isso, julgamos necessário passar mais tempo discutindo esse padrão e colocar o seu cumprimento na definição de pronto. Isso também vai exigir algum retrabalho naquilo que já havíamos avançado na primeira história. Nosso sentimento é que realizamos apenas um ponto dessa história.
Scrummaster:
Muito bem, e quanto a terceira história, de cinco pontos, “como prestador de serviços, desejo cadastrar meu estabelecimento para que ele seja encontrado por donos de pets”?
Equipe:
Também discutimos um padrão de tela a ser seguido na sequência do desenvolvimento, que foi colocado na definição de pronto, mas sentimos que apenas completamos um ponto dela.
O Scrummaster anota nas notas adesivas correspondentes que ainda restam seis pontos para a primeira história, sete para a segunda e quatro para a terceira e, no Burndown Chart, que foram realizados dois pontos dos quinze restantes, faltando treze para ser realizado no terceiro e no quarto dia. O Burndown Chart fica como o da Figura 21.5.
Figura 21.5 – O Burndown Chart no início do terceiro dia de 90 minutos
Você percebe o quanto nos afastamos da “reta ideal” do Burndown Chart? Esse foi o resultado de apenas dois dias de trabalho, durante o primeiro Sprint, após o primeiro exercício de estimativas. É claro que a chance de erro é muito grande e, de fato, o Burndown Chart é uma ferramenta de aprendizagem e refinamento das estimativas. Nesse caso, aparentemente subestimamos o trabalho, mas poderia ter sido o contrário.
O Scrummaster, junto com a equipe, calcula que foram realizados oito pontos nos dois primeiros dias (seis no primeiro, dois no segundo), uma média de quatro pontos por dia. Isso é sinal (ainda que muito precoce) de que a equipe tenderá a realizar apenas doze pontos de um total de quinze e deve-se levar em conta que no quarto dia ocorre a Revisão, a demonstração para o Product Owner. Em uma situação real o Product Owner já deveria ser alertado que alguma história do Sprint Backlog deixará de ser entregue. Mas, mesmo na vida real, é preciso entre três a quatro Sprints para que a equipe tenha a real noção de sua velocidade.
Depois da reunião diária e das observações quanto ao Product Backlog, o dia de 90 minutos segue.
