AULA 5

FRAMEWORK SCRUM

Prof. Anderson Rodrigues Matos

TEMA 1 – PMBOK

Nas aulas anteriores, falamos sobre o Framework Scrum – conceituação,

origem, valores, pilares, componentes, funções, artefatos e eventos.
Ao iniciar um projeto em uma empresa, é essencial existir um
planejamento, para que a execução ocorra da melhor forma possível. E, para isso,
o gerenciamento de projetos é fundamental. Ele pode ser feito, ou melhor, deve
ser feito de acordo com uma metodologia, por meio de técnicas exclusivas da
empresa, ou, ainda, com sistemas que já existem e são utilizados em todo o
mundo, decorrentes de sua eficiência comprovada. Dois conjuntos de técnicas e
boas práticas aplicados no mundo em razão de sua eficiência são o Scrum e
PMBOK. Conhecer e aprender sobre ambos é fundamental para que sejam
tomadas as melhores decisões em uma empresa.
Nesta aula, vamos falar sobre as diferenças entre o Scrum e o PMBOK.
Basicamente, ambos são um passo a passo de extrema importância no
gerenciamento de projetos, mas cada um apresenta suas peculiaridades.
Entendê-las é de suma importância para saber em quais projetos podemos aplicar
um ou outro.
O objetivo desta aula é conhecer a dinâmica de cada guia para que seja
feita a escolha mais acertada no momento de aplicá-la, ou até mesmo realizar
uma combinação de ambos.
Para podermos identificar e esclarecer melhor as diferenças e similaridades
entre esses dois conjuntos de técnicas e por termos, nas aulas anteriores, falado
somente do Scrum, vamos descrever resumidamente o PMBOK para refrescar a
memória e facilitar a análise de ambas.

Figura 1 – PMBOK

PMBOK

Crédito: ImageFlow/Shutterstock.

2
 Project Management Body of Knowledge é um guia de conhecimento em
Gestão de Projetos publicado pelo Project Management Institute (PMI), com o
intuito de assegurar as boas práticas para o gerenciamento de projetos. Desde
1996, ele consolida, padroniza e dissemina as práticas de gerenciamento de
projetos mais eficientes. Ainda, divide-as em dez áreas de conhecimento para a
realização de uma boa gestão, que são: gerenciamento de aquisições, qualidade,
riscos, escopo, custos, integração, comunicação, recursos humanos, tempo e
partes interessadas, as chamadas Stakeholders.
Veja um exemplo de como essas áreas funcionam: temos a área do
gerenciamento de recursos humanos, em que são realizadas a identificação e
documentação das funções do projeto; são delegadas as responsabilidades;
avaliadas as habilidades necessárias; e estabelecido um plano de gerenciamento
pessoal. Outro exemplo extremamente importante é o gerenciamento do escopo,
porque funciona como base para o gerenciamento do projeto até sua entrega final,
com a função de estabelecer prazos, funções, entre outras informações
necessárias.
O PMBOK representa o ciclo de vida de um projeto dividido em cinco
grandes grupos, as etapas do gerenciamento de projetos. São elas: iniciação,
planejamento, execução, monitoramento e controle e encerramento. Essas etapas
são muito bem divididas e organizadas e se aplicam às áreas de conhecimento,
seja em sua totalidade ou apenas onde se fazem necessárias.

Figura 2 – Dez áreas do gerenciamento de projetos

3
 Nesse ciclo de vida do projeto, o PMBOK apresenta 49 processos, os quais
serão realizados de acordo com cada etapa e em cada área de conhecimento,
conforme sua necessidade.
Essa organização toda, bem como as boas práticas (que podem ser
utilizadas em vários projetos), faz com que o PMBOK seja adotado como base
para o desenvolvimento de novas metodologias, já que abrange todos os detalhes
sobre projetos, não deixando que algo passe despercebido.
Com essa descrição resumida do PMBOK, vamos ao objetivo desta aula,
que é falar sobre as diferenças e similaridades entre o Scrum e PMBOK, como e
quando devem ser aplicados.

