Curso de

Scrum
 M e t o d o lo g ia s Á g e is

Agenda
• Manifesto Ágil

• Os fundamentos do Scrum

• O Time Scrum

• Eventos do Scrum

• Artefatos do Scrum

• Considerações Finais
 M e t o d o lo g ia s Á g e is

Manifesto Ágil
• Em 2001, um grupo de profissionais veteranos na área de software decidiram se reunir
em uma estação de esqui, nos EUA, para discutir formas de melhorar o desempenho
de seus projetos.

• Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um
projeto de software ter sucesso, cada qual com as suas particularidades, todos
concordavam que, em suas experiências prévias, um pequeno conjunto de princípios
sempre parecia ter sido respeitado quando os projetos davam certo.
 M e t o d o lo g ia s Á g e is

Manifesto Ágil
Com base nisso eles criaram o Manifesto para o Desenvolvimento Ágil de Software,
frequentemente chamado apenas de Manifesto Ágil, e o termo Desenvolvimento Ágil
passou a descrever abordagens de desenvolvimento que seguissem estes princípios, que
são apresentados a seguir.
 Me t odologia s Á ge is

Manifesto Ágil
• Estamos descobrindo melhores formas de desenvolver software através da nossa
própria prática e auxiliando outros.

Valores

• Indivíduos e Iterações • Processos e Ferramentas

• Software funcionando • Documentação detalhada
• Colaboração com cliente • Negociação de contratos
• Responder a mudanças • Seguir um plano
 M e t o d o lo g ia s Á g e is

Princípios da agilidade
 A mais alta prioridade é a satisfação do cliente, por meio da
liberação mais rápida e contínua de software de valor.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade
 Receba bem as mudanças de requisitos, mesmo em estágios
tardios do desenvolvimento. Processos ágeis devem admitir
mudanças que trazem vantagens competitivas para o cliente.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade
 Libere software frequentemente (em intervalos de 2 semanas
até meses), dando preferência para uma escala de tempo mais
curta.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade

 Mantenha pessoas ligadas ao negócio (clientes) e

desenvolvedores trabalhando juntos a maior parte do tempo do
projeto.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade

 Construa projetos com indivíduos motivados, dê a eles o

ambiente e suporte que precisam e confie neles para ter o
trabalho realizado.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade
 O método mais eficiente e efetivo para repassar informação
entre uma equipe de desenvolvimento é pela comunicação face-
a-face
 Me t odologia s Á ge is

Princípios da agilidade

 Software funcionando é a principal medida de progresso de um

projeto de software.

 Processos ágeis promovem desenvolvimento sustentado. Assim,

patrocinadores, desenvolvedores e usuários devem ser
capazes de manter conversação pacífica indefinidamente.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade
 A atenção contínua para a excelência técnica e um bom projeto
(design) aprimoram a agilidade.

 Simplicidade - a arte de maximizar a quantidade de trabalho não

feito – é essencial, devendo ser assumida em todos os aspectos
do projeto.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade
 As melhores arquiteturas, requisitos e projetos emergem de equipes auto
organizadas.
 M e t o d o lo g ia s Á g e is

Princípios da agilidade

 Em intervalos regulares, as equipes devem refletir sobre como se tornarem

mais efetivas, e então refinarem e ajustarem seu comportamento de acordo.
 M e t o d o lo g ia s Á g e is

Princípios e valores

Os valores apresentam uma visão do desenvolvimento de software como

um jogo de cooperação para inventar e comunicar cujo objetivo primário é
entregar algo útil e, se preparar para o próximo jogo.

Os valores pregam que os métodos são centrados nas

pessoas e nas suas comunicações, sendo altamente
tolerantes a modificações por levarem em conta as
diferenças entre as pessoas.
 M e t o d o lo g ia s Á g e is

Os princípios do Crystal
 Entrega frequente. A propriedade mais importante de praticamente todos os
projetos é garantir a entrega de um software funcionando e pronto em um período
curto de tempo, e de forma frequente.

 Melhorias reflexivas. Permite que falhas sejam revertidas em sucesso. Para isso
a equipe se reúne para discutir o que pode funcionar melhor na próxima iteração e
como pode aplicar essas mudanças de melhoria.

 Comunicação osmótica. A comunicação osmótica, também conhecida como

comunicação cara a cara, é a informação que surge naturalmente entre os
membros do Time, fazendo com que estes consigam captar as partes mais
importantes do processo. A melhor forma de proporcionar essa comunicação é
colocar a equipe na mesma sala, assim todos conversem entre si, e a comunicação
vai de um para o outro como se estivessem pegando as informações por osmose.

Observação: a comunicação cara a cara é a maneira mais barata e rápida de

trocar informações
 M e t o d o lo g ia s Á g e is

Os princípios do Crystal
 Foco. O foco é sem dúvida um princípio fundamental quando se fala em saber
no que se deve trabalhar, e as equipes precisam ter esse conhecimento. As
equipes precisam estar confortáveis para trabalhar nas tarefas que lhes foram
demandadas. Essa tranquilidade vem de um ambiente onde as pessoas não
são retiradas repentinamente de sua tarefa para realizar outra atividade não
acordada e fora do contexto.
 Segurança pessoal. Este é um princípio bem interessante e importante que o
Crystal reforça. Refere-se à possibilidade de dizer sempre quando algo está
incomodando, sem medo de represálias ou perseguições. Essa liberdade de
expressão deve recair sobre todos do Time e em qualquer direção, por exemplo:
poder dizer a um gerente que o planejamento dele não está bom, ou que um
colega desenvolvedor não escreveu bem um código..

Observação: as equipes precisam descobrir e trabalhar suas fraquezas. Sem

segurança pessoal ninguém falará e todos vão continuar se prejudicando,
prejudicando os outros e todo o projeto.
 M e t o d o lo g ia s Á g e is

Os princípios do Crystal

 Fácil acesso aos especialistas. É importante que a equipe do projeto tenha

acesso a especialistas que possam contribuir com entregas e testes
frequentes do time. Esse acesso permite rápidos e frequentes feedbacks sobre
a qualidade do produto produzido e entregue, além de facilitar a tomada de
decisões.
 Excelência técnica. Ambientes técnicos com testes automatizados,
gerenciamento de configuração e integração contínua proporcionam um
caminho para a excelência técnica.

Todo projeto possui necessidades próprias – e, portanto,

requer uma metodologia própria. É por isso que o Crystal tem
uma aplicação eficiente
 M e t o d o lo g ia s Á g e is

Boas Práticas Ágeis - INVEST

