O Desafio do Sprint Planning 2 no Scrum

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!

Anúncios

Um comentário sobre “O Desafio do Sprint Planning 2 no Scrum

  1. Muito massa o post!! de fato saber o grau a ser usado faz muita diferença, acho que na medida do possível é melhor refinar mais pois tira a margem do cara ficar inventando impedimento dia a pois dia. porém muitas vezes as tasks ficam tão divididas mas apenas uma pessoas faz e os outros podendo pegar preferem outras tasks menos priorizadas para evitar problemas com merge. o que vale é o bom senso mesmo.

    Bem uma coisa minha equipe faz é fazer um check list do critério de pronto ao final da quebra em tasks de cada IBL da sprint para verificar se realmente o que planejamos atende ao pronto.

    Ex de Critério de Pronto:
    – Todos testes unitários passando.
    – Documento de caso de uso revisado.
    – Layout aprovado pelo designer.
    – Performance de post back abaixo dos 10 segs.

    Se uma ou mais de uma tasks garante todos os critério provavelmente não é necessário adicionar mais nenhuma task, quando aparece nós atualizamos o critério. As vezes acontece uns esquecimentos mas falando daqui é muito raro.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s