Introdução aos Métodos Ágeis e o Scrum

Prévia do material em texto

Gestão de Times – Métodos Ágeis
Introdução aos Métodos Ágeis e o Scrum
Luis Gustavo Rezende Motta
UNIDADE 1
Fundador e Presidente do Conselho de Administração
JANGUIÊ DINIZ
Diretor-presidente
JÂNIO DINIZ
Vice-presidente de Serviços
JOALDO DINIZ
Diretor de Ensino
ADRIANO AZEVEDO
Diretor Financeiro JOÃO AGUIAR
UNIDADE 1
APRESENTAÇÃO
Projetos ágeis fazem parte da cadeia de processos de uma empresa. Os Métodos Ágeis surgiram
como alternativa para os problemas pontuais que apresentam durante a elaboração de um
software usando os métodos de desenvolvimento orientado a planos. O Scrum é um framework
para gerenciamento de projetos ágeis, e que apesar de muito utilizado na área de
desenvolvimento de software, pode ser utilizado para o planejamento, gerenciamento e
desenvolvimento de qualquer produto, principalmente por ser um framework iterativo (repetitivos)
e incremental.
A ideia principal aqui é controlar processos empíricos, mantendo o foco na entrega de valor, de
um negócio, no menor tempo possível. Os projetos são divididos em ciclos repetitivos (iterativos) e
curtos para que possam ser modificados e adaptados para corrigir os desvios (incrementais).
Estes ciclos podem durar de duas a quatro semanas, e são chamados de Sprints.
O framework Scrum é simples de entender. Para ajudar eu separei abaixo alguns tópicos que
resumem o Scrum, sua teoria, sua história e seus componentes. Ao longo desta unidade letiva
você vai mergulhar neste universo!
O AUTOR
LUIZ GUSTAVO REZENDE MOTTA
Olá! Meu nome é Luiz Gustavo Rezende Motta. Sou formado
em Ciência da Computação, com experiência técnico-
profissional na área de Gestão de Projetos há mais de 10 anos.
Passei por empresas com a Unimed, Benner e Postal Saúde.
Sou apaixonado pelo que faço e adoro transmitir minha
experiência de vida àqueles que estão iniciando em suas
profissões. Por isso, fui convidado pela Editora Telesapiens a
integrar seu elenco de autores independentes. Estou muito
feliz em poder ajudar você nesta fase de muito estudo e
trabalho. Conte comigo!
UNIDADE 1
ICONOGRÁFICOS
Olá! Meu nome é Manuela César. Sou a responsável pelo projeto gráfico de seu 
material. Esses ícones irão aparecer em sua trilha de aprendizagem significam:
SAIBA MAIS 
Informações adicionais 
sobre o conteúdo;
ACESSE 
Links úteis para fixação 
da informação;
DEFINIÇÃO
Apresentação de um 
novo conceito;
RESUMINDO
Resumo acumulativo das 
últimas abordagens;
OBSERVAÇÃO
Breve descrição do 
objetivo;
OBJETIVO
Breve descrição do 
objeto;
CITAÇÃO
Parte retirada de um 
texto;
TESTANDO
Foco em um objeto 
de estudo;
IMPORTANTE
As observações escritas 
têm que ser priorizadas;
DICA
Destaque para sugestões 
e novas informações;
+
+
OBJETIVOS DA UNIDADE
Olá! Seja bem-vindo(a) a nossa Unidade 1, o nosso objetivo é auxiliar você no
desenvolvimento das seguintes competências profissionais até o término desta
etapa de estudos:
1 CONHECER O UNIVERSO DOS MÉTODOS ÁGEIS
2 ENTENDER A DEFINIÇÃO E OS USOS DO FRAMEWORK SCRUM.
3
4
COMPREENDER A TEORIA POR TRÁS DO FRAMEWORK SCRUM.
ENTENDER OS VALORES DO MÉTODO SCRUM.
Tópicos de estudo
•O MANIFESTO ÁGIL POSSUI A SEGUINTE BASE
•O DESENVOLVIMENTO ÁGIL É INCREMENTAL
•DESENVOLVIMENTO ÁGIL NECESSITA DE PRÁTICAS ÁGEIS
• EQUIPES
Conhecendo o 
universo dos 
métodos
•DEFINIÇÃO DO SCRUM
•O TIME DO SCRUM
•O PRODUCT OWNER
•O TIME DE DESENVOLVIMNTO
• TAMANHO DO TIME DE DESENVOLVIMENTO
•O SCRUM MASTER
•BACKLOG DO PRODUTO
• EVENTOS SCRUM
• SPRINT
•REVISÃO DA SPRINT
•RETROSPECTIVA DA SPRINT
•REUNIÃO DIÁRIA
Entendendo a 
definição e o 
uso do 
FRAMEWORK 
SCRUM
Tópicos de estudo
•ÁREAS DE CONHECIMENTO DO GERENCIAMENTO DE PROJETOS APLICÁVEIS
•A DINÂMICA DO SCRUM
•O GERENTE DE PROJETO NO APOIO
•ADAPTABILIDADE
• TRANSPARÊNCIA
• FEEDBACK CONTÍNUO
•MELHORIA CONTÍNUA
• ENTREGA CONTÍNUA DE VALOR
• EFICIÊNCIA
•MOTIVAÇÃO
•ALTA VELOCIDADE
•AMBIENTE INOVADOR
Compreendendo 
a teoria por trás 
do FRAMEWORK
•PAPEL E OS PRINCÍPIOS DO SCRUM
• TRANSPARÊNCIA
• INSPEÇÃO
•ADAPTAÇÃO
•PONTOS PARA INSPEÇÃO E ADAPTAÇÃO EM SCRUM
•VALORES QUE SUSTENTAM OS PILARES DO SCRUM
Entender os 
valores do 
método SCRUM 
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
Metodologias ágeis existem há anos, desde a década de 80, mas algumas informações passaram por
distorções, fato que dificultou no início a utilização das metodologias. Por conseguinte, desenvolvedores
passaram a entender a metodologia ágil como algo que tudo pode, ou seja, podemos desenvolver sem
documentação, sem padrão e sem cuidado. Isto não é verdade, as metodologias ágeis podem trazer
sucesso ao projeto e são utilizadas inclusive na indústria. Apesar das metodologias existirem, foi em
2001 que um grupo de renomados desenvolvedores assinaram o MANIFESTO PARA O
DESENVOLVIMENTO ÁGIL DE SOFTWARE e o grupo foi batizado de aliança dos ágeis.
• O MANIFESTO ÁGIL POSSUI A SEGUINTE BASE:
Os indivíduos e as interações são mais importantes do que
os processos e as ferramentas;
O software funcionando é mais importante do que uma 
documentação completa;
A colaboração dos clientes acima de apenas negociações de 
contratos e;
Respostas à mudanças acima de seguir um 
plano.
A engenharia de software ágil combina filosofia com um conjunto de princípios de desenvolvimento. A filosofia
defende a satisfação do cliente e a entrega de incremental prévio; equipes de projetos pequenas e altamente
motivadas; métodos informais; artefatos de engenharia de software mínimos e, acima de tudo, simplicidade
no desenvolvimento geral.
Os princípios de desenvolvimento priorizam a entrega mais que a análise e projeto (embora essas atividades
não sejam desencorajadas); também priorizam a comunicação ativa e contínua entre desenvolvedores e
clientes. (Pressman, 2011)
Um projeto envolve pessoas e mudanças, principalmente quando falamos de entregas constantes. Desta
forma, as metodologias ágeis trabalham com equipes altamente motivadas e suporte à mudanças durante o
processo de desenvolvimento.
Isso não quer dizer que
documentação não seja
importante e que os
processos e as ferramentas
sejam inúteis. Significa que
os itens à esquerda são mais
valorizados, apenas isso.
IMPORTANTE
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
• O DESENVOLVIMENTO ÁGIL É 
INCREMENTAL
Um plano completo com tudo que devemos fazer para depois iniciar o
desenvolvimento. Você não deve desenvolver o produto sem antes fazer
contato com o cliente, ao invés disso desenvolver incrementalmente, ou
seja, o produto é feito aos poucos e entregue constantemente. Desta
forma, toda mudança é bem-vinda, pois o projeto está em
desenvolvimento e não foi concluído por completo.
Os incrementos iniciais do sistema podem fornecer uma funcionalidade de alta prioridade, de forma que os clientes
logo poderão obter valor do sistema durante seu desenvolvimento. Os clientes podem assim ver os requisitos na
prática e especificar mudanças para serem incorporadas nos releases (liberações ou lançamentos) posteriores do
sistema.
O contato constante com o cliente também gera conhecimento, pois a equipe vai entendendo o negócio, para ao
desenvolver, fazê-lo com maior velocidade e precisão, e em caso de erros, a equipe não terá perdido um ano de
desenvolvimento, e sim, terá perdido apenas o tempo de desenvolvimento do incremento, podendo corrigir
rapidamente.
“Incremental” relativo a
incremento, ato ou efeito
de desenvolver ou
aumentar alguma coisa.
Que visa aprimorar
gradualmente em etapas:
mudança incremental e
atualização incremental.
DEFINIÇÃO
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
Falamos da importância de saber escolher o que será feito, ou seja,
funcionalidades que tenham alta prioridade, desta forma, o cliente já pode
usufruir de recursos do sistema. O que antes demoraria meses, agora em
semanas ele poderá ter acesso para verificar erros e especificar novas
mudanças ou melhorias, não necessitando chegar ao final do desenvolvimentopara ver os problemas.
RESUMINDO
• DESENVOLVIMENTO ÁGIL NECESSITA DE PRÁTICAS ÁGEIS
Podemos citar:
Utilização de TDD: é a técnica que permite fazer testes contínuos, e não apenas na conclusão
do sistema, melhorando assim a qualidade técnica do produto;
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
Incrementos desenvolvidos em tempo reduzido:
releases (liberações ou lançamentos) pequenos,
entregando funcionalidades em meses ou semanas, ao
invés de anos;
Utilização de refatoração: melhorando o código e
tornando-o mais fácil de manter constantemente;
Integração continua: quando o incremento está pronto,
ele é integrado ao sistema como um todo, ou seja, isto
é feito diariamente.
Planejamento incremental: ao invés de planejar o
software como um topo, podemos planejar de forma
sistêmica, ou seja, definir o todo, mas planejar em
etapas, realizando um planejamento por incremento. Os
requisitos do incremento podem ser registrados em
cartões que algumas metodologias denominam de
“histórias do usuário”, aqui determinamos a prioridade
que o cliente define e também o tempo que os
desenvolvedores precisam para o desenvolvimento;
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
Os métodos ágeis são eficientes para alguns tipos de sistemas, como em
desenvolvimento de produtos para venda em pequeno e médio porte, ou também,
em desenvolvimento de sistemas que o cliente estará envolvido no processo de
desenvolvimento, em que não haverá muitas regras que afetam o software.
DICA
• EQUIPES
Os pontos acima são base para quase todas as metodologias
ágeis, mas o principal ponto nestas metodologias, além dos
citados acima, é a possibilidade de a equipe ser auto
gerenciável, ou seja, não há necessidade de um gerente e sim
um líder, que tem o papel de facilitador. A equipe e a
comunicação entre os membros da equipe e o cliente é crucial
para o sucesso das metodologias ágeis, e para isso, as
equipes pequenas tornam-se fatores de sucesso.
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
As equipes pequenas reduzem problemas de conflitos, comunicação, entre outros. Mike Cohn, um
dos colaboradores da invenção da metodologia de desenvolvimento de software Scrum, afirma que
equipes pequenas possuem menos ociosidade social, melhoram a interação construtiva, possui
menor tempo na coordenação e ninguém fica para trás, pois todos apreendem em conjunto, há
maior satisfação entre os membros do grupo e é menos provável que ocorra excesso de
especialização, pois todos devem conhecer o projeto.
Outro ponto que foi notado por Cohn, é que o tamanho não
indica realmente maior produtividade, pois equipes grandes
não são necessariamente mais produtivas, pois há menos
comunicação e maior número de conflitos. Ainda segundo
Cohn, não é de se surpreender que equipes menores
concluem os projetos com um esforço total menor, equipes
maiores demandam mais esforços e custos. Equipes entre
5 a 8 integrantes têm maior chance de sucesso, pois é
mais fácil a comunicação e mais fácil criar uma integração
do que equipes com 20 a 30 integrantes. Equipes muito
pequenas podem sofrer problemas de falta de pessoal.
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
IMPORTANTE
Como a equipe é pequena, a perda de um integrante pode prejudicar o grupo
como um todo, para isso, não há grande especialização na equipe, ou seja, todos
devem ser responsáveis pelo projeto e não por apenas uma tarefa, o que torna a
equipe elástica caso algum integrante saia do projeto.
O Scrum e outras metodologias ágeis, indicam que equipes pequenas tem maior chance de
concluir o projeto do que equipes grandes. Caso isso ocorra, nas equipes pequenas, o líder nota
as deficiências, e pode atacá-las com maior facilidade utilizando capacitação, integração, e etc.
CONHECENDO O UNIVERSO 
DOS MÉTODOS ÁGEIS
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
• DEFINIÇÃO DO SCRUM
Um framework dentro do qual pessoas podem tratar
e resolver problemas complexos e adaptativos,
enquanto produtiva e criativamente entregam
produtos com o mais alto valor possível. Scrum é:
Leve;
Simples de entender;
Extremamente difícil de dominar;
Scrum é um framework estrutural que está sendo usado para gerenciar o desenvolvimento de produtos
complexos desde o início de 1990. Ele não é um processo ou uma técnica para construir produtos, em vez
disso, é um framework, dentro do qual você pode empregar vários processos ou técnicas. O Scrum deixa
claro a eficácia relativa à práticas de gerenciamento e desenvolvimento de produtos, de modo que você
possa melhorá-las.
O framework Scrum consiste nos times do Scrum associadas a papéis, eventos, artefatos e regras. Cada
componente dentro do framework serve a um propósito específico e é essencial para o uso e seus
sucesso.
As regras do Scrum integram os eventos, papéis e artefatos, administrando as relações e interações entre
eles. As suas regras serão descritas ao longo deste documento.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
IMPORTANTE
Scrum não é metodologia.
• O TIME SCRUM
O Time Scrum é composto pelo Product Owner, o Time de
Desenvolvimento e o Scrum Master. Times Scrum são auto-
organizáveis e multifuncionais, eles escolhem qual a melhor forma
para completarem seu trabalho, em vez de serem dirigidos por
outros de fora do Time. Times multifuncionais possuem todas as
competências necessárias para completar o trabalho sem depender
de outros que não fazem parte da equipe. O modelo de time no
Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e
produtividade. Times Scrum entregam produtos de forma iterativa e
incremental, maximizando as oportunidades de realimentação.
Entregas incrementais, do produto “Pronto”, garantem que uma
versão potencialmente funcional do produto do trabalho esteja
sempre disponível.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
• O PRODUCT OWNER
O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto e do
trabalho do Time de Desenvolvimento. Como isso é feito pode variar amplamente através das
organizações, times Scrum e indivíduos.
O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O
gerenciamento do Backlog do Produto inclui:
Expressar claramente os itens do Backlog do Produto;
Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
Garantir o valor do trabalho realizado pelo Time de Desenvolvimento;
Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o
que o time Scrum vai trabalhar a seguir; e,
Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível
necessário.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
IMPORTANTE
O Product Owner pode fazer o trabalho acima, ou delegar para o Time de
Desenvolvimento fazê-lo. No entanto, ele continua sendo o responsável pelos
trabalhos. O Product Owner é uma pessoa e não um comitê pode representar o
desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma
alteração nas prioridades dos itens de Backlog devem convencer o Product Owner.
• O TIME DE DESENVOLVIMENTO
O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão
usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes
do Time de Desenvolvimento criam incrementos.
Os Times de Desenvolvimento são estruturados e autorizados pela organização para organizar e
gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia do Time de
Desenvolvimento como um todo. Os Times de Desenvolvimento têm as seguintes características:
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao Time
de Desenvolvimento como transformar o Backlog do Produto em incrementos
de funcionalidades potencialmente utilizáveis;
Times 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 do Time 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.
Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades
especializadas e área de especialização, mas a responsabilidade pertence ao Time
de Desenvolvimento como um todo; e,
Times de Desenvolvimento não contém sub-times dedicados a domínios
específicos de conhecimento, tais como teste ou análise de negócios.
O tamanho ideal do time de desenvolvimento é pequeno
o suficiente para se manter ágil e grande o suficiente
para completar uma parcela significativa do trabalho
dentro dos limites da Sprint.
Menos de três integrantes no Time de Desenvolvimento
diminuem a interação e resultam em um menor ganho
de produtividade. Times de Desenvolvimento menores
podem encontrar restrições de habilidades durante a
Sprint, gerando um Time de Desenvolvimento incapaz
de entregar um incremento potencialmente utilizável.
Havendo mais de nove integrantes é exigida muita
coordenação. Times de Desenvolvimento grandes
geram muita complexidade para um processo empírico
gerenciar. Os papéis de Product Owner e de Scrum
Master não são incluídos nesta contagem, a menos que
eles também executem o trabalho do Backlog da Sprint.
• TAMANHO DO TIME DE DESENVOLVIMENTO
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
• O SCRUM MASTER
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. O Scrum Master faz
isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. O Scrum Master é um
servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender
quais as suas interações com eles e, quais são úteis e quais não são. O Scrum Master ajuda todos a
mudarem estas interações para maximizar o valor criado pelo Time Scrum.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
O Scrum Master serve o Product Owner de várias maneiras, incluindo: 
 Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
 Claramente comunicar a visão, objetivo e itens do Backlog do Produto para o Time
