031 – Gestão de Projeto – Ágil SCRUM

(Um breve resumo do Guia Scrum)

Parte 1

INTRODUÇÃO

Projetos são meios pelos quais as organizações introduzem mudanças em seus negócios visando transformar suas
operações atuais para sobreviver e competir no futuro e necessitam ser planejados, delegados, monitorados e
controlados em todos os seus aspectos, incluindo a motivação dos envolvidos para atingir os seus objetivos
(Prince2®).

O termo “ágil” decorre do Manifesto Ágil publicado em 2001 sendo aplicado quando estamos referenciando um
conjunto de práticas eficazes e reconhecidas que permite realizar as entregas de um projeto (produtos) de forma
rápida, fracionada e atendendo a qualidade especificada e, neste aspecto, ágil SCRUM “é uma estrutura
(framework) dentro da qual as pessoas podem abordar problemas adaptativos complexos, enquanto entregam de
forma produtiva e criativa produtos do mais alto valor possível”.

O entendimento de um “problema complexo” pode ser obtido pela estrutura conceitual do Modelo Cynefin que, em função do contexto
predominante e da natureza da relação entre causas e efeitos decorrentes, identifica 4 (quatro) tipos diferentes de contextos: simples,
complicado, complexo e caótico, considerando a desordem existente. Neste modelo as tomadas de decisão em um contexto complexo se
baseiam em: sondar, sentir – aprender com a sondagem e responder.

Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento
de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos:
responsabilidades, eventos, artefatos e as regras que os unem.

Ao extrapolar seu ambiente de origem e ser aplicado nos mais diversos tipos de projetos, em que as práticas
particulares de engenharia e gestão da organização são incorporadas aos elementos do ágil Scrum, é possível
afirmar que existem versões exclusivas do ágil Scrum em diversas organizações.

Figura 1 – Elementos do Ágil Scrum

Cada elemento do ágil Scrum atende a um propósito específico e não podem ser ignorados ou mudados. Outra
característica do ágil Scrum é que a sua estrutura possui como unidade principal um pequeno grupo de pessoas,
designado como Time Scrum, e as regras do ágil Scrun não são instruções detalhadas, mas orientações quanto aos
relacionamentos e interações pessoais.

O ágil SCRUM foi idealizado com base no empirismo e no “lean thinking”, onde o empirismo afirma que o
conhecimento vem da experiência e da tomada de decisões com base no que é observado e o “lean thinking” reduz
o desperdício e se concentra no essencial, conduzindo o ágil Scrum a uma abordagem iterativa e incremental para
otimizar a previsibilidade e controlar o risco, a qual é suportada pelos seguintes pilares do Scrum:

 Transparência

Decisões baseadas em informações confiáveis (artefatos) para assegurar valor e minimizar riscos.
Transparência permite inspeção;

 Inspeção

Os artefatos Scrun devem ser inspecionados com frequência e diligência para assegurar o progresso em direção
às metas estabelecidas e identificar possíveis desvios indesejados. Os eventos Scrum fornecem cadência para a
inspeção;
 Adaptação

Ao se identificar desvios indesejáveis é necessário realizar ajustes no processo aplicado ou nos materiais que
estão sendo produzidos na maior brevidade possível para se evitar novos desvios. O Time Scrum deve se
adaptar no momento em que aprende algo novo por meio da inspeção.

Inspeção e adaptação requerem flexibilidade em torno daquilo que se busca alcançar (produto) e, desta forma, o
ágil SCRUM realiza ciclos de Sprints que resultam em entregas fraccionadas em direção ao produto final
concluído.

Considerando que o foco principal do ágil Scrum é o trabalho da Sprint para atingir o melhor progresso possível
em direção às metas estabelecidas é de se esperar que o Time Scrum esteja aberto quanto ao trabalho a ser
realizado e seus desafios, aprendendo enquanto fazem, suportando uns aos outros e se respeitando quanto as suas
capacidades e independência, para isso o Time Scrum deve incorporar os 5 (cinco) valores do Scrum:

 Coragem: Os membros do Time SCRUM precisam ter coragem para fazer a coisa certa e trabalhar em
