Time Box e Sprint Planning

Hoje passei por uma experiência que provou muita coisa a respeito de Time Box na hora de executar o Sprint Planning.

O que aconteceu foi o seguinte: Precisávamos especificar algumas ferramentas para nosso projeto, cada uma destas ferramentas seriam um Product Backlog e então entramos na reunião com o Product Owner, que veio com alguns 'cartões de estória' para cada um destes, e dai retiraríamos então nossos Sprint Backlogs. Já partindo do pressuposto que nossa Sprint teria o Time Box de duas semanas, começamos a ver o primeiro Product Backlog, já priorizado pelo PO.

Começamos a ler cada um dos 'cartões de estória' e tirar nossas dúvidas com o PO, em seguida resolvemos levantar os pontos, que por sugestão do gestor acabou sendo visto em dias, logo vimos que o primeiro item já seria o suficiente para ocupar a nossa Sprint, com uma certa possibilidade (baixa) de sobrar tempo e podermos então pegarmos um novo item. Apesar de avisado sobre isso o gestor resolveu que deveríamos ver todos os outros itens de backlog que o PO já havia feito os 'cartões de estória', mesmo após a argumentação que este conhecimento muito provavelmente seria perdido durante o tempo decorrido, nosso gerente argumentou que deveríamos ver, pois haviam itens que se repetiam nos itens de backlog e isso poderia nos ajudar a ter a visão de criar "dispositivos reutilizáveis".

Bom, mesmo descordando (eu) seguimos (toda equipe) em frente. Gastamos 2,5H pela manhã e 1,5H na parte da tarde. Isso basicamente conversando com o PO e discutindo algumas coisas técnicas com a equipe. Depois disso tudo claro que devíamos ainda analisar os itens vistos e separar em tarefas pequenas que não tivesse mais de 2 dias de trabalho, nesta parte estávamos só nós sem o PO e o gerente. Vimos tudo que foi levantado distribuímos os pontos nas tarefas e então obtivemos a visão de tudo que teríamos que fazer nos próximos dias, como de costume... muuuuito trabalho! :)

Vamos apontar o que esteve errado nisso tudo:

1º - O time box foi totalmente desrespeitado. Partindo do princípio que no Sprint Planning devemos levantar os itens que serão 'atacados' durante a sprint e logo definirmos seus pontos de esforço. Ou seja, deveríamos usar as 4Hs para fazer tudo isso e não perder quase o dia todo em reunião.

2º - Ao vermos tantos Products Backlogs no mesmo dia, quando fomos levantar as tarefas, toda a equipe estava confusa com alguns requisitos de um item para outro. Claro que excesso de informação pode ser prejudicial ehehe

3º - Se um novo integrante entrar na equipe ele vai ter que tirar todas as suas dúvidas com os membros da equipe e com o PO, é claro, mas deixou de ter todo aquele Brain Storn do Sprint Planning. Ou seja acabou lembrando Waterfall!

4º - Reuniões demoradas e sem pausa causam um certa fadiga onde gera falta de atenção e comprometimento dos envolvidos. Desta forma deveríamos ter tido uma leve pausa no período da manhã.

O que eu vejo que deveria ter sido feito:

1º - Para atender o gerente o Scrum Master devería ter analisado o documentos juntamente com o gerente e o PO (se possível), afim de ter a visibilidade dos itens a seguir conforme o solicitado. Isto é possível porque o Scrum Master (eu) possui um perfil técnico que faz parte da equipe como arquiteto/desenvolvedor e ainda conhece do negócio (praticamente um severino). Desta forma o Scrum Master poderia passar para a equipe um visão do que ocorreria nos próximos passos que poderia ser reaproveitado.

2º - Deveria ter sido respeitado o Scrum e feito da maneira correta: 4Hs para toda a Sprint Planning, pois o Time Box é algo que o Scrum bate muito forte para que seja seguido a risca.

3º - Tentar tirar dúvidas técnicas entre a equipe junto com o PO pode ser bem desastroso e tomar o tempo precioso dele. Acho que o PO deve participar de forma bem ativa, mas só até o time ter todo o entendimento do negócio, depois o PO pode ser dispensado e a equipe parte para a divisão das tarefas e devida pontuação, claro que em determinados momentos pode haver dúvidas que devem ser tiradas com o PO.

Por fim, nós acabamos tendo todo este trabalho, creio eu, pelo fato do PO tirar férias daqui a uns 50 dias e por isso o gerente quis adiantar as coisas, mas acabou dando um pouco errado. Penso que o Scrum foi elaborado para ser seguido e algumas de suas partes adaptadas, mas não tudo.

Ainda precisamos arrumar uma solução para esta falta no PO em determinada parte do projeto, pois desta forma perdemos um dos pontos fortes do Scrum que é ter o PO o mais junto da equipe o possível.

Abraços!