Metodologias ágeis de gerenciamento de projetos - Scrum

01/05/2021 Ead.
br
CRIATIVIDADE, IDEAÇÃO E
RESOLUÇÃO DE PROBLEMAS
METODOLOGIAS ÁGEIS DE
GERENCIAMENTO DE
PROJETOS - SCRUM
Autor: Esp. Anderson Oliveira
Revisor: Rafael Araújo
INICIAR
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_666627_1&PA… 1/33
01/05/2021 Ead.br
introdução
Introdução
Na economia globalizada, a velocidade das ações a serem tomadas precisa
acompanhar o timing esperado pelas empresas, e o planejamento não pode fugir
desse princípio. Na década de 1990, quando iniciou o desenvolvimento em massa de
softwares para as grandes companhias, Je Sutherland e Ken Schwaber identi caram
que o planejamento tradicional de projetos já não era tão e ciente quanto o
mercado exigia, especialmente no tocante aos prazos que precisavam ser cumpridos
para a entrega dos produtos. E como os clientes não percebiam de imediato os
resultados do planejamento, que durava muito tempo, a proposta de valor se perdia.
Para tanto, eles desenvolveram uma metodologia de planejamento e execução de
projetos que tinham um claro propósito: oferecer ao cliente a percepção do valor do
projeto a ser entregue, num curto espaço de tempo. Surgia assim o Scrum.
Como diz o próprio Sutherland, o Scrum pode ser de nido como “A arte de fazer o
dobro, na metade do tempo”. Vamos conhecer melhor essa metodologia e suas
aplicações a partir de agora!
01/05/2021 Ead.br
O Gerenciamento de
Projetos
Nos dias atuais as transformações são muito rápidas, especialmente devido ao uxo
incessante de informações e às transformações político-econômicas, como o
surgimento de novos mercados, produtos, concorrentes e até modelos de negócio
baseados no avanço tecnológico acessível a todos. Nesse sentido, as empresas, para
obterem sucesso, precisam ser resilientes nos processos de gestão, buscando a
adaptação aos cenários desfavoráveis, a agilidade nos processos, e um planejamento
que busque estratégias para atender às suas necessidades. É nesse sentido que o
gerenciamento de projetos busca oferecer uma possibilidade de atingir as metas
esperadas.
Com isso, busca-se a melhoria nos processos de gerenciamento de projetos, dada a

importância do tema na gestão organizacional. Para tanto, existem diversas fontes
de conhecimento, habilidades e ferramentas para produzir resultados interessantes
para agir em resposta às mudanças o mais e cientemente possível.
O gerenciamento de projetos como um estudo formal que leva as organizações a

obterem resultados positivos iniciou-se a partir da fundação do PMI – Project
Management Institute – que desenvolveu estudos no campo do gerenciamento de
projetos que culminou na criação de um livro que lista um conjunto de “boas
práticas” em gestão, chamado PMBoK – Project Management Book of Knowledge.
01/05/2021 Ead.br
O modelo proposto pelo PMBoK não pode ser considerado de fato uma metodologia,
visto que não precisa ser cumprido “à risca” para proporcionar os resultados
esperados, mas oferece premissas que os projetos desenvolvidos pelas empresas
mais renomadas no mercado mundial cumpriram e obtiveram resultados excelentes
em seus projetos. O modelo proposto pelo livro traz a conexão entre 10 áreas do
conhecimento (6ª edição – integração, escopo, cronograma, custos, qualidade,
recursos, comunicações, riscos, aquisições, partes interessadas) que regulam e
associam todos os passos durante o ciclo de vida do projeto, atribuindo
responsabilidades, recursos, prazos e uxos de comunicações bem de nidos, com o
objetivo de atender os requisitos de nidos no escopo para cumprir as necessidades
dos stakeholders (partes interessadas no projetos. De ne-se partes interessadas
quaisquer pessoas que possam impactar ou serem impactadas pelo projeto).
O gerenciamento de projetos baseado nas boas práticas oferece uma assertividade

na execução que evidencia sua relevância no planejamento de soluções para as
empresas. Entretanto, apesar das inúmeras vantagens, a aplicação das ferramentas
do PMBoK tem algumas desvantagens, onde a principal delas advém do conjunto
demasiado grande de processos em sua aplicação. Exatamente por esse motivo, a
sua aplicação em alguns casos especí cos já não atendia às expectativas de agilidade
em seu desenvolvimento.
Nesse viés, as metodologias ágeis de gerenciamento de projetos ganharam força em

seu desenvolvimento de projetos de software, devido à necessidade de velocidade
na resposta aos clientes. E dada a sua e cácia nesses casos, passaram a ter sua
aplicação difundida nos mais diversos âmbitos do planejamento. Assim, a partir do
manifesto ágil a metodologia passou a ser estruturada e organizada. O manifesto ágil
é um documento que organiza as premissas básicas de uma loso a que prega a
diminuição dos processos buscando uma maior agilidade na entrega dos projetos
aos clientes. Atualmente, a metodologia de gerenciamento de projetos ágeis mais
conhecida é o Scrum.
01/05/2021 Ead.br
saiba
mais
Saiba mais
O manifesto ágil é o documento que regulamenta
a loso a de gerenciamento que visa a agilidade
na entrega dos produtos/serviços planejados,
aumentando a e ciência dos processos,
eliminando os passos que não agregam valor ao
produto nal. Saiba mais acessando o vídeo a
seguir.
ASSISTIR
Diferenças Entre as Metodologias:

Tradicional x Ágil
Ambas metodologias são relevantes e possuem características semelhantes em
diversos pontos, porém divergem em tantos outros, o que nos faz precisar avaliar
qual delas (ou se até ambas) pode(m) ser utilizada(s) para produzir o resultado mais
satisfatório para o projeto que desejamos desenvolver.
No método tradicional de gestão (o método mais rígido, proposto pelo PMI no guia
PMBoK), o objetivo é concluir todo o projeto para que haja a percepção de valor por
parte do cliente, ou seja, apenas o projeto nalizado é passível de ser avaliado. Já na
metodologia ágil, uma das premissas básicas é a subdivisão das metas a serem
atingidas, de nidas como “entregáveis”. Tal fato faz com que o cliente possa
perceber as funcionalidades, como uma espécie de “degustação” do resultado nal
do projeto, que vai sendo construído como um quebra-cabeças, e cada fase do
projeto agrega valor para o cliente.
01/05/2021 Ead.br
Outra característica que diferencia as metodologias de gestão toca no fato que

