AULA 4

FRAMEWORK SCRUM

Prof. Anderson Rodrigues Matos

TEMA 1 – PRODUCT BACKLOG

Nas três aulas anteriores, falamos sobre o conceito e a origem do Scrum,

bem como de seus princípios e valores. Foram apresentados também os
componentes humanos do Scrum, com seus papéis e suas responsabilidades.
Com o Time Scrum definido e com cada um dos três papéis representados
(Scrum Master, Product Owner e Time de Desenvolvimento), vamos entender
como a dinâmica de desenvolvimento dos processos acontece nos times
utilizando o Scrum.
Quando falamos em processos, precisamos saber que existem dois tipos:
os Definidos, em que se determina o que deve ser feito, quando e como; e os
Empíricos, em que não é possível conhecer todas as variáveis de entrada para
estabelecer um processo repetível. São baseados na inspeção e na adaptação e
a sua utilização é indicada quando processos definidos não forem adequados em
razão da complexidade do projeto.
Os artefatos e os eventos são as características Scrum. Com reuniões em
pé e quadros cheios de post its, são símbolos da informalidade e da criatividade
dos colaboradores e funcionam como base para a transformação cultural nas
empresas.
Falando especificamente do Scrum, precisamos nos lembrar dos pilares:
transparência, inspeção e adaptação. Eles funcionam como base para os
artefatos, com ferramentas que apoiam o Time Scrum, e para os eventos
realizados, garantindo maior produtividade e qualidade na entrega do produto.
Se buscarmos um conceito para artefato, encontraremos como todo
instrumento ou mecanismo que se constrói para um propósito específico. Esse
propósito no Scrum é o de trazer o máximo de transparência nas informações para
que todos envolvidos tenham entendimento da linha de desenvolvimento do
produto.
No Guia do Scrum, de 2017, os criadores do Scrum conceituam os artefatos
como representantes do trabalho ou do valor para o fornecimento de
transparência e oportunidades para realização dos pilares de inspeção e
adaptação. Ainda, afirmam que os artefatos foram especificamente projetados
para maximizar as informações-chave, promovendo a todos o mesmo
entendimento dos artefatos.

2
Figura 1 – Artefatos do Scrum

Fonte: Matos, 2020.

Como demonstra a figura acima, os Artefatos do Scrum são: Product

Backlog; Sprint Backlog e Incremento. A Definição de Pronto também é
mencionada no guia e deve se fazer presente em todos os artefatos, além de estar
alinhada e ser de conhecimento de todos os envolvidos. Por isso, será detalhada
na sequência.
O backlog do produto é uma lista que ordena tudo o que já é conhecido e
que será necessário para produção do produto. Ele é a única origem de requisitos,
melhorias ou correções a serem implementados no produto. A responsabilidade
sobre as informações, que devem ser suficientes, tem como ordem o Product
Owner. Por ser um artefato dinâmico, ele evolui com o produto, sempre com a
finalidade de torná-lo competitivo e aderente às expectativas e necessidades do
cliente. Para isso, é indispensável obter feedbacks constantes do mercado e dos
clientes, por meio dos quais serão realizados os ajustes necessários no produto.
É necessário também estar atento a tudo o que possa interferir de forma positiva
ou negativa na evolução do desenvolvimento do produto, sejam novidades
tecnológicas ou de oportunidades de negócio.
Fabio Cruz, em seu livro Scrum e Agile em Projetos: Guia Completo (2018),
chama a atenção para a definição do Backlog do Produto, afirmando que ele não
é apenas uma lista de itens ou conjunto de histórias, sendo composto dos itens
do backlog e adicionado a todo o entendimento indispensável para atender esses
3
requisitos. Portanto, é constituído de características, funções, detalhamentos,
melhorias e correções que se fizerem necessárias para a construção da versão
futura do produto. Afirma, ainda, que o backlog é o item principal e mais importante
de um projeto, porque ele influencia todas as áreas, e o trabalho de entendimento
e detalhamento é um dos mais importantes para o sucesso do projeto.

Figura 2 – Product Backlog

Fonte: Matos, 2020.

O backlog do produto nunca está pronto. Ele é iniciado com as informações

básicas, requisitos que inicialmente são mais bem conhecidos e entendidos.
Depois, serão feitas alterações para que o backlog esteja alinhado com a evolução
do produto ou do ambiente no qual ele está inserido.
Segundo o Guia Scrum, de 2017, o backlog do produto lista todas as
características, funções, requisitos, melhorias e correções que compõem as
alterações necessárias no produto nas versões futuras, bem como atributos de
descrição, ordem, estimativa e valor. E o backlog vai além, incluindo geralmente
a descrição de testes para a comprovação quando o item estiver completo,
“pronto”.
À medida que um produto ou serviço é usado, ele ganha valor por meio do
feedback do mercado e do cliente, por isso o backlog do produto é dinâmico e
está em constante mudança.