• Independente. A história precisa ser independente das demais, para não dificultar a sua
completa finalização.
• Negociável. A história não pode ser algo imutável; é necessário poder negociá-la com a
cliente, alterando data de entrega, conteúdo e até mesmo retirando-a ou substituindo-a.
• Valiosa. Toda história deve gerar valor ao cliente, valor este que precisa ser apoiado através
de uma concordância formal ou informal. Histórias que não gerem valor precisam ser
removidas do backlog do produto.
• Estimável. O Time deve ser capaz de estimar o tamanho de cada história e o esforço para
completá-la.
• Dimensionada apropriadamente. Muitos interpretam essa característica como pequena
(scalable), mas é mais seguro pensar em um tamanho apropriadamente dimensionado. Uma
história pequena demais não é recomendada, nem uma história grande demais. Muitas vezes
uma história atinge o seu tamanho adequado quando o Time consegue estimá-la com
segurança.
• Testável. Toda história deve poder ser testada, e o Time precisa entender quais serão os
critérios de teste e aceitação.

Histórias INVEST contribuem para que as estimativas sejam mais assertivas e

ajudam o Time a definir melhor os objetivos das Sprints e a atingir a meta de
entregas e de projetos.
 M e t o d o lo g ia s Á g e is

Tarefas SMART
É recomendável utilizar o conceito SMART para escrever uma tarefa, de forma que ela seja
específica (S – Specific), mensurável (M – Measurable), realizável (A – Achievable),
relevante (R – Relevant) e que tenha uma duração fixa (T – Time-boxed).
As boas práticas para escrever uma tarefa SMART são:
• Específica. A tarefa deve ser específica o suficiente para que todos possam atender e
compreender que história ela ajudará a completar.
• Mensurável. Todas as tarefas precisam ser medidas, assim como suas histórias. Caso
contrário, não será possível saber quantas tarefas caberão em um dia e muito menos quantas
tarefas serão realizadas dentro de uma Sprint.
• Realizável. Cada tarefa deve poder ser feita de forma independente. A dependência ou
deficiência precisa ser identificada e removida.
• Relevante. Todas as tarefas devem ser individualmente relevantes para completar pelo menos
uma história do backlog. Uma tarefa inútil deve ser removida do Quadro de Tarefas.
• Duração fixa. O conceito de duração fixa ou time-boxed pode ser aplicado para criar tarefas
que caibam em um dia de trabalho. As tarefas precisam caber dentro da Sprint que está sendo
realizada.
Tarefas SMART contribuem para a criação de atividades que
Time conseguirá realizar com mais segurança e de maneira
mais assertiva quanto a prazo, qualidade e custo
 O s F u n d a me n tos d o Sc r u m

O que é Scrum?
• O Scrum é um método de reinício de jogada no rugby, onde os jogadores dos
dois times se juntam com a cabeça abaixada e se empurram com o objetivo
de ganhar a posse de bola
 O s F u n d a me n tos d o Sc r u m

O que é Scrum?
 Scrum é um framework dentro do qual pessoas podem tratar e resolver
problemas complexos de modo adaptativo, enquanto procuram entregar
produtos com o mais alto valor possível do mais produtivo e criativo possível,
sempre visando a satisfação do cliente.
 O s F u n d a me n tos d o Sc r u m

Scrum

 Uma alternativa de utilizar métodos ágeis na gerência de projeto

 Pode ser aplicável a qualquer tipo de projeto.

 É simples
– Processo, artefatos e regras são poucos e fáceis de
entender
– A simplicidade pode ser decepcionante aos
acostumados com metodologias clássicas.
 O s F u n d a me n tos d o Sc r u m

Características do Scrum
 É um conjunto de processos Leve, que não demanda muito esforço ou
ferramentas pesadas para sua prática

 É relativamente Simples de entender e praticar

 É Extremamente difícil de dominar, apesar de sua simplicidade, o jeito de

pensar ágil força o profissional a abrir mão de diversos conceitos enraizados
pelos métodos tradicionais e o força a pensar em qualidade e entrega
contínua.
 O s F u n d a me n tos d o Sc r u m

Teoria do Scrum
 O Scrum foi fundamentado nas teorias empíricas de controle de processo, ou
empirismo.

 O empirismo afirma que o conhecimento vem da experiência e de tomada de

decisões baseadas no que é conhecido.

 O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a

previsibilidade e o controle de riscos.
 O s F u n d a me n tos d o Sc r u m

Os três pilares do Scrum

• Transparência
• Aspectos e informações relevantes do seu projeto devem estar
sempre visíveis e claros para todos os participantes do projeto.
Os responsáveis pelos resultados do projeto tem a solene
responsabilidade de manter uma comunicação clara e promover
constantemente a transparência.
 O s F u n d a me n tos d o Sc r u m

Os três pilares do Scrum

• Inspeção

• Os profissionais do time Scrum devem, frequentemente, inspecionar os artefatos

Scrum e o progresso do projeto a fim de detectar prontamente indesejáveis variações.
Esta inspeção, não deve no entanto, ser tão frequente que atrapalhe a própria
execução das tarefas.

• As inspeções quando realizadas de forma diligente, sem exageros, por profissionais

especializados no trabalho de garantia de qualidade são normalmente as que obtém
melhores resultados.
 O s F u n d a me n tos d o Sc r u m

Os três pilares do Scrum

 Adaptação

 A adaptação é um dos pilares mais importantes do Scrum. Através deste

prisma de tomada de ação, o projeto passa a ter mais foco na qualidade de
entrega do produto do que normalmente ocorre em projetos tradicionais.

 Um modo de se verificar a adaptação no mundo real é quando situações

imprevistas acontecem na rotina do projeto e as datas acordadas junto aos
nossos clientes ou mesmo os requisitos não mudam.
 O s F u n d a me n tos d o Sc r u m

Dicas Importantes
• O Scrum oferece quatro oportunidades formais para promover a
transparência, inspeção e adaptação.

 Reunião de planejamento da Sprint (O famoso Sprint Planning)

 Reunião diária (Daily Scrum ou Standup Meetings)
 Reunião de revisão da Sprint (Também conhecida como Sprint Review)
 Retrospectiva da Sprint
 O s F u n d a me n tos d o Sc r u m

Valores do Scrum?
 Foco na Entrega
 Transparência
 Time-Box
 Qualidade Total
 Trabalho em Equipe
 Comunicação Constante
 Comprometimento
 Auto Gerenciamento
 Trazer à tona os problemas
 O s F u n d a me n tos d o Sc r u m

Princípios da Auto-Organização
• Este princípio é um dos mais difíceis para a transição ao método ágil, pois
demanda confiança na equipe e por outro lado, a responsabilidade dos
indivíduos para com as entregas comprometidas.
 O s F u n d a me n tos d o Sc r u m

Princípios da Auto-Organização
• A maioria dos profissionais que atuam em métodos tradicionais desconfiam
do pleno funcionamento deste princípio, porém, se não aplicado, não há
Scrum.
• Pois a equipe tem um papel fundamental na condução dos Sprints e a sua
atuação independente e responsável é o fator de sucesso que o projeto
precisa.
 O s F u n d a me n tos d o Sc r u m