abrange o custo do projeto. A metodologia tradicional preconiza durante a fase de
planejamento seja estabelecido um orçamento prévio e as margens de erro,
especialmente de nidas (na maioria dos casos) como um dos critérios de aceitação e
qualidade do projeto. Na metodologia ágil, na maioria dos casos, o escopo é muito
aberto e passível a mudanças, o que faz com que as expectativas de custo quem
distantes daqueles planejados no início do projeto.
No que tange aos processos, na metodologia tradicional há uma maior rigidez nos
passos a serem cumpridos, no escopo de nido, gerenciamento do tempo e recursos,
o que faz com que o gerenciamento passe por menos mudanças. Na metodologia
ágil os processos são mais abertos, suscetíveis às mudanças.
As equipes partícipes de projetos baseados na metodologia tradicional costumam

ser maiores e mais heterogêneas, com papéis e responsabilidades distintas,
competências e habilidades diversas e hierarquias bem de nidas. As
responsabilidades desses pro ssionais estão ligadas à execução do seu trabalho em
si, não sendo cobrados pelos resultados nais do projeto. Na gestão ágil, as equipes
tendem a ser mais enxutas, multidisciplinares e autogerenciadas. Cada pro ssional
tem responsabilidades múltiplas, e comprometidos diretamente com o resultado
nal do projeto.
01/05/2021 Ead.br
reflita
Re ita
Je Sutherland e Ken Schwaber
desenvolveram a metodologia ágil para
resolver um problema que aturdia a
cabeça deles no que tangia ao
desenvolvimento de projetos: entregar
resultados rapidamente, garantindo a
qualidade e reduzindo custos. Entretanto,
a metodologia tradicional proposta pelo
PMBoK ainda é amplamente utilizada e
respeitada em todo o mundo. Na sua
opinião, qual das metodologias mais se
adequa à sua realidade?
Fonte: Adaptado de Sutherland (2016).
Em geral, não existe metodologia certa nem errada para a aplicação no

gerenciamento de um determinado projeto. O correto é um planejamento que
contemple as necessidades do projeto, especialmente no que tange ao atendimento
às demandas do cliente, principal stakeholder do projeto (CRUZ, 2018).
praticar
Vamos Praticar
01/05/2021 Ead.br
A metodologia Scrum desenvolvida por Je Sutherland e Ken Schwaber é uma proposta de

gerenciamento de projetos de maneira mais rápida e sistemática, com atividades altamente
caracterizáveis e com uma proposta clara e objetiva. Assinale a alternativa que traz a
proposta da metodologia Scrum.
a) Gestão heterogênea.
b) Mais processos.
c) Proposta de valor.
d) Rigidez.
e) Boas práticas.
01/05/2021 Ead.br
Metodologia Scrum
Uma de nição resumida do Scrum pode ser apresentada como uma metodologia
ágil para proporcionar o desenvolvimento de projetos nos quais as equipes
trabalhem em sinergia para atingir os objetivos propostos. A metodologia é baseada
no preceito de que o cliente enxerga melhor o valor do projeto quando recebe
“pequenos produtos utilizáveis”. E para alcançar esse objetivo, a metodologia propõe
que a equipe de pro ssionais precisa ser autônoma, promovendo uma cultura de
autogestão, ou seja, cada membro da equipe está comprometido com o seu
“entregável”.
É fundamental para o uxo correto dos processos uma estratégia de gerenciamento

chamada “gestão à vista” onde os processos precisam ser visualmente conhecidos
para avaliar seu progresso, até mesmo para garantir o engajamento de todos em
prol do resultado nal, além de evidenciar gargalos e falhas nos processos
preestabelecidos.
Outra premissa atribuída ao desenvolvimento de projetos via Scrum é que os prazos

para a concretização dos chamados “entregáveis” sejam curtos e críveis, de forma
que as medições do projeto aconteçam em intervalos de tempo que não passem do
horizonte de “alguns dias”. As entregas precisam ser comunicadas à equipe sempre
que as medições forem aceitas pelo cliente, fomentando o espírito de engajamento
da equipe em prol do resultado nal.
01/05/2021 Ead.br
Além das características apresentadas, ainda existe mais uma que é fundamental
para a e ciência da aplicação do Scrum: a tendência de adaptar-se a novas
realidades apresentadas pelo ambiente ou exigências advindas do cliente. Ou seja,
as mudanças nos projetos executados via metodologia Scrum são altamente
resilientes no que diz respeito às mudanças no projeto, cujos processos são muito
menos rígidos (em comparação com a metodologia tradicional do PMI).
Os estudos da metodologia Scrum foram iniciados por Je Sutherland e Ken

Schwaber, que desenvolveram um documento que norteia a aplicação do framework
nas mais diversas aplicações, cujo propósito, declarado no Scrum Guide (2013) é
contribuir na elaboração e manutenção de produtos complexos. O guia do Scrum
atribui e de ne os papéis, eventos, artefatos e as regras do Scrum (SUTHERLAND;
SCHWABER, 2013).
De acordo com Sutherland e Schwaber (2013, p. 3), a de nição formal 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”.
A metodologia foi desenvolvida com o intuito de ser leve, simples de entender e

difícil de dominar. Ainda de acordo com os autores, o Scrum não pode ser associado
a um processo ou técnica para construir produtos. É um framework aberto, que
pode ser associado a diversas técnicas e ferramentas para seu desenvolvimento. O
Scrum tem por objetivo evidenciar a e cácia dos processos de gerenciamento de
projetos, apresentando um potencial solução para melhorá-los (SUTHERLAND;
SCHWAlBER, 2013).
Teoria da Aplicação do Scrum