1.1 Refinamento do product backlog

O refinamento tem a função de detalhar e ordenar os itens do backlog do

produto, além de inserir informações como tamanhos e estimativas. Esse
processo é contínuo e realizado pelo Product Owner, que conta com a

4
colaboração do Time de Desenvolvimento. São realizadas análises e revisões até
que haja concordância de que o refinamento está completo, “pronto”.

Figura 3 – Product backlog refinement

Fonte: Quickscrum, s.d.

Esse refinamento ocupa menos de 10% da capacidade do Time de

Desenvolvimento, contudo os itens podem ser sempre atualizados pelo Product
Owner, gerando novas ações de refinamento.
No refinamento do backlog do produto, são definidos também o nível de
clareza e o detalhamento dos itens, seguindo a ordem do topo da lista para baixo.
Ou seja, os itens na ordem mais alta da lista serão mais claros e detalhados, e o
nível vai diminuindo até os itens na ordem mais baixa da lista.
Os itens do topo da lista são prioritários e receberam maior detalhamento
após o refinamento, de maneira que serão divididos em itens menores e
estimados corretamente. Esses itens entrarão em produção já na próxima Sprint.
Já os itens que se encontram na ordem mais baixa da lista são definidos como
menos prioritários, desta forma não há necessidade de investir a energia da
equipe no momento inicial.

5
 As reuniões de refinamento do backlog servem também para diminuir a
ansiedade dos membros da equipe e deixá-los nivelados no que se refere ao
conhecimento das prioridades.
Os itens já refinados, que estarão “prontos” na Sprint, são considerados
“preparados” para seleção no planejamento da Sprint. O Time de
Desenvolvimento é quem o estima e o avalia como “preparado”. O Product Owner
contribui e até influencia no refinamento do item, porém não tem a atribuição de
determinar um item como “preparado”.

TEMA 2 – SPRINT BACKLOG

O Backlog da Sprint é o conjunto de itens do Backlog do Produto

considerados prioritários pelo Product Owner e Time de Desenvolvimento,
“preparados” pelo Time de Desenvolvimento e selecionados para a Sprint.

Figura 4 – Sprint backlog

Fonte: Matos, 2020.

6
 A previsão dada pelo Time sobre a funcionalidade estará no próximo
incremento, bem como o trabalho necessário para a entrega da funcionalidade
“pronta”.
O Backlog da Sprint é a imagem em tempo real do trabalho que o Time de
Desenvolvimento pretende completar na Sprint. O objetivo é tornar visível todo o
trabalho identificado como necessário para atingir a meta da Sprint.
O Time de Desenvolvimento altera o Backlog da Sprint durante toda a
Sprint, porque ele vai surgindo nessa etapa do desenvolvimento, conforme a
equipe trabalha seguindo o plano para entrega do incremento, que contém os
mesmos itens selecionados do Backlog do Produto. E quando o Time trabalha
segundo o plano, ele se aperfeiçoa mais sobre o que é necessário para atingir a
meta da Sprint.
Conforme o desenvolvimento evolui, podem surgir novos trabalhos
necessários, os quais devem ser adicionados ao Backlog da Sprint. Assim como
os trabalhos identificados como desnecessários serão removidos, a estimativa do
trabalho restante é atualizada.
O Scrum Master auxilia o Time de Desenvolvimento, facilitando as entregas
por meio do incentivo à colaboração, da condução das reuniões e da ajuda às
equipes na melhoria da produtividade.

Figura 5 – Burn Down Chart

Fonte: Insight, 2019.

7
 A responsabilidade e a competência para alteração do Backlog da Sprint
são do Time de Desenvolvimento. A estimativa do que ainda falta ser realizado é
calculada diariamente e os dados são lançados em um gráfico, resultando em um
Sprint Burndown chart.
O Burndown chart é um gráfico utilizado pelo Time de Desenvolvimento
para representar diariamente o progresso do trabalho. Apresenta a porção de
trabalho finalizada em comparação com o trabalho total planejado.

TEMA 3 – INCREMENTO

Figura 6 – Incremento no produto

Fonte: Elaborado com base em Framework.net da Microsoft.

O Incremento é a soma dos itens do Backlog do Produto completados

