(Passo 11) Quebrar Sprint Backlog em Tarefas e Estimar o Tempo

“Product Backlog Item Effort” é a estimativa de tempo necessário para a realização de um item do Backlog.
Alguns praticantes de Scrum preferem estimar o esforço por dias de trabalho, mas outros preferem fazer estimativa utilizando unidade de medidas menores que um dia. Um exemplo é o uso de pontos de cartão de historia, pontos de função, “t-shirt”, etc.

(Passo 10) Reunião de Planejamento do Sprint (Sprint Planning Meeting)

A reunião de planejamento do Sprint é uma negociação entre a equipe e o Product Owner sobre o que a equipe fará de execução de funcionalidades durante a próxima Sprint.
Nesta reunião é definido as funcionalidades que entram na Sprint e as que ficam fora, conforme a priorização do Product Owner.
O tempo necessário para esta reunião é de aproximadamente 4 horas.
1 - Product Owner seleciona itens do Product Backlog
2 - Sprint Backlog é criado
2.1 - Tarefas identificadas e estimadas (1 a 16 horas)
2.2 - De forma coletiva e não apenas feito pelo ScrumMaster
2.3 - Equipe compromete-se a concluir as tarefas

(Passo 9) Distribuir Itens do Backlog por Sprint

Em Scrum, um item do produto Backlog (“PBI”, “Backlog item”, ou “item”) é uma unidade de trabalho a ser realizada pela equipe em uma execução de “Sprint”. Um item de Backlog é decomposto em uma ou mais tarefas.
O Sprint Backlog é a relação de funcionalidades que devem ser realizadas em uma iteração, isto é, um Sprint.
1 - Cada indivíduo escolhe o trabalho que fará
1.1 - Trabalhos nunca são atribuídos
2 - Atualização diária da estimativa do trabalho restante
3 - Qualquer membro da equipe pode: adicionar, apagar ou mudar tarefas
4 - Atualize as coisas a serem feitas na medida em que se tornam mais conhecidas
Nesta tarefa temos que pegar os Itens de Backlog e distribuir por Sprint, respeitando a priorização do Product Owner.

(Passo 8) Montar Release Burndown Chart

Release é um produto gerado pela equipe de desenvolvimento e que vai ser instalado no cliente. Um release tipicamente é gerado após a execução de um ou mais Sprints, que resultaram um produto com algum valor agregado ao cliente.
Em Scrum, o gráfico de “Release Burndown” é uma grande figura com as informações do andamento do projeto para a geração de um “Release”. Esta figura mostra quanto de trabalho esta alocado em cada Sprint e as Sprint necessárias para a liberação de um “Release”. Mas neste gráfico nos temos a visão de todos os “Releases”.

(Passo 7) Montar Product Burndown Chart

Burndown charts mostra o trabalho restante (a ser realizado) com relação ao tempo necessário para a sua realização. O trabalho restante (a ser realizado) é representado pelas coordenadas de Y e o tempo necessário para a realização deste trabalho é representado pelas coordenadas X. Deve ser traçado uma linha com a representação da execução do trabalho, onde esta linha representa o esforço já realizado na execução das tarefas. Espera-se que a execução das atividades (tarefas) leve a linha de inicio em Y ao encontro de X, onde este encontro representa o termino das execuções das tarefas.
A literatura de Scrum define que temos dois tipos de “Burndown”, sendo a primeira referente a “Sprint Burndown”, que mostra o acompanhamento diário das execuções das tarefas existentes num “Sprint” e o segundo “Product Burndown” que representa as execução das tarefas existentes em todos as “Sprint”, que representa o projeto por inteiro.
Com estes dois “Burndown” podemos ter uma visão de como esta indo a execução do “Sprint” atual e como esta indo a execução do projeto inteiro pelo controle de todos as “Sprints” existentes no projeto.

(Passo 6) Definir a qtd de Sprint´s

1 – Progresso do projeto é baseado em uma serie de iterações (Sprint)
2 – Todas Sprint devem ter um objetivo, isto é, gerar algo de valor
3 – Ocorrem em um período de duas a quatro semanas
4 – Esses período são chamado de time-box
5 – O produto é desenvolvido durante o Sprint
6 – Nenhuma mudança deve ocorrer durante o Sprint
Um Sprint é uma interação, isto é, um período de tempo onde uma quantidade de funcionalidades serão implementadas. Uma Sprint não deve passar de 30 dias e ser menor que 2 semanas.
Uma Sprint tem seu inicio com uma reunião de planejamento. Uma Sprint possui as reuniões diárias de 15 minutos. Uma Sprint possui uma reunião de revisão do Sprint ao seu termino e também possui uma reunião de retrospectiva após a reunião de revisão.
Durante uma Sprint a equipe não pode ser interrompida com pedidos adicionais de novas funcionalidades. Com esta regra a equipe mantém o foco no compromisso assumido de entregar as funcionalidades selecionadas para a execução da Sprint no prazo combinado.
A quantidade de Sprint é calculada pegando o total de pontos das funcionalidades e dividindo pela velocidade da equipe.

(Passo 5) Velocidade da equipe?

Velocidade é a capacidade da equipe de executar funcionalidades (tarefas). Esta velocidade pode ser recalculada ao termino de cada Sprint e desta maneira realizar uma previsão se o projeto vai estar atrasado ou adiantado em relação ao cronograma inicial.
Uma vez identificada a velocidade de execução de um Sprint, esta velocidade pode ser utilizada para planejar as datas de conclusão das Sprint do projeto e das versões de demonstração.
A equipe deve estimar a velocidade que ela acredita ser capaz de realizar (Exemplo: 5, 7, 10, 15 pontos por Sprint).