O Scrum é uma metodologia que utiliza processos empíricos em sua estruturação
básica. Ou seja, muitos dos conhecimentos aplicados no seu desenvolvimento são
construídos sobre o alicerce da experiência prévia e da tomada de decisão em cima
de lições aprendidas, visto que o Scrum utiliza uma estrutura iterativa, isto é, seu
desenvolvimento é construído em cima de ciclos de produção incremental, para
re nar os resultados esperados e reduzir os riscos, apoiados em 3 pilares básicos:
transparência, inspeção e adaptação (SUTHERLAND; SCHWABER, 2013).
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_666627_1&P… 10/33
01/05/2021 Ead.br
Sobre a transparência, a aplicação do Scrum preconiza que os principais passos e

resultados precisam estar acessíveis, especialmente aqueles que dizem respeito aos
principais stakeholders. Entretanto, essa acessibilidade requer alguns padrões
comuns para que todos possam obter o mesmo nível de entendimento sobre o que
está sendo apresentado. Já no que tange às inspeções, faz-se necessário que, em
intervalos de tempo regulares, os usuários (alguns dos principais stakeholders do
projeto) precisam acompanhar o desenvolvimento dos “artefatos”, documentos que
constituem o planejamento e execução do projeto, com o intuito de procurar
“discrepâncias” entre o planejado e o executado. Essa veri cação ativa é fundamental
para o re namento do produto nal, e precisa ser executado por especialistas, pois
os feedbacks são essenciais para as melhorias, evidenciando os erros e potenciais
ajustes. A adaptação busca realizar os ajustes, o mais rápido possível para evitar os
erros em cascata no projeto. Na ocasião da inspeção, caso algum processo não
esteja adequado com a sua usabilidade, pode ser ajustado ou realinhado em seu
propósito. Conforme será descrito posteriormente, as inspeções ocorrerão nos
eventos formais em 4 instantes: reunião de planejamento do sprint; reunião diária;
reunião de revisão do sprint; retrospectiva do sprint (SUTHERLAND; SCHWABER,
2013; SABBAGH, 2014).
O uxo dos processos da aplicação do framework Scrum pode ser visto na Figura 4.1.
Figura 4.1 - Fluxo de processos da metodologia Scrum

Fonte: Aleksandra Sabelskaia / 123RF.
A metodologia, até mesmo por conta de sua construção, utiliza vários termos
especí cos, a maioria deles em inglês, que possuem reconhecimento mundial e,
justamente por esse motivo, serão aqui apresentados.
01/05/2021 Ead.br
praticar
Vamos Praticar
A metodologia Scrum desenvolvida por Je Sutherland e Ken Schwaber é uma proposta de
gerenciamento de projetos de maneira mais rápida e sistemática, com atividades altamente
caracterizáveis e com uma proposta clara e objetiva, alicerçada em 3 pilares fundamentais.
Assinale a alternativa que apresenta os 3 pilares fundamentais corretamente.
a) Transparência, inspeção e adaptação.
b) Time Scrum, eventos e artefatos.
c) Proposta de valor, boas práticas e framework.
d) Backlog do produto, Backlog da Sprint e incremento.
e) Product Owner, Scrum Master e time de desenvolvimento.
01/05/2021 Ead.br
Time Scrum
O time Scrum é o conjunto de pessoas que planejam, orientam, desenvolvem e

executam o planejamento do projeto através da metodologia Scrum. Sutherland e
Schwaber (2013) dividem a equipe de trabalho de aplicação do framework em:
Product Owner;
Time de desenvolvimento;
Scrum Master.
A grande premissa para o bom funcionamento da metodologia é a capacidade de

autogerenciamento do time Scrum, além da mobilidade funcional entre os
participantes, dada a multifuncionalidade deles. Esses times autogerenciáveis
determinam as melhores ferramentas a serem utilizadas no desenvolvimento da
metodologia, característica avessa ao planejamento tradicional (onde as ações a
serem tomadas seguem um uxo claro de hierarquia, geralmente o sponsor ou
patrocinador é o responsável). Outra característica importante dessas equipes é que
cada membro possui clara responsabilidade sobre suas ações, então todos precisam
possuir as habilidades e competências necessárias para executar as suas ações
independentemente de qualquer pessoa fora do time Scrum. A metodologia impõe a
utilização dessa estrutura para disseminar a cultura de exibilidade, criatividade e
produtividade (SUTHERLAND; SCHWABER, 2013).
01/05/2021 Ead.br
A proposta clara da formação do time Scrum é oferecer o desenvolvimento de

soluções de maneira iterativa e incremental, aproveitando o feedback gerado ao
longo do processo para retroalimentação. Os entregáveis, produtos ou parcelas
utilizáveis do produto nal têm a missão de oferecer a experiência da utilização de
funcionalidades do resultado nal, proporcionando a valorização contínua do projeto
(SUTHERLAND; SCHWABER, 2013).
Vamos apresentar agora, cada um dos “membros” do time Scrum.
Product Owner
O “dono do produto” é o maior responsável pela proposta de valor do projeto via
metodologia Scrum. Possui a missão de explorar todo o potencial do time de
desenvolvimento, com a utilização de diversas ferramentas para atingir seu objetivo.
Também é responsabilidade do Product Owner o gerenciamento do Backlog do
produto (cuja de nição será apresentada posteriormente). Segundo Sutherland e
Schwaber (2013, p. 5), a responsabilidade do Product Owner sobre 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.
O papel do Product Owner, apesar de, em vários casos atuar sob os propósitos de
uma empresa ou um comitê, é executado sempre por apenas uma pessoa,
responsável direto pelas ações a serem tomadas sob sua área de competência.
Entretanto, as ações sob sua responsabilidade podem ser executadas por outrem,
sob seu controle. É imprescindível que o Product Owner conquiste o respeito de toda
equipe sobre as suas decisões, sem as quais não será possível obter sucesso em seu
gerenciamento. Todas as suas decisões são evidenciadas no conteúdo e nas etapas
de priorização do Product Backlog. Suas decisões são soberanas sobre as dos demais
membros do time (time de desenvolvimento e Scrum Master), especialmente no que
tange às prioridades de execução (SUTHERLAND; SCHWABER, 2013).
01/05/2021 Ead.br
Time de Desenvolvimento
(Development Team)
O time de desenvolvimento do Scrum é o conjunto de pessoas que executam o
trabalho que constrói os “entregáveis”, que segundo o framework Scrum são
chamados de Pronto ou DoD (De nition of Done), sempre que um Sprint é nalizado.
Somente os membros do time de desenvolvimento possuem a responsabilidade de
elaborar os incrementos, e exatamente por esse motivo, os membros estão aptos a
gerir seu próprio trabalho, devidamente autorizados a tomarem as decisões
necessárias para cumprir a sua missão. A efetividade do processo de gerenciamento
é garantida pela sinergia entre os membros do time (SUTHERLAND; SCHWABER,
2013).
Segundo os autores do Guia do Scrum (SUTHERLAND; SCHWABER, 2013, p. 6), as

