Este documento fornece um resumo sobre o framework Scrum. Ele discute porque os projetos falham, os pilares do Scrum (transparência, inspeção e adaptação), os papéis no Scrum (Scrum Master, Product Owner e time), eventos como Sprint Planning e Review, e conceitos como Product Backlog e Definition of Done.

1. Um resumo sobre Scrum.
Rafael Vinicius Kuhn Toebe.
@rafaeltoebe
rafael_viny@hotmail.com

2. Conteúdo
Por que os projetos falham? ......................................................................................................... 4
O que estamos fazendo de errado? .......................................................................................... 5
O que torna a forma atual de gerenciamento de projetos questionável? ............................... 6
O que é Scrum? ......................................................................................................................... 6
Como escolher uma metodologia/framework para usar na minha empresa? ............................. 6
Pilares do Scrum ............................................................................................................................ 7
Transparência: ....................................................................................................................... 8
Inspeção: ............................................................................................................................... 8
Adaptação: ............................................................................................................................ 8
Manifesto para o desenvolvimento ágil de software. .................................................................. 8
O Scrum é composto pelo seguinte: ............................................................................................. 8
Responsabilidades dos papéis definidas pelo Scrum. ................................................................... 9
Responsabilidades do Scrum Master: ................................................................................... 9
Responsabilidades do Product Owner: ................................................................................. 9
Responsabilidades do Time: ................................................................................................ 10
A visão. ........................................................................................................................................ 11
O tamanho das Sprints. ............................................................................................................... 12
A síndrome de Estudante: ................................................................................................... 12
Definindo o estado “Done” (Pronto). .......................................................................................... 13
Sobre o Done. ...................................................................................................................... 13
Definindo o estado “Ready” (Preparado).................................................................................... 13
O Product Backlog. ...................................................................................................................... 14
User Stories (procedente do XP). ................................................................................................ 14
Story – Writing Workshop. .................................................................................................. 14
O que é necessário para fazer um Story – Writing Workshop? .......................................... 14
EPIC.............................................................................................................................................. 15
Há perigo para estimar um epic? ............................................................................................ 15
Themes. ....................................................................................................................................... 15

3. Sprint Planning Meeting. ............................................................................................................. 15
Estimando Story Points. .............................................................................................................. 17
Planning poker. ........................................................................................................................... 17
Execução da Sprint. ..................................................................................................................... 18
A reunião diária. .......................................................................................................................... 19
Importância da reunião diária: ............................................................................................ 19
Mudanças no Sprint Backlog durante sua execução................................................................... 19
Sprint Review. ............................................................................................................................. 19
Participantes em uma Sprint Review ...................................................................................... 20
Importância da Sprint Review. ................................................................................................ 20
Consequências da Review. .................................................................................................. 20
Retrospectiva. ............................................................................................................................. 20
Ciclo de vida de um projeto Scrum ............................................................................................. 21
Para refletir: ................................................................................................................................ 22
Diferença entre Problema e Impedimento. ................................................................................ 22

4. Em uma rápida pesquisa durante a certificação CSM foram detectadas os seguintes problemas:
Falta de
comprometi Atrasos
mento
Falta de
Comunicação Retrabalho
entre Mudanças
de escopo
outros
Por que os projetos falham?
Em um documento (mais precisamente um relatório) formulado por grupo chamado Stanches Group
mostra uma realidade preocupante e que não mudou em nada (apenas piorou) nos ultimos anos:
Porcentagem de projetos concluidos, que tiveram mudanças e os que falharam.

5. Como podemos ver nos dados acima, tivemos:
 32% Sucesso (no prazo, dentro do orçamento e com escopo completo).
 44% Mudaram (atrasaram, estourou o orçamento, e/ou reduziram escopo).
 24% Falharam (cancelados ou nunca usados)