Tabela 1 – Processos de gerenciamento e mapeamento das áreas do

conhecimento

Fonte: Matos, 2021.

TEMA 2 – DIFERENÇAS E SIMILARIDADES ENTRE O SCRUM E PMBOK

Figura 3 – Scrum

Crédito: Ibreastock/Shutterstock.

4
Figura 4 – Project management

Crédito: Mindscanner/Shutterstock.

Podemos iniciar a comparação na conceituação de ambos.

Scrum é um framework (estrutura) que apresenta um conjunto de valores,
princípios e práticas para acelerar o desenvolvimento de um produto/serviço,
sempre com o objetivo de melhoria contínua do processo, com benefícios para a
equipe de desenvolvimento e geração de valor para o cliente.
PMBOK é um guia no qual estão inseridas as melhores práticas da
gerência de projetos. Aborda todas as áreas vitais do planejamento e orienta os
gerentes de projeto a atingir objetivos como prazo, orçamento e qualidade, com o
mínimo de imprevistos possíveis.
Como o Scrum é um framework, as adições ou exclusões de itens
essenciais para produção de um produto são facilitadas, desde que não impactem
seus princípios de transparência, inspeção e adaptação. Neste ponto, podemos
afirmar que processos do PMBOK podem ser adaptados e adicionados ao Scrum.
O Scrum se encaixa melhor nos projetos em que o escopo é incremental,
ou, ainda, desconhecido. Isso porque tolera bem as incertezas e atua sempre com
priorizações e ciclos curtos de entregas, o que significa reduzir o nível de riscos
na entrega do produto.
Já no PMBOK, conhecer o escopo é crucial para que o planejamento e a
execução do projeto sejam realizados. O guia trabalha com os riscos, realiza ciclos
de entregas, que seria o planejamento em ondas sucessivas, e admite a
priorização de entregas.
Dentre as diferenças entre o Scrum e PMBOK, a seguir vamos falar sobre
as cinco que mais se destacam.

• Flexibilidade

5
 Projetos que permitem a alteração do escopo enquanto os processos estão
em andamento e o resultado permanece inconstante, ou seja, ainda não é
conhecido, são os que mais se adequam ao Scrum.
• Fases
Para o PMBOK, os projetos devem ser divididos em etapas distintas:
iniciação, planejamento, execução, monitoramento ou controle e enceramento.
Cada uma delas é utilizada como um guia para implantação da etapa seguinte.
Já no Scrum, o projeto deve ser dividido em fases: o Product Backlog, em
que são descritos os requisitos iniciais dos produtos; o Sprint Backlog, que
organiza esses requisitos e estima o esforço para os seus processamentos; a
Sprint, que analisa os requisitos e implementa os processos necessários.
• Funções
No Scrum, a equipe de trabalho é tratada como um time, existem os papéis
do Product Owner, que representa o cliente, e do Scrum Master, que fica
responsável pela organização das Sprints e viabiliza o que for necessário para
sua realização. Esses papéis são os responsáveis pela agilização do andamento
do projeto.
No PMBOK, a divisão das funções se dá por meio de grupos de processos,
quais sejam: iniciação, execução, de controle e monitoramento e de
encerramento.
• Interface
No Scrum, os feedbacks contínuos são uma prática que garante a interação
constante do Product Owner com o cliente, possibilitando a correção de eventuais
erros ou adaptações nos processos a cada etapa ou ciclos. Isso otimiza todo o
processo.
No PMBOK, essa interação é quase inexistente, já que segue a premissa
de que o resultado do projeto é conhecido. Desta forma, a comunicação com o
cliente após a iniciação do projeto não se faz necessária.
• Encerramento
Quando o produto é entregue, no PMBOK se observam e documentam as
lições aprendidas a cada processo.
No Scrum, esse processo ocorre na retrospectiva de cada Sprint.

Podemos perceber que a utilização tanto do Scrum quanto do PMBOK

