AULA 1

GERENCIAMENTO DE ESCOPO,
RISCO E MUDANÇAS EM
PROJETOS ÁGEIS

Prof. Luciano Furtado C. Francisco

TEMA 1 – ESCOPO DE PROJETOS

O escopo de um projeto, tanto do desenvolvimento de um software quanto

da construção de uma máquina ou de qualquer outro projeto, pode ter várias
definições. Se olharmos sob a óptica dos requisitos, trata-se da lista de
funcionalidades que o produto deve conter. Já se o enxergarmos sob a visão de
um gerente de projetos, seria um documento. Para os desenvolvedores de um
software, trata-se de módulos a serem programados. Para um engenheiro ou
arquiteto, são o memorial descritivo e plantas da obra.
Inicialmente é importante deixarmos claro que o escopo é algo de
primordial importância em projetos, seja qual for a metodologia que vamos usar
para sua concepção, tradicional ou ágil, esta última o objeto de nossa disciplina.
O escopo é universal e vale para qualquer metodologia de projetos.
Assim, vamos entender o que é exatamente um escopo, trazendo um
entendimento comum.
O termo escopo tem origem na palavra grega skopos. Significa aquele que
protege ou vigia. Trata-se do objetivo, finalidade, alvo de algo estabelecido como
meta principal.
Dentro da ciência de gestão de projetos, escopo é aquilo que será feito no
projeto, ou seja, uma descrição detalhada de cada produto (ou serviço) que será
construído, bem como a sua forma de construção, de modo a atender aos
objetivos propostos no projeto. Trata-se de definir claramente quais são os
recursos e atividades necessárias de modo que o projeto seja feito com sucesso,
dentro do prazo e recursos estabelecidos com o cliente, aquele que vai usar o
produto ou serviço advindo do projeto. Vamos fazer uma comparação simples,
com uma receita de bolo. Normalmente uma receita de bolo contém os
ingredientes e o modo de trabalhar com esses ingredientes, a fim de que o bolo
seja feito com a melhor qualidade possível e que atenda aos objetivos do projeto,
isto é, produzir um bolo. Podemos dizer, nesse caso, que o escopo é a união da
lista de ingredientes com as instruções de como fazer o bolo.
O PMBOK® (Project Management Body of Knowledge – Corpo de
Conhecimentos de Gerenciamento de Projetos), publicação do Project
Management Institute (Instituto de Gestão de Projetos) – PMI, entidade que reúne
as melhores práticas de gestão de projetos – define escopo de projeto como “o

2
trabalho que precisa ser realizado para entregar um produto, serviço ou resultado
com os recursos e funções especificados” (PMI, 2000).
Ainda de acordo com o PMBOK®, o escopo de um projeto deve ter o
trabalho necessário de modo que o projeto seja realizado com sucesso. Detalhe:
deve ser apenas o necessário, pois entregar mais do que é solicitado pode gerar
riscos ao projeto. Por isso a importância do escopo. É ele que vai determinar o
que será feito no projeto, seus limites, quais recursos serão usados e de que
maneiras, e até mesmo, em muitos casos, conter o não escopo, ou seja, aquilo
que não fará parte do projeto. Por exemplo, no projeto de construção de uma casa,
o escopo pode definir que será feita uma cozinha, e pode haver uma observação
(nesse caso, o não escopo), informando que não serão feitos armários nessa
cozinha.

Saiba mais

Acesse o link a seguir e veja neste vídeo um pouco mais sobre o Project
Management Institute, entidade que edita e mantém o PMBOK®:
O QUE É o PMI – Project Management Institute. PMI Ceará, 28 maio 2019.
Disponível em: <https://www.youtube.com/watch?v=7rw4ySJ_-fY>. Acesso em: 3
nov. 2020.

Figura 1 – Escopo da obra

Créditos: Constantin Stanciu/Shutterstock.

Contudo, em projetos temos dois elementos distintos. Um é o trabalho

necessário para o projeto, com a definição das tarefas, equipes, prazos e
orçamentos. Outro é o produto por ele gerado. Voltando ao exemplo do bolo, uma

