Desenvolvimento Ágil com Scrum e Lean

Prévia do material em texto

Desenvolvimento Ágil 
Responsável pelo Conteúdo:
Prof. Me. Artur Marques 
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Revisão Ágil
Revisão Ágil
• Revisar Scrum e Lean como metodologias de gerenciamento de software ágil.
OBJETIVO DE APRENDIZADO 
• Revisão e Atualizações;
• Revisão Scrum;
• Uso e Recomendações sobre Definição e Montagem de um Time Scrum;
• Uso de XP na Engenharia de Sistemas;
• Sprint 0 e o Controle do Tempo do Projeto Ágil;
• Determinação do Tempo da Sprint do Projeto;
• Resumo Lean.
UNIDADE Revisão Ágil
Revisão e Atualizações
O Manifesto Ágil é um contraste dramático com o guia e os padrões tradicionais 
do Corpo de Conhecimento do Gerente de Projeto (PMBOK) focado no desenvolvi-
mento sequencial ou Cascata.
E sim, ágil possui muitos termos associados a ele, como, por exemplo, Lean, 
DevOps, Kanban e Scrum. 
Falar de processos ágeis, ao contrário do senso comum sobre essa palavra, é 
complexo e multidisciplinar. Abordamos assuntos relacionados à estimativa, como 
previsibilidade, transparência, inspeção, adaptação, incerteza, velocidade e rastrea-
mento de tempo. Mas a ideia aqui é recapitular de maneira geral, para trabalharmos 
na iniciação de um Projeto.
Então, vamos passo a passo!
De acordo com a Agile Alliance (2019, p. 1): “Agile é a capacidade de criar e 
responder às mudanças. É uma maneira de lidar e, finalmente, ter sucesso em um 
ambiente incerto e turbulento.” Enquanto isso, “Desenvolvimento ágil de software é 
um termo genérico para um conjunto de estruturas e práticas baseadas nos valores 
e nos princípios expressos no Manifesto para software ágil”. 
Isso, para ser executado, exige forte comprometimento comportamental dos in-
divíduos, criando o que se chama de mentalidade ágil, que envolve aceitar e adotar 
mudanças úteis e que gerem valor.
Revisão Scrum
O SCRUM foi desenvolvido, inicialmente, para gerenciar e desenvolver produtos. 
Todavia, encontrou um grande apelo na indústria de software devido a suas deman-
das complexas e que devem ser respondidas de forma rápida e direta, produzindo 
software de qualidade.
De acordo com o Scrumguides.org (2018), a partir do início dos anos 1990, o 
Scrum tem sido amplamente utilizado em todo o mundo para desenvolver software, 
hardware, software embarcado, redes de funções interativas, veículos autônomos, 
escolas, governo, marketing, gerenciamento da operação de Organizações e quase 
tudo o que usamos em nossas vidas diárias, como indivíduos e Sociedades.
À medida que as complexidades tecnológicas, de Mercado e ambientais e suas 
interações aumentam, rapidamente a utilidade do SCRUM em lidar com a complexi-
dade é comprovada diariamente.
Em essência, quando falamos de SCRUM, estamos tratando de uma Equipe peque-
na de pessoas (entre 5 e 9 pessoas, quando você inclui o Dono do Produto, e o Scrum 
8
9
Master fica entre 7 e 11 – tente não ultrapassar isso), altamente flexível e adaptável, 
que colaboram e interoperam por meio de sofisticadas arquiteturas de desenvolvimento 
e ambientes de liberação de destino (versionamento de softwares e funcionalidades).
Para trabalharmos com SCRUM, há um guia mantido por 2 dos profissionais 
que elaboraram e participaram ativamente não apenas do Manifesto Ágil, mas do 
desenvolvimento de metodologias que hoje são o arcabouço da agilidade no geral e 
do SCRUM em particular. São eles: Ken Schwaber e Jeff Sutherland, portanto, os 
criadores do SCRUM.
Em primeiro lugar, quando vamos iniciar um Projeto, temos em SCRUM o DOD – 
Definition of Done ou, se prefere em Português, uma Definição de Concluído/Pronto. 
Essa é uma maneira de ajudar uma Equipe e seus stakeholders a entender a dife-
rença entre o que a Equipe entrega a cada Sprint versus o que seria necessário para 
que o produto fosse incrementado em um estado “entregável” (e, apesar de essa 
palavra não existir em Português, é a mais utilizada e aceita no linguajar de Projetos. 
Ela vem de Deliverable e significa Entrega) a cada Sprint.
Mas antes disso, você deve se lembrar das regras do SCRUM, certo?!
• C ada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre Sprints;
• A intenção de cada Sprint é um software “potencialmente remetível”;
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
• As reuniões de revisão e retrospectiva são colocadas em caixas de horas no total 
de 2 horas/semana de duração da Sprint;
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint
(interrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da 
Sprint Review;
• Os PBIs têm seu esforço estimado coletivamente pela Equipe que os implementará;
• A Equipe Scrum é composta por cinco a onze pessoas;
• A Equipe Scrum inclui o Product Owner, o ScrumMaster e os membros da Equipe;
9
UNIDADE Revisão Ágil
• A Equipe Scrum não inclui outras pessoas (por exemplo, um Gerente que não 
executa tarefas).
Assim como sobre o Backlog do Produto:
• Não existem dois PBIs (Product Backlog Items) na mesma posição no Product 
Backlog (pedido);
• Todos os PBIs estão relacionados a um único produto (ou Sistema);
• Os PBIs são ordenados pelo valor esperado (ROI, NIAT etc.);
• Os PBIs são «fatias» através do nosso Sistema (recursos ou funções);
• Os PBIs são escritos como Histórias de Usuário (“Como ___ eu posso ___ para 
que ___”);
• Os PBIs principais são pequenos o suficiente (esforço) para que vários possam 
caber em um único Sprint;
• PBIs são convites para conversas, não especificações detalhadas;
• Defeitos conhecidos (qualidade externa), geralmente, são solicitados na parte 
superior do Backlog do Produto para serem corrigidos no próximo Sprint;
• O Product Backlog é refinado para garantir que esteja pronto para todas as 
reuniões do Sprint Planning;
• Qualquer parte interessada (por exemplo, membro da Equipe, vendedor, cliente) 
pode sugerir um novo PBI;
• O Backlog do Produto é facilmente visível para todas as partes interessadas (por 
exemplo, cartões em uma parede ou uma ferramenta eletrônica com acesso aberto):
Desenvolvimento Ágil
1 – Requisitos
2 – Planejam
ento
3 – D
esign
4 – Desenvolvimento
5 –
 Li
be
ra
çã
o
6 – 
Rast
reab
ilida
de
e Mo
nito
ram
ento
Figura 1 – característica circular do SDLC Ágil 
Ciclo de Vida do Desenvolvimento de Software Ágil
Fonte: Freepik
10
11
Uso e Recomendações sobre Definição
e Montagem de um Time Scrum
O que é um time ágil segundo seus próprios criadores e membros da AGILE 
ALLIANCE:
Definição: U ma “Equipe” no sentido Ágil é um pequeno grupo de pes-
soas, designado a um mesmo projeto ou esforço, quase todos em período 
integral. Uma pequena minoria de membros da Equipe pode colaborar 
em período parcial ou ter responsabilidades concorrentes. A noção de 
Equipe implica responsabilidade compartilhada: bom ou ruim, os resul-
tados devem ser atribuídos a toda a Equipe, e não a qualquer indivíduo. 
Espera-se que a Equipe possua todas as competências necessárias, sejam 
técnicas (programação, design, teste) ou comerciais (conhecimento de 
 domínio, capacidade de tomada de decisão).
Papéis e responsabilidades: não importam tanto quanto resultados: um 
desenvolvedor pode testar, executar análises ou pensar nos requisitos; um 
analista ou especialista em domínio pode sugerir ideias sobre implemen-
tação e assim por diante.
Armadilhas comuns: o erro mais elementar é equiparar “grupo” e 
“Equipe”, para pensar que uma Equipe resulta automaticamente de ter 
pessoas trabalhando juntas. Uma Equipe deve ter pelo menos três pessoas 
(duas são um par) e geralmente não excederá dez.Uma única pessoa 
pode contribuir com mais de um “projeto” simultaneamente, mas é alta-
mente improvável que se considere pertencer a mais de uma “Equipe” ao 
mesmo tempo.
Origens: 2004, Kent Beck propõe “Equipe Inteira” como a nova denomi-
nação para a prática anteriormente conhecida como “Cliente no Local”
O modelo conceitual de Tuckman (“normatizar, formar, atacar, executar”) 
é provavelmente o mais citado com relação à dinâmica das Equipes Agile”. 
(AGILE ALLIANCE, 2019, p. 1)
Sugerimos duas leituras importantes para você entender os modelos de monta-
gem de times ágeis para um projeto SCRUM validados pela AGILE ALLIANCE.
Vale o investimento de tempo nisso:
TUCKMAN B. W. Developmental sequence in small groups. “Desenvolvimento sequencial 
em pequenos grupos”. 1984. Disponível em: https://bit.ly/3erJAfE
HOEGL, M.; GEMUENDEN, H. G. Teamwork Quality and the Success of Innovative Projects: 
A Theoretical Concept and Empirical Evidence. “Qualidade e sucesso de projetos inovadores: 
um conceito teórico e evidências empíricas”. 2001. Disponível em: https://bit.ly/2TZN8w4
Lembrando-se rapidamente dos componentes de uma Equipe SCRUM:
• Scrum Master: é responsável pela criação da Equipe, pela reunião do sprint e 
por remover os obstáculos ao Progresso do Projeto;
11
UNIDADE Revisão Ágil
• Product Owner: proprietário do produto: cria um backlog do produto, prioriza 
o backlog e é responsável pela entrega da funcionalidade a cada iteração;
• Equipe Scrum: gerencia seu próprio trabalho e organiza o trabalho para con-
cluir o sprint ou o ciclo.
Aqui vão regras úteis para você quanto a ser um membro da Equipe:
• Eu uso o Scrum como uma ferramenta para o desenvolvimento de produtos;
• Sou sincero quanto à qualidade interna do meu produto (dívida técnica);
• Eu trabalho com apenas uma Equipe Scrum;
• Sou membro em tempo integral dessa Equipe (não há deveres que não sejam 
membros da Equipe);
• Conheço bem meu produto e posso descrever rapidamente seu objetivo de 
alto nível;
• Conheço bem meu produto e posso descrever rapidamente sua arquitetura de 
alto nível;
• Busco ativamente ajudar meus companheiros de Equipe;
• Comprometo-me a fazer o que for preciso para atingir todos os objetivos 
da Sprint;
• Sou voluntário para uma nova tarefa do backlog da Sprint assim que concluo 
uma tarefa;
• Compartilho meus obstáculos (técnicos, ferramentas, processos, trabalho em 
Equipe, pessoal) todos os dias do Scrum Diário;
• Estou disposto a aprender qualquer habilidade necessária para ajudar 
minha Equipe;
• Eu trabalho com todos os membros da Equipe para expandir a Definição 
de “Concluído”;
• Eu tomo a direção do escopo e a visão do produto pelo Dono do Produto da 
minha Equipe;
• Vivo os valores e princípios do Manifesto Ágil em minha Equipe;
• Participo pessoalmente de todas as reuniões do Sprint Planning;
• Participo de todas as reuniões diárias do Scrum pessoalmente;
• Participo de todas as reuniões de revisão da Sprint pessoalmente;
• Participo pessoalmente de todas as reuniões retrospectivas da Sprint;
• Eu nunca digo a nenhum outro membro da Equipe qual tarefa trabalhar 
na próxima;
• Nenhum membro da minha Equipe se reporta a mim;
• Não acompanho minhas horas ou meu tempo “real” nas tarefas;
12
13
• Cada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre sprints;
• A intenção de cada Sprint é um software “potencialmente viável para produção”; 
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
• As reuniões de revisão e retrospectiva são colocadas em caixas de horas no total 
de 2 horas/semana de duração da Sprint;
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O Daily Scrum é timeboxed por 15 minutos;
• O Daily Scrum ocorre todos os dias na mesma hora do dia;
• Os membros da Equipe respondem apenas a três perguntas no Daily Scrum
(sem discussão);
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint (in-
terrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da 
Sprint Review;
• Os PBIs têm seu esforço estimado coletivamente pela Equipe que os implementará.
Mas caso você seja um Scrum Master:
• Cada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre Sprints;
• A intenção de cada Sprint é um software “potencialmente funcional”;
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
13
UNIDADE Revisão Ágil
• As reuniões de revisão e de retrospectiva são colocadas em caixas de horas no 
total de 2 horas/semana de duração da Sprint;
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O Daily Scrum é determinado em 15 minutos;
• O Daily Scrum ocorre todos os dias na mesma hora do dia;
• Os membros da Equipe respondem apenas a três perguntas no Daily Scrum 
(sem discussão);
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint 
(interrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da 
Sprint Review;
• Os PBIs (backlog do produto) têm seu esforço estimado coletivamente pela Equi-
pe que os implementará;
• A Equipe Scrum é composta por cinco a onze pessoas;
• A Equipe Scrum inclui o Product Owner, o Scrum Master e os membros 
da Equipe;
• A Equipe Scrum não inclui outras pessoas (por exemplo, um Gerente que não 
executa tarefas).
Por fim, caso você tenha o papel de Dono do Produto, veja o que se espera de sua 
função, porque há muita coisa daqui que as pessoas, no geral, acham que é o Scrum 
Master que faz, principalmente aqui no Brasil.
Eu, nas minhas consultorias, tenho visto Scrum Masters sendo obrigados a faze-
rem papel de Gerente de Produto, coisa que não existe no SCRUM, porque a Equipe 
é multifuncional e a liderança é situacional:
• Cada Sprint tem o mesmo comprimento;
• Cada Sprint tem quatro semanas ou menos de duração;
• Não há quebras entre Sprints;
• A intenção de cada Sprint é um software “potencialmente funcional”;
• Todo Sprint inclui Planejamento de Sprint;
• A Reunião de Planejamento da Sprint tem a validade definida para 2 horas/
semana de duração da Sprint;
• Cada Sprint inclui a Revisão da Sprint para obter feedback das partes interes-
sadas sobre o produto;
• Cada Sprint inclui Retrospectiva da Sprint para que a Equipe inspecione e 
se adapte;
• As reuniões de revisão e retrospectiva são colocadas em caixas de horas no total 
de 2 horas/semana de duração da Sprint;
14
15
• Não há interrupção entre as reuniões da Sprint Review e da Retrospective;
• O Daily Scrum é feito em 15 minutos e somente isso!;
• O Daily Scrum ocorre todos os dias na mesma hora do dia;
• Os membros da Equipe respondem apenas a três perguntas no Daily Scrum
(sem discussão);
• O escopo do trabalho de um Sprint nunca é expandido no meio do Sprint (in-
terrupções);
• Todas as partes interessadas são convidadas a participar da parte demo da
Sprint Review;
• Os PBIs têm seu esforço estimado coletivamente pela Equipe que os implementará;
• A Equipe Scrum é composta por cinco a onze pessoas;
• A Equipe Scrum inclui o Product Owner, o Scrum Master e os membros
da Equipe;
• A Equipe Scrum não inclui outras pessoas (por exemplo, um Gerente que não
executa tarefas).
Lembrando-se de que o Dono do Produto se preocupa muito com o que foi pro-
metido em cada sprint (sprint backlog), lembrando-se deque: a Sprint Backlog (uma 
fração escolhida por prioridade pelo dono do produto a partir do backlog do produto 
visando a realizar uma entrega útil e funcional para o cliente) define o trabalho, ou 
tarefas, que uma Equipe (entre 5 à 9 pessoas) define para transformar o Backlog 
do produto (a quantidade de tarefas totais a serem feitas, ou seja, o produto ou um 
Sistema de Informação inteiro) selecionado para esse Sprint em um incremento da 
funcionalidade do produto potencialmente implementável. 
A Equipe compila uma lista inicial dessas tarefas na segunda parte da reunião de 
planejamento da Sprint, de tal forma que as tarefas devem ser divididas para cada 
uma tomar de 4 a 16 horas para acabar.
Tarefas maiores de 4 a 16 horas são consideradas como não tendo sido definidas 
de forma adequada.
Para que tudo isso funcione de maneira sinérgica, trataremos aqui de algumas 
regras de ouro que devem ser seguidas para a composição de um time ágil e de um 
SCRUM nos eixos e funcional que, além disso, são alguns conselhos. 
Você que trabalha ou trabalhará com o framework, deve ler o Manual SCRUM 
GUIDE e seguir esses princípios. 
Mersino (2018), do PMI, revela-nos o seguinte:
A Equipe é auto-organizada: O Guia Scrum é bastante claro sobre 
isso, afirmando que “Ninguém (nem mesmo o Scrum Master) diz à 
Equipe de Desenvolvimento ...” como realizar o trabalho. A Equipe 
é composta por indivíduos motivados, competentes e deve pos-
15
UNIDADE Revisão Ágil
suir confiabilidade da empresa. O que frequentemente encontramos 
é alguém fora da Equipe dizer a Equipe o que fazer, e esse alguém é 
o Scrum Master. Por vezes, é o gerente de desenvolvimento ou, outra 
gerente funcional. De qualquer forma, a Equipe não é confiável ou confi-
gurada para operar sem essa dependência. Portanto, essa falta de auto-
nomia prejudica a adesão e a motivação dos membros da Equipe.
O Scrum Master é um líder servo que ensina a Equipe do Scrum 
como se auto organizar. O papel do Scrum Master é amplamen-
te mal compreendido. Como o nome indica, o Scrum Master deve 
 dominar o SCRUM. Eles não são gerentes de projetos. Em vez disso, eles 
são um tutor que ensina a todos o SCRUM e ajuda a Equipe a se auto 
organizar. Se bem feito, o Scrum Master sairia do trabalho à medida que 
a Equipe aprende e cresce. Vemos frequentemente o Scrum Masters que 
não conhecem SCRUM, não saberem atuar nem como tutores e nem 
como líderes e, portanto, não sabem como ajudar as Equipes a se auto 
organizarem. Eles geralmente vêm de outros papéis e carregam a baga-
gem desses papéis. Eles frequentemente se sentem compelidos a tomar 
decisões e a dizer à Equipe o que fazer. Em vez de tornar a Equipe inde-
pendente, esses Scrum Masters se fazem tornar indispensáveis.
O Scrum Master não precisa participar do Daily Scrum. Essa é 
uma regra interessante que se alinha à regra anterior. O pensamento 
tradicional é que uma pessoa – normalmente o gerente do projeto – hos-
peda e dirige a reunião de status. Não é assim que as coisas funcionam 
no Scrum. O Daily Scrum não é uma reunião de status, é uma reunião 
para os membros da Equipe coordenarem seu trabalho e garantirem que 
estão no caminho certo para alcançar seu objetivo da sprint. O motivo 
pelo qual o Scrum Master não pode participar da reunião é porque eles 
não são necessários na reunião. Scrum Masters novos ou inábeis podem 
realmente fazer mais mal comparecendo do que bem.
O Scrum Master é responsável por garantir que a Reunião diária do 
Scrum ocorra, que seja eficaz e que seja mantida dentro do prazo 
de 15 minutos. A Equipe deve ter a reunião, independentemente 
de o SM estar presente ou não. As Equipes de Scrum devem traba-
lhar de forma multifuncional sem transferências. As Equipes tradicionais 
trabalham como se estivessem realizando uma corrida de revezamento: 
membros especializados da Equipe entregam o trabalho em uma fase a 
diferentes especialistas na próxima fase. As transferências entre os silos 
são geralmente a maior área de risco. Espera-se que as Equipes Scrum 
colaborem e trabalhem de forma multifuncional em um ou alguns itens de 
cada vez. Dentro da Equipe Scrum, você não deve ouvir os membros da 
Equipe falando sobre a “Equipe de front end” ou a “Equipe de controle 
de qualidade”. A Equipe do Scrum deve estar operando como um todo.
Realize eventos do Scrum ao mesmo tempo e local. Os eventos do 
Scrum devem estar no calendário e realizados ao mesmo tempo e 
colocar cada sprint. Essa prática ajuda a criar consistência e evitar o 
desperdício associado ao reagendamento de reuniões ou à reserva dupla 
16
17
de pessoas e salas. O que vemos ocorrendo é que as reuniões são remar-
cadas, mantidas fora de sequência ou simplesmente canceladas. Muitas 
organizações operam em um ciclo contínuo de combate a incêndios e 
não veem que a adesão a uma estrutura como o SCRUM os ajudaria a 
minimizar esses incêndios. Além disso, faça as reuniões na sequência 
correta, da maneira como foram projetadas. Eu observei uma reunião de 
que foi realizada no meio do sprint. Os membros da Equipe já haviam 
esquecido o que aconteceu no sprint anterior e não foram capazes de 
incorporar melhorias na próxima.
O proprietário do produto é a única fonte de trabalho para a Equipe. 
O objetivo desta regra é ter um tomador de decisão que priorize o 
trabalho para a Equipe. Ninguém mais pode dizer à Equipe o que 
 fazer, e a Equipe não deve agir de acordo com o que os outros dizem. 
O proprietário do produto possui a lista de pendências e todo o 
trabalho é refletido na lista de pendências. Existem algumas maneiras 
pelas quais as organizações quebram essa regra. Alguns não atribuem o 
proprietário de um produto. Alguns têm um proprietário do produto, mas 
não permitem que o proprietário do produto seja o proprietário e priorize 
a lista de pendências; em vez disso, o Scrum Master, o gerente de projetos 
ou o gerente funcional o fazem. Às vezes, há um proprietário do produto 
priorizando o trabalho, mas os membros da Equipe ainda são orientados 
a trabalhar em outros itens.
Não há títulos na Equipe SCRUM além do desenvolvedor. O moti-
vo dessa regra é incentivar o comportamento multifuncional, evitar 
subEquipes e promover a propriedade da Equipe. O SCRUM procura 
evitar as ineficiências dos líderes de Equipe e subEquipes especializadas 
dentro da Equipe. Cada membro da Equipe é responsável por participar 
totalmente da Equipe. As Equipes do Scrum trabalham como Equipes de 
rugby, com o único objetivo de mover a bola para o campo. (MERSINO, 
2018, p. 2-3)
Uso de XP na Engenharia de Sistemas
A Técnica de Programação Extrema XP é muito útil quando há demandas ou 
requisitos constantemente em mudança dos clientes ou quando eles não têm certeza 
sobre a funcionalidade do sistema. 
Para tanto, XP defende “lançamentos” frequentes do produto em curtos ciclos 
de desenvolvimento, o que melhora inerentemente a produtividade do sistema e 
introduz um ponto de verificação em que quaisquer requisitos do cliente podem ser 
facilmente implementados. 
O XP desenvolve softwares mantendo o cliente como foco.
17
UNIDADE Revisão Ágil
Requisitos do
Projeto
Automação de Testes Unitários
Métricas das
Histórias
Iteração
Teste 
do Cliente
Entrada
do Cliente
Reunião de
Planejamento
de Iteração
Testes de
Aceitação
Iteração
Casos de Testes Tarefas ConclusãoHistórias
Figura 2 – Projeto XP
Os requisitos de negócios são reunidos em termos de histórias. Todas essas histó-
rias são armazenadas em um local chamado “depósito”.
Nesse tipo de metodologia, as liberações são baseadas nos ciclos mais curtos 
chamados Iterações, com período de 14 dias. Cada iteração inclui fases como codi-
ficação, teste de unidade e teste do sistema, no qual, em cada fase, algumas funcio-
nalidades menores ou maiores serão construídas no aplicativo.
São seis as fases do XP, a saber:
Quadro 1
Planejamento
• Identificação de partes interessadas e patrocinadores;
• Requisitos de infraestrutura;
• Informações e coleta relacionadasà segurança;
• Acordos de nível de serviço e suas condições.
Análise
• Captura de Histórias em Estacionamento;
• Priorizar histórias no estacionamento;
• Limpeza de histórias para estimativa;
• Definir tempo da Iteração;
• Planejamento de recursos para as Equipes de desenvolvimento e 
controle de qualidade.
Projeto
• Divisão de tarefas;
• Preparação do cenário de teste para cada tarefa;
• Estrutura de automação de regressão.
Execução
• Codificação;
• Teste de Unidade;
• Execução de cenários de teste manual;
• Geração de relatórios de defeitos;
• Conversão de casos de teste de regressão manual para automação;
• Revisão da Iteração Média;
• Revisão de fim de iteração.
Release
• Pequenas Versões;
• Teste de regressão;
• Demonstrações e críticas (lições aprendidas);
• Desenvolva novas histórias com base na necessidade;
• Melhorias de processo com base nos comentários da revisão de final 
da iteração.
18
19
Encerramento
• Lançamento do piloto;
• Treinamento;
• Lançamento de produção;
• Garantia de Nível de Serviço ou SLA;
• Revise da estratégia;
• Suporte à Produção ou Sustentação.
Sprint 0 e o Controle do
Tempo do Projeto Ágil
Sprint é a unidade básica de trabalho quando utilizamos o SCRUM. Os sprints
têm duração fixa, de modo que a Equipe tenha tempo previsível disponível para rea-
lizar o trabalho, o que, por sua vez, auxilia no planejamento de curto e longo prazo, 
conforme Berteig (2013, p. 1). 
Ao fazer com que cada Sprint tenha o mesmo comprimento, a Equipe Scrum
aprende sua própria capacidade de trabalho. Se a duração do Sprint mudar, o ritmo 
do Scrum será interrompido e uma Equipe terá de reaprender sua capacidade, o que, 
geralmente, leva pelo menos alguns Sprints. 
Se houver uma pausa entre os Sprints, a Equipe pode esquecer o que aprendeu 
ou deixar de aplicar esse aprendizado em tempo hábil no próximo Sprint.
A duração de uma Sprint determina a rapidez com que uma Equipe Scrum pode 
“inspecionar e se adaptar” a mudanças de circunstâncias e aprendizado. 
Se uma Equipe tem um Sprint de cinco semanas (ou mais), os benefícios do 
Scrum diminuem rapidamente. Em particular, você aumenta drasticamente os riscos 
associados ao planejamento de curto prazo, respondendo a mudanças, desenvolvi-
mento de Equipes, janelas de oportunidades de negócios e detecção de erros.
Mas, e a Sprint Zero?
Na maioria das vezes, as pessoas pensam na Sprint Zero como a aplicação da 
estrutura de uma Sprint Scrum normal ao processo de pré planejamento de um 
Projeto ou, como alguns dizem, “O Projeto antes do projeto”. No entanto, essa é 
uma representação simplificada, se não problemática, do significado do Sprint Zero.
Bom, para facilitar o entendimento e tirar um pouco dos mitos que envolvem esse 
artefato, vamos deixar claro para você o que ela não é:
• A Sprint Zero não é a fase em que a Equipe é montada;
• Para realizar uma Sprint, mesmo a Zero, em primeiro lugar, uma Equipe já
deve existir;
• Não se trata da fase de configuração da infraestrutura, que já deve ser imple-
mentada ou facilmente implementada sob demanda, mas não como parte da
Sprint Zero;
19
UNIDADE Revisão Ágil
• Por fim, mas sem se esgotar, uma Sprint Zero não deve envolver a adição de 
produtos a uma lista de pendências ou considerar/incluir no planejamento.
Cuidado, todas as etapas acima devem ser realizadas nas fases de pré planejamento, 
mas não como parte de qualquer Sprint, mesmo um Sprint Zero no SCRUM. 
Creio que isso que estou escrevendo pouca Literatura de Concursos ou até mesmo 
de vídeos relata, e isso é um ponto problemático para quem quer tocar um Projeto 
baseado em SCRUM ou realizar os desafios de estudo dessa Disciplina mais prática. 
Normalmente, numa Empresa estruturada e que trabalha de verdade com SCRUM, 
um grupo de colaboradores que criará a Sprint Zero é, provavelmente, composto 
por pensadores de alto nível que podem não fazer parte de outros Sprints, portanto, 
do time SCRUM desse ou de outro Projeto.
Watts (2018), bastante recentemente, nos mostra que o principal objetivo de uma 
Sprint Zero é fornecer algum valor utilizável que possa ser construído pela próxima 
Equipe (time SCRUM designado para o projeto). 
Para que essa abordagem funcione, deve haver algumas histórias no backlog 
antes do início do Sprint Zero, apenas o suficiente para que resulte em um produto 
que possa ser demonstrado.
A Sprint Zero serve para:
• Criar o arcabouço do projeto;
• Manter o design mínimo (nada desnecessário ou vultuoso, apenas o simples 
e indispensável);
• Desenvolver um pequeno número de histórias do usuário até a conclusão;
• Ser de baixa velocidade e leve (nada de complexidade para desenvolver):
O principal objetivo de um Sprint Zero é a produção. Mas um Sprint 
Zero não é necessário para desenvolver tanto software intensivo quanto 
um Scrum Sprint. De fato, as Equipes da Sprint Zero devem mantê-lo 
leve, como mencionado acima. Mais especificamente, as entregas de um 
Sprint Zero devem ser as seguintes:
• Um pedaço de código utilizável, por menor que seja;
• Um ambiente mínimo para escrever código;
• Uma priorização de recursos ou uma lista de histórias;
• Um plano de lançamento atribuindo cada história a um Sprint;
• Um plano para a implementação mais provável de recursos.
Como a ênfase de um Sprint Zero é garantir a prontidão para um Sprint, 
algumas organizações ou projetos não precisarão incorporar essa abor-
dagem. Se sua empresa produz Sprints de sucesso em projetos recentes, 
você já deve conhecer sua situação de prontidão para Sprint sem realizar 
um Sprint Zero.
Assim como outros Sprints, o Sprint Zeros deve seguir as mesmas atividades:
• Backlog atualizado;
20
21
• A sessão de planejamento da Sprint segue ;
• Reuniões diárias da Equipe Sprint ;
• Sessões de revisão de sprint ou debrief ;
• Produto entregue ;
• Retrospectiva do Sprint .
O principal benefício de um Sprint Zero é que ele permite que uma Equi-
pe tenha uma ideia do trabalho à sua frente. Eles podem se auto orga-
nizar para ter um desempenho melhor a longo prazo. Isso também cria 
confiança nos membros da Equipe de que eles podem lidar com o traba-
lho que está por vir.
Diferentemente de outros Sprints, o Sprint Zeros não deve demorar mais 
que alguns dias; uma semana no máximo. (WATTS, 2018, p. 3)
Determinação do Tempo
da Sprint do Projeto
No Scrum, uma estimativa é um dos quatro atributos prescritos de um item do 
Backlog do Produto, assim como valor, descrição e ordem, além, é claro, da inclusão 
opcional de descrições de teste, principalmente, se você está trabalhando com TDD 
(Desenvolvimento Orientado por Testes) e XP (Programação Extrema). 
Mas não se iluda: o Dono do Produto determina o valor e, por outro lado, a com-
plexidade e o esforço são atribuições da Equipe de Desenvolvimento.
Portanto, cada item do Backlog do Produto deve possuir:
• Atributos de descrição;
• Ordem e/ou prioridade;
• Estimativa;
• Valor.
O Scrumguide (2017, p. 14) escreve que a Equipe de desenvolvimento, geralmen-
te, começa projetando o Sistema e o trabalho necessário para converter o Backlog
do produto em um incremento do produto em funcionamento.
Uma coleção de itens de backlog, quando postas para serem resolvidas dentro de 
um tempo determinado, é uma Sprint (corrida), sendo que as Sprints devem seguir 
certas regras, a saber:
• Metas de qualidade pré-determinadas devem ser mantidas;
• Depois que um Sprint começa, nenhuma alteração deve ser feita para impedir
que a meta seja atrasada ou concluída;
• O escopo só pode ser renegociado entre o Scrum Master e o Product Owner;
21
UNIDADE Revisão Ágil
• O Sprint deve ter entre 2 a 4 semanas de duração.
Além disso, cada Sprint aderirá a um padrão cíclico de ações:
• Backlog atualizado;
• A sessão de planejamento da Sprint segue:
• Reuniões diárias da Equipe Sprint;
• Sessões de revisão de sprint ou debrief;
• Produto entregue;
• Retrospectiva do Sprint.
Quando um sprint termina, o backlog é atualizado para que o processo inicie 
novamente atéque o desenvolvimento do software seja concluído e encerrado. 
Complexidade é um tema central no Scrum, pois ele foi projetado para ser apli-
cado em ambientes complexos, nos quais as pessoas lidam com problemas adapta-
tivos complexos. 
Seu valor está em fazer com que as Equipes possam otimizar a previsibilidade e 
controlar os riscos, baseadas nos pilares de transparência, inspeção e adaptação.
A complexidade tem como resposta no SCRUM o exercício da transparência 
quando temos que estimar. Senão, vejamos, segundo Nijland (2018, p. 3), sem trans-
parência dada pela Equipe durante a estimativa, o Dono do produto enfrentará difi-
culdades para solicitar o backlog do produto com eficiência. 
Além disso, o exercício de estimar é realmente mais valioso do que a estimativa 
resultante. Quando estimamos coletivamente, na verdade, estamos trabalhando para 
criar um entendimento compartilhado do que é conhecido na época sobre valor (que 
revela propósito) e complexidade. As Equipes que não se importam com a estimativa 
coletiva terão essa falta de transparência assombrando-as ao longo do desenvolvimento.
Figura 3 – Uma Equipe estimando coletivamente PBIs 
(Cartões de História para compor o Backlog do Produto) por meio do Planning Poker 
Fonte: Getty Images 
22
23
Uma das coisas que impactarão profundamente as estimativas que você 
fará quando participante de um time SCRUM diz respeito à complexidade. E ela 
pode se revelar de diversas formas quando vemos um cartão de história sobre a 
mesa de um jogo de planejamento com Plannig Poker, por exemplo. 
Uma variável importante para a complexidade é a dependência. Quando 
as dependências existem, mas não são conhecidas, ocorre o caos, mas quando 
conhe-cidas, revela complicações e complexidades. 
Nesse aspecto, quero lembrá-lo(a), caro(a) aluno(a), a que me refiro como dependência. 
Conforme um Sistema de Informação vai crescendo, mesmo quando de sua 
cons-trução, e as sprints vão se acumulando, devemos nos lembrar de que quando 
vamos resolver as complexidades dos cartões para compor a próxima sprint 
devemos olhar as dependências entre as histórias e resolvê-las, levá-las em 
consideração para que possamos compor um sprint backlog possível e correto. 
Quanto mais nos adapta-mos ao criar clareza sobre dependências, melhor será 
nossa tomada de decisão.
Melhor entenderemos o quão complicado é algo provável e quanto esforço 
pro-vavelmente estará envolvido. É por isso que a estimativa costuma ser um 
exercício coletivo, pois as Equipes de desenvolvimento são multifuncionais. 
As estimativas no SCRUM são abordadas, principalmente, sobre o que já 
aconteceu, portanto, isso pode ser utilizado para tomadas de decisão prospectivas.
Quanto mais pessoas envolvidas com um item do Backlog do produto, mais 
com-plicado ele é. Por isso você deve sempre se lembrar no início de nossa 
unidade de que SCRUM coloca Equipes de desenvolvimento de 5 até 9.
Nijland (2018, p. 5) explica que a tomada de decisão, quando estamos em 
Equipes grandes, gerará muita complexidade para que um Processo empírico seja 
útil, e usa como exemplo figuras geométricas (pessoas e linhas).
23
UNIDADE Revisão Ágil
Figura 4 – Relação de complexidade versus membros da Equipe
Fonte: WENBIN, 2017, p. 1 
Como o diagrama acima ilustra, quanto mais pessoas envolvidas com um 
item do Backlog do produto, mais complicado ele é. Outra consideração 
para determinar a complexidade é o nível de consistência. A consistência 
reduz a complexidade e otimiza a previsibilidade. É por isso que é importan-
te manter os intervalos, locais e caixas de tempo dos eventos consistentes.
Trabalhar em ciclos consistentes permite que uma Equipe SCRUM avalie suas 
atividades dentro desses ciclos e detecte certos padrões e tendências.
Uma Equipe SCRUM poderia, por exemplo, acompanhar quanto tempo gasta no 
trabalho que eles não haviam previsto. Isso pode envolver a resposta à complexidade 
inesperada, mas também à mudança de prioridades, pois a Equipe ou o cliente des-
cobre algo novo de alto valor. 
Bem, como o valor e a complexidade dos itens do Backlog do Produto são esti-
mados, isso deve ser acompanhado de uma inspeção do que realmente aconteceu. 
Assim, mantemos a consistência e fazemos os ajustes às mudanças, quando pós 
executado, recalibrando a expectativa. 
E aqui vai uma reflexão para você!
Não escrevemos nesse texto sobre estimativas no SCRUM, uma linha sequer, 
 sobre cronogramas elaborados, diagramas de sequência, PERT/CPM, Gantt, cálcu-
los de rede PERT tentando dizer quanto tempo dura cada etapa, cada tarefa. 
Para SCRUM, a unidade de tempo e de produção nesse tempo é chamada 
SPRINT, e ela pode variar de 1 semana de trabalho até 4 semanas cada iteração.
24
Veja:
25
Não interessa se dentro dessa sprint existam 3 tarefas ou 10 tarefas, o que inte-
ressa é que, por exemplo, em 1 semana, todo o trabalho estimado para aquela sprint
tenha sido executado, testado, validado e entregue com valor agregado ao cliente. 
Simples assim.
SCRUM permite que, em intervalos regulares, a Equipe reflita sobre como se tornar 
mais eficaz, depois ajusta e ajusta seu comportamento de acordo com o necessário.
Nijland (2018, p. 8) expõe da seguinte maneira: o Daily Scrum não serve para 
ensinar as Equipes a seguir o plano, mas para fazer alterações à medida que mais for 
aprendido durante a execução daquela Sprint. 
A revisão e as retrospectivas da Sprint servem para permitir que a Equipe revele 
o progresso e os aprendizados reais de forma consistente.
Eles ensinarão a Equipe a agir de acordo com as experiências e as descobertas 
reais, em vez das projeções desejadas.
Por fim, em ambientes complexos, sempre haverá incerteza. Poderíamos dizer 
que o aumento da incerteza é igual ao aumento do risco. Dito isso, também existe o 
risco de assumir a certeza, o que normalmente, nesse tipo de, irá nos levará inevita-
velmente ao desastre. 
Até porque, quanto mais garantidos nos sentimos, menos preparados e abertos 
estaremos para responder com ideia novas e criativas.
Dessa forma, a incerteza de algo acaba por nos tornar melhores em lidar com 
incertezas dos negócios e dos Sistemas de Informação que os refletem.
Como resolver um problema de estimativa relacionado a um alto grau de incerte-
za, portanto, risco? 
Aproprio-me de uma atitude importante que vem do XP – Programação Extrema. 
Quando uma dificuldade técnica ameaça atrasar o desenvolvimento do Sistema, 
por exemplo, coloque um par de desenvolvedores no problema por uma semana ou 
duas e reduza o risco potencial para, quando chegar a hora, estarmos preparados. 
Isso funciona se esse pessoal for sênior, principalmente:
As Equipes costumam usar um número estimado relativo de complexida-
de e, em seguida, medem o total de quanto eles são capazes de concluir 
cada Sprint. Esta não é uma prática prescrita ou mesmo recomendada. 
A experiência nos ensinou que estes podem ser facilmente abusados, pois 
o gerenciamento organizacional pressiona as Equipes a aumentar sua ve-
locidade. Alguns até (de maneira um tanto ingênua) estabelecem metas 
para as Equipes aumentarem sua velocidade em x % durante um perío-
do de tempo. Algumas organizações simplesmente contratam um “Scum 
Master” para esse fim. A velocidade é frequentemente medida no total de 
Story Points entregues. Os Story Points são indicadores de complexidade 
e esforço. ELES NÃO REPRESENTAM VALOR. Portanto, eles não re-
25
UNIDADE Revisão Ágil
presentam o valor que está sendo entregue, apenas a complexidade sen-
do resolvida. Atletas profissionais passam muito tempo treinando como 
aperfeiçoar uma jogada aparentemente simples. Muito esforço é feito para 
tomar pequenos passos / ações, para que sejam feitos da maneira certa. 
Isso também envolve um aprendizado que não se move. Isso pode levá-los 
a um início aparentemente lento, mas o configura para aceleração rápida. 
No Scrum, as tentativas de apressar uma Equipe os desacelerarão, per-
mitindo que eles tomem o tempo necessário paradar pequenos passos 
certos, em incrementos pequenos, mas frequentes, os acelerará.
A necessidade do controle de produção através de folhas de apontamento 
está martelando a falta de confiança e envolvimento. Se a alta gestão quer 
saber como os desenvolvedores estão se saindo (e se estão realmente tra-
balhando nas coisas certas), devem trabalhar com eles (sim, é inadmissível 
no meio de TI um gerente não saber as rotinas produtivas, codificar por 
exemplo), inspecionar seu trabalho real ou confiar que eles farão seu tra-
balho corretamente, como eles fazem. (NIJLAND, 2018, p. 9)
O Scrumguides (2017, p. 10) descreve que a Equipe de Desenvolvimento é 
responsável por todas as estimativas. 
O Dono do Produto pode influenciar a Equipe de Desenvolvimento, ajudando-a 
a entender e selecionar trade-offs, mas as pessoas que executarão o trabalho fazem 
a estimativa final. 
Embora o Lean, o Agile e o DevOps tenham origem nas Equipes de Desenvolvi-
mento de Software, não são apenas essas Equipes que podem usá-los. 
As práticas Lean e Agile podem beneficiar todos os Departamentos de uma Or-
ganização. 
Devido às suas características, é mais provável que o DevOps seja usado nos 
Departamentos de TI, mas não há restrições quanto ao tipo de Departamento 
que pode adotar e usar o DevOps. 
Resumo Lean
Refere-se a um conjunto de conhecimentos chamado de Lean Manufacturing, 
ou Manufatura Lean, desenvolvido no Japão, nas décadas de 50 e 60 do século XX, 
por um engenheiro chamado Taiichi Ohno. 
O Lean transformou muitos conceitos tradicionais, como:
• A produção deve ser baseada na demanda e não na oferta. Trata-se, portanto,
de fazer algo quando alguém deseja e ordena, em vez de fazê-lo primeiro, espe-
rando que alguém precise;
26
27
• A produção é mais eficiente se realizada em pequenos lotes para aproveitar as 
economias de escala;
• Reservar um tempo para se concentrar na qualidade também aumenta a produ-
ção e a eficiência;
• Trabalhadores, não Gerentes, são responsáveis por definir sua maneira de trabalhar.
• Em vez de executar tarefas predefinidas repetidas vezes, os trabalhadores 
devem melhorar continuamente a maneira como trabalham com o Kaizen 
ou melhoria contínua.
A metodologia Lean diz para eliminar implacavelmente tudo o que não agrega valor. 
Eliminar o desperdício significa eliminar reuniões, tarefas e documentação des-
necessárias, mas também eliminar formas ineficientes de trabalho. A metodologia 
Lean também coloca uma ênfase muito forte no que chama de “sistema”, isto é, 
como a Equipe opera como um todo.
Essa metodologia alega respeitar o fato de que as pessoas que fazem o trabalho 
são as que sabem como fazê-lo melhor. Depois de oferecer a eles o que eles preci-
sam para ser eficazes, você deve deixá-los fazer isso e confiar neles. Além disso, algo 
muito importante tanto em Lean quanto em Ágil em geral é que as pessoas/traba-
lhadores que executam as tarefas são mais importantes do que as ferramentas que 
usam, e criar valor para o cliente é o único objetivo do processo de desenvolvimento.
SDLC usando LEAN para desenvolver software. Disponível em: https://bit.ly/3p0Hybi
27
UNIDADE Revisão Ágil
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Scrum – Aprenda Scrum em 9 minutos
https://youtu.be/XfvQWnRgxG0
Os Papéis do Scrum
https://youtu.be/9__bzr_lX88
Extreme Programming (XP) – Programação Extrema
https://youtu.be/ALvpFMcL-dI
Lean Software Development – Princípios
https://youtu.be/6HtpkqHswFw
28
29
Referências
BERTEIG, M. Cada Sprint é do mesmo Comprimento. 2013. Disponível em: 
<http://www.agileadvice.com/2013/05/15/referenceinformation/the-rules-of-
-scrum-every-sprint-is-the-same-length/>. Acesso em: 20/01/2020.
MERSINO, A. Sucesso com Scrum: não quebre estas 7 regras. 2018. Disponí-
vel em: <https://pmi-portland.org/news-and-content/758-7-rules-of-scrum>. Acesso 
em: 20/01/2020.
NIJLAND , S. Estimativa. 2018. p. 1-9. Disponível em: <https://medium.com/
serious-scrum/estimation-103de626551e>. Acesso em: 20/01/2020.
WATTS, S. O que é o Sprint Zero? 2018. P. 2-4. Disponível em: <https://www.
bmc.com/blogs/sprint-zero/>. Acesso em: 20/01/2020.
WENBIN, J. H. Construindo Equipes eficazes, o principal desafio é lidar com 
a complexidade das comunicações. 2017. p. 1. Disponível em: <https://john-
sonwongvp.wordpress.com/2017/10/11/building-effective-teams-main-challenge-is-
-dealing-with-the-complexity-of-communications/>. Acesso em: 20/01/2020.
Sites Visitados
AGILE ALLIANCE. Essenciais Ágeis. 2019. Disponível em: <https://www.agi-
lealliance.org/glossary/team/#q=~(infinite~false~filters~(postType~(~’page~’post
~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_
paper~’aa_video)~tags~(~’team))~searchTerm~’~sort~false~sortDirection~’asc~pa
ge~1)>. Acesso em: 20/01/2020.
________. O que é Agile? 2019. Disponível em: <https://www.agilealliance.org/
agile101/>. Acesso em: 20/01/2020.
SCRUMGUIDES. Alterações entre os Guias Scrum de 2016 e 2017. 2018. 
p. 1. Disponível em: <https://www.scrumguides.org/revisions.html>. Acesso em: 
20/01/2020.
 ________. Guia SCRUM. 2017. p. 10-14. Disponível em: <https://www.scrum-