de Desenvolvimento;
 Ensinar ao Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
 Compreender a longo prazo o planejamento do Produto no ambiente empírico;
 Compreender e praticar a agilidade; e,
 Facilitar os eventos Scrum conforme exigidos ou necessários.
++ SAIBA MAIS
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.
Um Backlog do Produto nunca está completo. Os primeiros desenvolvimentos apenas estabelecem os
requisitos inicialmente conhecidos e melhor entendidos. Ele evolui tanto quanto o produto e o ambiente no
qual ele será utilizado, evoluem é dinâmico, mudando constantemente para identificar o que o produto
necessita para ser mais apropriado, competitivo e útil que existirá enquanto o produto também existir.
O Backlog do Produto lista todas as características, funções, requisitos, melhorias e correções que formam
as mudanças que devem ser feitas no produto nas futuras versões, seus itens possuem os atributos de
descrição, ordem, estimativa e valor.
Enquanto um produto é usado, ganha valor e o mercado oferece retorno, o Backlog do Produto torna-se
uma lista maior e mais completa. Requisitos nunca param de mudar, então ele é um artefato vivo, por isso,
mudanças nos requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças nele.
Múltiplos Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é
usado para descrever o trabalho previsto para o produto, assim um atributo seu, que agrupe itens, pode
ser então aplicado.
• BACKLOG DO PRODUTO
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
O refinamento é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do Produto.
Este é um processo contínuo em que o Product Owner e o Time de Desenvolvimento colaboram nos
detalhes dos itens do Backlog do Produto. Durante o seu refinamento os itens são analisados e
revisados. O Time de Desenvolvimento decide como e quando o refinamento está “Pronto”. Este
refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento.
Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product
Owner ou a critério do dele.
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais
detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em
maior clareza e maior detalhamento, quanto menor a ordem na lista, menos detalhes. Os itens irão
ocupar o desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam
ser “Prontos” dentro do time-box da Sprint esses itens são considerados como “Preparados” para
seleção no Planejamento da Sprint e geralmente adquirem este grau de transparência através das
atividades de refinamento descritas acima.
O Time de Desenvolvimento é responsável por todas as estimativas. O Product Owner deve
influenciar o Time, ajudando no entendimento e nas decisões conflituosas de troca, mas as pessoas
que irão realizar o trabalham fazem a estimativa final.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
SAIBA MAIS++
Time-box na tradução literal significa "caixa de tempo". Ou seja, o tempo para
fazer um trabalho é limitado, executando-o da melhor forma que puder, nessa
janela de tempo. É uma técnica simples, usada no desenvolvimento de software
para rastrear o progresso e para ter o trabalho feito.
Eventos prescritos são usados no Scrum para criar uma rotina
e minimizar a necessidade de reuniões não definidas
anteriormente. Todos os eventos são eventos time-box, de tal
modo, que todo evento tem uma duração máxima. Uma vez
que a Sprint começa, sua duração é fixada e não pode ser
reduzida ou aumentada. Os eventos restantes podem
terminar sempre que o propósito do evento é alcançado,
garantindo que uma quantidade adequada de tempo seja
gasta sem permitir perdas no processo.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
• EVENTOS SCRUM
Além da Sprint, que é um container para outros eventos, 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.
O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um
“Pronto”, versão incremental potencialmente utilizável do produto, é criado. 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.
• SPRINT
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
RESUMINDO
As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões
diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da
Sprint.
Durante a Sprint:
 Não são feitas mudanças que possam colocar em perigo o objetivo da Sprint;
 As metas de qualidade não diminuem; e,
 O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de