3
coisa é a lista de ingredientes e o modo de trabalhar com esses ingredientes, outra
é o bolo em si.
Cada um desses elementos tem o seu próprio escopo. Vejamos cada um
deles.

1.1 Escopo de produto versus escopo de projeto

É comum, em alguns projetos, a equipe, o cliente e até mesmo os gerentes

de projetos confundirem os conceitos de escopo do projeto e escopo do produto.
A compreensão dessa diferença, no entanto, é fundamental para que tenhamos
um bom projeto.
Escopo de projeto é a definição de todo o trabalho necessário para entregar
o produto do projeto atendendo à expectativa do cliente. Trata-se de listar todas
as atividades necessárias no projeto, de que modo e por quem serão feitas, em
que prazos, com quais insumos e quais os resultados esperados de cada uma.
Já o escopo do produto é uma lista de atributos que descrevem o resultado
do projeto, seu produto ou serviço esperado. Para isso, temos de entender o que
o cliente espera em relação produto por ele desejado. Vamos retomar o exemplo
da construção de uma casa.
No escopo do produto, o cliente – dono da futura casa – vai explicar que
tamanho de casa deseja, quantos andares terá, a quantidade de cômodos e
janelas, tipos de materiais, divisões e tamanhos dos ambientes etc. Tudo isso
pode estar expresso em uma planta baixa ou em simulações 3D em computador.
Logo, é melhor que seja definido primeiro o escopo do produto para
somente depois ser definido o escopo do projeto, pois somente sabendo os
detalhes do produto final é que podemos ter uma ideia do tempo, orçamento,
atividades e equipes necessários para a construção da casa, ou seja, o escopo
do projeto. Precisamos saber o que é preciso ser entregue para definirmos como
essa entrega será feita.
De forma resumida, podemos dizer que o escopo do produto é o que deve
ser feito e o escopo do projeto é o como deve ser feito.

4
1.2 Declaração de escopo

Um projeto tem uma quantidade muito grande de informações, tanto

relativas às suas atividades, quanto ao produto que deve ser gerado, ou seja, o
escopo.
Logo, é importante registrar essas informações em algum local, de modo
que estejam acessíveis rápida e facilmente, assim como quando alguma dessas
informações tiver de ser alterada, para que essa tarefa seja igualmente rápida. O
motivo disso tudo é simples: primeiro, ninguém tem uma memória tão eficiente
que consiga guardar todas as informações do projeto na cabeça; depois, porque
existem várias pessoas que devem ter acesso a tais informações em tempos
variados. Portanto aqui entra mais um elemento importante: a declaração de
escopo.
Segundo o PMBOK®, a declaração de escopo “é o documento final, ao qual
tanto a empresa contratante quanto a contratada têm acesso. É uma parte
essencial do sucesso de um projeto porque descreve as entregas e o trabalho
necessário para criá-las” (PMI, 2000).
Na declaração de escopo, descrevem-se detalhadamente itens como
prazos, custos, etapas e tarefas do projeto, além do escopo do produto. Seu
objetivo é dar um entendimento comum sobre o projeto, evitando dúvidas e
interpretações distintas sobre ele. Outro objetivo é orientar os integrantes da
equipe do projeto durante a execução das tarefas, o planejamento, a gestão e a
execução das atividades.
Existem vários formatos e modelos para declarações de escopo.
Concretamente é um documento escrito que contém todo o escopo do projeto, em
seus detalhes. Cabe aos interessados no projeto, mais especialmente o gerente
do projeto, escolher o modelo mais adequado para a declaração de escopo,
levando em conta o projeto em si, quem está envolvido, a natureza do produto e
outros critérios. As empresas que têm mais maturidade na forma de trabalhar com
projetos costumam ter modelos preestabelecidos, que se encaixam em todos ou
na maioria dos projetos que executa.
Porém, a declaração de escopo é um artefato intimamente ligado às
metodologias mais tradicionais de projetos, que são do tipo waterfall (cascata),
composta de fases e subfases e nos quais o produto só é disponibilizado ao final
do projeto. Diferente das metodologias ágeis, nas quais normalmente o produto é