Organizar e Dividir o Trabalho

 Não necessariamente o time todo deve ser Sênior, porém a auto-organização
requer comprometimento e responsabilidade desde o primeiro dia de
projeto.
 O s F u n d a me n tos d o Sc r u m

A Mitologia Ágil

• Juntamente com o Scrum surgem diversas desconfianças, que na maioria das vezes
se transformaram em mitologia em relação ao método ágil, isto é, mais do que
preconceitos, são mitos gerados por profissionais que desconhecem o Scrum ou
temem sua aplicação prática.

Mitologia
 Metodologias Ágeis

Product Owner
 Responsável por apresentar os interesses de todos os Stakeholders
 Define fundamentos iniciais do projeto, objetivos e planos de release
 Responsável pela lista de requisitos (Product Backlog)
 Certifica se as atividades com maior valor para o negócio são
desenvolvidas primeiro
– Priorização frequente das funcionalidades antes de
cada iteração.
 Metodologias Ágeis

Product Owner
 O Product Owner é uma pessoa e não um comitê.

 Algumas empresas podem tender a delegar esta responsabilidade para um comitê,

porém, para que isso funcione adequadamente, é necessário que um profissional
seja o responsável por assumir tal papel e assim desempenhar os pilares do Scrum
nesta função.

 Para que o Product Owner tenha sucesso, toda a organização deve respeitar as
suas decisões.

 As decisões do Product Owner são visíveis no conteúdo e na priorização do

Backlog do Produto.
 M e t o d o lo g ia s Á g e is

Product Owner
 Metodologias Ágeis

Scrum Team
 Responsável por escolher as funcionalidades a serem desenvolvidas em cada
interação e desenvolvê-las.

 O time se auto gerencia, se auto organiza.

 Todos os membros do time são

coletivamente responsáveis pelo
sucesso de cada iteração
 Metodologias Ágeis

Scrum Team - Características

 Eles são auto organizadas. Ninguém (nem mesmo o Scrum Master) diz a Equipe de
Desenvolvimento como transformar o Backlog do Produto em incrementos de
funcionalidades potencialmente utilizáveis;

 Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades

necessárias, enquanto equipe, para criar o incremento do Produto

 O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que

não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado
pela pessoa; Não há exceções para esta regra.
 Metodologias Ágeis

Scrum Team - Características

 Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades
especializadas e área de especialização, mas a responsabilidade pertence à Equipe de
Desenvolvimento como um todo;

 Equipes de Desenvolvimento não contém sub-equipes dedicadas a domínios

específicos de conhecimento, tais como teste ou análise de negócios.
 O T IM E SC R U M

Tamanho do Scrum Team

 O tamanho ideal da Equipe de Desenvolvimento é pequeno o suficiente para se manter ágil
e grande o suficiente para completar uma parcela significativa do trabalho.

 Menos de três integrantes na Equipe de Desenvolvimento

diminuem a interação e resultam em um menor ganho
de produtividade.

 Equipes de desenvolvimento menores podem

encontrar restrições de habilidades durante a
Sprint, gerando uma Equipe de Desenvolvimento
incapaz de entregar um incremento potencialmente
utilizável.

 Havendo mais de nove integrantes é exigida

muita coordenação. Equipes de Desenvolvimento
grandes geram muita complexidade para um processo
empírico gerenciar. Os papéis de Product Owner e do
Scrum Master não são incluídos nesta contagem.
 O T IM E SC R U M

Scrum Master
 Responsável pelo sucesso do Scrum
 Ensina o Scrum para os envolvidos com o projeto
 Implementa o Scrum na empresa de forma
adaptada a sua cultura, para continuamente
gerar benefícios
 Certifica se cada pessoa envolvida está
seguindo seus papéis e as regras do Scrum
 Certifica que pessoas não responsáveis
não interfiram no processo
 O T IM E S C R U M

Scrum Master
• Ele é ponto focal entre o Scrum Team e o restante dos Stakeholders. Uma das
suas principais contribuições é a ajuda na comunicação adequada com o
Scrum Team, evitando quaisquer viés de comunicação ou pedidos informais
de alteração do product backlog.
 O T IM E SC R U M

Scrum Master / Product Owner

 Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
 Tornando a visão do projeto bem clara e objetiva, ainda esclarecendo dúvidas
a respeito dos itens do Backlog do Produto para a Equipe de
Desenvolvimento;
 Ensinar o Scrum Team a criar itens de Backlog do Produto de forma clara, no
padrão de qualidade adequado e concisa;
 Compreender a estratégia de planejamento do Produto no ambiente
empírico e tornar isso realidade junto ao Scrum Team;
 É o guardião dos processos Scrum e age como apoio direto do Product Owner.
 Facilitar os eventos Scrum conforme exigidos ou necessários.
 O T IM E S C R U M

Scrum Master / Scrum Team

 Treinar a Equipe em autogerenciamento e disciplina de entrega;

 Ensinar e liderar a Equipe de Desenvolvimento na criação de produtos de
alto valor; Isso pode incluir a aplicação de técnicas de qualidade,
desenvolvimento e gerenciamento do tempo;
 Remover impedimentos para o progresso do Scrum Team;
 Facilitar os eventos Scrum exigidos ou necessários (Reuniões);
 Treinar a Equipe de Desenvolvimento em ambientes organizacionais nos
quais o Scrum não é totalmente adotado e compreendido.
 Transmitir a visão da estratégia de desenvolvimento do produto e as
respectivas expectativas do Product Owner.
 O T IM E SC R U M

Scrum Master / Organização

 Responsável pela transição para o modelo ágil;

 Liderando e treinando a organização na adoção do Scrum;
 Planejando implementações Scrum dentro da organização;
 Ajudando funcionários e partes interessadas a compreender e
tornar aplicável o Scrum e o desenvolvimento de produto empírico;
 Causando mudanças que aumentam a produtividade do Time
Scrum;
 Trabalhando com outro Scrum Master para aumentar a eficácia da
aplicação do Scrum nas organizações.
 EVEN TO S SC R U M

Eventos Scrum
• O Scrum se utiliza de uma série de eventos ou cerimônias a de se criar um
padrão de comunicação e também colocar os seus pilares em ação,
minimizando assim a necessidade de reuniões adicionais ou excessivas.
 EVEN TO S SC R U M

Eventos Scrum
• O Scrum usa eventos time-boxed, isto é, todo evento tem uma duração
máxima. Isto garante que uma quantidade adequada de tempo seja gasta no
planejamento evitando desperdício de tempo e garantindo maior agilidade.
 EVEN TO S SC R U M

Eventos Scrum
• Além da Sprint, que é um evento base para as demais cerimônias, cada
evento no Scrum é uma oportunidade de inspecionar e adaptar alguma coisa.

• Estes eventos são especificamente projetados para permitir uma