durante a Sprint e adicionados aos valores dos incrementos das Sprints
anteriores.
Ao final de cada Sprint, um novo incremento deve estar “pronto”, ou seja,
estar na condição de ser utilizado. Deve ter passado por todas as etapas de
desenvolvimento e validação, cabendo ao Product Owner a decisão de colocá-lo
em produção ou não.
No Guia Scrum (2017), o Incremento é descrito como parte principal, que é
inspecionada e suporta o empirismo no final da Sprint, sendo um passo na direção
de uma visão ou objetivo. A condição de um Incremento utilizável deve existir
independentemente da liberação ou não do Product Owner.

8
3.1 Definição de Pronto

A Definição de Pronto é um artefato que reforça a transparência, no qual

todos do Time Scrum devem entender o que significa um trabalho estar completo,
assegurando, assim, a transparência.
A Definição de Pronto se aplica ao Backlog do Produto e ao Incremento,
orientando o Time de Desenvolvimento no conhecimento de quantos itens do
Backlog devem ser selecionados. Os Incrementos gerados ao final de cada Sprint
devem ser potencialmente utilizáveis, definindo como entregável com um nível de
qualidade para ser entregue.
Conforme o Time trabalha, após várias Sprints, a Definição de Pronto evolui
garantindo que a qualidade do time seja tão alta quanto necessária e que o
empirismo existente nos processos de melhoria contínua contribua na produção
de um produto com cada vez mais qualidade.

Figura 7 – Características do Scrum

TEMA 4 – SPRINT

Os Eventos do Scrum são a Sprint e suas especificidades desmembradas

em: Planejamento da Sprint; Reunião Diária; Revisão da Sprint e Retrospectiva
da Sprint.
Os Eventos no Scrum têm a finalidade de criar uma rotina e minimizar a
necessidade de reuniões que não estejam definidas no Scrum. A realização
desses eventos garante também a transparência e uma inspeção criteriosa.
No Scrum, os eventos também são chamados de Time-boxed, porque têm
duração fechada. Eles podem até ser fechados em um tempo menor, mas em
hipótese alguma, maior. O entendimento do Time-boxed é importante para

9
compreensão dos eventos, porque não se refere apenas ao tempo, mas ao
trabalho. Time: duração fixa de tempo que deve ser encerrada assim que o tempo
terminar. Boxed: caixa fechada de trabalho. Existindo uma definição de trabalho a
ser realizado, este deve ser finalizado completamente. O Scrum Master, como
facilitador, deve garantir esse tempo de execução.
No Guia Scrum (2017), a Sprint é conceituada como o coração do Scrum,
realizada em um Time-boxed de até um mês (trinta dias), em que um incremento,
“pronto”, potencialmente executável é liberado.
Durante a Sprint, não serão aceitas mudanças que ameacem o objetivo da
Sprint; as metas de qualidade são definidas e não podem ser diminuídas; e há
possibilidade de elucidação e renegociação do escopo entre o Product Owner e o
Time de Desenvolvimento de acordo com o que foi aprendido.
Sprints são como projetos que devem ser concluídos em um mês (trinta
dias), com o objetivo de realizar algo com a meta do que será construído e com
um plano flexível, que guiará o trabalho e a construção do incremento. Como a
Sprint é a parte central do Scrum, ela envolve os outros quatro eventos realizados
na Sprint.
A Sprint pode ser cancelada pelo Product Owner, e somente ele pode optar
por fazê-lo. Esse cancelamento não é um procedimento comum, mas aplicável se
o objetivo da Sprint se tornar obsoleto, em razão de alterações nas direções do
projeto ou nas condições do mercado.

4.1 Planejamento da Sprint

É um trabalho realizado em colaboração de todo Time Scrum para planejar

o trabalho a ser realizado na Sprint. É um Time-boxed com no máximo oito horas
de duração, para uma Sprint de um mês (trinta dias), podendo ser menor
proporcionalmente ao prazo da Sprint.
Neste evento, são levantadas e discutidas as seguintes questões, que
devem ser respondidas:

1) O que pode ser entregue como resultado do incremento da próxima Sprint?

Para responder a essa pergunta, o Time de Desenvolvimento deve prever
as funcionalidades que serão desenvolvidas de acordo com os itens
selecionados do Backlog do Produto, após refinamento. Somente o Time
de Desenvolvimento será capaz de avaliar o que pode ser completado ao
longo da Sprint. O Product Owner, por sua vez, debate o objetivo que
10
 deverá ser realizado e os itens do Backlog do Produto, que, completados