5
entregue em etapas (interações) e a documentação é item secundário e a qual se
recomenda ser breve e sucinta. Logo, você pode se perguntar: diante disso, como
é feita uma declaração de escopo em projetos com metodologias ágeis?
É o que veremos na sequência.

TEMA 2 – ESCOPO EM METODOLOGIAS TRADICIONAIS

Inicialmente temos de entender como o escopo é abordado em

metodologias tradicionais.
Nestas metodologias, o escopo é, em geral, inteiramente descrito antes de
se iniciar a execução do projeto. Há uma lista completa de funcionalidades
preestabelecidas. Os envolvidos reúnem-se para descrever os atributos do
produto/serviço a ser construído – o escopo do produto como vimos anteriormente
– e procuram dissecar esses atributos antes de pôr a mão na massa. Nada deve
ser construído antes de se saber completamente o escopo do produto, suas
limitações e demais características. Enfim, há uma grande ênfase no
planejamento do projeto e no controle de suas atividades.
Por exemplo, no desenvolvimento de um software em que se use uma
metodologia tradicional, os envolvidos – gerentes de projeto, analistas de
sistemas, de negócios, usuários etc. – fazem um trabalho de listar todas as
funcionalidades técnicas e de negócio que o software deve ter. Esse trabalho,
chamado de levantamento de requisitos, por vezes é extenso. Muita
documentação é gerada e várias reuniões para discutir esses detalhes são feitas
de modo a garantir o máximo possível que o produto a ser gerado atenda
plenamente aos objetivos de seus patrocinadores.
As pessoas discutem sobre regras de negócios, fluxos de operação,
interfaces (telas e relatórios) e tudo que esteja envolvido no software, o escopo
do produto. Só depois que todos concordem sobre o escopo do produto é que se
bate o martelo sobre todos esses requisitos, para que então o software comece a
ser construído. Essa construção se vale do escopo do projeto, como vimos, isto
é, qual metodologia e quais técnicas serão usadas pela equipe de projeto para a
construção do sistema. A expectativa é que o produto seja entregue inteiro, com
todas os requisitos combinados. Outra razão para que tudo seja definido
previamente é porque esse detalhamento é o que muitas vezes determina o prazo
e orçamento do projeto.

6
Figura 2 – Metodologia ágil versus metodologia tradicional

Créditos: Olivier Le Moal/Shutterstock.

Mas perceba que, dessa forma, muita coisa é discutida sem se ter ainda ao
menos um protótipo do software. No máximo, alguns esboços de telas e relatórios.
Investe-se muito tempo em discussões técnicas, sem a presença do
cliente/patrocinador. E este normalmente tem de esperar um tempo considerável
para poder ver algum resultado prático, geralmente nas fases de testes e
homologações, que acontecem um bom tempo depois do início do projeto, o que
é algo que deixa muitas vezes as pessoas ansiosas, sendo essa a razão principal
de desgastes e pressões, criando um clima pesado no projeto. Também é comum
ocorrerem atrasos em cronogramas e estouro de orçamentos, que trazem ainda
mais problemas às equipes de projetos.
Esses atrasos ocorrem justamente por causa dos requisitos. Por várias
razões: requisitos podem sofrer mudanças ao longo do projeto, aliás, algo
absolutamente normal, dada a dinâmica dos negócios e normativas. Na fase de
discussão dos requisitos, há funcionalidades que não foram corretamente
descritas, devido ao desconhecimento dos participantes ou ausência de pessoas
chaves. Requisitos podem ter suas prioridades definidas erradamente, isto é, um
requisito prioritário pode ser tratado como secundário ou vice-versa. Por fim, pode
haver requisitos importantes deixados de fora do projeto, pela mesma razão de
desconhecimento ou a não participação de pessoas importantes no projeto.
Com isso, os projetos têm de ser revistos, há retrabalho, interrupções,
revisões de custos e cronogramas etc., ou seja, uma série de problemas causados
pelo engessamento que as metodologias tradicionais possuem.
Embora as metodologias tradicionais tenham seus benefícios e uma
infinidade de produtos tenham sido concebidos com o uso dessas técnicas, os

