Planejamento de Sprint (Tarefas)

Depois de concluir o Passo 3 , você deve gora ter seu backlog de produtos em ordem de prioridade e backlog estimado baseado em tamanho, e planejado o seu sprint, o próximo passo é planejar o Sprint em detalhes , ou seja vamos quebrar em tarefas.

Vamos lá?

A primeira parte de Planejamento de Sprint (no passo anterior desta série) foi  focada em esclarecer como selecionar os requisitos do  Backlog de Produtos.

A segunda parte do Planejamento do Sprint Planning está focada em quebrar os requisitos em tarefas e estimar as horas necessárias para completá-los.

Embora esse passo da série possa seguir diretamente da primeira parte, às vezes é útil que haja um tempo curto para uma pausa entre as reuniões;

Isso permite uma margem de tempo para esclarecer quaisquer dúvidas pendentes decorrentes do passo 1  antes de prosseguir para o próximo.

Uma vez fechado a recorrência da reunião de modo a atender a disponibilidade de todos os membros da equipe. Inclua todos os papéis.

Analistas de negócios. Testadores, e TODOS os desenvolvedores da equipe Scrum para o produto.

Neste momento o Proprietário do Produto e qualquer representante de clientes não precisam participar do Planejamento de Sprint, pois é uma reunião bem técnica e com detalhes de como equipe trabalhará com os itens de backlog selecionados e como serão Entregue.

Porém, são bem vindos para participar, o que pode ajudar a entender o que está envolvido para entregar os itens e pode ainda ajudar se qualquer esclarecimento adicional se necessário à medida que as tarefas são discutidas e estimadas.

 

Definir a capacidade Sprint

 

 

Antes de mais, calcule a capacidade de Sprint da equipe. Este pode ser o o número de horas disponível que a equipe tem para trabalhar no Sprint ou em pontos como já falado.

 

Comece, multiplicando as horas disponíveis na Duração do Sprint pelo número de pessoas de tempo integral no Sprint. Para as pessoas que trabalham a tempo parcial no Sprint, inclua o número de horas que podem comprometer.

Em seguida, faça as deduções razoáveis ​​pelo tempo que os membros da equipe não poderão gastar trabalhando no Sprint. Como reuniões ou qualquer momento que possa ser gasto trabalhando em outros projetos, etc.

Com base na experiência passada, deduza uma quantidade razoável de tempo de apoio, se apropriado.

 

Verifique se todos esses cálculos são transparentes e visíveis para todos.

 

 

Requisitos em Tarefas

 

Percorra cada item de Backlog do produto através da prioridade selecionado para o mesmo para Sprint. Neste momento o time deve dividir os requisitos em tarefas.

 

As tarefas devem incluir as etapas tradicionais em um ciclo de vida de desenvolvimento (embora limitado ao item “requisitos” em questão, e não ao produto completo)

Quer um exemplo?

 

Design, Desenvolvimento, Teste de Unidade, Teste de Sistema, UAT (Teste de Aceitação de Usuário), Documentação, etc.

 

Cada uma dessas tarefas, especialmente o desenvolvimento, pode ser quebrada ainda mais.

Quer ver só?

 

Publicação slot produção

Replicação do Banco

Implementar limite baseado no tamanho total

 

Talvez para um nível de componente detalhando cada um dos elementos individuais da arquitetura de software que serão necessários para entregar a característica do produto.

 

Inclua todas as tarefas necessárias para tornar o item Backlog do Produto 100% completo – ou seja, para que no final do Sprint, possamos dizer “Pronto”.

O conceito de “Pronto” “Done” deve ser definido e concordado por todos da equipe, para que todos estejam cientes do que deve ser completado e incluído nas estimativas.

Estimar tarefas em horas

Mantenha as tarefas pequenas.

Estime todas as tarefas em horas.

Estime as tarefas como uma equipe.

Pergunte a todos o que eles pensam, para identificar tarefas perdidas ou para identificar soluções mais simples.

Idealmente, as estimativas de tarefas não devem ser superiores a 1 dia.

Se uma estimativa for muito maior do que isso, os requisitos devem ser discriminados para que as tarefas sejam menores.

Embora muitas vezes isto pode ser difícil, ficará mais fácil com a prática dia a dia.

 

Manter tarefas pequenas o suficiente para estimar em menos de 1 dia tem alguns benefícios específicos.

 

Em primeiro lugar, a quebra de tarefas em pedaços muito pequenos significa que eles são mais fáceis de estimar.

A precisão da sua estimativa será melhorada como resultado. Em segundo lugar, as tarefas de menos de 1 dia são melhor mensuráveis ​​no Scrum diário (reunião de stand-up).

E ainda assim você pode lidar com problemas como “superestimarem”. Na minha larga experiência, isso é bastante comum quando as equipes são novas para o Scrum. Eu acho que é porque eles não estão familiarizados com o processo e potencialmente fora de sua zona de conforto inicialmente.

Eles podem não ter tido muita experiência de estimar no passado ou podem não ter sido convidados a se comprometer com a sua própria entrega antes.

 

Preparado para o próximo passo?

Então, agora você obteve seu backlog em ordem, estimou seu backlog, esclareceu seus requisitos e planejou seu sprint.

Vamos ao passo 5, e que basicamente é a que eu mais gosto – Criar um ambiente de trabalho colaborativo.

 

 

 

 

 

4 Comments

0

Post A Comment