transparência e inspeção criteriosa. A não inclusão de qualquer um dos
eventos resultará na redução da transparência e da perda de oportunidade
para inspecionar e adaptar.
 EVEN TO S SC R U M

Sprint

• Este é o coração do Scrum.

• É a Sprint, um time-box de normalmente
um mês ou menos, durante o qual um
produto potencialmente utilizável é
criado.
 E V E N TO S S C R U M

Sprint
• Os Sprints tem durações coerentes em todo o esforço de desenvolvimento.
Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior.
 EVEN TO S SC R U M

Sprint
• As Sprints são compostas por uma reunião de planejamento da:

 Sprint (Sprint Planning);

 Reuniões diárias (Daily Scrums);

 O trabalho de desenvolvimento, uma revisão da Sprint (Sprint Review) e;

 Retrospectiva da Sprint.
 E V E N TO S S C R U M

Durante a Sprint

 Não são feitas mudanças que podem afetar o objetivo da Sprint;

 A composição do Scrum Team permanece constante;

 As metas de qualidade não diminuem;

 O escopo pode ser clarificado e renegociado entre o Product Owner e a

Equipe de Desenvolvimento quanto mais for aprendido.
 E V E N TO S S C R U M

Sprint
• De acordo com o Scrum Guide, as Sprints são limitadas a um mês corrido.
• Quando o horizonte da Sprint é muito longo, a definição do que será
construído pode mudar, a complexidade pode aumentar e o risco pode
crescer, isso é a essência da entrega contínua e com qualidade do Scrum.
 EVEN TO S SC R U M

Sprint
 O time recebe uma parte do
backlog para desenvolvimento

 O backlog não sofrerá

modificações durante o Sprint

 Duração de 1 a 4 semanas

 Sempre apresentam um executável 4 semanas

ao final
 E V E N TO S S C R U M

Cancelamento da Sprint

• Uma Sprint pode ser cancelada antes do time-box da Sprint terminar.

• Somente o Product Owner tem a autoridade para cancelar a Sprint, embora

ele (ou ela) possa fazer isso sob influência das partes interessadas, do Scrum
Team ou do Scrum Master.
 E V E N TO S S C R U M

Cancelamento da Sprint
• A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto
pode ocorrer se a organização mudar sua direção ou se as condições do
mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser
cancelada se ela não faz mais sentido às dadas circunstâncias.

• No entanto, devido a curta duração da Sprint, raramente cancelamentos

fazem sentido.
 EVEN TO S SC R U M

Cancelamento da Sprint
• Quando a Sprint é cancelada, qualquer item de Backlog do Produto
completado e “Pronto” é revisado. Se uma parte do trabalho estiver
potencialmente utilizável, tipicamente o Product Owner o aceita.

• Todos os itens de Backlog do Produto incompletos são re-estimados e

colocados de volta no Backlog do Produto. O trabalho feito se deprecia
rapidamente e deve ser frequentemente re-estimado.
 EVEN TO S SC R U M

Reuniões do Scrum
 Planejamento
 Sprints
 Reuniões Diárias
 Revisão
 Retrospectivas
 Encerramento
 E V E N TO S S C R U M

Reunião de Planejamento
• O trabalho a ser realizado na Sprint é planejado na reunião de planejamento da
Sprint (Sprint Planning).

• Este plano é criado com o trabalho colaborativo de todo o Scrum Team.

• A reunião de planejamento da Sprint é uma time-box de oito horas para uma Sprint
de um mês de duração.

• Para Sprints menores, este evento deve ser proporcionalmente menor. Por exemplo,
uma Sprint de duas semanas terá uma reunião de planejamento de Sprint de quatro
horas.
 EVEN TO S SC R U M

Reunião de Planejamento
• Relativamente curto
• Projeto da arquitetura do sistema
• Estimativas de datas e custos
• Criação do backlog
 Participação de clientes e outros
departamentos
 Levantamento dos requisitos e atribuição de
prioridades
• Definição de equipes e seus líderes
• Definição de pacotes a serem desenvolvidos
 O T IM E SC R U M

Reunião de Planejamento
• A reunião de planejamento da Sprint consiste em duas partes, cada uma sendo uma
time-box de metade do tempo de duração da reunião de planejamento da Sprint. As
duas partes da reunião de planejamento da Sprint respondem as seguintes questões,
respectivamente:

 O que será entregue como resultado do incremento da próxima Sprint?

 Como o trabalho necessário para entregar o incremento será realizado?

 EVEN TO S SC R U M

Objetivo ou Meta da Sprint

• O objetivo da Sprint dá a Equipe de Desenvolvimento alguma flexibilidade em
relação as funcionalidades a serem implementadas dentro da Sprint.

• Conforme o Scrum Team trabalha, ela mantém o objetivo em mente, e no caminho

de buscar satisfazer o objetivo da Sprint, ela implementa a funcionalidade e a
tecnologia.

• Caso o produto entregue seja diferente do esperado pelo Product Onwer, então os
membros do ScrumTeam colaboram para negociar o escopo do Backlog da Sprint
dentro da Sprint.
 EVEN TO S SC R U M

Reunião Diária ou Daily Scrum

• A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que o Scrum
Team possa sincronizar as atividades e criar um plano para as próximas 24 horas.

• Esta reunião é facilitada pelo Scrum Master e é feita para inspecionar o trabalho desde
a última Reunião Diária, e prever o trabalho que deverá ser feito antes da próxima
Reunião Diária.
 E V E N TO S S C R U M

Reunião Diária ou Daily Scrum

 Cerca de 15 minutos de duração

 Todos respondem às perguntas:
 O que foi completado desde a última reunião?
 O que será feito até a próxima reunião?
 Quais os impedimentos que estão no caminho?
 Benefícios:
 Maior integração entre os membros da equipe
 Rápida solução de problemas
 Promovem o compartilhamento de conhecimento
 Progresso medido continuamente
 Minimização de riscos
 EVEN TO S SC R U M

Reunião Diária ou Daily Scrum

• O Scrum Team usa a Reunião Diária para avaliar o progresso em direção ao
objetivo da Sprint e para avaliar se o progresso tende para completar o
trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade da
Equipe de Desenvolvimento atingir o objetivo da Sprint.
 E V E N TO S S C R U M

Reunião Diária ou Daily Scrum

• O Scrum Master assegura que o Scrum Team tenha a reunião, mas a Equipe
de Desenvolvimento é responsável por conduzir a Reunião Diária.

• O Scrum Master ensina a Equipe de Desenvolvimento a manter a Reunião

Diária dentro da time-box de 15 minutos. Esta parte é uma das mais
importantes a fim de se manter a ordem e obter ganhos de produtividade.
 EVEN TO S SC R U M

Reunião Diária ou Daily Scrum