possibilita o gerenciamento de projetos com excelência e atenção total a cada um
dos processos, mas cada um tem uma abordagem diferenciada sobre eles.
6
 No Scrum, a estrutura permite a inclusão ou exclusão de processos ou
requisitos, conforme a necessidade, desde que não interfira na continuidade do
projeto, em sua excelência e produtividade.
O PMBOK geralmente é aplicado a equipes que têm o conhecimento do
projeto como um todo, porque teoricamente ele é mais burocrático e,
consequentemente, mais fechado para as mudanças.
Já o Scrum é mais aplicado aos projetos complexos, porque não existe uma
determinação para seguir uma sequência exaustiva de processos até que a
equipe alcance suas metas e seus objetivos. Ele propõe etapas que fornecerão
uma base para que os outros processos sejam realizados, com o objetivo de
fornecer uma forma simplificada de a organização obter sucesso e agregar valor
a seu negócio.
Em síntese, os projetos que não são tão simples e envolvem processos
empíricos compõem um ambiente para a experimentação e adaptação dos
processos no Scrum, e mesmo que sejam implementados de modo incremental,
seus objetivos serão atingidos.
Projetos com um nível mais baixo de complexidade são os melhores para
a aplicação do PMBOK, em razão de suas práticas, que funcionam bem para os
projetos com requisitos e tecnologias que podem ser mapeadas e conhecidas
desde o início, principalmente os processos que tratam da gestão de escopo,
tempo e custos. Por isso, os projetos que não apresentam muitas variáveis têm
um bom resultado quando aplicadas às boas práticas do PMBOK, e alcançam
seus objetivos sem maiores dificuldades.
No entanto, precisamos estar cientes de que essa diferenciação que
mencionamos é subjetiva, porque definir um projeto como simples ou complexo
não é tão simples, e essa definição pode, muitas vezes, ocorrer de forma
equivocada. O que pode ser identificado com mais facilidade é se um projeto tende
a ser mais complexo ou mais simples.
Podemos concluir, então, que para definir se um projeto é complexo ou não
é necessário avaliar o domínio de seus requisitos e tecnologia, e identificar se o
conhecimento desses pontos aproxima o projeto da simplicidade ou da
complexidade. Se for simples, o PMBOK é o mais indicado, se complexo, o melhor
é a aplicação do Scrum.

7
TEMA 3 – UNIÃO DO SCRUM E PMBOK EM PROJETOS

Anteriormente, foram apresentadas as diferenças e similaridades entre os

conjuntos de técnicas mais usados atualmente. Mas precisamos entender que são
igualmente importantes e sua utilização depende do tipo de projeto a ser
implementado para trazer o resultado esperado.
Com o material apresentado, podemos verificar que o Scrum tem uma forma
mais simplificada de aplicação, por isso a união do Scrum às boas práticas do
PMBOK melhorará algumas fragilidades que possam ser identificadas no Scrum
em determinados projetos.
Mesmo antes de o Scrum começar a ser implementado, existe a
necessidade de serem realizadas algumas atividades contidas no PMBOK,
principalmente no que se refere ao registro de certas etapas importantes em um
projeto, por exemplo, a oficialização de seu início.
Muitas empresas ainda preferem e se sentem mais seguras com um
detalhamento inicial, incluindo formalizações e controles.

TEMA 4 – PROCESSOS – SCRUM E PMBOK

A seguir, apresentamos os processos que podem ser realizados e a

responsabilização de cada um deles, com o objetivo de exemplificar uma das
formas de aplicação do Scrum e PMBOK em um mesmo projeto.

Figura 5 – Estudo de caso pela ótica do Scrum

Fonte: Elaborado com base em FabioCruz, [S.d.].

8
 Ao iniciar um projeto, é necessário realizar sua formalização por meio de um
termo de abertura que contenha basicamente o propósito do projeto, seus
requisitos, cronograma, riscos, custos, responsáveis, as partes interessadas, bem
como o patrocinador do projeto. O responsável por fazer esse termo seria o Gerente
de Projetos, seguindo as práticas contidas no PMBOK.

