Com o Product Backlog definido, a reunião de planejamento é feita, o Product Owner apresenta o projeto aos demais membros da equipe Scrum e toda a equipe define a quantidade de horas que cada tarefa deverá ocupar. Os aspectos técnicos são levados em consideração e todo o planejamento é feito deste modo. O resultado é um Product Backlog que agora tem suas estimativas de custo/hora.

Funcionalidade	Prioridade	Custo/horas
Modelagem de dados	1	32
Cadastro de usuário	2	18
Cadastro de ônibus	2	18
Registro de rotas e escalas	3	24
Quantidade de assentos disponíveis	4	10
Reserva e emissão de passagem	5	10
Segurança	6	10
Layout da página	7	28

Com o novo Product Backlog, define-se qual será a meta do primeiro Sprint:

• Modelagem de dados;
• Cadastros de usuários e ônibus
• Registro de Rotas e Escala

Funcionalidade	Prioridade	Custo/horas
Modelagem de dados	1	32
Definição de dados	1.1	8
Organização de tabelas	1.2	12
Relacionamento	1.3	8
Implementação em SGBD	1.4	4
Cadastro de usuários e ônibus	2	36
Formulários	2.1	10
Interação com cadastro na base de dados	2.2	10
Visualização de perfil	2.3	5
Mudança de dados	2.4	5
Relacionamento entre usuários	2.5	6
Registro de rotas e escalas	3	24
Definição e implementação da estrutura	3.1	24

Com as metas preparadas e as tarefas bem definidas, é hora de começar o ciclo de desenvolvimento, o Sprint.

No nosso exemplo, temos o total de 92 horas de estimativa para acabar o Sprint. É importante lembrar que esta quantidade de horas deve ser ajustável para não ser menos de dois dias e não mais que duas semanas de ciclo de desenvolvimento. Durante o ciclo de desenvolvimento, o time irá trabalhar nas tarefas, conforme o sub-ciclo:

• Desenvolver o produto: implementar, testar e documentar;
• Empacotar: deixar o produto pronto para ser apresentado e integrado;
• Revisar: o trabalho para se certificar do que foi feito;
• Ajustar: qualquer mudança nos requisitos ou planos.

O Scrum Master irá acompanhar o desenvolvimento através de reuniões diárias de aproximadamente quinze minutos para se certificar de que os desenvolvedores estejam completando suas tarefas, estejam bem de saúde e bem comprometidos com o projeto.

Com o Burndown Chart, podemos ver claramente o andamento do projeto ao longo do seu ciclo de desenvolvimento (Sprint). Também, no meio do projeto, podemos calcular facilmente a velocidade com que o projeto está andando e assim estimar uma data para que o Sprint seja concluído.

Este dado estimativo pode ser comparado com o prazo que o Product Owner nos deu para que possamos saber se o projeto vai acabar ou não no prazo.

Este é um dos mais importantes trabalhos que o ScrumMaster terá que fazer, e o Burndown Chart é o indicar perfeito para ele gerenciar o tempo de projeto e sua equipe de desenvolvimento.

Ao final do ciclo de desenvolvimento (Sprint), toda a equipe se reune e vê quais foram os resultados obtidos. O Product Owner identifica todo o progresso e revisa o projeto. Ele, junto com o cliente, concorda que os itens especificados para o Sprint foram completos e esta primeira versão do sistema é satisfatória.

Depois disso, será definido quais as próximas prioridades e o que será feito no próximo Sprint. Assim, o processo começa novamente, chamado agora de Sprint 2. Define-se prazos e prioridades, assim, será montado o plano de desenvolvimento para o próximo ciclo de desenvolvimento Scrum.