• Reuniões Diárias melhoram as comunicações, eliminam outras reuniões,
identificam e removem impedimentos para o desenvolvimento, destacam e
promovem rápidas tomadas de decisão, e melhoram o nível de conhecimento
da Equipe de Desenvolvimento.

• Esta é uma reunião chave para inspeção e adaptação.

 EVEN TO S SC R U M

Revisão da Sprint ou Sprint Review

• A Revisão da Sprint é executada no final da Sprint para

inspecionar o incremento e adaptar o Backlog do Produto se
necessário.
 EVEN TO S SC R U M

Revisão da Sprint ou Sprint Review

• Durante a reunião de Revisão da Sprint o Scrum Team e as partes
interessadas colaboram sobre o que foi feito na Sprint. Com base nisso
e em qualquer mudança no Backlog do Produto durante a Sprint, os
participantes colaboram nas próximas coisas que precisam ser prontas.

• Esta é uma reunião informal, e a apresentação do incremento destina-

se a motivar e obter comentários e promover a colaboração.
 EVEN TO S SC R U M

Revisão da Sprint ou Sprint Review

 O Product Owner identifica o que foi “Pronto” e o que não foi “Pronto”;

 A Equipe de Desenvolvimento discute o que foi bem durante a Sprint, quais

problemas ocorreram dentro da Sprint, e como estes problemas foram
resolvidos;

 A Equipe de Desenvolvimento demonstra o trabalho que está “Pronto” e

responde as questões sobre o incremento;

 O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela)
projeta as prováveis datas de conclusão baseado no progresso até a data;

 O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião de
Revisão da Sprint fornece valiosas entradas para a Reunião de Planejamento
da próxima Sprint.
 EVEN TO S SC R U M

Revisão da Sprint ou Sprint Review

• O resultado da Reunião de Revisão da Sprint é um Backlog do Produto
revisado que define o provável Backlog do Produto para a próxima Sprint.

• O Backlog do Produto pode também ser ajustado completamente para

atender novas oportunidades.
 EVEN TO S SC R U M

Retrospectiva da Sprint
• A Retrospectiva da Sprint é uma oportunidade para o Scrum Team
inspecionar a si próprio e criar um plano para melhorias a serem aplicadas na
próxima Sprint.

• A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da reunião

de planejamento da próxima Sprint.

• Esta é uma reunião time boxed de três horas para uma Sprint de um mês.

• Proporcionalmente um tempo menor é alocado para Sprints menores.

 EVEN TO S SC R U M

Propósito da Retrospectiva
 Inspecionar como a última Sprint foi em relação as pessoas, relações,
processos e ferramentas;

 Identificar e ordenar os principais itens que foram bem e as potenciais

melhorias;

 Criar um plano para implementar melhorias no modo que o Time Scrum faz
seu trabalho;
 EVEN TO S SC R U M

Retrospectiva da Sprint
• O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo
do framework do Scrum, o processo de desenvolvimento e as práticas
para fazê-lo mais efetivo e agradável para a próxima Sprint.

• Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de

aumentar a qualidade do produto, adaptando a definição de “Pronto”
quando apropriado.
 EVEN TO S SC R U M

Retrospectiva da Sprint
• Ao final da Retrospectiva da Sprint, o Time Scrum
deverá ter identificado melhorias que serão implementadas
na próxima Sprint.

• A implementação destas melhorias na próxima Melhorias

Sprint é a forma de adaptação à inspeção que

o Time Scrum faz a si próprio.

• A Retrospectiva da Sprint fornece um evento

dedicado e focado na inspeção e adaptação,
no entanto, as melhorias podem ser adotadas
a qualquer momento.
 A R T EFATOS D O SC R U M

Artefatos do Scrum
• Os artefatos do Scrum são excelentes ferramentas de apoio para a prática
dos pilares do Scrum, bem como, apoiar as tomadas de decisões do Scrum
Master e Product Owner e prover informações significativas para o Scrum
Team.
 A R T EFATOS D O SC R U M

Backlog do Produto
• O Backlog do Produto é uma lista ordenada de
tudo que deve ser necessário no produto, e é uma
origem única dos requisitos para qualquer mudança
a ser feita no produto.

• O Product Owner é responsável pelo Backlog do

Produto, incluindo seu conteúdo, disponibilidade
e ordenação.
 A R T EFATOS D O SC R U M

Backlog do Produto
• A rigor, um Backlog do Produto nunca está completo. Os primeiros
desenvolvimentos apenas estabelecem os requisitos inicialmente conhecidos
e melhor entendidos.

• O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele

será utilizado evoluem.

• O Backlog do Produto é dinâmico; mudando constantemente para identificar

o que o produto necessita para ser mais apropriado, competitivo e útil. O
Backlog do Produto existirá enquanto o produto também existir.
 A R T EFATOS D O SC R U M

Backlog do Produto
• O Backlog do Produto é, geralmente, ordenado por valor, risco, prioridade e
necessidade.

• Os itens no topo da lista ordenada do Backlog do Produto determinam as

atividades de desenvolvimento mais imediatas.

• Quanto maior a ordem (topo da lista) de um item, mais o item do Backlog do

Produto deve ser considerado, e mais consenso existe em relação a ele e ao
seu valor.
 A R T EFATOS D O SC R U M

Backlog do Produto
• Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo.

• Mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem

causar mudanças no Backlog do Produto.

• Preparar o Backlog do Produto é uma atividade de tempo parcial, durante a Sprint,

entre o Product Owner e o Scrum Team.

• O Scrum Team é responsável por todas as estimativas.

• O Product Owner deve influenciar o Time, ajudando no entendimento e

eventualmente em esclarecimentos a respeito de Itens de Backlog.
 Metodologias
A R T EFATOS D O SCÁgeis
RUM

Burn Down
• Trata-se de um gráfico que permite ter uma visão da evolução diária do projeto, além de
permitir fazer projeções do término do Sprint, baseado na velocidade da equipe.

• O gráfico de Burn Down representa visualmente a soma das

estimativas dos esforços restantes do Backlog, permitindo também uma comparação com
os atuais trabalhos realizados.
 A R T EFATOS D O SC R U M

Backlog da Sprint
 O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para
a Sprint, visando atingir o objetivo da Sprint.

 O Backlog da Sprint é a previsão da Equipe de Desenvolvimento sobre qual

funcionalidade estará no próximo incremento e do trabalho necessário para entregar
a funcionalidade.

 O Backlog da Sprint define qual trabalho o Scrum Team realizará para converter os
itens do Backlog do Produto em um incremento “Pronto” do Produto ao final do
Sprint.

 O Backlog do Produto torna visível todo o trabalho que a Equipe de Desenvolvimento

identifica como necessário para atingir o objetivo da Sprint.

 O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que a
Equipe de Desenvolvimento planeja completar durante a Sprint, e pertence
exclusivamente à Equipe de Desenvolvimento.
 A R T EFATOS D O SC R U M

Monitorando o Progresso da Sprint