7
problemas acima descritos sempre foram uma forte preocupação dos profissionais
envolvidos com projetos, tanto que, a partir dos anos 1990, com o crescente
aumento da tecnologia e o uso de projetos pelas organizações, nasceram
movimentos para se encontrarem formas de tornar menos estressantes a
execução e a gestão dos projetos. O cerne desses movimentos foi tornar mais
ágeis as fases de concepção e execução dos projetos, eliminando ou pelo menos
reduzindo drasticamente os problemas que vimos acima por meio de adoção de
novas abordagens.

Saiba mais

1. Os métodos ágeis foram inspirados no processo de produção chamado

Lean Manufacturing (manufatura enxuta), criado pela empresa japonesa Toyota,
no final dos anos 1940.
2. Em 2001, surge o Manifesto Ágil, uma reunião de 17 especialistas em
processos de desenvolvimento de software, na qual foi criada a Aliança Ágil.
Acesse o link a seguir para conhecer melhor a história desse movimento:
MANIFESTO para desenvolvimento ágil de software. Ágil Manifesto, 2001.
Disponível em: <https://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 3
nov. 2020.
3. Leia na página 17 do livro Gestão ágil de projetos, de Cristiano Foggetti,
a relação dos métodos ágeis mais conhecidos para desenvolvimento de software,
bem como os princípios dos métodos ágeis:
FOGGETTI, C. (org.). Gestão ágil de projetos. São Paulo: São Paulo:
Pearson Education do Brasil, 2015.

TEMA 3 – ESCOPO EM METODOLOGIAS ÁGEIS

Seja qual for a metodologia que usemos para um projeto, o escopo sempre
estará presente. Não há projeto sem escopo. É o escopo que determina o que vai
ser feito e como vai ser feito. Assim, é falso afirmar que nas metodologias ágeis
não há um escopo. Ele existe, entretanto tem uma abordagem diferente das
metodologias tradicionais.
Nas metodologias tradicionais, existem fases bem definidas, em geral no
início do projeto, nas quais se documentam os requisitos e a solução técnica, de
preferência com o maior nível de detalhe possível. Somente depois disso é que a
execução do projeto começa efetivamente. Já os métodos ágeis preveem que é
8
mais importante um software em funcionamento do que documentação
abrangente. Neste ponto, também devemos entender que as metodologias ágeis
não dispensam a documentação e apenas fazem dela algo bem menos extenso e
detalhado, pois a preocupação dos métodos ágeis é entregar o produto com suas
funcionalidades corretas, acima de tudo. Nas metodologias ágeis, como afirma
Foggetti (2014, p. 19), deve-se “utilizar mais tempo na implementação do que na
documentação, mas, ainda assim, ter documentos objetivos para que o
conhecimento não seja perdido”.
O escopo de projetos invariavelmente é expresso em forma documental.
Mas se nas metodologias ágeis a documentação é um item de menor
detalhamento e relevância e os projetos não dispensam um escopo, como tratar
esse fator nos métodos ágeis?
Para resolver essa questão, nas metodologias ágeis existe um artefato
chamado backlog do produto. Assim, para compreendermos o escopo dentro de
metodologias ágeis, temos de entender o que é esse backlog, uma terminologia
básica em métodos ágeis.

3.1 Backlog