Segundo o Gartner, 70% dos projetos falham no cumprimento de cronograma, custos e metas de
qualidade e 50% são executados acima do orçamento. Já o CHAOS divulgou que 50% dos projetos de TI
são cancelados, 82% são entregues com atraso e as pesquisas da KPMG destacam que menos de 40%
desses projetos alcançaram os objetivos de negócios um ano depois.
O que estamos fazendo de errado?
Na minha opinião um dos principais erros que todos cometem é usar um modelo de gerenciamento
desenvolvido a meados do século XVIII.
Durante aquela época era muito difícil encontrar mão de obra capacitada, então quem tinha certo nível de
conhecimento era colocado como chefe para ensinar aos menos capacitados como executar uma parte do
processo, e os chefes ficavam verificando se a execução foi feita corretamente.
Hoje em dia muitos colaboradores têm mais conhecimentos técnicos que seus respectivos chefes,
deixando o modelo mencionado acima defasado.
Outro erro é uma herança da engenharia civil, vamos à outra historinha:
Na engenharia civil as coisas são pouco complexas, por exemplo:
Vamos projetar um prédio:
Vai ter 10 andares, cada andar com quatro apartamentos, porcelana da marca fulana ou similar, cor
branca, etc.
Alguém já viu um cliente do engenheiro civil chegar quando está construindo o oitavo andar e falar:

6. Não era isso que eu queria, mudou as minhas necessidades, vai ter que ser dois quartos por andar! E
agora?
Ou seja, a engenharia usa o planning driver manager e funciona perfeitamente! Se tiver mudanças será a
troca da porcelana da marca fulana para a marca ciclano.
E agora eu pergunto: isso acontece no planejamento de software?
Hora de mudar de planning driver manager para value driver manager!
Muitas vezes o
Gerenciar um projeto é um empreendimento, por sua natureza, cheio de incertezas plano pode nos
deixar cegos
e mudanças então por que continuamos apenas focado no plano.
“Entregar algo de valor para o cliente é mais importante que seguir o plano.”
“O plano não paga seu salário, quem paga e seu cliente.”
“O que adianta cumprir o escopo do seu planejamento e não cumprir a necessidade de seu cliente.”
O que torna a forma atual de gerenciamento de projetos questionável?
1- Requisitos não são completamente compreendidos no inicio do projeto.
2- Usuários só sabem exatamente o que querem após ver uma versão inicial do software.
3- Requisitos mudam durante o processo de desenvolvimento.
4- Novas ferramentas e tecnologias tornam a estratégia de desenvolvimento imprevisível.
Se você não conhece o problema completamente para poder especificar como acontece na engenharia
civil vou ensinar uma técnica que funciona:
- Calculo Hipotético Utilizando Técnicas Estatísticas. (CHUTE)
O que é Scrum?
Uma definição simples de Scrum: consiste em um conjunto de papéis e práticas simples orientados para o
processo de gerenciamento de projetos, especialmente de software.
Uma definição que eu gosto muito é a seguinte: Scrum é um processo iterativo e incremental para
desenvolvimento de produtos e gerenciamento de projetos.
Alguns autores dizem que o Scrum seria um framework para gerenciamento de projetos, outros insistem
em que Scrum é uma metodologia então nada melhor que uma citação do próprio criador:
“Ken Schwaber disse; Scrum não é uma metodologia, é um framework. O que significa que Scrum não
vai te dizer exatamente o que fazer”.
Como escolher uma metodologia/framework para usar na minha empresa?

7. Para esta escolha observe a complexidade dos seus processos.
Processos empiricos
Complexidade
Processos prescritivos
Pilares do Scrum
Scrum
Transparência Inspeção Adaptação

8. Transparência:
Aspectos que afetam os resultados do projeto devem ser visíveis para os que gerenciam estes resultados.
O que é visto deve ser compreendido: se quem inspeciona o processo acredita que está pronto, isso deve
corresponder à definição de pronto utilizada.
Inspeção:
Os vários aspectos do processo devem ser inspecionados com uma frequência suficiente para que a
variâncias inaceitáveis no processo possam ser detectadas
Adaptação:
Se a inspeção determinar que um ou mais aspectos do processo esta fora dos limites aceitáveis e que o
produto que resultara será inaceitáveis, ele deve ajustar o processo ou o material sendo construído, este
ajuste deve ser feito o mais rápido possível para evitar outros desvios.
Manifesto para o desenvolvimento ágil de software.
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando
outros a fazê-lo. Através deste trabalho, passamos a valorizar:
1. Indivíduos e interação entre eles mais que processos e ferramentas
2. Software em funcionamento mais que documentação abrangente
3. Colaboração com o cliente mais que negociação de contratos
4. Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Fonte: Manifesto Ágil.
O Scrum é composto pelo seguinte:

9. • Tempo da Sprint de 2 •Reunião diaria
a 4 semanas.
•review
• tamanho do time .
• Não modificar o •retrospective
Backlog durante a • Sprint Planning
Sprint. Meeting
• as reuniões devem ser
ser diárias
Regras Eventos
Papéis Artefatos
•Scrum Master •Product Backlog
•Product Owner •Incremento de
•Time Funcionalidades
•Sprint Backlog
•Burndown Chart
Responsabilidades dos papéis definidas pelo Scrum.
Responsabilidades do Scrum Master:
 Permitir que o time seja auto  Facilitar as reuniões do projeto
gerenciável. (Planning Meeting, Daily Meeting,
 Garantir que os caminhos para a Review e Retrospectiva).
comunicação do time estejam abertos
permanentemente.
 Garantir e auxiliar o time a seguir
corretamente as práticas do Scrum.
 Remover qualquer impedimento que o
time encontre.
 Proteger o time de interferências
externas para garantir que sua
produtividade não seja afetada.
Responsabilidades do Product Owner:
 Definir visão do produto.  Atuar como facilitador quando mais de
 Gerenciar retorno sobre investimento um cliente estiver envolvido no
(ROI). projeto.
 Apresentar ao time os requisitos  Colaborar com o time.
necessários para entrega do produto.
 Priorizar cada requisito de acordo com
seu valor para o negocio/cliente.
 Gerenciar a entrada de novos requisitos
e sua priorização.
 Planejar entregas.

10. Responsabilidades do Time:
 Auto-organizáveis.  Responsável para a resolução de
 Multidisciplinares. conflitos.
 Possuem de 5 a 9 membros.
 Comprometidos com o trabalho.
 Focado em metas.
 Responsável por fazer o necessário
para atingir essas metas.
 Comunicativos.
 Organizados em um espaço físico
apropriado para o trabalho.

11. A visão.
Projetos sem
visão é
suicídio. Procurando na internet por imagem que
mostram o fluxo do Scrum vejo que a maioria
começa pelo product backlog, porem todo
projeto Scrum deve iniciar pela visão.
Lembre-se:
 A visão deve ter no mínimo o tamanho de um release.
 Qualquer priorização sem visão é apenas ideia do P.O.
 Visão fixa, product backlog variável.
A visão é um parâmetro que representa o que deve ser satisfeito no final do projeto.
Para a definição da visão o Product Owner colhe informações junto aos usuários finais, clientes, time,
executivos, stakeholders, envolvidos no projeto, etc.
Informações
do Produto
Visão
Informações Informações
do proejto do Processo
O plano mínimo necessário para iniciar um projeto Scrum consiste de um documento de visão e um
product backlog. A visão descreve porque o projeto esta sendo implementado e o que se deseja no final.

12. Uma visão efetiva deve responder os seguintes questionamentos:
 Quem irá comprar o produto?
 Quais os clientes que o produto foca em atender?
 Quais são os usuários alvos?
 Quem são os usuários alvos?
 Quais necessidades do cliente e dos usuários o produto pretende satisfazer?
 Quais atributos o produto deve possuir para satisfazer as necessidades do usuário?
 Quais os atributos do produto garantirão o sucesso do mesmo?
 Quais são os diferenciais do produto em vista dos concorrentes?
O tamanho das Sprints.
O tamanho recomendado pelo Scrum é de sprints com duração de 2 a 4 semanas, porem não devemos nos
deixar cegar seguindo a risca a “receita” do Scrum e ferindo um dos seus princípios de Agilidade:
A Adaptação.
Leve em consideração as seguintes situações para escolher o tamanho de sua Sprint:
 Mudanças constantes no topo do Product backlog e equipes com síndrome de estudante devem
preferentemente trabalhar com sprints curtos.
 Quando existe uma dificuldade em entregar valores aos interessados devem ser usado sprints
curtos.
 Times e/ou clientes cansados de sprints curtos devem aumentar a duração das mesmas.
 O cliente não sabe o que quer? Sprints curtos.
 Sprints muito curto podem ser estressantes.
A síndrome de Estudante:
É a atitude que muitos estudantes têm de começar a se dedicar inteiramente a uma tarefa logo antes do
prazo final.
Dica:
Para saber se o time tem síndrome de estudante observe os dois primeiros e os dois últimos dias de uma
sprints, caso o primeiro dia for tranquilo e o ultimo um caos, sua equipe sofre deste problema.
Para descobrir se você tem síndrome de estudante pense em quantas vezes usa a opção soneca do celular
logo pela manha.

