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 feitos na sprint. Nessa reunião, é muito importante a presença do product owner, pois ele é um dos principais responsáveis pelo roadmap do produto/projeto sendo desenvolvido por ele, na grande maioria das vezes, 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 IBLs é feita 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 IBLs (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 :P; 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 um dia de trabalho (ou menos), caso contrário é melhor quebrar ainda mais a tarefa, com o objetivo de que ela caiba em um 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 task (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.). Cada detalhe, então, vai virar uma task, e isso facilita a vida de quem for 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. Por exemplo, 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) à parte.
3. Refinamento Contínuo: A idéia aqui é sempre adequar a quebra de tarefas à realidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá de base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, é preciso juntar mais coisa em uma task 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!