É comum que o cliente – aquele que vai usar o produto – tenha uma visão
menos nítida desse produto do que do problema que ele quer resolver. Portanto
as metodologias tradicionais pecam no sentido de que forçam o cliente a elencar
todo o escopo do produto, em mínimos detalhes, quando isso, para ele, em muitos
casos, é uma tarefa difícil, pois tendo apenas uma visão macro da solução e
conhecimento dos problemas a serem resolvidos, ele não terá o conhecimento de
como detalhar um escopo, de como dissecar requisitos e seus pormenores.
As metodologias ágeis desoneram o cliente dessa tarefa de detalhar
profundamente o escopo. Elas compreendem esse paradigma do cliente: visão
macro do produto e entendimento mais profundo dos problemas a serem
resolvidos. Assim, o cliente é instigado a participar da elaboração do backlog do
projeto e não de um detalhamento complexo de escopo.
Uma vez detectada a viabilidade da solução, as metodologias ágeis
preveem a elaboração de uma lista de funcionalidades, não muito complexas, mas
o suficiente para entender o que é a funcionalidade. O backlog nada mais é do
que essa lista de funcionalidades. É com o backlog que o projeto começa.

9
Figura 3 – Backlog

Créditos: Uwe Rilling/Shutterstock.

Duarte (2016, p. 31) afirma que o backlog é “uma lista ordenada por
prioridade de tudo que deve ser necessário no produto, e origem única dos
requisitos para qualquer mudança a ser feita no mesmo”. Repare que o autor
menciona o termo prioridade. Em backlogs, a prioridade de cada funcionalidade
(ou requisito) é importante para definirmos quando vamos construir cada um
desses requisitos.

3.1.1 Componentes de um backlog

Não existe uma forma única, um padrão a seguir quando se constrói um

backlog. No entanto algumas informações são recomendáveis:

• ID: uma identificação, numérica e sequencial;

• Nome: uma descrição curta e autoexplicativa da funcionalidade (que depois
será possivelmente transformada em uma estória). Por exemplo: Relatório
de pedidos;
• Importância: uma escala numérica ou de outra forma que define a
prioridade do requisito, quanto maior mais prioritário; aqui, pode-se adotar
uma escala numérica, por exemplo de 0 a 10, de 100 em 100 etc.; ou em
níveis, alto, médio, baixo etc.;
• Estimativa inicial: uma ideia de quanto tempo a funcionalidade levará para
ser construída, testada e entregue; é importante salientar que, apesar de
se tratar de uma estimativa, existem métodos para levantar essa
informação;

10
 • Observações ou notas: eventuais informações complementares do
requisito, por exemplo, “a fonte do relatório de pedidos deverá ser da família
verdana”.

Portanto, preparar um backlog não é das tarefas mais difíceis (como quase
tudo nas metodologias ágeis). Uma planilha ou editor de textos é mais que
suficiente para essa atividade.

3.1.2 Critérios para um bom backlog de produto

Estabelecer a lista de requisitos – o backlog do produto – é tarefa que

demanda certo trabalho e, acima de tudo, discussão. Isso é ainda mais natural
quando se tem mais de uma pessoa na posição de cliente ou patrocinador do
projeto. Cada um irá ter uma visão sobre os requisitos, quais suas prioridades e
até mesmo se um requisito deve ou não ser deixado de lado.
Logo, é necessário ter algum critério para avaliar se um requisito é bom ou
não, se é necessário ou não, se tem a prioridade adequada e se está descrito
corretamente.
Uma boa forma de se avaliar uma lista de requisitos de um backlog é usar
a técnica INVEST, criada por Wake, autor do livro Extreme Programming Explored
(Programação Extrema Explorada). O Extreme Programming ou XP é uma das
metodologias ágeis criadas no início dos anos 2000.
A palavra INVEST é um acrônimo com as iniciais em inglês das palavras
independent, negotiable, valuable, estimable, small e testable. Ou seja, um
requisito deve ser independente, ser negociável, ter valor, poder ser estimado, ser
pequeno e testável. Vejamos cada uma dessas características.
Independent (independente)
Os requisitos devem ser independentes uns dos outros. Isso por um motivo
simples: cada requisito em geral se transformará em uma estória, uma unidade
de desenvolvimento do projeto. Isso também permite que essas estórias possam
ser feitas em qualquer ordem e que uma delas não precise esperar outra ficar
pronta para ser iniciada, dando grande flexibilidade.
Negotiable (negociável)
Nenhum requisito deve ser escrito na pedra. As metodologias ágeis têm em
sua essência a filosofia de que requisitos podem mudar e isso deve ser encarado