problemas difíceis.

 Foco: Todos focam no trabalho da Sprint e nos objetivos do Time Scrum.

 Comprometimento: As pessoas se comprometem pessoalmente a alcançarem os objetivos do Time Scrum.

 Respeito: Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes.

 Abertura: O Time Scrum e suas partes interessadas concordam em estarem abertos a todo o trabalho e aos
desafios com a execução dos trabalhos.

Esses valores devem ser plenamente vivenciados pelo Time Scrum para que os pilares do Scrum gerem confiança
para todos. Com ajuda do Scrum Master, os membros do Time Scrum aprendem e exploram esses valores
enquanto trabalham com os elementos do Scrum.

“Para que o ágil Scrum alcance o sucesso desejado é aconselhável que antes de se iniciar o projeto o Time Scrum
se certifique de ter entendido o seu escopo e as necessidades do Cliente quanto à qualidade, prazos e custos.”

Parte 2

RESPONSABILIDADES - TIME SCRUM

Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento
de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos:
responsabilidades, eventos, artefatos e as regras que os unem.

No artigo anterior apresentamos a definição e a teoria do ágil Scrum o qual já apresenta algumas das regras que
unem os demais elementos.
Um Time Scrum envolve 3 (três) papéis e responsabilidades principais em sua estrutura:

 Scrum Master
 Product Owner
 Developers (Desenvolvedores)

Objetivando uma boa comunicação e maior produtividade, o Time Scrum deve ser pequeno o suficiente para ser
ágil e grande o suficiente para concluir um trabalho significativo dentro de uma Sprint, normalmente 10 ou menos
pessoas. Se o Time Scrum se tornar muito grande deve ser avaliado a sua reorganização em diversos Times Scrum
que mantenham uma atuação coesa e focados no mesmo produto, ou seja, compartilhando a mesma meta do
produto, Product Backlog e Product Owner.

O Time Scrum é multifuncional e autogerenciável, não havendo sub-times ou hierarquias. Seus membros devem
possuir todas as habilidades necessárias para criar valor a cada Sprint e para decidirem internamente quem faz o
quê, quando e como, sendo responsável por todas as atividades relacionadas ao produto desde a sua concepção,
construção e testes, criando Incrementos valiosos e úteis a cada Sprint.

O ágil Scrum requer um Scrum Master para promover um ambiente harmonioso no qual:

1. O Product Owner ordene o trabalho (priorização de itens) para um problema complexo em um Product Backlog;
2. O Time Scrum transforme uma seleção do trabalho em um incremento de valor durante uma Sprint; e,
3. O Time Scrum e seus stakeholders inspecionem os resultados e se adaptam para a próxima Sprint.

Figura 2 - Time Scrum

Product Owner

O Product Owner é um tomador de decisões que representa os Clientes e demais partes interessadas, não podendo
ser um comitê, e domina os requisitos do produto a ser entregue. Deve possuir poder para exercer sua
responsabilidade principal: gerenciar eficazmente o Product Backlog (lista de prioridades) de forma a maximizar o
valor resultante do trabalho dos Developers e, mesmo que delegue suas atividades, continuará responsável pelo
sucesso do projeto.

O sucesso do ágil Scrum depende do respeito às decisões do Product Owner, as quais devem estar visíveis através
do conteúdo e ordenação do Product Backlog e por meio do Incremento inspecionável na revisão da Sprint.
Somente o Product Owner pode adicionar, excluir ou modificar a ordenação dos itens do Product Backlog, o Time
Scrum e as demais partes interessadas devem convencê-lo caso desejem alterar o produto ou parte do produto.

Suas atividades principais são:

 Desenvolver e comunicar explicitamente a meta do produto;

 Criar e comunicar claramente os itens do Product Backlog;
 Ordenar os itens do Product Backlog considerando seu valor, custo, conhecimento e risco;
 Garantir que o Product Backlog seja transparente, visível e compreensível; e,
 Refinar o Product Backlog, sempre que necessário.

Developers