13. Lembre-se:
 O objetivo da Sprint é definido pelo tamanho da mesma, e não o objetivo que define o tamanho
dela.
 Após definir o tamanho da Sprint o mantenha por um largo tempo.
Definindo o estado “Done” (Pronto).
Definição de Done é uma premissa que visa garantir o que está sendo entregue REALMENTE atende as
necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnologia.
Exemplo:
- Implementações com boas práticas de engenharia (ex. testes automatizados).
- Implantações no ambiente de produção.
- Com documentação técnica e de usuário.
Sobre o Done.
 Configurável de estória para estória, projeto para projeto de empresa para empresa.
 É um compromisso entre o time e o product owner referente aos itens do product backlog.
 A qualidade não é negociável na composição do estado Done.
 O pronto deve ser definido apenas para coisas imprescindíveis.
Definindo o estado “Ready” (Preparado).
Uma definição que gosto muito é a Ready (esta não descrita no Scrum) e a ready, que nada mais é que um
compromisso do Product Owner com o time sobre os requisitos dos itens do product backlog.
Exemplos:
 Para quem é importante a user history.
 O que deve ser atendido na user history.
 Porque da user history estar no backlog.
 Protótipo de tela.
Estes são exemplos para que entendam a definição de “ready” que nada mais é que uma especificação
mínima necessária para que o time possa desenvolver seus trabalhos.

14. O Product Backlog.
O Product Backlog é uma lista contendo todas as funcionalidades desejadas para que a visão do produto
seja alcançada.
Esta lista é definida pelo Product Owner e não precisa estar completa no início do projeto. Pode-se
começar com tudo aquilo que é mais óbvio em um primeiro momento. Com o tempo, o Product Backlog
cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Com a lista de itens do product backlog feita, o time prioriza e determinam quais destes itens poderão ser
concluídos durante a execução da Sprint.
Após a priorização tais itens são transferidos do Product Backlog para o Sprint backlog. Ao fazer isso, a
equipe quebra cada item da Sprint Backlog em uma ou mais tarefas, isso ajuda a dividir o trabalho entre
os membros da equipe. Podem fazer parte do Product Backlog tarefas técnicas ou atividades diretamente
relacionadas às funcionalidades solicitadas.
User Stories (procedente do XP).
É uma técnica para representar requisitos em um product backlog. Ela descreve uma funcionalidade que
deve fornecer valor para o usuário ou cliente de um projeto de software.
Story – Writing Workshop.
São reuniões em que desenvolvedores, usuários, clientes, stakeholders, Product Owner e qualquer pessoa
que deseja contribuir e/ou estejam envolvidas no projeto com o objetivo de descobrir estórias.
O que é necessário para fazer um Story – Writing Workshop?
 Folha de rascunhos.
 Post-it.
 Um quadro branco
 Canetas para o quadro (varias cores).
 Canetas e lápis.
 E o principal, as pessoas.
Dicas:
 Focar na quantidade, ao invés de qualidade (estamos em busca de ideias).
 Não perca tempo com detalhes.
 Não julgue as idéias.
 Não se preocupe com as prioridades.
A estrutura de User Story pode ser:
UM [ator]
PODE [fazer algo]
ou o modelo tradicional
COMO [ATOR],
QUERO/DEVO/POSSO[FAZER]
ALGO/PARA[GERAR VALOR]

15. Cuidado:
 Usuário não deve ser mencionado como perfil.
 Detalhes, preferentemente os técnicos não entram nas user stories.
 Pense sempre pela ótica do usuário.
Lembre-se:
 Se quiser requisitos bem definidos não use user stories.
 User stories são ótimas para comunicar uma idéia.
 Responda essas perguntas tendo em mente a visão do produto.