11
naturalmente. Portanto todo requisito pode ser objeto de negociação a qualquer
tempo entre cliente e equipe de projeto.
Valuable (com valor, relevante)
Um requisito sem valor, isto é, sem relevância para o cliente, não deve ser
implementado, assim deve ser retirado do backlog ou ser alterado. Requisito de
valor é aquilo que confere valor ao negócio, ser importante para atingir os objetivos
do projeto. Por exemplo, em um desenvolvimento de um site de e-commerce, um
requisito importante é implementar integração com todas as bandeiras de cartão
de crédito.
Estimable (estimável)
Cada requisito deve ter uma estimativa de quanto tempo vai levar para ser
desenvolvido/produzido. Sem isso, sua construção não deve ser iniciada. Essa
estimativa deve ser feita pelo time ágil. Vale lembrar que estimativas não precisam
ser exatas, mas razoáveis. Por isso a importância de pessoas com experiência no
time.
Small (pequena)
Um requisito, como vimos, será transformada em uma estória. A estrutura
da estória é composta de um enunciado (a quem o requisito serve, o que o
requisito deve fazer e que benefícios traz ao produto) e de critérios de aceitação
(lista de itens verificáveis da estória, se todos esses itens forem atendidos, o
requisito/estória é considerado construído). O que esse critério significa é que
boas estórias são pequenas, têm redação concisa, o que inclusive dá mais
precisão na sua estimativa.
Testable (testável)
Estórias devem ter critérios de aceitação que permitam testar o que foi
construído. Um bom critério é objetivo nesse sentido. Por exemplo, o critério deve
ser “Ao cadastrar o CPF, os dois dígitos verificadores devem ser validados
conforme o módulo 11” e não algo como “Os dígitos verificadores do CPF devem
estar corretos para prosseguir o cadastro”.

12
TEMA 4 – PRIORIZAÇÃO DE REQUISITOS

Vimos que criar um backlog em si não é uma tarefa difícil. Contudo dois
itens dão um pouco mais de trabalho: a priorização e as estimativas de tempo de
construção. Por ora, vamos tratar da priorização.
Há um célebre artigo publicado em 2011, no site da Scrum Alliance
(entidade certificadora na metodologia ágil Scrum), de autoria do professor de
ciência da computação James O. Coplien, da Universidade de Bruxelas, Bélgica.
Nesse artigo, ele afirma que:

As prioridades guiam a comparação dois-a-dois dos itens na lista. Pense

na aplicação do algoritmo de ordenação por bolhas (bubble sort) para
priorizar o backlog do produto: compare os dois itens do topo e troque-
os de posição se estiverem na ordem errada. Passe, então, para o
próximo par e continue percorrendo a lista até que todos os itens estejam
nas posições corretas. Priorização e ordenação andam de mãos dadas.
Todas as comparações são locais, ou seja, são restritas a uma
otimização local (Scrum Alliance, S.d.).

O conselho de Coplien é uma das várias técnicas de priorização e

ordenação dos itens do backlog, mas não a única. Repetindo: como nada é
engessado nas metodologias ágeis, também há mais de uma técnica de
priorização de backlogs.
Nesse ponto, você deve estar se perguntando: existe alguma técnica
melhor ou mais usada para priorizar os itens de um backlog? A resposta é não.
Isso porque as metodologias ágeis são bastante flexíveis, podendo ser adaptadas
de acordo com a empresa, projeto ou do produto que será construído (lembremos
que metodologias ágeis não servem apenas para software).

TEMA 5 – TÉCNICAS DE PRIORIZAÇÃO DE REQUISITOS

Algumas técnicas de priorização e ordenação de backlogs são mais usadas