• O Scrum Team monitora o total do trabalho restante pelo menos a cada
Reunião diária.

• A Equipe de Desenvolvimento acompanha estes resumos diários e projeta

a probabilidade de alcançar o objetivo da Sprint juntamente com o Scrum
Master.
 A R T EFATOS D O SC R U M

Monitorando o Progresso da Sprint

• O Scrum não considera o tempo gasto trabalhando nos itens do Backlog
da Sprint.

• O trabalho restante e a data são as únicas variáveis que interessam, sendo

que a data do Sprint é um compromisso do Scrum Team que deve ser
perseguido sob toda e qualquer circunstância.
 A R T EFATOS D O SC R U M

Monitorando o Progresso da Sprint

• Kanban é um termo de origem japonesa e significa literalmente “cartão” ou
“sinalização”.

• É um conceito relacionado com a utilização de cartões (post-it e outros) para

indicar o andamento dos fluxos de produção em empresas de fabricação em
série.

• Nesses cartões são colocadas indicações sobre uma determinada tarefa, por
exemplo, “para executar”, “em andamento” ou “finalizado”.
 A R T EFATOS D O SC R U M

Monitorando o Progresso da Sprint

• O Quadro Scrum pode ser de grande valia para além de

controlar o fluxo de trabalho dentro de um Sprint, também
fornecer transparência nas reuniões diárias e também
eliminar quaisquer tipos de ansiedade em relação ao
andamento do projeto.
 A R T EFATOS D O SC R U M

Quadro Kanban
 A R T EFATOS D O SC R U M

Incremento
 O incremento é a soma de todos os itens do Backlog do Produto
completados ao final das Sprints.

 Ao final da Sprint um novo incremento deve estar “Pronto”, o que

significa que deve estar na condição utilizável e atender a definição de
“Pronto” do Time Scrum.

 Este deve estar na condição utilizável independentemente do Product

Owner decidir por liberá-lo realmente ou não para produção.

 Em resumo é o produto entregue a cada Sprint até se ter a versão final

do produto.
 A R T EFATOS D O SC R U M

Definition of Done

• Quando o item do Backlog do Produto ou um incremento é descrito como

“Pronto”, todos devem entender o que o “Pronto” significa.

• Embora, isso varie significativamente de um extremo ao outro para cada

Scrum Team, os integrantes devem ter um entendimento compartilhado
do que significa o trabalho estar completo, assegurando a transparência.

• Esta é a “Definição de Pronto” para o Time Scrum e é usado para

assegurar quando o trabalho esta completado no incremento do produto.
 A R T EFATOS D O SC R U M

Definition of Done

• A definição de pronto é ponto chave para garantir qualidade do produto e

um dos itens necessários para garantir um processo de entrega à
expectativa do Product Owner.

• Neste ponto é onde se demonstra a necessidade de autogerenciamento e

maturidade por parte dos times Scrum, uma vez que um item do Product
Backlog jamais será considerado concluído se não estiver realmente
“Pronto”.
 M e t o d o lo g ia s Á g e is

Calendário NIKO-NIKO
Quando os integrantes de um Time deixam o escritório no final do dia, vão até uma parede
com calendário pendurado e desenham ali uma carinha alegre, uma carinha neutra ou uma
carinha triste, isso é chamado de calendário NIKO-NIKO (NIKO-NIKO calendar).

O Objetivo é armazenar as emoções de todos os integrantes do Time nos dias de trabalho

de forma que todos possam ver.
 M e t o d o lo g ia s Á g e is

Calendário NIKO-NIKO

A Ideia principal é colher feedbacks diários a respeito do

clima de trabalho e de possíveis causas para o aumento de
defeitos, a falta de motivação, o baixo desempenho e outras
situações negativas.

O calendário NIKO-NIKO é um radiador de informação. Ele

não se propõe a fornecer todas as respostas para os
problemas do Time, mas pode maximizar as autoavaliações
dos seus membros e fornecer aos seguintes ou líderes temas
para discussões com foco na resolução de problemas e
conflitos.
 M e t o d o lo g ia s Á g e is

Calendário NIKO-NIKO

Outra Forma de usar o calendário NIKO-NIKO é permitir que

as pessoas coloquem suas carinhas de forma anônima. Essa
prática evita que as pessoas mintam sobre suas reais
emoções , porém não permite discussões diretas de forma
individualizada.

Você sabia que pessoas mais felizes são mais produtivas e

que para isso precisam de um conjunto de coisas que as
façam se sentir realizadas?
 M e t o d o lo g ia s Á g e is

Radiadores de Informação
Informações de Forma Ágil
Durante um projeto, precisamos compartilhar
informações como, o andamento do projeto,
acompanhamento de riscos , custo, lições
aprendidas entre outras. Estas informações
devem estar disponíveis para todas as
pessoas, interessadas no projeto.
Para isso utilizamos radiadores de informação,
que são conjuntos de informações,
apresentadas de maneira simples e com a
maior exposição possível, para que todos
recebam a informação necessária de maneira
Eficiente.
 M e t o d o lo g ia s Á g e is

Técnica MoSCoW
Aplicando a técnica MoSCoW como auxílio na priorização
Quando houver problemas ou conflitos de definição de importância com o cliente,
uma sugestão é usar o MoSCoW, que é uma ótima técnica para ser exercitada
pelo Product Owner em conjunto com o cliente, pois facilita o entendimento do
que realmente é importante para o projeto.
O Significado da sigla MoSCoW está
ilustrado na figura ao lado e o seu
funcionamento é o seguinte: separe
primeiro as histórias de acordo com a
indicação MoSCoW, sendo que os itens
“Deve ter” (Must have) e “Deveria ter”
(Should have) devem ser os primeiros da
lista, e “Poderia ter” (Could have) e “Não
terá” (Won’t have) ficam no final –
inclusive, este último item pode ser
considerado para versões futuras do
produto, não fazendo parte do projeto
corrente.
 M e t o d o lo g ia s Á g e is

Scrum em projetos com preço fixo

O mundo ideal para os projetos de desenvolvimento de software seria
aquele onde os times trabalham sob demanda de seus clientes com base
exatamente nas necessidades de maior valor e onde os orçamentos são
abertos e pagos no final de acordo com as horas trabalhadas após
realizar todos os trabalhos da iteração, ou do conjunto de iterações. No
entanto, o mundo real está distante disso.

Na maioria dos projetos de desenvolvimento de software no mundo

corporativo, onde as metas, as diminuições de custo e a busca por fazer
mais com menos imperam com soberania, os clientes querem saber
exatamente quanto vão gastar e quando vão receber todo o sistema que
estão contratando, sendo que, na maioria dos casos, um prazo curto já
vem estabelecido e nem sempre o orçamento é o desejado.
 M e t o d o lo g ia s Á g e is

Scrum em projetos com preço fixo

Quando um cliente quer saber exatamente quando vai pagar por um