São pessoas com habilidades amplas (técnica, funcional ou outras) e comprometidas com o desenvolvimento do
produto (trabalho = Incremento de valor da Sprint) e podem variar ao longo do projeto para assegurar o domínio
sobre o trabalho a ser realizado, mas devesse evitar alterações ao longo de uma Sprint.
O propósito do trabalho dos Developers é atender ao objetivo da Sprint, geralmente um problema de negócio que é
abordado. A funcionalidade (itens do Product Backlog) pode ser ajustada durante a Sprint para que o trabalho dos
Developers possa ser considerado concluído gerando valor em um Incremento utilizável que atenda a Descrição de
Pronto.

Suas atividades principais são:

 Elaborar a “Sprint Backlog”, ou seja, um plano para atender ao objetivo da Sprint, normalmente uma previsão
de funcionalidade e o trabalho necessário para entregar essa funcionalidade;
 Atender a qualidade requerida com aderência à Descrição de Pronto, que resume o entendimento
compartilhado entre o Product Owner e os Developers de quando o trabalho poderá ser considerado concluído;
 Adaptar o “Sprint Backlog” diariamente para assegurar o atendimento da meta da Sprint; e,
 Responsabilizar-se mutuamente como profissionais.

Scrum Master (“Mestre” Scrum)

O Scrum Master é um líder que atua como facilitador no Time Scrum e na organização, mas não possuindo a
autoridade de um gerente tradicional. Ele é responsável por estabelecer o ágil Scrum atuando como uma guardião
que ajuda as pessoas a entenderem a sua teoria, prática e regras, assegurando a incorporação dos pilares e valores
do Scrum, respeitando as particularidades da organização. Ele também é responsável pela eficácia do Time Scrum
ao permitir que seus integrantes melhorem suas práticas dentro da estrutura Scrum.

Em relação aos Developers suas atividades são:

 Fornecer treinamento em autogerenciamento e multifuncionalidade;

 Auxiliar na concentração do trabalho em Incrementos de alto valor que atendam à Definição de Pronto;
 Remover interferências externas e impedimentos ao progresso do trabalho; e,
 Garantir que todos os eventos Scrum ocorram adequadamente e conforme planejados.

Em relação ao Product Owner suas atividades são:

 Ajudar na definição eficaz da meta do Produto e no gerenciamento do Product Backlog;

 Ajudar o Time Scrum a entender as necessidades de itens do Product Backlog claros e concisos;
 Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo; e,
 Facilitar a colaboração das partes interessadas no produto, quando solicitado ou necessário.

Em relação às demais partes interessadas no produto (organização) suas atividades são:

 Liderar, treinar e orientar a organização na adoção do ágil Scrum;

 Planejar e orientar a implementação do ágil Scrum;
 Ajudar na compreensão e aplicação da abordagem empírica para trabalhos complexos; e,
 Remover barreiras entre todas as partes interessadas.

“Para que o ágil Scrum alcance o sucesso desejado é aconselhável que antes de se iniciar o projeto seja
assegurado que o Time Scrum e o Cliente compreendam os eventos Scrum e estejam cientes de seus papéis e
responsabilidades no projeto.”

Para o ágil Scrum o importante é determinar quais pessoas atuam no projeto e em qual papel, ressaltando que os
papéis de Product Owner e de Scrum Master não podem ser exercidos por uma mesma pessoa, sendo irrelevante a
função ou cargo na organização que essas pessoas efetivamente exercem.

Além dos papéis e responsabilidades relacionados acima o ágil Scrum permite que, quando necessário, outros
papéis possam ser considerados, tais como: consultores (definição do Product Backlog), analistas de negócio
(definição do Sprint Backlog), além das partes interessadas (Cliente/Usuário) que auxiliam na inspeção dos
Incrementos.

Segundo Davis J. West, as organizações que desejam implementar o ágil Scrum rapidamente costumam instituir o
papel de Líderes Ágeis responsáveis em cobrir áreas da organização e cujas funções são:

 Criar um ambiente para a agilidade florescer;

 Gerir impedimentos e problemas; e,
 Instruir e suportar o Scrum Master, o Product Own e os Developers.

Parte 3

Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento
de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos:
responsabilidades, eventos, artefatos e as regras que os unem.

