Bom dia Rodrigo! Vamos lá!
Compartilhando informações, os profissionais deverão alinhar com o Project Owner quais funções serão implementadas, assim como as tarefas a serem executadas. Essa parte é chamada de Sprint Planning. Ele é o primeiro evento realizado no sprint, e deve responder duas perguntas primordiais para o decorrer do método Scrum: o que será feito? Como será feito?
Logo, o Sprint Planning é dividido em duas partes, cada uma com tempo sugerido de quatro horas. A primeira definirá quais os itens do Product Backlog serão desenvolvidos no sprint. Enquanto a segunda parte, definirá como esses itens serão abordados durante o trabalho, ou seja, quais serão as tarefas executadas para que os elementos selecionados sejam entregues no fim dessa etapa.
O resultado é um novo Backlog, que se caracteriza por ser uma parte do Product Backlog, porém, com maior detalhamento de tarefas e funções para cada item selecionado. Esse novo artefato gerado a partir da reunião inicial do sprint é chamado de Sprint Backlog.
Normalmente, a atribuição de prioridades nos Backlog é feita por pontuação. Tarefas mais importantes para o Product Owner, mais difíceis de executar, mais demoradas ou que possuem alguma incerteza ou risco técnico recebem maior pontuação.
Cada Scrum Team tem uma pontuação limite aferida, com base na produtividade da equipe. Com isso, o grupo fica limitado a pegar um conjunto de tarefas que não exceda o limite. Esse parâmetro é criado para diminuir o número de tarefas não entregues devido ao sobrecarregamento da equipe.
Assim que o Product Owner define os itens do Backlog a serem desenvolvidos, fica a cargo do Scrum Team dizer o que é possível de ser entregue dentro do prazo final do sprint. Nesse ponto, é necessário que o time aceite apenas uma quantidade de tarefas que não exceda a pontuação máxima que a equipe é capaz de desenvolver.
Em alguns casos, pode ser mais interessante dar prioridade para as atividades que envolvem um maior risco técnico ou de segurança. Em outros casos, os gestores podem optar por priorizar os trabalhos que agregam mais valor ao produto. Nesse momento, a opinião do Product Owner deve ser levada em consideração.
No método Scrum, todo evento ou processo é Time-boxed. Ou seja, tudo que será realizado no método tem uma duração, um prazo pré-definido, determinado com base em uma análise anterior ou a um padrão já conhecido de trabalho.
Assim, cada sprint deverá ter sua duração de acordo com a capacidade de trabalho do Scrum Team, responsável pelo desenvolvimento da arquitetura do produto. Normalmente, em equipes que estão no início da implantação do método, é adotado um período de 30 dias para a execução da carga de tarefas padrão.
Assim que ela passar a dominar o método, esse período pode ser reduzido para 21 dias e em seguida para 14 dias. É importante que a duração do sprint seja dada em semanas exatas, o que facilita a organização da equipe. Da mesma forma, as tarefas a serem feitas devem ter no máximo 8 horas, ou seja, um dia de trabalho.
Se o sprint contar com muitas tarefas, será necessário reduzir a quantidade de atividades do Product Backlog que a equipe tentará executar. Caso o número de trabalhos seja baixo, mais itens do Product Backlog podem ser adicionados ao sprint.
Bons estudos!!!