responsabilidades do time de desenvolvimento são:
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 subtimes dedicados a domínios
especí cos de conhecimento, tais como teste ou análise de negócios.
Outra questão relevante sobre o time de desenvolvimento trata sobre o tamanho da

equipe. A quantidade de membros do time precisa ser de uma abrangência tal que
seja su ciente para atender às demandas do projeto e garantir as entregas no nal
do Sprint, porém não pode ser demasiadamente grande para garantir a agilidade
dos processos. De acordo com o Guia do Scrum (SUTHERLAND; SCHWABER, 2013),
01/05/2021 Ead.br
usualmente os times têm entre 3 e 9 colaboradores, excluindo-se o Scrum Master e o

Product Owner. Nos casos onde eles também executam o papel de membro do time
de desenvolvimento, eles entram na conta do time.
Scrum Master
O papel do pro ssional que ocupa a função de Scrum Master no framework é
garantir que a metodologia seja compreendida por todos os membros do Time
Scrum. É da sua responsabilidade garantir o cumprimento dos papéis e
responsabilidades do Time Scrum, e as práticas comuns à metodologia, como as
entregas dos artefatos, o cumprimento dos eventos e as de nições de Pronto (DoD).
O Scrum Master também tem o papel de avaliar (especialmente durante as
inspeções) as iterações desnecessárias e os erros nos processos, evidenciando o
valor oferecido pelo produto construído via Scrum (SUTHERLAND; SCHWABER, 2013).
O Scrum Master trabalha no apoio e lida diretamente com 3 stakeholders do projeto:

Product Owner, Time de desenvolvimento e Organização. De acordo com Sutherland
e Schwaber (2013, p. 7) a relação entre o Scrum Master e cada um deles estão
listados como segue:
Scrum Master x Product Owner
Encontrar 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 o Time Scrum a criar itens de Backlog do Produto de forma clara e
concisa;
Compreender em 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.
Scrum Master x Time de desenvolvimento:
Treinar o Time de Desenvolvimento em autogerenciamento e

interdisciplinaridade;
Ensinar e liderar o Time de Desenvolvimento na criação de produtos de alto
valor;
01/05/2021 Ead.br
Remover impedimentos para o progresso do Time de Desenvolvimento;

Facilitar os eventos Scrum conforme exigidos ou necessários; e,
Treinar o Time de Desenvolvimento em ambientes organizacionais nos
quais o Scrum não é totalmente adotado e compreendido.
Scrum Master x Organização:
Liderar e treinar a organização na adoção do Scrum;

Planejar implementações Scrum dentro da organização;
Ajudar funcionários e partes interessadas a compreender e tornar aplicável
o Scrum e o desenvolvimento de produto empírico;
Causar mudanças que aumentam a produtividade do Time Scrum; e,
Trabalhar com outros Scrum Masters para aumentar a e cácia da aplicação
do Scrum nas organizações.
Assim, evidenciamos os papéis e responsabilidades do Time Scrum, responsáveis

diretos pelo planejamento, controle e execução do framework. Agora
apresentaremos os eventos preconizados pela metodologia Scrum, fundamentais na
sua construção.
01/05/2021 Ead.br
Eventos Scrum
As atividades realizadas durante a execução do framework Scrum visam oferecer a

agilidade necessária para a execução do projeto como um todo. Para tanto, a
metodologia visa construir rotinas para o seu desenvolvimento, de forma a evitar
pausas desnecessárias, especialmente as reuniões improdutivas ao longo do projeto.
Todos os eventos executados ao longo da execução do Scrum acontecem com uma
duração especí ca (time-boxed). Também durante o planejamento, o Sprint (será
apresentada a sua de nição logo em seguida) terá a duração do seu ciclo fechado, de
tal maneira que não poderá ser alterada ao longo do projeto. Todos os demais
eventos poderão ser encerrados assim que o objetivo nal do projeto for atingido
(SUTHERLAND, SCHWABER, 2013).
A lista de eventos do Scrum abrange, além do Sprint, que se subdivide em alguns

outros subeventos, a Reunião de planejamento do Sprint (Sprint Planning Meeting), a
Reunião diária (Daily meeting), Revisão do Sprint (Sprint Review) e Retrospectiva do
Sprint (Sprint Retrospective). A partir da ocasião de cada um desses eventos,
evidencia-se uma oportunidade de inspecionar o planejamento e restaurar o seu
rumo, na ocasião de erros. A proposta da realização dos eventos visa oferecer uma
maior transparência da execução e a possibilidade de uma auditoria criteriosa das
atividades (SUTHERLAND; SCHWABER, 2013).
Apresentaremos a seguir cada um dos eventos realizados ao longo do