guides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf>. 
Acesso em: 20/01/2020.
29
Desenvolvimento Ágil
Responsável pelo Conteúdo:
Prof. Me. Artur Marques
Revisão Textual:
Mateus Gonçalves Santos
Planejamento Ágil 
Planejamento Ágil
 
 
• Aplicar técnicas de engenharia de requisito ágil na construção dos artefatos de história do 
usuário para gerar o PRODUCT BACKLOG
OBJETIVO DE APRENDIZADO 
• Introdução; 
• Definição de Escopo e Regras de Negócios Ágeis;
• Cartão de História do Usuário;
• Escrita Baseada em Story Cards (Épicos, Temas e Histórias);
• Criação de Product Backlog;
• Definição das Sprints e seus Conteúdos;
• Planning Poker para Determinar Complexidade com Cartões de Fibonacci.
UNIDADE Planejamento Ágil 
Introdução 
Vamos, a partir dessa unidade, trabalhar com o conceito e com a prática SCRUM 
através da construção guiada de artefatos de engenharia de sistemas. Nessa parte, tra-
balharemos com o planejamento ágil para que você entenda de onde vêm as “coisas” 
que serão utilizadas e como esse mosaico permite a visão geral, o controle e a visão 
micro da atividade, ou seja, onde o trabalho é realizado por alguém da equipe SCRUM.
Além disso, os exemplos são práticos na abordagem que faço com minhas equi-
pes de desenvolvimento e elas têm tido bastante êxito em terminar o que começaram 
com baixo número de alterações por mau entendimento de requisitos. Portanto, é 
algo que funciona, e você pode seguir e treinar os exemplos, pois são todos práticos, 
tirados de meus projetos.
Mas antes de entrarmos no escopo ágil, vamos entender a visão do produto no 
SCRUM, afinal, é de onde vem o trabalho que faremos na equipe SCRUM. 
Acesse Visão do Produto no SCRUM, disponível em: https://youtu.be/vg1S1WYZa6o
Definição de Escopo e 
Regras de Negócios Ágeis
Dentro das práticas de processos ágeis temos, como em todo processo, um início, 
uma demanda ou uma necessidade oriunda de um cliente que precisa de um sistema 
de informação a fim de melhorar seu processo, para que este possa gerar maior va-
lor percebido para quem utilizará ou sofrerá as consequências de seu funcionamento. 
Bom, isso começa necessariamente com uma declaração de escopo onde o cliente 
normalmente passa as informações necessárias para o desenvolvimento do sistema. 
A forma com que o escopo aparece em um projeto ágil normalmente é através das 
histórias dos usuários. 
Normalmente numa equipe ágil o dono do produto (product owner) é que recebe 
as histórias advindas dos usuários principais do cliente na forma de histórias.
Porém, se você já teve algum contato com o Guia Scrum, aqui em português, 
saberá que ele não menciona histórias de usuários. Há o Backlog do produto, a 
lista priorizada de tudo o que é conhecido e necessário no produtoque se deseja. 
Bem, essas listas são compostas de dezenas, às vezes centenas de histórias do 
usuário, que são as entradas individuais na lista, os itens do Backlog do produto. 
Eles estabelecem o que a equipe Scrum criará no software.
Guia do Scrum, disponível em: https://bit.ly/2HYHZSo
8
9
Então, podemos entender que o Backlog do produto nada mais é do que 
o Escopo do Projeto que antigamente usávamos nos projetos tradicionais, por 
exemplo, usando Waterfall (Cascata). Sim, é isso. 
 Assista ao vídeo “Anti-padrões da Agilidade: Product Backlog como Documento de Es-