Desenvolvimento quanto mais for aprendido.
Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos,
as Sprints são utilizadas para realizar algo. Cada Sprint tem a definição do que é para ser construído,
um plano projetado e flexível que irá guiar a construção, o trabalho e o resultadodo produto.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
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 Time de Desenvolvimento ou do Scrum Master.
IMPORTANTE
A Revisão da Sprint é executada no final para inspecionar o incremento e adaptar o Backlog do Produto, se
necessário. Durante a reunião Time Scrum e as partes interessadas colaboram sobre o que foi feito na
Sprint e as sobre próximas coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal,
não uma reunião de status e a apresentação do incremento destina-se a motivar e obter comentários e
promover a colaboração.
Esta é uma reunião time-box de 4 horas de duração para uma Sprint de um mês. Para Sprints menores,
este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes
entendam o seu objetivo. O Scrum Master ensina a todos a manter a reunião dentro dos limites do time-box.
A Reunião de Revisão inclui os seguintes elementos:
Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner.
• REVISÃO DA SPRINT
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
Stakeholders: Em inglês stake significa interesse, participação, risco. Holder
significa aquele que possui. De modo geral, descreve uma pessoa ou grupo que
tem interesse em uma empresa, negócio ou indústria, podendo ou não ter feito
um investimento neles.
SAIBA MAIS++
O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos”, e quais ainda não
foram.
 O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas
ocorreram dentro da Sprint, e como estes problemas foram resolvidos;
 Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as
questões sobre o incremento;
 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 (se necessário);
 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;
 Análise de como o mercado ou o uso potencial do produto pode ter mudado e o
que é a coisa mais importante a se fazer a seguir; e,
 Análise da linha do tempo, orçamento, potenciais capacidades e mercado para a
próxima versão esperada do produto.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
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.
OBSERVAÇÃO
A Retrospectiva da Sprint é uma oportunidade para o Time Scrum 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-box de três horas para uma Sprint de um mês. Para
Sprint menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e
que os participantes entendam seu propósito. O Scrum Master ensina todos a mantê-lo dentro do
time-box. O Scrum Master participa da reunião como um membro auxiliar do time devido a sua
responsabilidade pelo processo Scrum.
• RETROSPECTIVA DA SPRINT
O propósito da Retrospectiva da Sprint é:
 Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos
processos e às ferramentas;
 Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
 Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
IMPORTANTE
Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos
itens do Backlog da Sprint pode ser somado. O Time de Desenvolvimento
monitora o total do trabalho restante pelo menos a cada Reunião Diária. O Time
de Desenvolvimento acompanha estes resumos diários e projeta a probabilidade
de alcançar o objetivo da Sprint. Com o rastreamento do trabalho restante em
toda a Sprint, o Time de Desenvolvimento pode gerenciar o seu progresso.
A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para que o Time de
Desenvolvimento possa sincronizar as atividades e criar um plano para as próximas 24 horas. Esta
reunião é 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.
A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade.
• REUNIÃO DIÁRIA
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK SCRUM
Durante a reunião os membros do Time de Desenvolvimento esclarecem:
 O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a meta da