desenvolvimento do framework Scrum.
01/05/2021 Ead.br
Sprint
O Sprint é o principal evento da metodologia Scrum. É o intervalo de tempo
(normalmente cerca de um mês), no qual um produto “Pronto” (DoD) é entregue. Ou
seja, uma parte da solução nal já pode ser avaliada pelo usuário do
produto/serviço. Durante a execução do Sprint, os demais eventos são executados,
para garantir o cumprimento do planejamento, além da execução realizada pelo time
de desenvolvimento.
De acordo com Sutherland e Schwaber (2013, p. 8), durante a execução do Sprint:
Não são feitas mudanças que possam pôr em perigo o objetivo do Sprint;
As metas de qualidade não diminuem; e,
O escopo pode ser clari cado e renegociado entre o Product Owner e o
Time de Desenvolvimento quanto mais for aprendido.
O planejamento do Sprint não contempla prazos (time-box) maiores do que 1 mês,

visto que uma das propostas do framework é a adaptação às mudanças, e nesse
intervalo de tempo, muita coisa pode mudar o planejamento, até mesmo por que
cada Sprint têm no seu planejamento, as atividades a serem realizadas para atingir o
objetivo do Sprint, o trabalho executado e o “pronto” a ser entregue. Os riscos
também aumentam e a previsibilidade do resultado diminuem, reduzindo sua
efetividade.
Durante a execução de um Sprint, apenas um membro do Time Scrum possui a

autoridade de cancelar a sua execução antes do nal do prazo preestabelecido: O
Product Owner. Sua ação (cancelar) pode ser motivada por outros interesses, mas
durante a aplicação da metodologia, a decisão só poderá ser tomada pelo Product
Owner. As ocasiões que levam ao cancelamento do Sprint são poucas, mas a
principal delas é quando o Sprint já não conseguirá atender a expectativa do usuário
nal do produto. Isso ocorre em muitos casos devido ao próprio avanço tecnológico,
às condições mercadológicas ou se a própria organização já não possui o mesmo
processo gerencial. Em resumo, o Sprint deve ser cancelado quando o propósito ao
qual ele se destina se extinguiu. Na ocasião do cancelamento, os artefatos
resultantes do processo (Backlog do produto e “Pronto”) são revisados para avaliar se
o trabalho poderá ser aproveitado, e essa aprovação é realizada pelo Product Owner
(KNAPP; ZERATSKY; KOWITZ, 2017).
01/05/2021 Ead.br
Reunião de Planejamento do Sprint

(Sprint Planning Meeting)
A reunião de planejamento do Sprint é realizada no início do seu desenvolvimento, e
visa elencar as atividades que serão realizadas no Sprint. Tem duração estimada de
2h para cada semana de trabalho do Sprint (Conforme falamos anteriormente, os
tempos “time-box” são rigorosamente de nidos, de forma a evitar desperdício de
tempo com reuniões desnecessariamente longas). Esse controle rígido do time-box
da reunião é papel do Scrum Master.
De acordo com Sutherland e Schwaber (2013, p.9), a reunião de planejamento do

Sprint precisa responder às seguintes questões:
O que pode ser entregue como resultado do incremento do próximo Sprint?

Como o trabalho necessário para entregar o incremento será realizado?
O planejamento do Sprint visa de nir alguns pontos de alinhamento da sua execução

e controle:
O que será executado e entregue como “Pronto” do Sprint;

Quais os critérios de execução do “Pronto”;
Objetivo ou meta do Sprint.
A reunião de planejamento do Sprint é fundamental para que o time de

desenvolvimento possa entender como e quais atividades deverão ser executadas
prioritariamente para cumprir o incremento planejado para esse Sprint. Essa reunião
auxilia também no estabelecimento de metas do projeto.
Reunião Diária (Daily Meeting)

O evento Reunião diária (em muitos locais também é conhecido como Stand-up
meeting, pois em vários casos, a reunião diária acontece com os membros de pé,
para evitar o prolongamento desnecessário) do framework Scrum é realizado
diariamente, com tempo de nido de 15 minutos (Controlado pelo Scrum Master)
para avaliar as atividades executadas no dia anterior, corrigindo possíveis erros ou
discrepâncias no planejamento anterior e planejar as atividades que serão
01/05/2021 Ead.br
executadas no dia de trabalho. Possui uma característica interessante para aumentar

a produtividade: todos os dias, no mesmo horário e local.
Segundo Sutherland e Schwaber (2013, p. 11) durante a reunião diária os membros

do time de desenvolvimento buscam esclarecer:
O que eu z ontem que ajudou o Time de Desenvolvimento a atender a

meta do Sprint?
O que eu farei hoje para ajudar o Time de Desenvolvimento a atender a
meta do Sprint?
Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento
no atendimento da meta do Sprint?
A principal motivação da reunião diária é inspecionar o desenvolvimento do

framework em prol do “Pronto” de nido no Planejamento do Sprint, pois evidencia
as divergências entre o “planejado x realizado” e visa distribuir as atividades para que
os membros possam reparti-las para retomar o planejamento. Por isso mesmo a
reunião é totalmente voltada para o time de desenvolvimento, visto que todos os
membros do grupo possuem as competências e habilidades para desenvolver todas
as etapas da construção do pronto. Essa característica não pode ser dissociada de
um time autogerenciável, competência básica dos times de desenvolvimento. O
Scrum Master regula as ações, mas não interfere na reunião, visto que é voltado para
o time, também evitando que haja interferências de outras pessoas de fora do time
(como o Product Owner, por exemplo). As reuniões diárias além dos objetivos
supracitados ainda reforçam o sentimento de unidade do time, melhoram a
comunicação, eliminam ruídos e evidenciam as barreiras para o desenvolvimento,
melhorando a capacidade de tomada de decisão (SUTHERLAND; SCHWABER, 2013).
Revisão do Sprint (Sprint Review)