na Sprint, atingirão o objetivo dela.
2) Como o trabalho necessário para entregar o incremento será realizado?
O planejamento do trabalho para os primeiros dias da Sprint e sua
decomposição é feito pelo Time de Desenvolvimento até o final da reunião
de Planejamento da Sprint. Já a auto-organização do Time referente a todo
o trabalho do Backlog da Sprint ocorre durante o Planejamento da Sprint e,
o quanto mais for necessário, durante a Sprint.

Se o Time de Desenvolvimento identificar que existe excesso ou falta de

trabalho, os itens do Backlog do Produto podem ser renegociados com o Product
Owner, que pode auxiliar também na clarificação de cada um deles.
Se houver necessidade, outras pessoas, com conhecimentos técnicos e
domínios específicos, poderão participar da reunião a convite do Time de
Desenvolvimento.
Ao final da reunião de planejamento da Sprint, o Time de Desenvolvimento
deve estar preparado para expor ao Product Owner e ao Scrum Master a forma
como pretende realizar o trabalho para atingir o objetivo da Sprint e criar o
incremento.

4.2 Reunião diária

Esse evento do Scrum é um Time-boxed de 15 minutos, realizado

diariamente pelo Time de Desenvolvimento, em que será planejado o trabalho
para as próximas 24 horas. Tem o objetivo de otimizar a colaboração do time e
inspecionar o trabalho desde a última reunião diária, verificando se o progresso
está na direção correta para completar o trabalho do Backlog da Sprint.
O Time de Desenvolvimento é quem define a estrutura da reunião e pode
conduzi-la de formas diferentes, porém sempre com foco em atingir a meta da
Sprint. Basicamente, o Time vai explanar e discutir os seguintes pontos:

• O que foi realizado desde a última reunião;

• O que será realizado até a próxima reunião;
• Quais foram os obstáculos e impedimentos encontrados.

Como todos os membros do time explanam sobre os trabalhos realizados

e os que estão previstos, facilita a compreensão geral sobre a atividade de cada

11
integrante e onde ele precisa de ajuda, unificando os membros como uma equipe
e melhorando, consequentemente, o conhecimento do Time.
Na reunião, a explanação deve ser objetiva, com o intuito de identificar o
quão perto o Time de Desenvolvimento está da meta da Sprint. A inspeção do que
foi realizado e a identificação do que será realizado naquele dia auxiliam o Time
na tomada de decisões rápidas, utilizando a adaptação para melhorar o
desempenho na realização e a qualidade no que é feito. As discussões mais
detalhadas sobre pontos da reunião acontecerão após seu encerramento.
O Time de Desenvolvimento é responsável por conduzir a reunião, e outras
pessoas podem participar somente como ouvintes. O Scrum Master auxiliará o
Time, ensinando a não exceder o tempo de 15 minutos; garantindo que as
pessoas externas não perturbem a reunião e; ainda, trabalhando na resolução ou
remoção de obstáculos e impedimentos mencionados na reunião.

4.3 Revisão da Sprint

Esse evento é realizado no final da Sprint, com um Time-boxed de no

máximo quatro horas, para uma Sprint de um mês (trinta dias), ou tempo menor
proporcional ao da Sprint.
Na revisão, o Time Scrum e as partes interessadas colaboram sobre o que
foi desenvolvido na Sprint. É uma reunião informal para apresentação do
incremento. O objetivo é obter feedback e promover a colaboração.
A Revisão da Sprint inclui os seguintes elementos:

• Participam da reunião o Time Scrum e os stakeholders convidados pelo

Product Owner;
• O Product Owner esclarece os itens do Backlog do Produto que foram
“prontos” e os que não foram;
• O Time de Desenvolvimento descreve o que foi desenvolvido sem
problemas, bem como os obstáculos e impedimentos encontrados, e como
estes foram resolvidos;
• O Time de Desenvolvimento apresenta o incremento “pronto” e responde
aos questionamentos;
• O Product Owner discute o Backlog do Produto revisado, projetando os
prováveis alvos e dados de entrega com base no progresso do trabalho;
• Todo grupo colabora sobre o que deve ser feito a seguir;

12
 • Revisão de eventuais mudanças de mercado ou do uso do produto, para
identificar o que é mais importante a ser feito na sequência;
• Revisão da linha do tempo, orçamento, capacidade de trabalho e mercado
para uma nova versão da funcionalidade ou capacidade do produto.

Após a verificação dos elementos, o resultado será: um Backlog do Produto

revisado com a definição dos prováveis itens que serão trabalhados na próxima
Sprint.

4.4 Retrospectiva da Sprint

Segundo o Manifesto Ágil, no seu princípio de número 12: “Em intervalos