Sprint?
 O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint?
 Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no
atendimento da meta da Sprint?
O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao
objetivo da Sprint e para inspecionar se o progresso tende para completar o trabalho do Backlog
da Sprint. A Reunião Diária aumenta a probabilidade do Time de Desenvolvimento atingir o
objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve entender como o mesmo
pretende trabalhar em conjunto, como um time auto-organizado, para completar o objetivo da
Sprint e criar um incremento esperado até o final da Sprint. O Time de Desenvolvimento ou
membros da equipe frequentemente se encontram imediatamente após a Reunião Diária para
discussões detalhadas, ou para adaptar, ou replanejar, o restante do trabalho da Sprint.
ENTENDENDO A DEFINIÇÃO E O 
USO DO FRAMEWORK 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
do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e
adaptação.
RESUMINDO
O Scrum Master assegura que o Time de Desenvolvimento tenha a reunião, mas o Time de
Desenvolvimento é responsável por conduzir a Reunião Diária e ensina o Time de
Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos. Ele reforça a regra
de que somente os integrantes do Time de Desenvolvimento participem.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
• ÁREAS DE CONHECIMENTO DO 
GERENCIAMENTO DE PROJETOS APLICÁVEIS
A possibilidade de mudança do gerenciamento de projetos tradicional para o gerenciamento de
projetos ágil requer uma atenção especial em cinco áreas de conhecimento definidas:
 Gerenciamento de Recursos Humanos; 
 Gerenciamento da Qualidade;
 Gerenciamento da Integração; 
 Gerenciamento do Escopo; e,
 Gerenciamento do Tempo.
Tanto a abordagem ágil quanto a abordagem tradicional
identificam as três restrições de um projeto como sendo: custo,
tempo (agenda) e escopo. Para a abordagem tradicional, no
entanto, o escopo do projeto deve ser fixado para que tempo e
custo possam ser estimados. Já as abordagens ágeis se
manifestam acreditando que o escopo estará em constante
mudança, então tempo e custo devem ser fixados.
Em abordagens ágeis a estratégia de comando-controle deve
ser substituída por facilitação, colaboração e suporte.
Uma abordagem segundo o PMBOK - Project Management
Body of Knowledge e do PMI 2004 - Project Management
Institute, nos leva a perceber que:
A preocupação está na definição do escopo em um alto nível que permita
o entendimento do trabalho, inclusive com a participação do cliente para
a priorização das funcionalidades; o cronograma é orientadoao produto
que será produzido em iterações (repetições) curtas que contribuem para
uma redução dos conflitos pela cumplicidade no processo; as alterações
são incorporadas dentro da iteração mais apropriada e de comum acordo
com o cliente, podendo elevar o custo final; os padrões a serem
seguidos devem ser estabelecidos no início do projeto e estarem
concentrados na programação em pares; a monitoração e o controle dos
riscos ocorrem durante todo o processo de desenvolvimento; a
comunicação é colaborativa e direta entre todos os membros da equipe,
o que exige certo grau de maturidade por parte da organização, do
cliente e da equipe; todos os participantes do projeto executam suas
tarefas, planejam e tomam decisões em conjunto e compartilhando suas
experiências; o processo de aquisição deve ser evitado em função da
volatilidade dos requisitos; a atuação colaborativa da equipe com o
cliente favorece um major grau de informalidade e o conhecimento
implícito é privilegiado; o papel do gerente de projetos é voltado para o
papel de facilitador ou coordenador das atividades.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
Existem papéis e responsabilidades bem definidos, assim como diversas etapas que devem ser cumpridas
que visam produzir de forma rápida ao mesmo tempo em que atende às necessidades do cliente.
O dono do produto – ou Product Owner – representa os stakeholders e o negócio, os membros da equipe
ou Team é formada por cerca de 7 pessoas. Equipes com poucos envolvidos e multidisciplinares são uma
das características marcantes da metodologia.
Para gerenciar o projeto surge a figura do Scrum Master que funciona como o gerente de projeto, dirigindo
a equipe para que os objetivos e metas sejam atingidos. Ele garante que o processo está sendo seguido.
Participando das reuniões diárias, revisão da Sprint e planejamento.
• A DINÂMICA DO SCRUM
Um dos papéis mais polemizados quando o assunto é Scrum, é
o tradicional gerente de projetos. Primeiro, porque este papel
específico não aparece nas suas definições de papéis, e
segundo, porque ele defende que o time deve ser autogerencial,
o que resumidamente é interpretado como não havendo a
necessidade de ter um gerente de projetos na equipe.
• O GERENTE DE PROJETO NO APOIO
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
• ADAPTABILIDADE
O controle de processos empíricos e a entrega iterativa fazem com que os projetos sejam
adaptáveis e abertos à incorporação de mudanças.
Enquanto os métodos tradicionais de desenvolvimento, em especial o cascata, valorizam análise
extensa e definições rígidas de requisitos, visando “segurança” (ou a falsa sensação dela), o
Scrum abraça a imprevisibilidade que um projeto longo possui ao inserir mais resiliência neles.
• TRANSPARÊNCIA
Na administração tradicional a Gestão à Vista não é algo novo e comprovadamente vantajoso para
as organizações. Isso porque permite que todos vejam o que está acontecendo e consigam tomar
atitudes em relação a isso.
Scrum fala de adaptação, mas não há como se adaptar ao que não se consegue ver, e, por isso,
que o primeiro pilar da metodologia é a transparência.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
Sem transparência não há:
 Inspeção adequada Adaptação;
 Engajamento Confiança; e,
 Evolução do time Sucesso no projeto.