copo ” disponível em: https://youtu.be/bQGWn7M8DVc
Então, e sses itens do Backlog do produto podem incluir requisitos, casos de uso, 
especificações, correções de erros ou tarefas de manutenção. Porém, a maioria dos 
projetos Scrum opta por histórias de usuários, porque elas s ão uma ótima maneira 
de manter o cliente em mente e ajudar os proprietários do produto a maximizar o 
valor que será entregue.
E claro, as pessoas que escrevem as histórias dos usuários seguem um processo 
que, de um modo geral, se parece com um ciclo de vida e tem algumas etapas que 
sugiro a você segui-las para fazer com perfeição.
Quadro 1
Rascunho Inicial
É a primeira coisa para a captura da história. Isso segue o bom e velho 
script: "Como um [ator x], eu quero [satisfazer uma necessidade y], para 
que eu possa [objetivo z para satisfazer a necessidade y]". Às vezes, é 
preciso algumas interações para corrigir isso, ou seja, deixar coerente
Defi nir critérios de 
aceitação inicial
Depois que tivermos a história, podemos definir os critérios de aceitação 
- isso pode incluir alguns designs, wireframes, mockups levando em consi-
deração aspectos de UX – Experiencia do Usuário, necessidades especí-
ficas de desempenho (RNF – requisitos não funcionais) ou casos de uso.
Revisar a história com 
as partes interessadas 
e atualizar, 
se necessário
Muitas pessoas simplesmente publicam histórias sem nenhuma revisão 
com as partes interessadas (clientes, usuários, etc). Esse papel cabe ao 
dono do produto, pois é uma etapa de feedback essencial para garantir 
que a história do usuário, conforme escrita, realmente descreva a solu-
ção desejada. Portanto, revise e dimensione a história com a equipe de 
desenvolvimento e atualize, se necessário.
Depois que tivermos a 
história revisada
Precisamos garantir que seja convergente (partes interessadas e time 
de desenvolvimento SCRUM), daí jogamos o plannig poker, por exemplo, 
para obter um tamanho aproximado da história. Uma a uma.
Priorizar a história na 
lista de pendências
Para fazer isso, o dono do produto deve entender a prioridade dos negócios 
e a complexidade técnica da história. Sem isso, teremos problemas futuros.
Revise a história 
durante as sessões 
de preparação
A história permanecer na lista de pendências por um período significati-
vo, é provável que fique "obsoleta" e precise ser revisada e possivelmente 
reestimada. É exatamente para isso que servem as sessões de preparação.
Planejamento 
do Sprint
Quando chegar a hora, colocaremos a história em um sprint durante o pla-
nejamento, garantindo um mergulho mais profundo do que qualquer es-
forço anterior para garantir que a equipe entenda completamente o que 
lhes está sendo pedido e o que está sendo feito, esperado para entregar.
Re visão do Sprint
No final do sprint, rev isar a história do usuário, isso a equipe de desen-
volvimento SCRUM faz com o dono do produto e outras partes interes-
sadas. São feitas anotações para ver quais melhorias ainda precisam 
estar na lista de pendências.
9
UNIDADE Planejamento Ágil 
Esse ciclo de vida é normalmente seguido dessa forma.
Então, vejamos, quem pode escrever histórias do usuário num cartão e entregar 
para o Dono do Produto as juntar e, de acordo com o valor delas, criar prioridades 
para se fazer e gerar entregas importantes:
• O próprio usuário quando ele sabe disso;
• O dono do produto (mas não é responsabilidade dele escrever todas, mas, se ele 
puder colaborar, isso será ótimo);
• Os membros da equipe SCRUM;
• Clientes e partes interessadas que serão impactadas pelo sistema.
Pode acontecer que todo esse pessoal acima esteja com dificuldades em algum 
aspecto de escrita de uma ou outra historia. Bem, pense em algum usuário que pode 
ajudar “contando essa história, sobre esse aspecto ou tópico específico”.
Nesse caso, vá e pergunte a ele se ele pode formular um item de lista de pen-
dências de produtos para você (história do usuário). Nessa situação, pode ajudá-lo a 
usar a sintaxe da história do usuário juntamente com algum suporte. O método das 
3 perguntas pode se mostrar útil nesse caso:
• Quem quer isso?
• O que esse usuário deseja?
• Por que esse usuário quer isso? 
Se um usuário puder responder a essas três perguntas, ele realmente pensou nes-
se requisito e pode explicar concretamente o que deseja e por que isso o ajudaria. 
Nosso trabalho como equipe Scrum é entender isso ou ajudar os usuários a respon-
der a essas perguntas. 
Vamos lembrar o que é uma história de usuário e vamos escrever algumas na sequ-
ência, assim você vai se preparando.
Primeiramente, os requisitos do produto são histórias de usuários, preparadas 
para se fazer as estimativas de desenvolvimento e contêm alguns elementos extras, 
por exemplo, nome dos recursos, detalhes, prioridades e a justificativa, esta última 
não é não obrigatória, mas bastante recomendada, porque ajuda a equipe de desen-
volvimento a entender melhor o motivo por trás da funcionalidade declarada.
Exemplo de construção de uma história do usuário extraída de uma entrevista 
com um usuário. Do autor.
Cartão de História do Usuário
Quadro 2
Nome Visualizar calendário;
História Como médico, quero ver meu calendário de consultas para saber quando os pacientes estão chegando;
10
11
Detalhes
O médico deve ver todas as consultas - desde o início dos tempos e 
para o futuro. Por padrão, o calendário deve exibir a semana atual 
com a opção de navegar entre semanas e meses;
Justifi cativa
É uma funcionalidade básica em todos os produtos concorrentes; 
com base em pesquisas, essa experiência é esperada pelos usuá-
rios, é necessária para a integração do compromisso;
Prioridade 1
Cuidado aqui! O dono do produto deve priorizar as histórias, por isso, no item prio-
ridade, está o número 1, por exemplo. Quer dizer que ela é importante. Ele também 
poderá, se for o desejo, agrupá-las em conjuntos lógicos para um plano de liberação.
Quanto a equipe SCRUM que realizará o desenvolvimento, fará perguntas ao 
dono do produto sobre cada história e obterá mais informações sobre o que ela ten-
tará realizar. Assim, os critérios de aceitação serão mais claros e até refinados, isso 
vai durante o jogo do planejamento (mais adiante) a fornecer um tamanho relativo, 
uma estimativa em pontos de complexidade, por exemplo. 
Eles podem dividir as histórias em histórias menores (caso uma história seja muito 
complicada) para que possam ser feitas dentro de um sprint (quando for o momento 
de planejar a sprint).
Mas como estamos no começo, vamos fazer uma sequência de histórias de usu-
ários advindas de uma reunião com usuários. Assim, você percebe que podemos 
variar os padrões e até mesmo criar os nossos e ir treinando.
Quadro 3
Cadastro de 
usuário
Como cliente, eu quero poder me cadastrar no site para que possa ter con-
trole das minhas compras ou /e vendas.
Critérios de 
aceite
• Todo usuário cadastrado no primeiro momento é um usuário comum ;
• Somente um administrador poderá mudar o seu tipo de usuário;
• Para cancelamento da conta, o usuário poderá realizar em sua própria 
conta ou solicitando através de um E-mail para contato.
Editar dados de 
cadastro
Como cliente, preciso poder editar minhas informações pessoais para atu-
alização dos meus dados. 
Critérios de 
aceite
• O usuário terá acesso a seus dados e poderá editar a qualquer momento;
• O sistema deverá dar a opção para escolher entre tipo físico ou jurídico;• Todos os campos serão obrigatórios;
• Após atualização, uma mensagem de confirmação de dados editados 
será mostrada.
Alterar senha 
e e-mail
Como cliente, preciso ter a opção para editar/atualizar senha e e-mail
caso ache necessário ou a perca.
Critérios 
de aceite
• O Sistema terá campos com opção para visualizar senha e 
e-mail atual;
• Campos para confirmar a senha e e-mail novos.
11
UNIDADE Planejamento Ágil 
Contato Como usuário, eu preciso ter uma página para que possa entrar em contato com a livraria e retirar possíveis dúvidas.
Critérios 
de aceite
• É necessário ter tópicos pré-definidos: problemas técnicos, vendedor, en-
trega etc. para facilitar o atendimento ao usuário;
• O sistema deverá montar um e-mail através desses campos obrigatórios e 
enviar para o e-mail próprio da livraria;
• O usuário também receberá sua resposta através do seu 
e-mail pessoal.
Nos exemplos de histórias acima, temos um elemento útil inserido, o critério de 
aceitação que ajuda em muito no entendimento pelo time de desenvolvimento, bem 
como pode ajudar a equipe a criar testes que garantirão os requisitos e as regras a 
eles impostas.
Figura 1 – Exemplo de Template de Storycard usado em projetos de software
Fonte: Acervo do conteudista
Esse modelo de template é muito útil porque permite que uma vez conheci-
da a história e acrescentadas algumas regras importantes do usuário, algu-
mas sequencias e casos de uso já podem ser imediatamente imaginados e 
enriquecendo o cartão de história do usuário. Muito útil para quando formos 
fazer o planning poker. Portanto o time SCRUM já começa a entender as 
partes e um pouco mais do negócio/processo. Importante o dono do pro-
duto estar atento a isto!
O exemplo da figura acima torna um pouco mais organizadas as histórias e você 
pode organizá-las, inclusive em uma tarefa do TRELLO para depois ter um backbone 
de histórias e criar um gráfico de afinidade dessas histórias, isso facilita a vida do dono 
do produto além de auxiliar visualmente a equipe sobre a geral do projeto.
12
13
Escrita Baseada em Story Cards
(Épicos, Temas e Histórias) 
Bom, creio que escrever histórias de usuário seja uma arte, porém um artista 
pode e deve se desenvolver. Muitos de nós não nascemos prontos, mas aprendemos 
e, em alguns casos, nos tornamos melhores que os que já possuem o dom. A ideia 
aqui é explicar para você que devemos seguir um princípio, cujo acrônimo em inglês 
é INVEST, para termos maiores chances de sucesso em nossa escrita. 
Esse acrônimo ajuda a lembrar um conjunto de critérios ou lista de verificação 
amplamente aceito para avaliar a qualidade de uma história de usuário. Se a história 
falhar em atender a um desses critérios, a equipe poderá reformulá-la ou, até mesmo, 
reescrevê-la. Bom, minha experiencia de 32 anos trabalhando com projetos tradi-
cionais e ágeis sempre se traduz em rasgar fisicamente o cartão de história antigo e 
escrever um novo, de forma descente e inteligível.
Uma excelente história do usuário deve ser:
• Independent (independente): independente de todas as outras histórias, é fun-
damental para poder priorizar, adicionar e remover histórias de um release ou 
de um plano de iteração como unidades únicas. As histórias devem ser atômi-
cas, para que possam ser iniciadas e finalizadas isoladamente de outras como 
uma transação de banco de dados. Geralmente, essa integridade é alcançada ao 
definir uma história como uma fatia vertical de um aplicativo, um recurso que 
abrange a camada do banco de dados, o modelo de domínio e a interface do 
usuário ao mesmo tempo ;
• Negotiable (negociável): negociável, você deve ver a definição original da his-
tória como um lembrete para uma discussão com o cliente ou o especialista em 
domínio sobre esse recurso. O que posso lhe dizer sobre alguém que te entrega 
um documento de especificação de 20, 30 ou sei lá quantas páginas, tentando 
especificar tudo, não é um documento de nada, apenas mais um pedacinho de 
caos na sua vida, portanto, esse documento também não é uma história. A his-
tória tem que capturar a essência disso que deve ser feita, por quem e por que 
deve ser feita. Tudo o que não é necessário para priorizar e programar iterações 
não é necessário inicialmente ;
• Valuable (valiosa): Para que serve esta história? É realmente necessária? Além 
disso, é valiosa para o cliente ou isso só serve para desenvolvedores? CUIDADO! 
Adicionar campos a uma tabela de banco de dados sem mostrá-los, por exemplo, 
não é uma história, pois não tem valor para o cliente em si e talvez seja uma ta-
refa inútil, eu disse talvez. Se tiver que pôr, no exemplo que dei, as modificações 
necessárias no banco de dados da aplicação, estas devem ser incluídas em uma 
história valiosa, ou muitas delas ;
• Estimable (estimável): Somos humanos e, portanto, não somos bons em lidar 
com uma gama de valores, principalmente os que envolvam estimativa que 
13
UNIDADE Planejamento Ágil 
abrangem mais do que uma magnitude, como no caso de histórias dos usuários. 
Normalmente, as histórias são estimadas em pontos de complexidade, pontos 
de história ou horas ideais, onde a faixa de valores ao longo do início da sequ-
ência de Fibonacci, se você jogar PLANNING POKER, onde cada termo é a 
soma dos dois anteriores e colocar isso num “baralho”. Bom, veremos o jogo do 
planejamento mais adiante, enquanto isso tenha em mente:
 » Quando uma história é muito grande, você deve dividi-la em histórias mais 
