1) O Planejamento de Sprint deve fornecer informações suficientes para a equipe trabalhar e dar confiança ao Product Owner. 2) O Product Owner deve participar do Planejamento de Sprint para refinar estimativas e prioridades através de diálogo com a equipe. 3) Estimativas de histórias devem levar em conta a velocidade da equipe, focando em entregas concretas dentro do Sprint Backlog.

1. Planejamento de
Sprint
Dar a equipe informação suficiente para trabalhar;
Dar ao Product Owner confiança na equipe;

2. Resultado concreto
• Objetivo claro do Sprint.
• Equipe comprometida com a meta.
• Sprint Backlog.
• Data de apresentação do Sprint.

3. P.O. deve participar?
“Pessoal, eu já listei o que eu quero. Eu não tenho tempo para
estar na sua reunião de planejamento”

4. P.O. deve participar?
Essas três variáveis precisam ser refinadas continuamente por
diálogo “cara-a-cara” entre a equipe e o P.O.

5. P.O. deve participar? Sim!
Pode ocorrer:
• Mudança de estimativas pela equipe
• Mudança de importância/prioridade das estórias

6. P.O = O cara!
“Fundamental para o desenvolvimento ágil”

7. Objetivo do Sprint
“Por que nós estamos fazendo este sprint? Porque
não saímos de férias ao invés de fazê-lo?”

8. Tamanho do Sprint?
Sprints curtos (1 a 3 semanas)?
Ou
Sprints longos (1 mês a 2 meses)?

9. Tamanho do Sprint?
• Sprints curtos:
Ciclo curto de feedback = entregas mais freqüentes = feedback
mais freqüente do cliente = menos tempo perdido, indo na
direção errada = aprender e melhorar rápido, etc.
• Sprints longos:
A equipe tem mais tempo para ganhar ritmo, ela tem mais
espaço para se recuperar dos problemas, e conseguir atingir o
objetivo do sprint, você tem menos overhead em termos de
reuniões de planejamento, apresentações, etc.

10. Tamanho do Sprint?
“No geral, product owners gostam de sprints
curtos e desenvolvedores preferem os longos.
Então o tamanho do sprint representa um
compromisso”

11. Qualidade Externa vs. Interna
• Externa:
O que é percebido pelos usuários do sistema. Ex: “Interface”.
• Interna:
Questões que normalmente não são visíveis ao usuário, mas
que têm profundos efeitos na manutenibilidade do sistema.
Ex: “Cobertura de testes”.

12. Negociação de estórias
Alta qualidade INTERNA
+
Baixa qualidade EXTERNA

13. Negociação de estórias
Baixa qualidade INTERNA
+
Alta qualidade EXTERNA
?

14. Negociação de estórias
Baixa qualidade INTERNA
+
Alta qualidade EXTERNA
“É difícil construir algo legal a partir de fundações podres”

15. Estórias técnicas
• Não fazem parte das entregas.
• Não estão relacionadas diretamente com nenhuma estória
específica.
• Não agregam valor para o product owner.
Exemplo:
• Instalar um servidor de build.
• Escrever um resumo do projeto do sistema.
• Refazer a camada DAO.
• Fazer o upgrade de um framework.

16. Quais estórias faremos?

17. Técnica de estimativa
• Instinto / Sentimentos / Percepções.
• Cálculo de velocidade baseado no tempo de ontem, e cálculo
de velocidade baseada no homens-dia disponíveis e fator de
foco.

18. Velocidade Estimada x Real

19. Estimativas, como calcular?
Dias disponíveis
Bruno 15
Caio 15
Diego 15
Ricardo 15
Total 60 homens-dia

20. Estimativas, como calcular?
“Fator de foco”

21. Estimativas, como calcular?
28 | SCRUM E XP DIRETO DAS TRINCHEIRAS
O fator de foco é uma estimativa de como a equipe é focada. Um fator de
foco baixo, pode significar que a equipe espera ter muitas interferências
ou percebe que suas próprias estimativas de tempo são otimistas.
A melhor maneira para determinar um fator de foco razoável é considerar
o último sprint (ou melhor ainda, a média de alguns sprints anteriores).

22. O fator de foco é uma estimativa de como a equipe é focada. U
Estimativas, como calcular?
foco baixo, pode significar que a equipe espera ter muitas inte
ou percebe que suas próprias estimativas de tempo são otimistas
A melhor maneira para determinar um fator de foco razoável é
o último sprint (ou melhor ainda, a média de alguns sprints ante
A velocidade atual é a soma das estimativas iniciais de todas
que foram finalizadas no último sprint.
Vamos supor que o último sprint terminou 18 pontos p
utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trab

23. Vamos supor que o último sprint terminou 18 pontos por estória
Estimativas, como calcular?
utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trabalhando 3
semanas, resultando em um total de 45 homens-dia. E agora nós estamos
tentando calcular nossa velocidade estimada para o próximo sprint. Para
complicar as coisas, um cara novo, o Dave, está se juntando à equipe para
esse sprint. Levando em consideração as folgas e as obstruções nós temos
50 homem-dias para o próximo sprint.
Portanto, nossa velocidade estimada para o próximo sprint é de 20 pontos
por estória. O que significa que a equipe deveria adicionar estórias ao
sprint até atingir uma soma de aproximadamente 20.

24. Estimar pode ser um problema
• Normalmente nós não sabemos exatamente quem vai
implementar quais partes de quais estórias.
• Envolvem diversas pessoas e diversos tipos de expertise
(design de interface de usuário, codificação, teste, etc).
• Discrepâncias onde duas pessoas da equipe têm estimativas
bastante diferentes para a mesma estória.

25. Planning Poker

26. Planning Poker

27. Planning Poker

28. Planning Poker

29. Planning Poker
“Proporcionar uma visão comum do trabalho
envolvido na estória”

30. Planning Poker
Existem algumas cartas especiais:
• 0 = “esta estória já está feita” ou “esta estória é tão pequena que
leva somente alguns minutos de trabalho”;
• ? = “Eu não faço idéia alguma”;
• Xícara de café = “Estou cansado demais para pensar. Vamos fazer
uma pequena pausa”.

31. Hum, o que já vimos?
• P.O. é o cara.
• Entender e negociar as estórias.
• Estimar as estórias.

32. Organizando o Sprint Backlog?

33. Organizando o Sprint Backlog?

34. Término do Sprint Planning
Só será um sucesso se:
• Todos sairem da reunião com um sorriso no rosto.
• Todos acordarem no dia seguinte com um sorriso no rosto.
• Todos fizerem a primeira reunião diária com um sorriso no
rosto.

35. Definição de pronto
“Uma estória está completa quando todo o código
está no repositório? Ou está completa apenas
quando foi feito deploy em um ambiente de teste
e a estória foi verificada por uma equipe de testes
de integração?”

36. XP – Programação em par
( - ) “15% mais lento do que uma pessoa sozinha”
( + ) “Qualidade do software” e “Disseminação do
conhecimento”
Esses 15% de perda, são calibrado com 15% de ganho em:
• Menos bugs.
• Melhor manutenção.

37. Agenda da reunião
• P.O. repassa objetivo do Sprint.
• P.O. sumariza o Product Backlog para a equipe.
• Os itens priorizados são esclarecidos pelo P.O.
• Uma data de apresentação do Sprint é escolhida.
• Equipe estima as estórias, quebrando em tarefas se
necessario. Pode-se usar o “Como demostrar…” para
esclarecer melhor.
• Equipe escolhe e calcula cada estórias para entrar no Sprint.
• Todos criam a definição de pronto (DoD).
• Todos fecham o escopo e escolhem o local da reunião diária.