EPIC.
São estórias possui muitas incógnitas para poder saber qual o esforço necessário para ela definida ou
seu esforço é muito grande para ser terminada em uma Sprint pode ser chamada de EPIC.
Há perigo para estimar um epic?
Ao estimar um epic sem antes quebrá-la em varias estórias pequenas pode ser desastrosa pois
geralmente sempre existe uma diferença enorme entre o esforço estimado e o tempo total do epic.
Se for criado um orçamento a partir de um epic pode obrigar a equipe a concluir uma determinada
quantidade de trabalho desconhecida com um orçamento determinado.
Um exemplo:
Esta estratégia é semelhante a uma ida ao supermercado pensando em fazer uma refeição à noite com
uma quantia fixa de dinheiro para gastar, mas nenhuma idéia do que precisa ser comprado. É seguro
assumir que qualquer pessoa nessa situação teria muitas perguntas. O que estou fazendo? Quais são
os ingredientes? Se eu não posso pagar todos os ingredientes, quais são as mais importantes?
Basicamente, este cliente é deixado em uma posição difícil: Ele sabe que tem uma refeição para
preparar e ingredientes para comprar, mas, fora isso, ele está no escuro. O mesmo poderia ser dito do
Product Owner, que se compromete a estimar um epic.
Importante:
 Epic não é um conjunto de estórias.
 Sempre estão nas ultimas posição do backlog.
 Epic sempre vão morrer (quando forem quebrados em estórias menores).
Themes.
É um conjunto grande de estórias relacionadas por um objetivo de negocio importante.
Estes themes podem ser um grupo de estórias pequenas agrupadas referentes a um assunto.
Sprint Planning Meeting.
A reunião Sprint Planning é quando o time e o Product Owner determinam quais funcionalidades e
atividades serão realizadas no próximo Sprint.

16. A reunião conta com a presença do Product Owner, Scrum Master e de todo time, e quaisquer
interessados, diretores ou representantes do cliente.
A Sprint Planning é dividida em duas partes:
 Primeira parte: é decidido o que será feito na Sprint (Planejamento estratégico).
 Segunda parte: é quando o time decide como construirá essas funcionalidades, e as tornará um
incremento do produto durante essa Sprint (Planejamento tático).
Durante a reunião Sprint Planning, o Product Owner explica as funcionalidades de maior prioridade para
o time, e o time faz perguntas que sejam suficientes para que eles possam, depois da reunião, definir quais
atividades eles irão mover do Product Backlog para o Sprint Backlog.
Juntos, o time e o Product Owner definem um objetivo para o Sprint (Meta da Sprint), que é uma breve
descrição do que se pretende atingir na Sprint. O sucesso do Sprint será verificado posteriormente durante
a reunião da Sprint Review, baseado na meta da Sprint em vez de itens específicos do Sprint Backlog.
Depois da reunia de Sprint Planning, o time se reúne separadamente para discutir o que foi dito e decidir
o quanto eles se comprometem a fazer durante o próximo Sprint. Em alguns casos, haverá negociações
com o Product Owner, mas será sempre prerrogativa do time determinar o quanto eles podem se
comprometer.
Considerações
O Product Owner não precisa descrever cada item do Product Backlog. Dependendo do tamanho do item
e da velocidade do time pode ser suficiente para descrever apenas os itens de maior prioridade, deixando
a discussão dos itens de menor prioridade para a próxima reunião Sprint Planning. Normalmente, na
medida em que o time avançar na lista de Product Backlog, ele terá melhor noção do que poderá ser feito
no próximo Sprint.
O tempo da Sprint planning geralmente é de 8 horas para Sprints de um mês ou 5% do tempo da Sprint
caso elas forem menores há um mês.
Lembre-se:
 As metas são definidas pelo time.
 O Product Owner deve vir com o Product Backlog priorizado.
 Somente o time pode saber o que ele é capaz de fazer.
Conselho de W. Edwards Deming.
“Uma meta numérica leva a distorção e ao fingimento especialmente nas situações em que o sistema não
tem condição de atingir a meta”.
Explicação rápida:
Imagine que você esteja colocando como meta um número relacionado ao desempenho do time, então
este time sempre vai limitar seu Sprint backlog a este número, mesmo que seja capaz de ter um
desempenho melhor que a estabelecida.