pelo mercado, dadas suas características de facilidade, flexibilidade, eficiência e
outros atributos. A seguir, algumas dessas técnicas:
Value versus Risk (valor versus risco)
Uma das maneiras mais tradicionais de priorização. Consiste em comparar
o valor com o risco de cada requisito. Boa técnica para produtos ou features
novas. Trata-se de um gráfico cartesiano com quatro quadrantes nos quais o
requisito é classificado:

• Alto risco e baixo valor;

13
 • Alto risco e alto valor;
• Baixo risco e baixo valor;
• Baixo risco e alto valor.

Visualmente cada requisito é colocado em um desses quadrantes. A Figura

4 explica esse modelo:

Figura 4 – Gráfico valor versus risco de requisitos de backlogs

Assim, requisitos de alto valor e alto risco devem ser desenvolvidos

primeiro; já aqueles requisitos de baixo valor e alto risco devem ser evitados, e
assim por diante.
Valor versus esforço
Similar à técnica anterior, no entanto o risco nesse caso é substituído pelo
esforço de desenvolvimento do requisito. Ideal para times ágeis pequenos e com
grau de maturidade ainda baixo em metodologias ágeis. Veja a Figura 5, que
explica essa técnica:

Figura 5 – Gráfico valor versus esforço de requisitos de backlogs

14
 Scorecard
Técnica bastante usada para priorizar e ordenar requisitos. No entanto, o
cliente e demais integrantes do time de projeto devem estar bastante alinhados.
Isto porque devem ser atribuídos pesos e notas a critérios e categorias, o que
exige por vezes discussões para definir quais as categorias e seus pesos, bem
como as notas de cada requisito. Essa técnica funciona da seguinte forma:

• É feita uma planilha com categorias importantes para o produto e os

requisitos (itens do backlog);
• Cada categoria recebe pesos percentuais, de 1 a 100%; os percentuais
atribuídos devem somar 100%;
• Os requisitos recebem notas de 0 a 100, para cada categoria;
• A soma das notas de um requisito em relação ao peso de cada categoria
resulta na prioridade do requisito.

Para exemplificar, veja o exemplo a seguir:

Tabela 1 – Tabela ScoreCard para priorização de requisitos de backlogs

MoSCOW
Técnica de priorização bastante utilizada em métodos ágeis, especialmente
o Scrum. É um acrônimo em inglês para as palavras:

• Must (deve ter);

• Should (deveria ter);
• COuld (poderia ter);
• Won’t (não deverá ter).

O primeiro o, minúsculo, nada significa. Apenas existe para facilitar a

denominação da técnica.
Sua utilização é bem simples. Cada requisito deve ser classificado em uma
das categorias acima. Dessa forma, os requisitos mais prioritários serão
classificados como Must, ou seja, devem ser desenvolvidos por primeiro, pois são
15
os requisitos mais importantes do backlog. Os requisitos classificados como
Should são importantes, mas não em primeira prioridade. Os requisitos
considerados como COuld são aqueles desejáveis, mas que podem ser
desenvolvidos posteriormente, quando o produto estiver estabilizado e com
melhorias. Finalmente, os requisitos classificados como Won’t têm baixa
prioridade, mas isso não significa que nunca serão feitos; indica apenas que serão
desenvolvidos em uma segunda versão, pois em geral representam apenas
melhorias secundárias no produto.

16
REFERÊNCIAS

DUARTE, L. Scrum e métodos ágeis: um guia prático. [S.l.]: LuizTools, 2016.

FOGGETTI, C. (org.). Gestão ágil de projetos. São Paulo: Pearson Education do

Brasil, 2015.

MANIFESTO para desenvolvimento ágil de software. Agile Manifesto, 2001.

Disponível em <https://agilemanifesto.org/iso/ptbr/manifesto.html>. Acesso em: 3
nov. 2020.

PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management

Body of Knowledge – PMBOK® Guide 2000 Edition, Pennsylvania-USA:
PMBOK, 2000.

SCRUM ALLIANCE. Disponível em: <https://www.scrumalliance.org/>. Acesso

em: 3 dez. 2020.

WAKE, W. C. Extreme programming explored. Boston, Massachusetts:

Addison-Wesley Professional, 2001.

17