simples ou em uma história de exploração de pico com um limite de tempo 
fixo mais outro para estimar após o pico;
 » Quando uma história é muito curta, você pode agrupá-la com outras pequenas 
histórias ou incluí-la em uma das outras. Não apenas o tamanho de uma história 
influencia a estimativa, mas também o entendimento dos desenvolvedores sobre 
o que é necessário para concluir a história.
• Small (pequena): Quanto mais histórias estiverem perto do início da fase de 
desenvolvimento, mais elas devem ser mantidas pequenas, mesmo que você 
tenha que dividir em partes independentes depois. A característica “pequena” 
está relacionada à estimativa, portanto as histórias menores são mais fáceis de 
gerenciar, estimar e compor;
• Testable (testável): Os testes de aceitação geralmente são escritos no verso do 
cartão, quando usamos cartões de fichamento. Os testes são escritos em uma 
definição de linguagem natural, pois o código não caberia em um cartão. Você 
tem alguns exemplos de critérios de aceitação nas histórias nesse mesmo texto. 
Se uma história não for testável, repense-a ou você nunca terá uma definição de 
concluído (DONE) em seu desenvolvimento. Concluído é quando todos os testes 
de aceitação são aprovados. Bem, aqui eu peço que você use ferramentas de 
automação de testes, porque são muitos que deverão ser realizados.
Mas há mais que isso. Há histórias enormes, histórias grandes e histórias do usu-
ário. Certo, você não entendeu, não é? Então, vejamos...
Quando falamos de histórias realmente enormes, falamos de THEME (Tema). 
Trata-se de um grupo de histórias de usuários que compartilham um atributo comum 
e, por conveniência, são agrupados. Lembra-se do gráfico de afinidade que mencio-
nei? Ele vai ter uma atividade enorme daqui a pouco. As histórias de usuários indi-
viduais, no entanto, podem ser realizadas em um único sprint. Por exemplo, você 
pode ter três histórias de usuário diferentes que são todas atividades relacionadas ao 
carrinho de um e-commerce. Elas compartilham um canal comum de comunicação 
(um eixo, se preferir) e podem ser agrupadas como um Tema. 
O que é importante você notar para o Tema é que cada uma das três histórias 
de usuários possui uma meta final diferente e critérios de aceitação e públicos ou 
usuários diferentes. Todavia, não puderam ser escritas como uma única história de 
usuário. Veja só, elas não são épicas!
A palavra "Épico" deve nos dizer que é de amplo alcance. Assim como uma saga 
épica, ou um épico de Homero. Um filme ou história épica podeter vários temas. 
14
15
E dentro desses temas pode haver sequências dramáticas individuais ou eventos. É 
exatamente assim no desenvolvimento ágil de sistemas. Uma descrição épica e de 
alto nível consiste em vários temas, cada um contendo muitas histórias de usuários, 
cada uma com muitos cenários que podem ser construídos e testados usando uma 
variedade de dados de teste.
Se você pensa em funções tradicionais de uma organização, por exemplo, na área 
financeira, onde temos o contas a receber, onde temos as pessoas que controlam 
os recebimentos, os que mandam negativar os maus pagadores ou os que reconci-
liam os pagamentos recebidos de cartões de crédito de diversas bandeiras, e agrupa 
histórias de usuários por essas funções, elas certamente serão temas. Tudo o que o 
analista financeiro de reconciliação faz, por exemplo, é um TEMA.
 Conforme escritos do LUNA (2019 ), em algumas situações, uma “história de 