17. Estimando Story Points.
Quando vamos planejar, normalmente nós não sabemos exatamente quem vai implementar quais partes
de quais estórias.
Estórias normalmente envolvem diversas pessoas e diversos tipos de habilidades (design de interface de
usuário, codificação, teste, etc.).
Para prover uma estimativa, o membro da equipe precisa de algum tipo de entendimento do quê trata a
estória. Pedindo para todos estimarem cada item, nós nos certificamos que cada membro da equipe
compreende do que cada item se trata. Isso aumenta a probabilidade de que os membros se ajudarão
durante o sprint. Isso também aumenta a probabilidade de que questões importantes sobre a estória surjam
cedo.
Quando pedimos que todos estimem uma estória, frequentemente descobrimos discrepâncias onde duas
pessoas da equipe têm estimativas bastante diferentes para a mesma estória. Esse tipo de
coisa é melhor ser descoberto e discutido o quanto antes.
Se você pedir à equipe para que gere uma estimativa, normalmente a pessoa que melhor entende a estória
será a primeira a revelar a sua.
Infelizmente, isso afetará fortemente as estimativas de todo o resto.
Planning poker.
Cada membro da equipe recebe um baralho de 13 cartas, 10 delas com números (seguindo a tabela de
Fibonacci) e as outras três são cartas especiais como descreveremos mais abaixo. Sempre que uma estória
deve ser estimada, cada membro escolhe uma carta que representa a sua estimativa de tempo e coloca-a
virada para baixo sobre a mesa.
Após todos ter estimado a estória as cartas são reveladas, e caso houver uma grande divergência entre
duas estimativas, a equipe discute as diferenças e tenta chegar a uma visão comum do trabalho envolvido
na estória. Eles podem fazer algum tipo de decomposição de tarefas. Depois disso, a equipe faz
novamente à estimativa. Este processo é repetido até chegar a um consenso ou próximo a um.
É importante lembrar aos membros da equipe que eles devem estimar a quantidade total de esforço
envolvido na estória.
Caso deseje estimativas mais precisas, quebre as estórias em tarefas menores e estime-as.
Existem algumas cartas especiais:
 0 = Estória feita ou que leve apenas alguns minutos para a sua conclusão.
 ? = Não se tem idéia do esforço envolvido para terminar essa estória.
 Xícara de café = Pedido de pausa.
Lembre-se:
 O esforço estimado para os itens do product backlog deve ser negociado entre o time e o Product
Owner.
 Use o bom censo (Ambos, o time e o PO).
 Estimar baseando-se em esforço e não em complexidade.
 A quantidade de rounds recomendada para o planning poker é três rodadas, após isso é
desperdício de tempo.
 O Planning poker estimula o dialogo entre os rounds.
 A cada rodada os membros que mostram as estimativas mais extremas (tanto a menor quanto a
maior) devem explicar por que estimaram o item com aquele tamanho.
 Você pode comparar as suas estimativas com o que já foi estimado e não com o que ainda falta
estimar.
 Itens com tamanho 40 ou 100 são considerados EPIC e devem ser quebrados.
Na parte tática da Sprint planning Meeting, o time trata a questão de “como?”, ou seja, decide como
transformara aquela parte que foi selecionada do product backlog em um incremento pronto e
implementado.

18. Nesta parte da reunião as estórias são quebradas em tarefas, e as tarefas descompostas em atividades que
possam ser realizadas em menos de um dia, esta lista de tarefas são denominadas Sprint backlog.
Lembre-se:
 É responsabilidade do time se auto-organizar para delegar e se encarregar das tarefas da Sprint
backlog.
 O Product Owner deve estar presente nesta parte da reunião para esclarecer duvidas sobre os
itens e caso for necessário renegociar as estórias selecionadas para compor a Sprint Backlog.
 Nesta parte da reunião podem estar presentes outras pessoas que tenham domínio sobre os
assuntos técnicos ou de negocio que envolve a Sprint backlog.
 Meta da Sprint é o que o time tem o “compromisso” que alcançar.
 Plano da Sprint é o que o time “pretende” alcançar.
No final da Sprint planning teremos:
 Um conjunto de itens do product backlog que foram selecionados para fazer parte da nossa
Sprint backlog.
 Os itens selecionados quebrados em tarefas.
 A meta da Sprint.
Execução da Sprint.

19. A reunião diária.
Diariamente o time realiza uma reunião de 15 minutos na qual os membros devem responder a três
perguntas:
 O que fiz desde a ultima reunião?
 O que pretendo fazer até a próxima?
 Tive ou estou tendo algum impedimento?
Importância da reunião diária:
 Todos sabem o que todos estão fazendo (transparência).
 Ajuda a remover impedimentos.
 Ajuda a descobrir impedimentos.
 Sincroniza o trabalho da equipe.
 Estabelecer um compromisso do membro com a equipe sobre o que ele vai fazer até a próxima