Figura 6 – Termo de abertura do projeto

Crédito: Marynchenko Oleksandr/Shutterstock.

Para a criação deste termo de abertura, é imprescindível identificar as partes

interessadas, pois são elas que fornecerão as informações para que o projeto seja
realizado e utilizarão e/ou aprovarão o produto desse projeto. Por isso, é importante
dar o máximo de atenção a esse processo, que garantirá o nível de sucesso a ser
alcançado. Os responsáveis por esse processo na união do Scrum e PMBOK são
o Gerente de Projetos e o Product Owner. Um será o responsável por montar o
termo de abertura e o outro será o representante do projeto junto ao cliente,
estabelecendo contato para obter o máximo de informações quanto aos desejos
dos clientes, podendo identificar os requisitos necessários para o produto.
Outra etapa de extrema importância em um projeto é a criação de um plano
de gerenciamento do projeto, em que constarão o ciclo de vida do projeto com seus
processos, que serão aplicados a cada fase; a forma como o trabalho deve ser
executado, sempre com o foco voltado aos objetivos do projeto; o modo como as
etapas serão configuradas e gerenciadas; o trabalho a ser realizado para manter
íntegras as bases do projeto; o gerenciamento das comunicações com as partes
interessadas, dos custos, riscos e da qualidade. Para a criação deste plano, o
9
trabalho deve ser realizado conjuntamente pelo Gerente de Projetos, pelo Product
Owner e pelo Scrum Master.
Essas atividades que se iniciam mesmo antes de o projeto começar podem
ser classificadas como atividades externas ao Scrum, momento em que começa a
execução do projeto.
Como o Scrum é um ambiente ágil, assim que ele é iniciado as atividades de
planejamento, realização de testes e outras etapas são realizadas
concomitantemente de forma dinâmica, seguindo a estrutura de ciclos. Estes ciclos
podem ser alinhados com o Planejamento por Ondas Sucessivas, apresentado no
PMBOK, que nada mais é do que a divisão do projeto em várias fases conforme a
entrega de valor acertada com o cliente, de maneira que o projeto seja todo
planejado, executado, e, por fim, testado e aprovado. Porém, o PMBOK não explica
detalhadamente como a equipe pode aplicar essas Ondas Sucessivas. Como forma
de buscar sempre a excelência nos projetos, pode-se utilizar esse conceito e aplicá-
lo ao Scrum. Assim, obtemos Sprints do Scrum trabalhando conforme as Ondas
Sucessivas do PMBOK.
Antes mesmo da Sprint, em que são definidos, estimados e separados os
requisitos do Backlog do produto que serão transformados em funcionalidade, é
preciso uma preparação que contemple coletar informações sobre os itens, seguida
de análise, entendimento e detalhamento de cada um deles. Nesse ponto, os
processos do PMBOK servem de orientação para a equipe no que se refere
principalmente à organização e ao controle dos trabalhos de gerenciamento dos
requisitos elencados no Backlog do Produto.
O Backlog do Produto fica sob responsabilidade do Gerente de Projeto em
conjunto com o Product Owner, que tem a função de detalhar suficientemente os
itens do Backlog para que o Time de Desenvolvimento possa transformá-los em
funcionalidades prontas e potencialmente entregáveis. Para que isso seja possível,
é necessário seguir algumas etapas descritas no PMBK. Precisamos salientar que,
conforme determinação do Scrum, o único responsável pelo Backlog do Produto é
o Product Owner. Mas, então, qual é a responsabilidade do Gerente de Projetos
nesse processo? Ele deve controlar e verificar se as atividades do Backlog do
Produto estão sendo realizadas, dar suporte e facilitar as tarefas para o Product
Owner.
Para montar o Backlog do Produto, o Product Owner procura as partes
interessadas e identifica, dentre os desejos, os requisitos necessários para entregar