Nos artigos anteriores apresentamos a definição e a teoria do ágil Scrum o qual já apresenta algumas das regras
que unem os elementos Scrum e os papéis e responsabilidades do Time Scrum.

EVENTOS SCRUM

Os eventos Scrum representam o cerimonial do Time Scrum para que desenvolvam um Incremento utilizável de
valor tangível para os Clientes e usuários ao longo de uma Sprint, permitindo que seus esforços e trabalhos gerem
aprendizado e adaptação aos desafios que irão surgir.

Todos os eventos Srum possuem duração fixa e, preferencialmente, devem ser executados no mesmo horário e
local para facilitar as comunicações ainda mais se considerarmos a aplicação de práticas de gestão à vista para
monitoramento e controle do progresso, tais como: gráfico burndown e burnup, kanban, etc. A gestão à vista
contribui, também, para a transparência do projeto ao torná-lo visível a todos.

Figura 3 - Gráficos de Controle

“Para que o ágil Scrum alcance o sucesso desejado é aconselhável que antes de se iniciar o projeto o Time Scrum
se certifique de ter entendido o seu escopo e as necessidades do Cliente quanto à qualidade, prazos e custos.”

Sprint (corrida/arrancada)

Figura 4 - Evento Sprint

O evento Sprint é o principal evento do ágil Scrum pois é ao longo de sua execução que ocorrem os demais
eventos: Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.  

A Sprint é um evento com duração de 1 (um) mês ou menos para criar cadência e consistência ao trabalho do Time
Scrum em atingir a meta do produto. As Sprints são realizadas consecutivamente sem intervalos entre si, uma nova
Sprint se inicia imediatamente ao final da Sprint anterior. Cada Sprint é um projeto de curta duração.

A Spring deve assegurar previsibilidade e garantir inspeção e adaptação ao longo de sua execução. Não há uma
regra clara para a definição de sua duração sendo necessário considerar diversos aspectos, tais como: estabilidade
do escopo, maturidade Scrum da organização, complexidade do projeto, riscos, investimento, etc., sendo
importante ressaltar que a meta da Spring deve permanecer válida durante a sua execução.

A Sprint poderá ser cancelada pelo Product Owner caso a meta definida se torne obsoleta, seja por mudança de
tecnologia, mudança no direcionamento estratégico da organização, mudança de mercado ou quaisquer outros
fatores.

É durante a Sprint que ideias se transformam em valor, pois os itens do Product Backlog que serão priorizados
(escopo) e trabalhados pelo Time Scrum resultarão em Incrementos utilizáveis do produto (valor). Além do mais,
cada Sprint é um ciclo de aprendizado em que, devido ao empirismo do ágil Scrum, as experiências e observações
vividas subsidiarão as tomadas de decisões futuras.

Durante a Sprint:

 Nenhuma mudança é realizada caso gere risco ao alcance da meta da Sprint;

 A qualidade especificada não pode diminuir (Descrição de Pronto);
 O Product Backlog poderá ser refinado, se necessário; e,
 O escopo da Sprint pode ser melhor esclarecido (refinamento) e renegociado com o Product Owner com base
no aprendizado adquirido.

Sprint Planning

A Sprint Planning é conduzida pelo Scrum Master e deve ter duração máxima de 8 (oito) horas para Sprints de 1
(um) mês e duração menor para Sprints mais curtas.

A reunião de Sprint Planning é o evento inicial da Sprint na qual o Time Scrum deve definir de forma colaborativa
com o Product Owner os itens do Product Backlog que serão priorizados na Sprint, a meta da Sprint e o
planejamento dos trabalhos da Sprint, esses 3 (três) produtos de gerenciamento definem o Sprint Backlog. Se
necessário, outros participantes poderão ser convidados para aconselhamentos.

A pauta principal do Sprint Planning inclui os seguintes tópicos:

1. Porque está Sprint é valiosa?

2. O que pode ser realizado nesta Sprint?
3. Como o trabalho escolhido será realizado?

Para responder a estas questões o Product Owner propõe uma discussão com os Developers e demais participantes
para entendimento do valor e utilidade do produto, possíveis refinamentos do Product Backlog e esclarecimentos
das dúvidas até que seja possível definir, de comum acordo, o Sprint Backlog.