O evento Revisão do Sprint (Sprint Review) tem o objetivo de inspecionar a iteração
para veri car o incremento realizado, para ajustar o Backlog do produto caso não
esteja de acordo com o planejado. A Revisão do Sprint é realizada ao nal do “time-
box” do Sprint, e conta com todo o time Scrum (Scrum Master, Product Owner e Time
de desenvolvimento) e os principais stakeholders para identi car oportunidades de
melhoria para o processo e garantir a proposta de valor do framework. A Revisão do
Sprint, cuja proposta é engajar ainda mais os participantes do projeto, obter
feedbacks e incentivar a colaboração, é um evento informal no processo de
01/05/2021 Ead.br
desenvolvimento da metodologia e possui uma duração estimada de 1h para cada

semana do time-box do Sprint (controlado rigidamente pelo Scrum Master).
Como proposto por Sutherland e Schwaber (2013, p.12), a reunião de revisão do

Sprint precisa abordar os seguintes elementos:
Os participantes incluem o Time Scrum e os Stakeholders-chaves convidados

pelo Product Owner;
O Product Owner esclarece quais itens do Backlog do Produto foram
“Prontos” e quais não foram “Prontos”;
O Time de Desenvolvimento discute o que foi bem durante o Sprint, quais
problemas ocorreram dentro do Sprint, e como esses problemas foram
resolvidos;
O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e
responde às 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
(se necessário);
O grupo todo colabora sobre o que fazer a seguir, e é assim que a Reunião
de Revisão do Sprint fornece valiosas entradas para a Reunião de
Planejamento do próximo 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.
O principal produto da reunião de retrospectiva do Sprint é a melhoria do Backlog do

produto que será executado no Sprint seguinte.
Retrospectiva do Sprint (Sprint

Retrospective)
O evento Retrospectiva do Sprint (Sprint Retrospective) é executado pelo time Scrum
sempre entre a reunião de revisão do Sprint e o planejamento do próximo Sprint,
com o objetivo de promover uma auditoria nos processos, inspecionando-se com o
intuito de planejar as melhorias potencialmente aplicáveis nos próximos Sprints.
Tem duração estimada de 1,5 h para cada semana de execução do Sprint. Durante a
01/05/2021 Ead.br
reunião, o Scrum Master, membro responsável pela aplicação do framework, deverá

utilizar todo o seu conhecimento sobre a metodologia para incentivar e engajar a
equipe na execução, evidenciando as vantagens da sua aplicação. A uidez do
processo é essencial para o propósito da metodologia, e o Scrum Master possui a
responsabilidade de evidenciá-la. Para isso, durante a retrospectiva, ele deverá
enxergar os pontos falhos que podem ser melhorados, para serem implementados
nos próximos Sprints. Como um time autogerenciável, o time Scrum precisa
melhorar-se continuamente, e é na retrospectiva do Sprint que esse ciclo ca
evidente.
O propósito da reunião de retrospectiva do Sprint é (SUTHERLAND; SCHWABER,

2013, p. 13):
Inspecionar como o último Sprint foi em relação às pessoas, aos

relacionamentos, aos processos e às ferramentas;
Identi car 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.
01/05/2021 Ead.br
Artefatos do Scrum
(Scrum Artifacts)
Os artefatos produzidos ao longo da execução do framework são os “entregáveis”

desenvolvidos para representar o valor do projeto ao usuário nal, ou para oferecer
ao time Scrum a oportunidade de se autoavaliar ou readaptar. São prioritariamente
desenvolvidos para evidenciar a transparência do framework e precisam ser de fácil
entendimento para todos os stakeholders. Dentre os artefatos do Scrum podemos
listar o Backlog do produto, Backlog do Sprint e incremento (SUTHERLAND;
SCHWABER, 2013).
Backlog do Produto (Product Backlog)

O Backlog do produto (Product Backlog) constitui-se como um conjunto de
funcionalidades a serem cumpridas para atender aos requisitos do usuário do
produto, listando todas as características, rotinas, requisitos e mudanças realizadas
no objeto do estudo. O único responsável pela administração do Backlog do produto
sobre todos os aspectos (conteúdo, ordem e disponibilidade) é o Product Owner. O
Backlog do produto é desenvolvido inde nidamente e dinamicamente, na mesma
proporção que o produto é re nado, a equipe evolui e o ambiente é favorável. A
construção do Backlog do produto é contínua, e ele perdura enquanto o produto
ainda existir, visto que a proposta de valor do Scrum só estará completa a partir da
utilização do produto, e o feedback gerado após a sua utilização deve constar no
01/05/2021 Ead.br
Backlog do Produto. O desenvolvimento do produto deve seguir a ordem

determinada pelo Product Owner, e deve contemplar as mudanças ambientais as
quais afetam o diretamente o framework ou seus stakeholders, e as alterações feitas
nos produtos geram incrementos, que devem ser registrados no Product Backlog.
(SUTHERLAND; SCHWABER, 2013).
Visto que o desenvolvimento do Backlog do produto é realizado a cada incremento

no objeto em estudo, para melhor descrever e organizar as alterações realizadas
nele, apresentaremos alguns itens que podem oferecer um detalhamento (CRUZ,
2018):
Story (estória) – Processo de desenvolvimento de um novo incremento;

ID – Identi cação ou código de um incremento realizado no produto. É
realizado para mantermos o controle sobre as alterações realizadas;
Nome – Atribuição de uma descrição, que possa ser de fácil compreensão
por parte de todos os stakeholders, para o incremento realizado;
Importância – Criterização (quantitativamente ou qualitativamente) do
incremento por ordem de relevância, por parte do Product Owner;
Estimativa de conclusão – Duração estimada para concretização do
incremento;
Demonstração dos resultados – Apresentação da rotina de utilização do
incremento após a entrega;
Notas explicativas.
De acordo com o Scrum Guide (SUTHERLAND; SCHWABER, 2013) no processo de