sistema na sua entrega, esse tipo de negociação contratual é conhecido
como preço fixo, ou seja, antes da assinatura de um contrato oficializado
a contratação é fixado um preço total para os trabalhos de
desenvolvimento.

Esse tipo de contratação gera um grande problema para os projetos de

desenvolvimento de software: como fixar um preço para um produto que
ainda não existe e será construído após a fixação de seu preço?
 M e t o d o lo g ia s Á g e is

Scrum em projetos com preço fixo

É preciso então saber exatamente o que será construído para que seja
possível a fixação de um preço. Isso se chama fechar o escopo, que em
outras palavras significa que é preciso identificar, definir e delimitar em
comum acordo com o cliente tudo o que será realizado e tudo o que não
será realizado no projeto.
Para criar um cenário ainda mais complexo, se é conhecido o escopo
completo, ou seja, se o escopo é fechado, e se é conhecido quanto
custará para transformar o escopo fechado em um produto pronto e
utilizável, ou seja, se há um preço fixo para os trabalhos,
automaticamente é preciso existir um prazo definido para que as outras
duas definições sejam mantidas.
 M e t o d o lo g ia s Á g e is

Scrum em projetos com preço fixo

Com essas três definições tem-se o cenário mais complexo e temido no
mundo dos projetos de desenvolvimento de software o custo fixo, o
escopo fechado e o prazo definido.

Você sabia que para as contratantes o cenário de preço fixo

e prazo definido é considerado mais seguro, e muitas não
conseguem aprovação de orçamento sem essas premissas
tidas como básicas?

Bom, apesar desse cenário parecer inóspito e quase impossível ser

gerenciado e cumprido pensando em sistemas de tecnologia da
informação, que na sua maioria envolvem inovações, processo criativos e
muitas “coisas” desconhecidas, é a realidade de contratos praticados no
Brasil e no mundo, e por isso é preciso lidar com eles e chegar o mais
próximo possível do atendimento das premissas de custo fixo, escopo
fechado e prazo definido.
 M e t o d o lo g ia s Á g e is

Definindo horas por pontos por história

Quando se pensa em estimativa, em quase 100% dos casos é por causa de uma
entrega, e quando se pensa em entrega geralmente há datas atreladas, e com
isso prazos e horas.

Uma maneira bem prática de ter uma ideia de horas ao definir os tamanhos das
histórias é montar uma equivalência simples entre os pontos de histórias e as
horas estimadas de esforço para completar as histórias – por exemplo, 10 pontos
por história equivalem a oito horas de esforço. Vamos entender um pouco melhor
a seguir.

A equivalência não necessita ser precisa, até porque nesse momento o Time
ainda não tem informações suficientes para estimar esforço em horas, e acertar
será muito difícil. Por outro lado, será muito interessante ter um contraponto em
horas de esforço para os tamanhos das histórias, especialmente porque essa
informação poderá ser utilizada em momentos futuros durante os planejamentos e
as inspeções do projeto.
 M e t o d o lo g ia s Á g e is

Definindo horas por pontos por história

Pense em equivalências simples, como, por exemplo, 2 pontos por história
equivalem a quatro horas de esforço; ou 40 pontos por história equivalem a vinte
horas de esforço. A única regra para essa equivalência é ter uma lógica constante,
para que ao final das estimativas haja um total aproximado de horas de esforço.

Com o tempo o Time será bem mais assertivo nessa

equivalência do que no começo do exercício. Por isso
não tenha medo de montar e usar essa equivalência,
modificá-la ao longo do tempo e adaptá-la de acordo
com os exercícios do próprio Time. A única regra é só
realizar essa equivalência se realmente for necessária
para o seu projeto.
 M e t o d o lo g ia s Á g e is

Jogando o Planning Poker Card

O Planning Poker Card é uma
técnica que auxilia na estimativa de
histórias e tarefas com base no
consenso de todo o Time.
É utilizado um conjunto de cartas
com valores específicos que podem
representar Story Points (pontos por
história) ou até mesmo horas, como
pode ser visualizado na figura:
 M e t o d o lo g ia s Á g e is

Jogando o Planning Poker Card

O seu uso é simples: O Product Owner ou um membro do Time apresenta
a história ou tarefa. Após uma breve discussão, cada um escolhe uma
carta e a coloca virada sobre uma mesa, de forma que uma não veja o
valor da carta que o outro escolheu. Quando todos colocarem suas
cartas, elas são desviradas para que todos vejam os valores.

Caso não haja consenso entre as cartas escolhidas, as diferenças são

discutidas de forma breve e uma nova rodada acontece, até que haja
convergência e consenso.
 M e t o d o lo g ia s Á g e is

Jogando o Planning Poker Card

Vamos conhecer alguns aspectos do Planning Poker Card:

• São 12 cartas numeradas: 0 (zero), ½ ou 0,5 (meio), 1, 2, 3, 5, 8, 13,

20, 40 e 100
• As cartas com símbolos são duas: “?” (interrogação) e um desenho de
uma xícara de café.
• A carta 0 (zero) representa uma história ou tarefa já concluída ou com
um tempo tão curto para conclusão (por exemplo, alguns minutos) que
não vale a pena ser mensurado.
• A carta 100 representa uma história ou tarefa muito grande, também
conhecida como épico. O ideal é que seja quebrado em histórias ou
tarefas menores, pois, inclusive, o risco de estimar errado ser torna
alto em histórias/Épicos muito grandes.
 M e t o d o lo g ia s Á g e is

Jogando o Planning Poker Card

Uma história muito grande ganha o nome de Épico, e estes

não devem ser trabalhados ou construídos pelo Time. Épicos
não devem ser estimados. O ideal é que sejam quebrados em
histórias menores e só depois estimados e construídos.

• A carta “?” (interrogação) representa uma história ou tarefa indefinida e que,

além de não ser possível entender o seu tamanho, não se consegue nem dizer
se é muito pequena ou muito grande.

• A carta da xícara de café representa uma pausa para um café, uma água ou
um simples descanso, devido ao tempo da reunião estar muito longo.
 M e t o d o lo g ia s Á g e is

Estimativa por afinidade

Estimar por afinidade é a ação de determinar o tamanho e/ou esforço de
grupos de histórias com classificações similares.
Esta prática é geralmente aplicada quando um projeto é grande e possui
uma enorme quantidade de histórias. Em vez de estimar história a
história, individualmente, o Time faz um agrupamento de histórias e o
estima.
Frequentemente são utilizadas as definições de tamanho da estimativa T-
Shirt, que separa os tamanhos e/ou esforços das histórias como
camisetas, tais como PP, P, M, G e GG.
Com base na estimativa T-Shirt, o Time agrupa as histórias em categorias,
coleções ou temas similares e determina qual o tamanho T-Shirt de cada
grupo.
 M e t o d o lo g ia s Á g e is