Gerentes temem expor informações que possam gerar medos 
e conflitos no Time. Ao fazerem isso, impedem que o time 
amadureça e realmente “abrace a causa”.
• FEEDBACK CONTÍNUO
O feedback contínuo é fornecido através de processos
denominados como a Reunião Diária e a Sprint Review.
O Scrum fornece diversos mecanismos de feedback, o que
garante o segundo pilar do framework: inspeção, que leva à
adaptação, em um ciclo virtuoso, que gera a melhoria
contínua.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
RESUMINDO
Feedback contínuo não é dar tapinhas nas costas na reunião de final de ano da
empresa. Feedback contínuo tem a ver com transparência, pois o time precisa
saber se suas ações estão gerando resultado. Você precisa saber se está no
caminho certo. O seu colega precisa saber como pode lhe ajudar e você precisa
saber se ele precisa de ajuda também.
• MELHORIA CONTÍNUA
As entregas melhoram progressivamente, Sprint por Sprint, através do processo de refinamento do
Backlog do Produto e do processo em si.
Na metodologia de inovação em startups denominada Lean Startup, existe um ciclo chamado
construir-medir-aprender (build-measure-learn no original) que trabalha da seguinte maneira:
1.Você constrói um incremento de produto;
2.Você mede o desempenho dele;
3.Você aprende com os erros e refina-o; e,
4. Volte ao passo 1.
E assim o é também no Scrum.
O framework é enxuto, apenas 19 páginas. Talvez não cubra nem sequer 10% da “ciência” da
gestão de projetos. Mas os seus princípios fundamentais te ajudam a pensar de uma maneira
diferente, com o mindset correto. Ele próprio te ensina que a inspeção vai te levar inerentemente
ao aprendizado (adaptação) e com isso à melhoria contínua dos processos e produtos.
Esqueça aquela ideia que alguns métodos pregam que você deve apenas confiar cegamente em
um livro e seus problemas estarão resolvidos!
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
DEFINIÇÃO
Lean startup: Esse conceito, no universo da administração, envolve um trabalho de
enxugar, identificação, eliminar desperdícios nos processos e está muito ligado ao
ambiente de startups de tecnologia.
Mindset: traduzindo ao pé da letra seria mente configurada, ou configuração da mente.
O conceito significa o conjunto de atitudes mentais que influencia diretamente nos
nossos comportamentos e pensamentos.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
• ENTREGA CONTÍNUA DE VALOR
Os processos iterativos permitem a entrega contínua de valor tão frequente quanto o exigido pelo
cliente.
Tenha em mente que ninguém compra software. Ninguém.
Só quem gosta de software é programador. Cliente gosta de solução que entrega valor. Se o seu
time demora demais e/ou não entrega valor, ele não vai ir muito longe.
A chave aqui é entregar valor continuamente, em pequenas porções mas frequentes, deixando
sempre o cliente satisfeito e com um “gostinho de quero mais”. A cada iteração do Scrum (sprint),
um incremento de produto é entregue ao cliente, um que gera valor ao mesmo. É assim que tem
que ser em todos os projetos.
Você nunca terá como entregar tudo o que o cliente quer, no prazo que ele quer e dentro do
orçamento dele. Isso não existe!
Mas o processo de criar e priorizar um Backlog de Produto garante que as exigências de maior
valor ao cliente sejam atendidas primeiramente e que o valor que ele tanto busca (não confunda
valor com custo) seja entregue em partes, à cada iteração.
Uma abordagem colaborativa com stakeholders (como a do Scrum) e a ênfase no valor de
negócio, garantem uma estrutura orientada para o cliente. E não orientada ao software.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
OBSERVAÇÃO
Seus clientes não querem seus softwares. Eles querem o valor gerado pelos
mesmos. Eles querem ser “melhores” do que eram antes de comprar seu software.
O Time-boxing e a minimização de trabalho não-essencial conduzem a níveis mais altos de eficiência.
As coisas mais excêntricas existentes no Scrum são em prol da eficiência e, por isso, que seguir o
Scrum à risca é tão importante, principalmente em equipes imaturas do ponto de vista de agilidade.
Pense nas time-boxes: restrições pétreas quanto à duração de eventos no ciclo de desenvolvimento.
Sprints de x semanas. Reuniões de x horas. E por aí vai. Isso não é algo negociável. Esse tipo de
restrição estimula os desenvolvedores do time a pensar no que é mais importante ser desenvolvido
hoje rumo ao objetivo de amanhã. Não há tempo a perder com coisas que não gerem valor à meta da
sprint. Estimula o Product Owner a manter o backlog priorizado como que realmente deve entrar no
produto na próxima sprint, deixando para um futuro incerto o que não é essencial à aplicação.
• EFICIÊNCIA
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
Todos sabemos (ou deveríamos saber) que a falácia
da próxima feature e a over-engineering são alguns
dos piores maus que podem arruinar um projeto de
software e até mesmo uma empresa. As restrições de
tempo do Scrum (e as demais também) te ajudam a
não cair nessas tentações, como essa outra, de
reescrever todo o código da sua aplicação para que
fique “melhor”, por exemplo.
DEFINIÇÃO
Feature: é uma funcionalidade ou uma característica. É algo que tem uma função.
Over-engineering: quando se constrói um código mais sofisticado do que ele precisa
ser.
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
Os processos de conduzir a reunião diária e de
retrospectiva da Sprint conduzem a níveis mais altos de
motivação entre os colaboradores.
É necessário um ambiente de alta confiança para que o
time se sinta motivado a seguir em frente em prol dos
objetivos gerais da Sprint.
Processos do Scrum como a Reunião Diária e a
Retrospectiva da Sprint promovem a transparência (pilar 1,
lembra?) e a colaboração, resultando em um ambiente de
trabalho de alta confiança, e garantindo baixo atrito entre os
colaboradores, além de uma alta motivação, uma vez que o
time tem o suporte e aval necessários para que consiga
avançar sem impedimentos.
Quando os Times confiam sem si mesmos e seus líderes confiam no time, a motivação se torna algo
inabalável, gerando a responsabilidade coletiva e o comprometimento, que é o que todo gerente quer
da sua equipe e toda empresa quer ver nos seus funcionários.
• MOTIVAÇÃO
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
O processo de aprovar, estimar e comprometer-se às tarefas (ou histórias de usuário, casos de uso,
etc.) permite que os membros do time se sintam responsáveis pelo projeto e por seu trabalho,
resultando em uma qualidade muito maior. Não importa se você vai usar planning poker ou não, mas se
não houver confiança no time para tomar essas decisões, não haverá motivação para executar as
tarefas. Tudo começa na confiança!
DEFINIÇÃO
Planning poker: é uma técnica do Scrum que permite ao time do projeto gerar
estimativas rapidamente.
Uma estrutura de colaboração permite que os times multifuncionais atinjam o seu pleno potencial e alta
velocidade.
Se o seu time vem vencendo nos demais quesitos como motivação, entrega contínua de valor,
transparência, adaptação, entre outros, você terá o que todo gerente de software almeja: alta
velocidade!
Não, agilidade não é entregar software, pura e simplesmente, mais rápido. É sobre entregar valor mais
cedo. Mas quando você entrega valor mais cedo, a percepção que todos têm (interna e externamente)
é que o time está avançando mais rápido.
• ALTA VELOCIDADE
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
OBSERVAÇÃO
O que vale mais, um professor sedentário correndo em linha reta por 100m ou o
Usain Bolt correndo em zigue-zague para chegar no mesmo destino que está 100m
à frente? É o mesmo para software!
Se você não está trabalhando com um backlog priorizado, não está entregando
software com foco no cliente (ou seja, entregando valor pra ele), você está
“andando em zigue-zague” rumo ao mesmo objetivo que poderia estar perseguindo
em linha reta!
A alta velocidade obtida com o Scrum não está na quantidade de linhas de código
que seu time vai escrever por Sprint, mas, sim nas linhas certas que serão
escolhidas para serem escritas. Aquelas que trarão os maiores resultados para o
cliente em menos tempo. Isso é velocidade, de maneira inteligente!
COMPREENDENDO A TEORIA POR 
TRÁS DO FRAMEWORK SCRUM
• AMBIENTE INOVADOR
Os processos de Retrospectiva da Sprint e de Review da Sprint criam
um ambiente de introspecção, aprendizagem e adaptabilidade, que
levam a um ambiente de trabalho inovador e criativo.
Não custa repetir: transparência, inspeção e adaptação. Os três
pilares do Scrum.
Esse ciclo virtuoso é a chave para a inovação. A inspeção e adaptação
frequentes do Scrum levam o seu produto sempre aonde ele deve
estar, agora, neste momento. E não conforme foi planejado um ano
atrás com a diretoria.
Embora seja extremamente válido (e aconselhável) definir as estratégias a médio e longo prazo, é a
execução em curto prazo (aliado aos pilares do Scrum) que vão garantir a existência do projeto para
talvez chegar no destino desejado. Se ele ainda fizer sentido um ano depois de traçado.
A chance de revisitar o processo e ajustá-lo a cada Sprint é única e dá uma vantagem muito grande ao
time frente às metodologias tradicionais: a vantagem de poder errar. Mas errar rápido e aprendendo com
esse erro para acertar.
Ninguém tem as respostas sobre como os softwares precisam ser desenvolvidos em todos os casos,
nem o Scrum, mas a inspeção e adaptação às mudanças devem ser o cerne dos projetos.
ENTENDER OS VALORES 
DO MÉTODO SCRUM
Como sabemos o Scrum é uma metodologia ágil para gestão e
planejamento de projetos. Nele, os projetos são divididos em
ciclos com atividades que devem ser executadas dentro de um
cronograma. As metodologias ágeis de desenvolvimento de
software são iterativas, ou seja, o trabalho é dividido em
iterações. As funcionalidades a serem implementadas no
projeto são mantidas em uma lista, para criá-la ou definir as
atividades prioritárias são feitas pequenas reuniões de
planejamento. As reuniões também servem para disseminar
conhecimento sobre o que foi feito no dia anterior, identificar
impedimentos e priorizar o trabalho do dia que se inicia.
Mostrar a eficácia das suas práticas de desenvolvimento para que você possa melhorá-las, enquanto
provê um framework dentro dos quais produtos complexos podem ser desenvolvidos. O Scrum é
fundamentado nas teorias empíricas de controle de processo e tem como base para sua
implementação três pilares: transparência, inspeção e adaptação. A metodologia emprega uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.
• PAPEL E OS PRINCÍPIOS DO SCRUM
Os aspectos do processo que afetam o resultado devem ser visíveis àqueles que gerenciam-no. Esses
aspectos não apenas devem ser transparentes, mas também o que está sendo visto, deve ser
conhecido. O que isso quer dizer? Quando alguém que inspeciona um processo acredita que algo está
pronto, isso deve ser equivalente à sua definição de pronto. A transparência se dá através da
comunicação (verbal ou escrita) e ocorre em diversos momentos, por exemplo:
• TRANSPARÊNCIA
 Quando o cliente (Product Owner) descreve as funcionalidades esperadas para o produto;
 Quando o cliente informa as prioridades das entregas;
 Quando o Scrum Master apresenta o planejamento e o andamento das sprints;
 Quando a equipe comunica diariamente o andamento do trabalho;
 Quando a equipe atualiza um kanban deixando claro o andamento do desenvolvimento do