10
o produto. E essa é uma função que cabe exclusivamente ao Product Owner, já
que ele será o representante do cliente no projeto e, portanto, deve ter
conhecimento para definir quais requisitos são indispensáveis e para fazer o
detalhamento necessário de cada um deles. Por meio dessa identificação e
detalhamento, obtém-se o escopo detalhado que o produto deve atender ao final
do projeto. Ainda, o Product Owner pode preparar protótipos de tela e descrever o
formato e as ações de forma visual, bem como documentos de apoio, contendo as
regras de negócio, que são altamente recomendáveis, independentemente do
conjunto de técnicas utilizado no projeto.
Uma opção para a apresentação visual das ações e do escopo definido para
o projeto é a criação de uma EAP (Estrutura Analítica do Projeto), que mostrará
graficamente o escopo geral, para que o gerente e a equipe de gestão visualizem
todas as funcionalidades que precisam ser construídas. Trata-se de uma
ferramenta para acompanhamento com o objetivo de lembrar todos os detalhes que
precisam ser construídos. Sua utilidade é ainda maior na definição das estórias,
porque elas serão apresentadas em formato visual, seguindo a estrutura da EAP.
Nesta tarefa, o Product Owner é quem fornece apoio e suporte ao Gerente de
Projetos para a montagem da EAP e o entendimento dos pacotes de trabalho.

TEMA 5 – PAPÉIS – SCRUM E PMBOK

Definidos os requisitos, seu detalhamento e a apresentação visual das ações

necessárias para o desenvolvimento das funcionalidades e entrega do produto,
vem a fase de montar o Time Scrum e, como faz parte das regras do Scrum, essa
etapa não pode ser infringida ou negligenciada.
A formação do Time Scrum deve ser realizada uma única vez, na primeira
onda, ou seja, na preparação da primeira Sprint. Isso é necessário para que o Time
Scrum possa realizar auto-organização, automonitoramento, autocontrole, bem
como automelhoria, que deve ser constante. Esse time deve se manter durante
todo o projeto com o mesmo tamanho e mesmos integrantes, o que seria o ideal,
mas projetos são instáveis e não há garantias de que o time que inicia o projeto
seja o mesmo na entrega do produto. Portanto, essa fase pode vir a ocorrer durante
as interações, o que pode alterar o tamanho do time, o tamanho das Sprints, bem
como a quantidade destas.
No PMBOK, este processo é conhecido como estimar os recursos das
atividades. Neste ponto, o Gerente de Projetos pode apresentar um plano de

11
recursos humanos para atender e gerenciar preocupações com recompensas e
treinamentos do Time. Esse plano pode ser revisto durante as interações em razão
de novas necessidades que podem surgir durante o projeto. Neste processo, o
Product Owner apoia o Gerente de Projetos para estimar os recursos e definir o
plano de recursos humanos.
Com o Backlog do Produto finalizado e o Time Scrum montado, é hora de o
Product Owner fazer a apresentação dele ao time e informar sua responsabilidade
de transformá-lo em funcionalidades prontas e potencialmente entregáveis. Vale
destacar que esse Backlog do Produto pode ser completo ou parcial, de acordo
com o planejamento em Ondas Sucessivas, e pode ser alterado durante o projeto
em razão de mudanças de mercado ou das necessidades do cliente.
Nessa apresentação, o Product Owner conta com o apoio do Gerente de
Projetos para mobilizar o Time Scrum, oficializando os papéis e as
responsabilidades. Também ficará claro o papel da atuação do Gerente de Projetos
neste modelo misto.
O Product Owner, o Gerente de Projetos e o Time Scrum analisam os
requisitos constantes no Backlog do Produto para identificar e estabelecer a ordem
de prioridades para o desenvolvimento do produto, dando início às Sprints. Nesta
fase, o Gerente de Projetos será necessário somente se o Time Scrum definir que
será melhor comprar uma solução do que desenvolvê-la, surgindo a necessidade
de aquisições.
A função que o Gerente de Projetos pode desempenhar paralelamente ao
Backlog do Produto é estimar os custos da próxima entrega do projeto, de acordo
com a divisão das fases ou do tamanho do projeto, sempre com base nas
informações fornecidas pelo Time, e determinar o orçamento conforme a estimativa
de custos. Este processo é importante para a autorização do projeto no âmbito
financeiro.
Com o Backlog do Produto refinado, o Gerente de Projetos pode montar um
plano de gerenciamento de riscos que será apresentado às partes interessadas,
mostrando os riscos identificados e como eles serão tratados durante o projeto.
Neste plano realizado pelo Gerente de Projetos, o Product Owner atuará como
suporte somente se houver necessidade.
A próxima etapa ou fase do projeto é o planejamento da Sprint, evento no
qual são planejados pelo Time de Desenvolvimento todos os trabalhos da próxima
Sprint. Além do planejamento e entendimento dos trabalhos a serem realizados,