Para o detalhamento do esforço e do trabalho da Sprint os Developers, a seu critério, poderão decompor os itens
priorizados em itens menores de um dia e que serão inspecionados e adaptados ao longo da Sprint, não cabendo a
mais ninguém interferir em como ocorrerá à transformação dos itens priorizados em Incremento utilizável de valor
ao atenderem suas Descrições de Pronto.

O Time Scrum deve definir as atribuições específicas, as técnicas e ferramentas que serão aplicadas e a forma de
inspeção do progresso da Sprint.

 Caso o Sprint Backlog seja finalizado antes da duração prevista para a Sprint o Time Scrum poderá
trabalhar em dívidas técnicas anteriores (bugs), sugerir refinamentos no Product Backlog, reavaliar
critérios de planejamento, tirar folga, etc.
  Quando o Sprint Backlog não for totalmente concluído o Time Scrum deverá analisar as causas durante a
Sprint Retrospective e implementar as soluções na próxima Sprint.

Daily Scrum

A Daily Scrum é conduzida pelos Developers diariamente e deve ter duração máxima de 15 (quinze) minutos com
o intuito de inspecionar o progresso e adaptar os trabalhos, senecessário, em direção à meta da Sprint, criando foco
e aprimorando a comunicação e o autogerenciamento. Considerando o envolvimento do Product Owner e do
Scrum Master nos trabalhos estes participam da reunião.

É ideal que os impedimentos identificados sejam tratados e decisões sejam tomadas em relação ao próximo dia de
trabalho. Reuniões menos formais podem ser realizadas visando à adaptabilidade dos trabalhos a problemas que
surjam.

Sprint Review

A Sprint Review é o penúltimo evento da Sprint sendo conduzida pelo Time Scrum de forma colaborativa com as
partes interessadas e deve ter duração de 4 (quatro) horas para uma Sprint com duração de 1 (um) mês.

O intuito desta reunião é a inspeção do Incremento resultante dos trabalhos do Time Scrum para avaliar se o Sprint
Backlog foi plenamente atendido e, caso contrário, poderá conduzir a uma necessidade de revisão do Incremento,
aceitação de uma dívida técnica (bug) e/ou ajustes no Product Backlog em decorrência de mudanças no ambiente
do projeto.

A aceitação de dívidas técnicas (bugs) visando realizar valor com o Incremento resultante da Sprint será
administrada como um item do Product Backlog e tratada em outra Sprint.

Sprint Retrospective

A Sprint Retrospective é o último evento da Sprint sendo conduzida pelo Time Scrum e deve ter duração de 3
(três) horas para uma Sprint com duração de 1 (um) mês.

O intuito desta reunião é inspecionar e adaptar os trabalhos realizados pelo Time Scrum mediante:

 avaliação da aderência ao planejamento dos trabalhos;

 avaliação de desvios que tenham ocorrido e suas causas;
 avaliação da eficácia das soluções implementadas; e,
 planejamento de melhorias que aprimorem a qualidade e eficácia dos trabalhos futuros.

Com base nas experiências adquiridas em relação aos indivíduos, interações, processos, ferramentas e Definições
de Pronto, o Time Scrum promove as adaptações pertinentes para a próxima Sprint.

Parte 4

Idealizado em 1990 pelos seus co-criadores Ken Schwaber e Jeff Sutherland em um ambiente de desenvolvimento
de produtos de software, o ágil SCRUM é uma estrutura simples, leve e constituída dos seguintes elementos:
responsabilidades, eventos, artefatos e as regras que os unem.

Nos artigos anteriores apresentamos a definição e a teoria do ágil Scrum o qual já apresenta algumas das regras
que unem os demais elementos, os papéis e responsabilidades do Time Scrum e os eventos SCRUM.

ARTEFATOS SCRUM

Os artefatos SCRUM são a essência dos pilares do ágil SCRUM: Transparência, Inspeção e Adaptação e devem
ser confiáveis para suportar o processo de tomada de decisão, otimizando os trabalhos e assegurando a geração de
valor pelo Time Scrum.