regulares, a equipe reflete como se tornar mais eficaz e então refina e ajusta seu
comportamento”. É na Retrospectiva da Sprint que o Time Scrum avalia tudo o
que ocorreu relacionado às pessoas, às ferramentas e aos processos. Por meio
da análise dos acontecimentos, é criado um plano de melhorias para a próxima
Sprint. A avaliação, a análise e a construção do plano de melhorias devem estar
embasados nos três pilares do Scrum: Transparência, Inspeção e Adaptação.
A Retrospectiva da Sprint deve ser realizada sempre após a Revisão da
Sprint e antes do Planejamento da próxima Sprint, em um Time-boxed de no
máximo três horas para uma Sprint de um mês (30 dias), sendo sempre
proporcional ao tamanho da Sprint.
O Scrum Master deve garantir que a reunião se mantenha no tempo e que
os participantes entendam seu propósito. Ele participa da reunião como um
membro auxiliar do time.
No Guia do Scrum, de 2017, são elencados os pontos referentes ao
propósito da Retrospectiva da Sprint, da seguinte forma:

• Inspecionar o desenvolvimento da última Sprint em relação às pessoas, aos

processos e às ferramentas;
• Identificar e classificar de forma ordenada os principais itens que foram bem
e as melhorias necessárias aos itens que não foram tão bem;
• Criar um plano de melhorias a serem implementadas na forma como o Time
Scrum realiza seu trabalho.

Baseados no propósito da Retrospectiva da Sprint, o Time de

Desenvolvimento levanta as seguintes questões para serem respondidas durante
a reunião:
13
 1) Quais foram os principais itens que correram bem e podem ser mantidos
na próxima Sprint?
2) Quais itens podem ser melhorados para a próxima Sprint?
3) Quais itens devem ser descartados para a próxima Sprint?

Após o levantamento dos pontos que correspondem ao propósito da

Retrospectiva da Sprint, ao final da reunião, o Time Scrum deve ser capaz de
identificar as medidas de melhoria para implementação na próxima Sprint.
Fabio Cruz, no livro Scrum e Agile em Projetos, de 2018, sugere que o Time
Scrum selecione alguns itens prioritários e realize as melhorias identificadas na
reunião da Retrospectiva da Sprint, garantindo, desta forma, que as melhorias são
realmente factíveis para a próxima Sprint.

TEMA 5 – IMPORTÂNCIA DAS REUNIÕES PERIÓDICAS

As reuniões periódicas servem para que o projeto não saia dos trilhos, para
que os integrantes do Time Scrum e os envolvidos não percam o foco do que é
realmente necessário para a entrega do produto com qualidade e que agregue
valor.
Nestas reuniões, objetivos e metas são definidos e explanados de forma
clara para que todos os envolvidos tenham a compreensão de o que é necessário
realizar. São identificados também os obstáculos encontrados no dia a dia que
devem ser eliminados para que não afetem a produtividade e a qualidade do
trabalho, ou seja, para evitar desperdícios.
No Scrum, essas reuniões são eficientes no que se refere ao aumento de
produtividade das equipes, porque focam em pequenas partes do projeto para que
cada uma seja validada antes de seguir para a próxima, e assim sucessivamente
até a conclusão do projeto.
O controle de data, hora e tempo de cada reunião periódica se faz
necessário para que cada integrante trace seu planejamento e programação de
tempo, bem como o que será apresentado em cada reunião. Isso faz com que a
reunião seja mais eficiente, pois só serão tratados assuntos que realmente
impactam na conclusão de cada etapa.
Independentemente do tamanho do projeto ou do produto a ser entregue,
as reuniões periódicas têm uma importância incontestável na entrega, pois é por
meio delas que cada ponto pode ser discutido. Por exemplo: identificar a ordem e

14
a classificação de importância dos requisitos; esclarecer o objetivo principal;
estabelecer as metas e os prazos para entrega; e definir os processos.

15
REFERÊNCIAS

CRUZ, F. Scrum e Agile em Projetos: Guia Completo. Rio de Janeiro: Brasport,

2018.

_____. Scrum e Guia PMBOK: Unidos no Gerenciamento de Projetos. Rio de

Janeiro: Brasport, 2013.

DUARTE, L. Scrum e Métodos Ágeis: Um Guia Prático. [S.l.]: LuizTools, 2016.

PMI – Project Management Institute. Guia PMBOK®: Um Guia para o Conjunto

de Conhecimentos em Gerenciamento de Projetos. 6. ed. Pennsylvania: PMI,
2017.

SUTHERLAND, J. SCRUM: A Arte de Fazer o Dobro do Trabalho na Metade do

Tempo. Rio de Janeiro: Editora Sextante, 2019.

16