produto; e,
 Quando a entrega parcial é realizada e o cliente tem a oportunidade de dar um feedback
antes do final do projeto.
ENTENDER OS VALORES 
DO MÉTODO SCRUM
Os diversos aspectos do processo devem ser inspecionados com uma
frequência suficiente para que variações inaceitáveis no processo possam
ser detectadas. A frequência da inspeção deve levar em consideração que
qualquer processo é modificado pelo próprio ato da inspeção. O problema
acontece quando a frequência de inspeção necessária excede a tolerância
do processo à inspeção. Os outros fatores são a habilidade e a aplicação
das pessoas em inspecionar os resultados do trabalho.
A inspeção é um princípio tão forte que o Scrum considera que o processo de testes está dentro da própria
Sprint. Isso nos remete aos conceitos de integração contínua, test driven development e pair programming, que
são formas de garantir a qualidade enquanto o produto está sendo produzido, ao invés de controlar a qualidade
só no final. A inspeçãose dá, por exemplo, através dos seguintes itens:
 No conceito de ready (definition of ready);
 No conceito de done (definition of done);
 Na reunião de grooming;
 Quando se estima os story points de uma história de usuário;
 Reunião de revisão (review meeting) com o cliente (product owner);
 Diariamente, quando alguém termina uma história e um membro do grupo faz a verificação do DoD; e,
 Na verificação de bugs e sua respectiva correção.
