Uma boa sprint começa com um bom planejamento!

Para quem não está familiarizado com o scrum, no fluxo normal  nós temos dois passos que iniciam a execução da sprint chamados “Sprint Planning 1” e “Sprint Planning 2” (representados na imagem acima pelos dois primeiros blocos de fundo verde).   No Sprint Planning 1, é onde acontece a escolha de quais itens de backlog (IBL) serão feitas na sprint. Nesta reunião é muito importante a presença do product owner pois ele é um dos principais responsáveis pelo roadmap do produto/projeto sendo desenvolvido, na grande maioria das vezes ele que tem o conhecimento do negócio e que tem a visão mais acertada de onde quer que o produto/projeto chegue. Essa escolha das IBL’s é feita de pelo time todo, ou seja, todo o time tem que concordar que terão condições de implementar aquelas estórias escolhidas. Uma vez escolhidas as estórias que serão feitas na sprint, chega o momento da Sprint Planning 2…

Na reunião de “Sprint Planning 2” todo o time concentra seus esforços em quebrar aquelas IBL’s (estórias) em unidades menores de trabalho que são as conhecidas Tasks, representadas por post-its, e que estão eternizadas na imagem de uma parede cheia de post-its (nada contra, mas tenho pena das árvores 😛 vamos começar o movimento #RecyclePostIts). Bom, é nesse momento que acontece a explosão de tarefas, a sprint começa sem ter nenhuma tarefa a ser feita e na sprint planning 2 as tarefas são levantadas. A importância dessa fase do scrum é a seguinte: O que você levantar como tarefa aqui vai guiar seu desenvolvimento da sprint toda (e é claro que você pode lembrar/criar mais atividades no decorrer da sprint, mas essa visão inicial ajuda muito e já pode antecipar alguns problemas que poderiam acontecer).

É aí que aparece a pergunta: Mas como eu quebro as estórias em tarefas?  Qual a granularidade? E é justamente para tentar responder essas perguntas que eu vou tentar listar algumas dicas ou instruções de como quebrar as tarefas.

• 1) Granularidade grossa: Uma das primeiras recomendações para a quebra de tarefas é sempre criar tarefas que possam ser feitas em 1 dia de trabalho (ou menos), caso contrário é melhor quebrar ainda mais a tarefa com o objetivo que ela caiba em 1 dia de trabalho. O objetivo desta dica é facilitar o gerenciamento das tarefas, e também poder visualizar o trabalho diário no burndown, que nesse caso vai se mover dia a dia, ao invés de ficar parado uns dias e depois se mover.
• 2) Granularidade fina: O ideal para começar é tentar lembrar de cada detalhe, e transformar cada detalhe em uma tasks (lembrando que para que isso aconteça é preciso uma análise detalhada da estória a ser desenvolvida, levando em consideração todos os pontos possíveis: criação de classes, design, design gráfico, prototipação, testes, etc, etc, etc). Cada detalhe então vai virar uma task e isso facilita a vida de quem desenvolver a estória pois as tarefas já são quase que um guia e a finalização das tasks da estória simbolizaria que não falta mais NADA para aquela estória. Ex.: Se você sempre acaba a estória e vê que a equipe não fez uma validação javascript em um formulário, então na próxima sprint você já inclui a validação como uma tarefa (pois-it) a parte.
• 3) Refinamento Contínuo: A idéia aqui é sempre adequar a quebra de tarefas a relidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá por base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, junta mais coisa em um tasks só (que façam sentido estar junto obviamente). Caso a granularidade tenha sido muito grossa, tenta detalhar mais cada uma e separar os detalhes em tasks individuais.

Bom, acredito que com essas coisas em mente vamos conseguir planejar melhor nossas sprints, e consequentemente finalizá-las melhor também! Você tem alguma dica a respeito da separação de tarefas no sprint planning? Deixa tua dica aqui como comentário 🙂 valeu!