previsão e ajuste do Backlog do produto podem ser utilizadas técnicas como
burndown, burnup, entre outras técnicas de previsão. Entretanto, ainda não podemos
desprezar o efeito do empirismo no processo de melhoria contínua do Backlog do
produto.
01/05/2021 Ead.br
saiba
mais
Saiba mais
As ferramentas burndown e burnup são essenciais
no acompanhamento do cumprimento das metas
previstas para o Sprint, identi car gargalos e
planejar soluções. No artigo a seguir, Canazaro,
Costa e Oliveira apresentam uma aplicação
prática das ferramentas.
Backlog do Sprint
O Backlog do Sprint reúne todos os requisitos do projeto que devem ser cumpridos
naquele Sprint especí co, além de incluir o plano de execução para desenvolvimento
do incremento e atender as metas do Sprint. É uma espécie de estimativa realizada
pelo time de desenvolvimento sobre os requisitos que estarão presentes no produto
ao nal do Sprint e o trabalho a ser realizado, transformando o incremento em um
“Pronto”. Ele contém um planejamento detalhado das atividades que serão
apresentadas a cada reunião diária. O time de desenvolvimento é inteiramente
responsável pela construção, manutenção e cumprimento do Backlog do Sprint, de
forma a cumprir as metas preestabelecidas. O Backlog do Sprint também tem a meta
de garantir a transparência no desenvolvimento do planejamento do Sprint além de
evidenciar potenciais falhas e oportunidades de melhorias (SUTHERLAND;
SCHWABER, 2013).
Incremento
01/05/2021 Ead.br
O incremento de um produto pode ser de nido como o conjunto de todos os itens

constantes no Backlog do produto, bem como o resultado de todos os Sprints
anteriores. Cada Sprint tem como objetivo produzir um incremento “Pronto”
utilizável ainda que não seja liberado pelo Product Owner.
Conforme falado anteriormente, um dos pilares do Scrum é a transparência, e os

seus processos precisam garantir essa virtude. O Scrum Master tem a obrigação de,
em conjunto com os demais membros do time, proporcionar a transparência dos
artefatos, em um trabalho contínuo e incessante, visto que a tomada de decisão para
aumentar o valor e o controle dos riscos contemplam o estado em tempo real dos
artefatos. Entretanto, muitas decisões erradas podem acontecer, fazendo com que a
proposta de valor ao usuário diminua, aumentando os riscos (SUTHERLAND;
SCHWABER, 2013).
Uma das características que mais demandam a transparência do framework Scrum é

a “De nição de Pronto” (De nition of Done – DoD). A de nição de “Pronto” a rma o
instante no qual um incremento ou algum item do Backlog do produto atinge esse
status para todos os membros da equipe Scrum. Essa de nição é essencial na
metodologia, pois guia o time de desenvolvimento sobre quais itens do Backlog do
produto poderão ser realizados durante o “time-box” do Sprint, visto que um “Pronto”
precisa oferecer uma versão “potencialmente utilizável” do produto, e cabe ao
Product Owner liberá-lo ou não. Caso haja mais de um time Scrum trabalhando em
um determinado projeto, todos eles devem compartilhar a mesma de nição de
“Pronto”, assim que um determinado incremento de nido como “Pronto”, testado e
liberado, é somado aos demais incrementos já produzidos. É importante salientar
que com o progresso do time Scrum, e a sua metodologia está altamente
compreendida pela organização, os critérios que levam a “De nição de Pronto” são
mais rígidas e com altos padrões de qualidade.
A apresentação da metodologia evidencia uma característica fundamental para o

desenvolvimento de projetos que envolvem criatividade: a proposta de valor para o
usuário. Por isso que a metodologia Scrum tem sido aplicada nos mais diversos
planejamentos de produtos/serviços com sucesso, porque propicia um planejamento
com menos erros, transparência, menos custos e tempo para execução, tornando-se
uma excelente opção de planejamento em detrimento do gerenciamento de
projetos.
01/05/2021 Ead.br
praticar
Vamos Praticar
Os artefatos são produtos do desenvolvimento do framework Scrum que são produzidos ao
longo de sua execução. O Backlog do produto é um deles, onde consta o registro de todas
as atividades e incrementos realizados ao longo da execução da metodologia. Em relação
ao assunto, assinale a alternativa que corresponda ao responsável pela gerência do Backlog
do produto.
a) Scrum Master.
b) Product Owner.
c) Time de desenvolvimento.
d) Sponsor.
e) Stakeholder.
01/05/2021 Ead.br
indicações
Material
Complementar
FILME
Invictus
Ano: 2009
Comentário: O lme relata a história real do time de rugby

sul-africano campeão da copa do mundo de Rugby, em 1995,
inspirado pelo líder da libertação do país que sofria com o
apartheid, Nelson Mandela, e liderado pelo capitão François
Pienaar, superando todas as diferenças e evidenciando o
trabalho em equipe, fundamental para o sucesso. Uma
curiosidade: O termo Scrum origina-se de uma jogada do
rugby: o scrummage.
Para conhecer mais sobre o lme, acesse o trailer a seguir.
TRAILER
01/05/2021 Ead.br
LIVRO
A arte de fazer o dobro na metade do tempo

Je Sutherland
Editora: Leya
ISBN: 978-8544104514
Comentário: O livro apresenta a experiência de Je

Sutherland, um dos fundadores do manifesto ágil que
revolucionou os métodos de planejamento, eliminando os
processos burocráticos, evidenciando a proposta de valor de
um projeto.
01/05/2021 Ead.br
conclusão
Conclusão
Ao longo do nosso estudo apresentamos a metodologia de gerenciamento de
projetos ágeis chamado Scrum, cujo objetivo essencial é a proposta de valor que o
framework oferece aos seus usuários, apoiada em 3 pilares básicos: transparência,
inspeção e adaptação.
A metodologia é construída a partir do entendimento de 3 entes fundamentais:

Equipe Scrum, eventos e artefatos. A equipe Scrum é orientada pelo Scrum Master,
executada pelo time de desenvolvimento e aprovada pelo Product Owner. Os
eventos do Scrum têm por característica básica ocorrerem em intervalos de tempo
xos, chamados “time-box” que são determinados pela duração do Sprint, intervalo
de tempo de geralmente um mês para execução de um “Pronto”. Ao longo do seu
desenvolvimento, a metodologia evidencia a elaboração dos artefatos, que
correspondem à criação e manutenção do Backlog do produto, Backlog do Sprint e
os incrementos.
Diante do exposto, podemos concluir que a metodologia Scrum possui as