reunião diária.
Mudanças no Sprint Backlog durante sua execução.
O que o time se comprometeu a entregar ao Product Owner é o que deve ser entregue.
As mudanças que alterem a meta não são permitidas.
Caso haja alguma mudança no Sprint backlog que torne a meta inalcançável ou mesmo mude a meta este
Sprint deve ser encerrado e imediatamente iniciar o planejamento para o próximo Sprint, isto também
ocorre caso o time perceber que não vai conseguir atingir a meta.
Sprint Review.
É uma reunião com duração de 4 horas para sprints de um mês, caso a Sprint for menor há um mês esta
reunião não deve durar mais que 5% do tempo da Sprint.
No final de cada Sprint uma reunião de revisão da Sprint é realizada. Durante esta reunião o time mostra
o que eles realizaram durante o Sprint. Normalmente, este assume a forma de uma demonstração das
novas funcionalidades do produto.
A reunião de revisão de Sprint é intencionalmente mantida muito informal, tipicamente com regras
proibindo o uso de slides do PowerPoint e não permitindo mais de duas horas de tempo de preparação
para a reunião. A reunião de revisão de Sprint não deve se tornar uma distração ou desvio significativo
para a equipe, mas sim, deve ser um resultado natural do Sprint.

20. Participantes em uma Sprint Review
Participantes na revisão de Sprint tipicamente incluem o time, o Product Owner, o Scrum Master,
gerência, clientes e desenvolvedores de outros projetos.
Importância da Sprint Review.
 A equipe ganha crédito por suas realizações.
 Outros aprendem o que sua equipe está fazendo.
 A apresentação atrai feedback vital dos stakeholders.
 Apresentações é (ou deveriam ser) um evento social onde equipes diferentes podem interagir
umas com as outras e discutir seu trabalho.
 Fazer uma apresentação força a equipe a realmente terminar as coisas e liberá-las
Consequências da Review.
 Devolver ao Product Owner funcionalidades não terminadas e priorizá-las.
 Remover do Product Backlog atividades que foram realizadas antecipadamente.
 Trabalhar com o Scrum Master para reformular as equipes.
 Priorização do product backlog.
Lembre-se:
 Não existe Review sem Product Owner.
 A Review e focada em apresentar valor e não especificações técnicas.
 A Review é a parte interativa do Scrum.
Retrospectiva.
Após a reunião de revisão de Sprint, a equipe e o Scrum Master se reúnem para a reunião de
retrospectiva. Durante esta reunião, a equipe considera três coisas: o que correu bem, o que não fez, e que
melhorias poderiam ser feitas no Sprint seguinte. Sem o Product Owner nesta reunião, os membros da
equipe podem falar francamente sobre os sucessos e fracassos. É uma oportunidade especialmente
importante para a equipe se concentrar em seu desempenho global e identificar estratégias para melhorar
seus processos. Além disso, ela permite que o Scrum Master observe impedimentos que tenham
impactado no desempenho da equipe, e em seguida, trabalhar para resolvê-los.
Lembre-se:
 O objetivo da Retrospectiva é melhorar o processo Scrum.
 A Retrospectiva é a parte incremental do Scrum.

21. Ciclo de vida de um projeto Scrum

22. Para refletir
Acho que vi isso em um livro. Creio que essa seja a melhor definição para o que são as metodologias
ágeis. Vale a pena tentar aprender, incentivar e ingressar em seus projetos seja eles os mais diversos.
"Agilidade é a habilidade de criar e responder a mudanças com respeito ao resultado financeiro do projeto
em um turbulento ambiente de negócios. Agilidade é a habilidade de balancear flexibilidade com
estabilidade". (Highsmith, Jim. Agile Project Management, 2002)
Diferença entre Problema e Impedimento.
Problema:
Um problema é uma dificuldade na obtenção de um determinado objetivo.
Os problemas devem ser resolvidos entre os membros da equipe, sem a interferência do Scrum Master ou
qualquer outra pessoa.
Impedimento:
Um impedimento é uma dificuldade na obtenção de um determinado objetivo, no qual a resolução do
mesmo não está nas mãos do time.
Nesta situação o Scrum máster deve tomar as atitudes para que este impedimento não atrapalhe a meta da
Sprint.