Cada artefato está relacionado a um compromisso específico que fornece foco ao Time Scrum e que permite o
monitoramento e controle do progresso do projeto.
 ARTEFATO COMPROMISSO
Product Backlog Meta do Produto

Sprint Backlog Meta da Sprint

Incremento Descrição de Pronto

Product Backlog – Meta do Produto

O artefato Product Backlog é gerenciado pelo Product Owner e consiste em:

 Uma lista detalhada, ordenada e emergente dos trabalhos necessários (itens) para criar ou melhorar um
produto;
 Uma única fonte de requisitos para o produto; e,
 Uma descrição, ordem e tamanho para cada item.

O artefato Product Backlog representa valor e, desta forma, os itens de maior valor estão no topo da lista que segue
em direção aos itens de menor valor. No ágil Scrum os itens de maior valor são sempre a prioridade dos trabalhos
dos Developers.

O Product Backlog é um artefato dinâmico que evolui, muda, cresce e diminui ao longo do tempo e muitas vezes
não estará completo antes do início dos trabalhos, é preciso atualizá-lo e reordená-lo continuamente mantendo-o
pronto para uso antes de uma Sprint Planning.

Há várias formas de se registrar o Product Backlog: lista de cartões, planilha Excel, “histórias de usuários”,
softwares para gestão de Backlog, etc. mas é fundamental para o ágil Scrum que esteja sempre transparente para o
Time Scrum e as partes interessadas no produto.

A meta do produto é uma informação do Product Backlog que representa um estado futuro do produto e permite o
planejamento dos trabalhos pelo Time Scrum. A meta do produto deve ser alcançada (ou abandonada) antes de se
assumir uma nova meta.

Sprint Backlog – Meta da Sprint

O artefato Sprint Backlog é o resultado da reunião Sprint Planning e fornece uma visão geral do trabalho de
desenvolvimento dos Developers e consiste de 3 (três) produtos do gerenciamento:

 Os itens selecionados do Product Backlog para serem trabalhados durante a Sprint;

 A meta da Sprint; e,
 O plano de trabalho dos Developers.

É muito comum se realizar o refinamento dos itens selecionados do Product Bcklog durante a Sprint Planning, e
até mesmo ao longo da Sprint, para se desdobrarem em itens menores para que possam ser inspecionados e
permitam o monitoramento e controle do progresso dos trabalhos.

A meta da Sprint é um objetivo que será alcançado dentro da Sprint através da implementação do Product Backlog
sendo representada por uma breve expressão do compromisso assumido pelos Developers, geralmente um
problema de negócio a ser abordado, e deve ser mantida ao longo da Sprint.

Essa meta da Sprint visa fornecer ao Time Scrum:

 Propósito ao responder à pergunta: “Por que estamos construindo este incremento?”;

 Orientação para a inspeção frequente dos trabalhos durante a Sprint, permitindo que desvios sejam detectados
precocemente; e,
 Referência para a tomada de decisão pelo Product Owner, pois ele pode decidir cancelar a Sprint se a meta da
Sprint se tornar obsoleta.

Incremento – Definição de Pronto

O artefato Incremento é o resultado dos trabalhos do Time Scrum considerado concluído e utilizável para gerar
valor ao produto. Durante uma Sprint um ou mais Incrementos poderão ser desenvolvidos para atender aos itens
selecionados do Product Backlog.

Quando o Time Scrum considera que concluiu um Incremento deve apresentá-lo às partes interessadas para ser
inspecionado e liberado para uso se atender sua Definição de Pronto, não sendo necessário aguardar até a Sprint
Review.

Todos os Incrementos liberados nas Sprints devem ser incorporados harmoniosamente ao produto e liberar valor
na direção da meta do produto.

A Definição de Pronto é a descrição das características do Incremento que atendem a qualidade exigida para o
produto e assegura que um ou mais itens do Product Backlog foram concluídos e poderão ser liberados para uso. O
não atendimento a Descrição de Pronto descaracteriza o resultado do trabalho como um Incremento e este não
poderá ser apresentado na Sprint Review.

Links recomendados:

Guia Scrum https://scrumguides.org/

Glossário do Scrum https://www.scrum.org/resources/scrum-glossary
Scrum.org https://www.scrum.org/