• INSPEÇÃO
ENTENDER OS VALORES 
DO MÉTODO SCRUM
O inspetor determinará, a partir da 
inspeção, que um ou mais 
aspectos do processo estão fora 
dos limites aceitáveis e que o 
produto resultante será 
inaceitável, ele deverá ajustar o 
processo ou o material que está 
sendo processado. Esse ajuste 
deve ser feito o mais rápido 
possível para minimizar desvios 
posteriores.
A adaptação é a grande vedete
dos projetos Scrum, pois ele pode
começar com um conjunto de
histórias e terminar relativamente
diferente. O PO pode constituir,
modificar e excluir estórias ao
término de cada Sprint.
• ADAPTAÇÃO
ENTENDER OS VALORES 
DO MÉTODO SCRUM
• PONTOS PARA INSPEÇÃO E ADAPTAÇÃO EM SCRUM
 Daily Scrum: reunião utilizada para inspecionar o progresso em direção à Meta da Sprint e para
realizar adaptações que otimizem o valor do próximo dia de trabalho.
 Reuniões de Revisão da Sprint e de Planejamento da Sprint: utilizadas para inspecionar o
progresso em direção à Meta da Release e para fazer as adaptações que otimizem o valor da
próxima Sprint.
 Retrospectiva da Sprint: utilizada para revisar a Sprint passada e definir que adaptações
tornarão a próxima Sprint mais produtiva, recompensadora e gratificante.
A adaptação se dá, por exemplo, através dos seguintes itens:
 No planejamento do projeto, quando o PO prioriza as histórias;
 No review de uma Sprint, quando o PO reprioriza as histórias (itens do backlog);
 No conceito de meta da Sprint, quando o time tem a liberdade de realizar mais ou menos
histórias do que estava planejado; e,
 No conceito de velocidade – que difere de progresso, quando, após algumas Sprints se tem
a velocidade real do time e se pode calcular o tempo necessário para terminar o projeto.
ENTENDER OS VALORES 
DO MÉTODO SCRUM
• VALORES QUE SUSTENTAM OS PILARES DO SCRUM
Comprometimento: cada pessoa deve estar 
comprometida com os objetivos do time e com 
a meta do Sprint. 
Foco: o time mantém o foco constante na 
meta da Sprint e nos objetivos do time.
Coragem: trabalha com coragem para fazer a 
coisa certa e encarar os problemas difíceis, 
dentro dos limites do framework.
Respeito: os membros do time respeitam uns 
aos outros como pessoas capazes e 
independentes.
Abertura: o Time Scrum e Stakeholders concordam em estarem abertos a respeito do trabalho a
ser feito e dos desafios com a sua execução.
ENTENDER OS VALORES 
DO MÉTODO SCRUM
Scrum não descreve o que fazer em cada situação. Ele é usado para trabalhos complexos nos quais
é impossível predizer tudo o que irá ocorrer. Ele é mais que isso, representa um conjunto de valores,
princípios e práticas que fornecem a base para que a sua organização adicione suas práticas
particulares de planejamento e que sejam relevantes para a sua realidade, com uma versão de
Scrum exclusivamente sua.
OBSERVAÇÃO
No livro “Scrum – A arte de fazer o dobro do trabalho na metade no
tempo”, em que Jeff Sutherland autor e idealizador do Scrum, exemplifica
que se exige prática e atenção para se chegar a um novo estado no qual
as coisas apenas fluem para que o resto aconteça.
ENTENDER OS VALORES 
DO MÉTODO SCRUM
Referências 
bibliográficas
COHN, Mike, Gilleanes T.A. Uma Introdução ao Scrum. 2012
FIGUEIREDO, A.M. Gerenciamento de Projetos Ágeis. Golden Cross, 2007.
KERZNER, H. Project Management: A system approach to planning scheduling and controlling. John 
Wiley & Sons, 2002.
LEITAO, Rogério S. Escritório de Projetos: Definindo uma estratégia para projetos de TI, 2006.
LESSA, L. O Papel do PMO nas Estruturas Organizacionais. Belo Horizonte: PMI Chapter MG, 2006. 
Disponível em: <http://www.pmimg.org.br/Geral/visualizador Conteudo.aspx?cod_areaconteudo=423>. 
Acesso em: 14 fev. 2015.
PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body Of Knowledge -
PMBOK Guide. 3 ed. Pennsylvania: 2004.
PERBIRA, P et al. Entendendo Scrum para Gerenciar Projetos de Forma Ágil. Curitiba: Revista Mundo 
PM, 2007.
http://www.pmimg.org.br/Geral/visualizador
http://www.pmimg.org.br/Geral/visualizador