características essenciais para apoiar o desenvolvimento de projetos criativos, devido
essencialmente à proposta de valor ao usuário nal.
referências
Referências
Bibliográ cas
01/05/2021 Ead.br
CANAZARO, J. V.; COSTA, J. V. da S.; OLIVEIRA, F. M. de. Gerenciamento ágil de

projetos com scrum e kanban: desenvolvendo competências estratégicas na
elaboração de material didático de um curso superior em EAD. REINPEC - Revista
Interdisciplinar Pensamento Cientí co, v. 5, n. 1, p. 124-139, 2019.
CRUZ, F. Scrum e Agile em Projetos: guia completo. 2. ed. Rio de Janeiro: Brasport,
2018.
KNAPP, J.; ZERATSKY, J.; KOWITZ, B. Sprint: o método usado no Google para testar e
aplicar novas ideias em apenas cinco dias. Rio de Janeiro: Intrínseca, 2017.
SABBAGH, R. Scrum: Gestão ágil para projetos de sucesso. [S.l.]: Casa do Código,
2014.
SUTHERLAND, J. Scrum: A arte de fazer o dobro na metade do tempo. São Paulo:

Leya, 2016.
SUTHERLAND, J.; SCHWABER, K. The Scrum Guide. The de nitive guide to Scrum: The
rules of the game. July 2013. Disponível em:
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf. Acesso em:
jan. 2020.
01/05/2021 Ead.br

Metodologias ágeis de gerenciamento de projetos - Scrum

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodologias ágeis de gerenciamento de projetos - Scrum

Enviado por

Direitos autorais:

Formatos disponíveis

01/05/2021 Ead.

Com isso, busca-se a melhoria nos processos de gerenciamento de projetos, dada a

O gerenciamento de projetos como um estudo formal que leva as organizações a

O gerenciamento de projetos baseado nas boas práticas oferece uma assertividade

Nesse viés, as metodologias ágeis de gerenciamento de projetos ganharam força em

Diferenças Entre as Metodologias:

Outra característica que diferencia as metodologias de gestão toca no fato que

As equipes partícipes de projetos baseados na metodologia tradicional costumam

Fonte: Adaptado de Sutherland (2016).

Em geral, não existe metodologia certa nem errada para a aplicação no

A metodologia Scrum desenvolvida por Je Sutherland e Ken Schwaber é uma proposta de

É fundamental para o uxo correto dos processos uma estratégia de gerenciamento

Outra premissa atribuída ao desenvolvimento de projetos via Scrum é que os prazos

Os estudos da metodologia Scrum foram iniciados por Je Sutherland e Ken

De acordo com Sutherland e Schwaber (2013, p. 3), a de nição formal do Scrum é

A metodologia foi desenvolvida com o intuito de ser leve, simples de entender e

Teoria da Aplicação do Scrum

Sobre a transparência, a aplicação do Scrum preconiza que os principais passos e

Figura 4.1 - Fluxo de processos da metodologia Scrum

a) Transparência, inspeção e adaptação.

b) Time Scrum, eventos e artefatos.

c) Proposta de valor, boas práticas e framework.

d) Backlog do produto, Backlog da Sprint e incremento.

e) Product Owner, Scrum Master e time de desenvolvimento.

O time Scrum é o conjunto de pessoas que planejam, orientam, desenvolvem e

A grande premissa para o bom funcionamento da metodologia é a capacidade de

A proposta clara da formação do time Scrum é oferecer o desenvolvimento de

Vamos apresentar agora, cada um dos “membros” do time Scrum.

Expressar claramente os itens do Backlog do Produto;

Segundo os autores do Guia do Scrum (SUTHERLAND; SCHWABER, 2013, p. 6), as

Eles são auto-organizados. Ninguém (nem mesmo o Scrum Master) diz ao

Outra questão relevante sobre o time de desenvolvimento trata sobre o tamanho da

usualmente os times têm entre 3 e 9 colaboradores, excluindo-se o Scrum Master e o

O Scrum Master trabalha no apoio e lida diretamente com 3 stakeholders do projeto:

Scrum Master x Product Owner

Encontrar técnicas para o gerenciamento efetivo do Backlog do Produto;

Scrum Master x Time de desenvolvimento:

Treinar o Time de Desenvolvimento em autogerenciamento e

Remover impedimentos para o progresso do Time de Desenvolvimento;

Scrum Master x Organização:

Liderar e treinar a organização na adoção do Scrum;

Assim, evidenciamos os papéis e responsabilidades do Time Scrum, responsáveis

As atividades realizadas durante a execução do framework Scrum visam oferecer a

A lista de eventos do Scrum abrange, além do Sprint, que se subdivide em alguns

Apresentaremos a seguir cada um dos eventos realizados ao longo do

De acordo com Sutherland e Schwaber (2013, p. 8), durante a execução do Sprint:

O planejamento do Sprint não contempla prazos (time-box) maiores do que 1 mês,

Durante a execução de um Sprint, apenas um membro do Time Scrum possui a

Reunião de Planejamento do Sprint

De acordo com Sutherland e Schwaber (2013, p.9), a reunião de planejamento do

O que pode ser entregue como resultado do incremento do próximo Sprint?

O planejamento do Sprint visa de nir alguns pontos de alinhamento da sua execução

O que será executado e entregue como “Pronto” do Sprint;

A reunião de planejamento do Sprint é fundamental para que o time de

Reunião Diária (Daily Meeting)

executadas no dia de trabalho. Possui uma característica interessante para aumentar

Segundo Sutherland e Schwaber (2013, p. 11) durante a reunião diária os membros

O que eu z ontem que ajudou o Time de Desenvolvimento a atender a

A principal motivação da reunião diária é inspecionar o desenvolvimento do

Revisão do Sprint (Sprint Review)

desenvolvimento da metodologia e possui uma duração estimada de 1h para cada

Como proposto por Sutherland e Schwaber (2013, p.12), a reunião de revisão do