usuário” pode ocupar mais de uma sprint para se resolver e, em determinados ce-
nários, será realmente difícil saber quando aquela funcionalidade ficará disponível 
para ser utilizada pelo usuário. Por conta disso, você chama essas histórias de épi-
cos, nela a funcionalidade está concentrada integralmente, mesmo com múltiplas 
histórias a compondo.
Em resumo:
• Um Tema é uma coleção de histórias de usuário relacionadas. Ele fornece 
uma maneira conveniente de indicar que um conjunto de histórias que tem 
algo em comum, como estar na mesma área funcional; 
• Um tema corresponde a grandes grupos de valor de negócios que os clientes 
precisam e podem entender;
• Um tema geralmente corresponde ou possui um ou mais épicos.
Um épico é um contêiner lógico de histórias que podem ser agrupadas por recur-
so e função ou por qualquer outro critério comum que o dono do produto decida. 
Veja os exemplos que mostro nessa prática de como perceber um épico e juntar as 
histórias satélites a ele.
• Epic: Upload (carga de arquivo) para um álbum de fotos ;
• User Story: Como usuário, quero subir minhas fotos para que fiquem salvas na nuvem ;
• User Story: Como usuário, quero subir múltiplas fotos de uma única vez para 
que fiquem salvas na nuvem rapidamente ;
• User Story: Como usuário, quero nomear o meu álbum para que eu possa en-
contrá-lo facilmente ;
• User Story: Como usuário, quero remover uma foto do meu álbum para que 
mantenha o álbum organizado ; 
• User Story: Como usuário, quero remover meu álbum para que ele não esteja 
mais disponível na nuvem (LUNA, 2019, p. 1).
O ponto de atenção aqui não está em descobrir um épico e agregar as histórias, 
o erro está em não fechar o escopo disso. Ou seja, se continuarmos descobrindo 
15
UNIDADE Planejamento Ágil 
histórias sem fim e inserindo no épico vai ficar realmente muito complicado você ter-
minar a funcionalidade, por exemplo. E vai ser doloroso você explicar ao seu cliente 
que essa “sprint” não tem fim...
“Por exemplo, o item acima, onde colocamos 5 Histórias do usuário para 1 Epic. 
Ao longo do processo, poderíamos ainda inserir:
• User Story: Como usuário, quero reorganizar minhas fotos no meu álbum para 
que ele fique mais organizado;
• User Story: Como usuário, quero remover múltiplas fotos do meu álbum para 
que mantenha o álbum organizado rapidamente;
• User Story: Como usuário, quero reorganizar meus álbuns para que eles fiquem 
mais organizados (LUNA, 2019, p. 1).
Concorda que a tendência é que esse escopo continue aberto e que mais cartões 
sejam adicionados. Pois é, evite isso, é um erro grave. Deixe claro o escopo do épico 
e feche, encerre isso e vai para próxima. Coloque num backlog se elas aparecerem e 
forem realmente necessárias. Você vai encaixando nas sprint caso haja ociosidade ou 
implementa quando for o tempo permitido, portanto, evite, mas se não der, negocie.
Figura 2 – Quebra de Tema, Épico e Histórias do Usuário (hierarquia) 
Fonte: Acervo do conteudista
Se você acompanhou a imagem acima, deve ter percebido que podemos dizer 
que um épico é algo “parecido” com um Módulo. Aqui vem um conceito importante 
para você não esquecer:
“Geralmente temos um sistema e esse sistema é dividido em módulos, que agrupam 
funcionalidades (geralmente disponíveis através de interface gráfica).
Uma Feature faz parte de um Módulo, e possui seus Requisitos Funcionais e suas 
Regras de Negócio.
Uma User Story é uma função da Feature, e está associada a ela. Equivale aos Requi-
sitos Funcionais de uma interface gráfica, por exemplo.
Requisitos Não Funcionais geralmente atendem/suportam mais de um Requisito 
Funcional ou funcionalidade do sistema” (VENTURA, 2019, p. 1).
16
17
Exemplo de estrutura EPIC X FEATURE e a correlação entre os artefatos “novos e antigos”. 
Disponível em: https://bit.ly/3kJinrc 
“Se o processo for ágil, tem que usar história de usuário, senão não é ágil”. 
Na realidade, nem existe desenvolvimento ágil. Agilidade é mindset! E este 
mindset vai muito além da produção de software, se aplica até a clínica 
veterinária, por exemplo. (VENTURA, 2019, p. 1) 
Nessa altura, é importante que você saiba que histórias do usuário vieram do 
“amigo” inseparável do SCRUM, o XP (programação extrema).
Bom, já falamos e fizemos histórias de usuários suficientes, não é mesmo? Veja 
como fica a conformação nesse excelente diagrama de classes, assim creio que 
as dúvidas terminarão.
Theme
Epic Feature User Story
Task
Realizado por
1
1
1..*
1..* 1
1
1..*
1..*
Realizado por Realizado por
Realizado por
Figura 3 – Relação de realização entre os artefatos
 O relacionamento entre os artefatos é: 1 Theme (tema) é realizado por 1 ou 