12
existe a necessidade da preparação do ambiente de trabalho e do envolvimento do
Gerente de Projetos.
O ambiente de trabalho se refere basicamente à infraestrutura para a
realização dos trabalhos, como máquinas, local, ferramentas, softwares e
disponibilidade da equipe. O envolvimento do Gerente de Projetos é necessário na
definição de tamanho e número de Sprints, porque neste momento o projeto pode
sofrer alterações de cronograma e será necessário alterar o plano de
gerenciamento, adequando o que o time pode entregar com os requisitos desejados
pelo cliente.
No planejamento da Sprint, também é o momento de revisar os riscos já
identificados, atualizando o plano de gerenciamento de riscos e levando em
consideração possíveis impactos que podem ser gerados na preparação do
ambiente, na definição da velocidade do time e no tamanho das Sprints. Neste
ponto, o Gerente de Projetos pode iniciar a quantificação e a qualificação e planejar
as respostas para esses riscos.
Na Sprint, todo o trabalho é realizado pelo time de desenvolvimento, com o
apoio do Scrum Master, que auxiliará na resolução e eliminação dos obstáculos
encontrados e que atrapalham o desenvolvimento, afetando diretamente a
produtividade e qualidade da entrega.
Na Sprint propriamente dita, com suas reuniões diárias, não há envolvimento
direto do Product Owner ou do Gerente de Projetos, em razão de suas funções e
responsabilidades estarem ligadas somente ao contato com cliente e plano de
gerenciamento. Portanto, a execução do projeto ocorre em sua maioria sob
responsabilidade do Time de Desenvolvimento, com o apoio do Scrum Master,
utilizando o conjunto de práticas apresentadas pelo Scrum.
Quando a Sprint é finalizada e foram desenvolvidas funcionalidades prontas,
ocorre uma revisão, em que são analisados os pontos que deram certo e os que
precisam ser melhorados, adaptados ou até excluídos para a próxima Sprint. Neste
ponto, além do Time de Desenvolvimento e do Scrum Master, participa o Product
Owner, que fornecerá o feedback positivo ou negativo sobre as funcionalidades.
O monitoramento e o controle das atividades mencionadas no PMBOK são
realizados no Scrum por meio das reuniões diárias, na reunião de revisão da Sprint
e nas lições aprendidas da Retrospectiva da Sprint.
Monitoramento do escopo, custos, qualidade e riscos que fazem parte do
plano de gerenciamento do projeto são realizados pelo Gerente de Projetos, que

13
fará a atualização de acordo com as informações recebidas de cada revisão de
Sprint, na qual são identificadas mudanças necessárias ou não para a próxima
Sprint.
Assim como no PMBOK, no encerramento do projeto, ou Retrospectiva da
Sprint final, são testadas e avaliadas as funcionalidades prontas para garantir a
entrega do produto com a qualidade esperada e com o objetivo de agregar valor ao
cliente alcançado.

14
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.

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

Tempo. Rio de Janeiro: Editora Sextante, 2019.

15