Estimativa por afinidade

Tais equivalências podem ser convertidas para pontos por história, horas
ou outra unidade de medida que o Time entenda e com a qual tenha
familiaridade.

Os agrupamentos das histórias também podem ser

realizados por funcionalidades, ou até por Épicos.

A estimativa por afinidade é uma técnica para velocidade na estimativa

inicial de muitos itens de backlog e/ou classificação e categorização de
requisitos de negócio
 M e t o d o lo g ia s Á g e is

Triangulação
O processo de estimativa por referência que utiliza âncoras para determinar o tamanho ou
esforço de uma história ou item também é chamado de triangulação.
A técnica de triangulação é aplicada naturalmente quando se utiliza Planning Poker Card
para estimar, pois a triangulação se dá quando o time pega uma história e a compara com
outras duas para saber exatamente onde encaixá-la.
 M e t o d o lo g ia s Á g e is

Histórias
O que são histórias?

História é uma descrição resumida, porém clara e objetiva, de

alguma funcionalidade que deverá ser fornecida pelo produto
a ser entregue, sempre do ponto de vista do usuário final.
Uma história não é uma especificação completa da
funcionalidade, mas uma promessa de discutir uma
funcionalidade, ou, simplesmente, um lembrete de que a
discussão já aconteceu.
 M e t o d o lo g ia s Á g e is

Histórias
As histórias devem possuir uma descrição curta e objetiva, para que
caibam em um post-it, como o ilustrado na imagem adiante. Um modelo
simples de como escrever uma história seria:
“Como um <tipo de usuário>, eu quero <um objetivo> para que <atenda a
uma necessidade>.”
As palavras entre os sinais de <> (maior e menor) devem ser substituídas
pelas características, ações e necessidades reais para que a história
atenda a um requisito, como por exemplo:

Como um comprador, eu quero poder consultar

livros para que eu possa escolher qual comprar.
 M e t o d o lo g ia s Á g e is

Histórias
 M e t o d o lo g ia s Á g e is

Verificando a velocidade do Time

O exercício de limpar o backlog é tão importante que o seu resultado é utilizado em vários
outros processos. Neste aqui o Time verifica se o backlog já tem uma velocidade definida,
sou seja, quantas histórias (levando em conta a característica do tamanho) o Time consegue
realizar por Sprint.

O tamanho das histórias se dá pelos pontos por história, e geralmente a velocidade do Time
também. O Time mede a sua velocidade de acordo com a quantidade de pontos por história
que consegue completar por Sprint. As Sprints devem ter o mesmo tamanho do início ao fim
do projeto ou fase; caso contrário, a definição de velocidade perde o seu valor.

Então quando o Time determina, ou identifica, que a sua velocidade é de 1000 pontos por
história, isso significa que o Time, dentro de uma Sprint, consegue completar um conjunto de
histórias que totaliza no máximo 1000 pontos.

Essa velocidade do Time é uma definição muito importante porque determinará quantas
Sprints o projeto ou fase terá, e qual será a duração total do projeto ou fase em Sprints.
 M e t o d o lo g ia s Á g e is

Verificando a velocidade do Time

Essa velocidade do Time é uma definição muito importante porque determinará quantas
Sprints o projeto ou fase terá, e qual será a duração total do projeto ou fase em Sprints.

Entradas:
• A fase possui cinquenta histórias e a soma dos pontos por
história é 2.500 pontos.
• O Time já definido possui a velocidade de 200 pontos por história
para Sprints de três semanas.
Análises:
• Com as entradas em mãos, o primeiro cálculo pode ser realizado
– o de Sprints necessárias para completar as 50 histórias.
• Se em uma Sprint o Time consegue completar 200 pontos, então
o Time precisará de 13 Sprints para completar os 2.500 pontos.
• Se o Time precisa de 13 Sprints para completar todas as
histórias, e cada Sprint tem a duração de três semanas, então o
Time precisará de 39 semanas para completar a fase ou projeto.
• Considerando que um mês tem quatro semanas, o Time
concluirá a fase ou projeto em torno de 10 meses.
 M e t o d o lo g ia s Á g e is

Scrum de Scrums
Como o PO e o Scrummaster darão conta de tantas equipes?
A primeira coisa a fazer é realmente criar
Times Scrum completos, com seus próprios
Scrummasters e POs, com cada time atendendo
às necessidades delimitadas pelo seu PO e
sendo guiados e orientados pelo
próprio Scrummaster.
Com essa estrutura é que surge a necessidade
do Scrum of Scrums, que é um encontro dos
Scrummasters de cada um dos times para
Comunicar todas as realizações de seu time no
último período e o que cada um dos times pretende
fazer no próximo período, além de alinhar problemas e possíveis
impedimentos que podem inclusive ultrapassar as
fronteiras entre os times.
Para resumir a utilização do Scrum do Scrums e
compreender como pode ser feita a transição entre
um time grande e times menores, vejamos a figura:
 M e t o d o lo g ia s Á g e is

Scrum de Scrums
O primeiro passo é identificar que há um time muito grande e pouco eficiente, especialmente
pela identificação de problemas como backlog muito extenso dificultando planejamentos e a
dificuldade de realização de reuniões diárias com todo o time.
O passo 2 é separar grande time em equipes menores que satisfaçam a condição de
tamanho ideal de times Scrum. Cada um time terá os seus desenvolvedores e o
Scrummaster obrigatoriamente.
O passo 3 é realizar reuniões dos Scrummasters de cada time para compartilhar as
realizações e contribuir com a transparência de todos os times entre si.
Nessas reuniões, que podem ser semanais, os Scrummasters levam as realizações de seus
times, comunicando o que foi feito na última semana, o que será feito na próxima semana e
quais os problemas existentes, dando foco ainda maior para os problemas que podem
transpor as fronteiras de seus times e afetar os demais times, como interdependências,
relacionamentos de tarefas e atrasos de entregas.

Essas reuniões de Scrum of Scrums podem ser utilizados de forma

corporativa para comunicar executivos e a alta gestão da organização
sobre os acontecimentos dos projetos e das realizações do time.
 M e t o d o lo g ia s Á g e is

Scrum of Scrums
 M e t o d o lo g ia s Á g e is

Scrum of Scrums
 A R T EFATOS D O SC R U M

Ciclo de Vida do Scrum

 B ib lio g ra fia

Referências Bibliográficas

 AMBLER, S. Gerenciamento ágil de projetos: Colocando o desenvolvimento

de software em ordem. Mundo PM.

 PROJECT MANAGEMENT INSTITUTE – PMI. PMBOK Guide: Um guia do

conjunto de conhecimentos do gerenciamento de projetos. : Project
Management Institute, 4. ed., 2009.

 SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004.

 MAGALHÃES, A. O gerenciamento de projetos desenvolvidos à luz das

metodologias ágeis. PMI-MG jun/2006.