muitos Epics (épicos); 1 Epic (épico) é realizado por 1 ou muitas Features
(funcionalidades); 1 Feature (funcionalidade) é realizada por 1 ou muitas 
User Stories (histórias do usuário) onde, 1 User Story (história do usuário) é 
realizada por 1 ou muitas Tasks (tarefas) (VENTURA, 2019, p. 4).
Criação de Product Backlog
A base para um projeto Scrum bem executado é o Backlog do Produto. O 
Backlog do produto de ve ser composto de histórias do usuário. Ele deve ser 
priorizado pelo valor comercial e ter sido estimado pela equipe usando pontos da 
história, durante o jogo do planejamento. Um elemento chave no sucesso de um 
projeto Scrum é garantir a quantidade certa de detalhes para a quantidade certa 
de itens do Product Backlog.
A quantidade de detalhes necessários para descrever os itens no Backlog do 
Produto e as decisões sobre o uso de histórias de usuários ou casos de uso depen-
de realmente da Equipe Scrum. Não tenha medo de discutir com a equipe Scrum
17
UNIDADE Planejamento Ágil 
quantos detalhes eles precisam, isso melhorará o resultado e seu relacionamento 
com a equipe Scrum. Claro, se você for um usuário ou um membro da equipe, não 
interessa, pergunte!
O Backlog do Produto é de responsabilidade do dono do produto e o quão bem 
foram definidos os itens do Backlog do Produto, haverá uma relação direta com o 
sucesso do projeto. Um Backlog bem definido economizará tempo, dinheiro e con-
tribuirá diretamente para o sucesso do projeto.
OK, você precisa desenvolver o Backlog do produto para um projeto e não sabe 
por onde começar... Certo, sem problemas, faça o seguinte que é garantido que 
vai funcionar:
• Escreva uma lista de recursos/histórias (caso você seja parte da equipe de usuários), 
mas se você é o dono do produto (é sua função às vezes até mesmo escrever a lista 
em empresas menores ou desestruturadas infelizmente), bem, você vai receber a lis-
ta das “coisas” que precisam ser entregues para o projeto ser um pretenso sucesso;
• O dono do produto deve priorizar os recursos pelo valor comercial;
• O dono do produto vai passar um plano de release para os recursos, ou seja, 
quais ou quantos recursos devem ser agrupados em um release (versão) e quando 
eles precisarão ser entregues;
• O dono do produto também propõe uma seleção de itens da lista de pendências 
do produto (backlog do produto) para alguns Sprints e, em termos comerciais,descreva qual é o resultado desejado para cada recurso;
• Organize uma reunião com a Equipe Scrum para discutir cada um dos itens de-
finidos no Backlog do produto (ou seja, você como dono do produto vai conver-
sar sobre cada cartão de história do usuário respeitando e até percebendo o que 
for melhor, pôr em Temas o que for agregado por funcionalidade ou agregar em 
Épicos o que tiver a complementaridade e afinidade) e faça com que a Equipe 
Scrum forneça uma estimativa de alto nível para cada item. Estimativas de alto 
nível são obtidas pelo jogo do planejamento;
• Revise o Backlog estimado do produto e, se necessário, ajuste a prioridade 
e o plano de liberação adequadamente. E lembre-se: quem desenvolve é o 
time SCRUM, se eles disserem que não dá ou que não entenderam, não tente 
“aparecer”, provavelmente o problema é você; além disso, tente melhorar seu 
poder discricional, isso ajuda muito as pessoas entenderem o que o cartão quer 
dizer, ou pior, o que você quer dizer.
Como dono do produto, também não caia na armadilha de pensar que, uma vez 
criado o Backlog do produto, seu trabalho está concluído. Você é responsável 
pelo Backlog do produto e deve revisar, manter, especificar os itens regular-
mente e garantir que exista um Backlog do produto bem definido, priorizado e 
estimado para o próximo Sprint ou ao menos os dois próximos. 
Portanto, e isso que estou escrevendo é sério, o dono do produto deve ter 
um Backlog do produto bem definido, priorizado, estimado e pronto antes 
18
19
da reunião de planejamento da Sprint, caso contrário, a Equipe Scrum tem 
o direito de rejeitar itens no Backlog do produto que não estão bem defi-
nidos e, nos casos mais graves, a Equipe Scrum tem o direito de abortar 
completamente o Sprint. Olhe “onde está se metendo”, por gentileza. 
Suas responsabilidades não terminaram ainda. E acredite, isso é prática, 
não é teoria. A teoria ficou para trás nas disciplinas anteriores, aqui você está 
exercendo o papel!
• Depois que a equipe do Scrum criar seu Sprint Backlog e começar a trabalhar 
no Sprint, lembre-se de revisar o Product Backlog pelo menos a cada 2 dias. 
Lembrete, 2 dias não são uma semana, são 2 dias, acredite, é importante você 
seguir a regra do jogo e executar tudo com excelência ;
• Seja muito proativo na manutenção de itens no Backlog do produto ;
• Se os itens do Backlog do produto se tornarem uma prioridade mais alta e pas-
sarem para uma próxima Sprint, se eles não estiverem bem definidos ou não 
forem estimados, defina o item e peça à equipe do Scrum que faça uma estima-
tiva do item antes da próxima reunião de planejamento da Sprint ;
• Se novos itens aparecerem no Backlog do produto, defina o item e peça à Equipe 
Scrum que estime o item antes da próxima reunião de planejamento da Sprint ;
• De vez em quando, verifique com a equipe do Scrum para garantir que os itens 
do Backlog do produto tenham o nível certo de detalhes ;
• Proteja o Backlog do produto “com sua vida” (figurativamente é lógico), 
se outras tarefas e projetos estiverem causando interrupções ou se muitos 
itens novos estiverem aparecendo no Backlog do produto (isso é um problema 
mais sério do que você pode imaginar, porque é causada por problemas de 
falta de comprometimento seu ou do usuário, ou o produto é tão inovador 
“eu sinceramente duvido” que se sabe muito pouco sobre ele), portanto, sendo 
politicamente correto, pode haver um problema mais alto na sua organização 
que precisa ser resolvido, certifique-se de resolvê-lo.
Tabela 1 – Exemplo de Backlog do Produto no SCRUM
ID História do usuário Estimativa Prioridade
7 Como um usuário não cadastrado eu quero criar uma conta (logine senha) para acesso. 3 1
1 Como usuário cadastrado eu quero efetuar login. 1 2
1 Como usuário cadastrado eu quero efetuar logout. 1 3
0 Criar script para apagar o banco de dados. 1 4
9 Como usuário autorizado eu quero ver uma lista de itens para que eu possa selecionar algum. 2 5
2 Como usuário cadastrado eu quero adicionar, apagar ou editar um novo item à lista e ele deverá aparecer ou desaparecer na mesma. 4 6
8 Como administrador eu quero ver uma lista de contas logadas. 8 7
Exemplo de Backlog do Produto no SCRUM. O Backlog do produto Scrum
é alterado durante todo o projeto. Se necessário, novos requisitos são adicio-
nados e os requisitos existentes podem ser modificados, definidos com mais 
detalhes ou até excluídos.
19
UNIDADE Planejamento Ágil 
Cada entrada no Backlog do produto Scrum deve ter algum tipo de valor para 
o cliente. Entradas sem nenhum valor para o cliente são puro desperdício e não 
devem estar presentes. O Backlog do produto Scrum pode incluir entradas para a 
exploração das necessidades do cliente ou várias opções técnicas, uma descrição dos 
requisitos funcionais e não funcionais, o trabalho necessário para iniciar o produto e 
outros itens, como a configuração do ambiente ou a correção de defeitos. Algumas 
tarefas podem não agregar valor direto à funcionalidade, no entanto elas podem 
agregar valor aumentando a qualidade ou reduzindo incidentes a longo prazo.
Definição das Sprints e seus Conteúdos
Neste item, precisamos lembrar o que é uma SPRINT.
Uma Sprint, um período de um mês ou menos, durante o qual é criado onde se 
incrementa um produto "concluído", utilizável e potencialmente liberável. Os sprints 
têm durações consistentes ao longo de um esforço de desenvolvimento. Um novo 
Sprint começa imediatamente após a conclusão do Sprint anterior. Além disso, du-
rante o Sprint:
• Nenhuma alteração é feita que possa colocar em risco o objetivo da Sprint;
• Metas de qualidade devem ser cumpridas;
• O escopo pode ser aclarado e renegociado entre o dono do produto e a equipe 
de desenvolvimento à medida que se aprende mais.
Cada Sprint pode ser considerado um projeto com um horizonte não superior a 
um mês. Como projetos, os Sprints são usados para realizar algo. Cada Sprint tem 
uma meta do que deve ser construído, um design e um plano flexível que guiará a sua 
construção, bem como o trabalho e o incremento resultante do produto. 
Um Sprint pode ser cancelado antes que o período do Sprint termine. So-
mente o dono do produto tem autoridade para cancelar o Sprint, embora possa 
fazê-lo sob influência das partes interessadas, da Equipe de Desenvolvimento ou 
do Scrum Master.
O fluxo de trabalho do sprint tem como objetivo ajudar os membros da equipe a 
avaliar seu trabalho e se comunicar entre si durante todo o processo. 
O fluxo de trabalho é seguido para cada sprint. O processo inclui:
Lista de pendências: Uma lista de tarefas definidas que devem ser concluídas antes 
do lançamento do produto. A lista de pendências é criada pelo proprietário do produto. 
O proprietário do produto fornece uma list–a de pendências de itens priorizados para o 
SCRUM MASTER e a equipe de SCRUM. O backlog é baseado em histórias de usuários, fo-
cadas em recursos que consideram o tipo de usuário final, o que eles querem e por quê.
Planejamento do sprint: a equipe discute as histórias de usuários com prioridade 
máxima e decide o que pode ser entregue no sprint.
20
21
Lista de pendências do Sprint: Acordada por toda a equipe, esta lista finaliza e 
define o que a equipe de desenvolvimento concluirá durante a sprint.
Sprint : O período em que o trabalho deve ser concluído - geralmente 30 dias.
Scrum diário: Liderado pelo SCRUM MASTER, a equipe se reúne para breves reu-
niões diárias, nas quais discutem o que concluíram, em que estão trabalhando e 
quaisquer problemas que estejam bloqueando o trabalho.
Resultado: O resultado de um sprint é um produto hipoteticamente utilizável. O 
proprietário do produto pode decidir se o produto está pronto ou se são necessários 
recursos adicionais.
Fim do sprint: No final de um sprint, são realizadas duas reuniões:
Revisão da Sprint : A equipe mostra seu trabalho ao proprietário do produto.
Retrospectiva do Sprint: A equipe discute o que eles podem fazer para melhorar 
os processos. Um objetivo importante é