Unidade II - Planejamento Ágil

Prévia do material em texto

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 produto que 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 pode ter 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, assimcreio 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 potencialmenteliberá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 é a melhoria contínua (ROUSE; BRUNSKILL, 
2014, p. 2).
O trabalho a ser executado no Sprint é planejado no Planejamento do Sprint. 
Esse plano é criado pelo trabalho colaborativo de toda a equipe Scrum. O Planeja-
mento da Sprint tem uma duração de 8 horas, ou seja, um dia útil de trabalho, no 
máximo, para uma Sprint de 30 dias, para tempos menores como de 15 dias, 4 ho-
ras de Planejamento de Sprint serão mais que suficientes. Para Sprints mais curtos 
ainda, o evento geralmente é menor, 2 horas, por exemplo. O Scrum Master ga-
rante que o evento ocorra e que os participantes entendam seu propósito. O Scrum 
Master ensina, ou, ao menos, tenta fazer a Equipe Scrum mantê-lo dentro do prazo.
“O que pode ser feito neste Sprint?
A equipe de desenvolvimento trabalha para prever a funcionalidade que será desen-
volvida durante o Sprint. O dono do produto discute o objetivo que a Sprint deve al-
cançar e os itens do Backlog do produto que, se concluídos na Sprint, atingiriam 
a meta da Sprint. Toda a equipe Scrum colabora na compreensão do trabalho 
do Sprint. 
A entrada para esta reunião é o Backlog do produto, o Incremento do produto mais 
recente, a capacidade projetada da Equipe de Desenvolvimento durante o Sprint e 
o desempenho passado da Equipe de Desenvolvimento. O número de itens selecio-
nados no Backlog do produto para o Sprint depende exclusivamente da equipe de 
desenvolvimento. Somente a equipe de desenvolvimento pode avaliar o que pode 
realizar no próximo Sprint.
Durante o Planejamento da Sprint, a Equipe Scrum também cria um Objetivo da 
Sprint. O Objetivo da Sprint é um objetivo que será alcançado dentro da Sprint por 
meio da implementação do Backlog do Produto e fornece orientação à Equipe de 
Desenvolvimento sobre porque está construindo o Incremento. 
Como será realizado o trabalho escolhido?
Depois de definir a meta da Sprint e selecionar os itens do Backlog do produto 
para a Sprint, a equipe de desenvolvimento decide como criar essa funcionalidade 
em um incremento de produto "Concluído" durante a Sprint. Os itens do Backlog
21
UNIDADE Planejamento Ágil 
do produto selecionados para este Sprint mais o plano para entregá-los são cha-
mados de Sprint Backlog.
A equipe de desenvolvimento geralmente começa projetando o sistema e o trabalho 
necessário para converter o Backlog do produto em um incremento do produto em 
funcionamento. O trabalho pode ter tamanho variável ou esforço estimado. No en-
tanto, é planejado um trabalho suficiente durante o Planejamento da Sprint para a 
Equipe de Desenvolvimento prever o que acredita que pode fazer na próxima Sprint. 
O trabalho planejado para os primeiros dias do Sprint pela equipe de desenvolvi-
mento é decomposto no final desta reunião, geralmente em unidades de um dia ou 
menos. A Equipe de Desenvolvimento se auto organiza para realizar o trabalho no 
Backlog da Sprint, durante o Planejamento da Sprint e conforme necessário em toda 
a Sprint.
O Dono do produto pode ajudar a esclarecer os itens selecionados do Backlog do pro-
duto e fazer trocas. Se a Equipe de Desenvolvimento determinar que tem muito ou 
pouco trabalho, poderá renegociar os itens selecionados do Backlog do Produto com 
o Dono do Produto. A equipe de desenvolvimento também pode convidar outras 
pessoas a comparecer para fornecer conselhos técnicos ou de domínio.
Objetivo da sprint
A meta da Sprint é um objetivo definido para a Sprint que pode ser alcançado 
através da implementação do Product Backlog. Ele fornece orientação à equipe de 
desenvolvimento sobre o motivo da criação do incremento. Ele é criado durante 
a reunião de Planejamento da Sprint. O objetivo da Sprint oferece à equipe de de-
senvolvimento alguma flexibilidade em relação à funcionalidade implementada 
na Sprint. Os itens selecionados do Backlog do produto oferecem uma função coe-
rente, que pode ser a meta da Sprint. O Objetivo da Sprint pode ser qualquer outra 
coerência que faça com que a Equipe de Desenvolvimento trabalhe em conjunto, 
e não em iniciativas separadas.
Daily Scrum
O Daily Scrum é um evento de 15 minutos para a equipe de desenvolvimento. O Daily 
Scrum é realizado todos os dias do Sprint. Nele, a equipe de desenvolvimento planeja 
trabalhar pelas próximas 24 horas. Isso otimiza a colaboração e o desempenho da 
equipe, inspecionando o trabalho desde o último Daily Scrum e prevendo o próximo 
trabalho da Sprint. O Daily Scrum é realizado no mesmo horário e local todos os dias 
para reduzir a complexidade.
A Equipe de Desenvolvimento usa o Daily Scrum para inspecionar o progresso em 
direção ao Objetivo da Sprint e para verificar como o progresso está tendendo para 
a conclusão do trabalho no Sprint Backlog. O Daily Scrum otimiza a probabilidade de 
a equipe de desenvolvimento atingir o objetivo da Sprint. Todos os dias, a equipe de 
desenvolvimento deve entender como pretende trabalhar em conjunto como uma 
equipe auto organizada para atingir o objetivo da Sprint e criar o incremento previs-
to até o final da Sprint.
Aqui está um exemplo do que pode ser usado:
• O que fiz ontem que ajudou a equipe de desenvolvimento a atingir a meta da Sprint?
• O que farei hoje para ajudar a Equipe de Desenvolvimento a atingir a meta da Sprint?
• Vejo algum impedimento que impeça a mim ou à equipe de desenvolvimento 
de atingir a meta da Sprint?22
23
A equipe de desenvolvimento ou os membros da equipe geralmente se reúnem 
imediatamente após o Daily Scrum para discussões detalhadas ou para adaptar ou 
replanejar o restante do trabalho da Sprint.
O Daily Scrum é uma reunião interna para a equipe de desenvolvimento. Se houver 
outras pessoas, o Scrum Master garante que não atrapalhem a reunião.
Revisão da Sprint
Uma Revisão da Sprint é realizada no final da Sprint para inspecionar o Incremento 
e adaptar o Backlog do Produto, se necessário. Durante a Revisão da Sprint, a Equi-
pe Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint. Com 
base nisso e em quaisquer alterações no Backlog do produto durante o Sprint, os 
participantes colaboram nas próximas ações que podem ser feitas para otimizar o 
valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação do 
Incremento visa obter feedback e promover a colaboração.
Esta é, no máximo, uma reunião de quatro horas para Sprints de um mês. Para 
Sprints mais curtos, o evento geralmente é mais curto. 
A Revisão da Sprint inclui os seguintes elementos:
• Os participantes incluem a equipe Scrum e as principais partes interessadas, 
convidadas pelo Product Owner;
• O Dono do produto explica quais itens do Backlog do produto foram "Concluí-
dos" e o que não foi "Concluído";
• A equipe de desenvolvimento discute o que correu bem durante o Sprint, quais 
problemas ele teve e como esses problemas foram resolvidos;
• A equipe de desenvolvimento demonstra o trabalho "Concluído" e responde a 
perguntas sobre o incremento;
• O Dono do produto discute o Backlog do produto como está. Ele projeta datas-
-alvo e entregas prováveis com base no progresso até a data (se necessário);
Retrospectiva da Sprint
A Retrospectiva da Sprint é uma oportunidade para a Equipe Scrum se inspecionar 
e criar um plano para melhorias a serem implementadas durante a próxima Sprint.
A Retrospectiva da Sprint ocorre após a Revisão da Sprint e antes do próximo Plane-
jamento da Sprint. Esta é uma reunião de no máximo três horas para Sprints de um 
mês. Para Sprints mais curtos, o evento geralmente é mais curto. O Scrum Master 
garante que o evento ocorra e que os participantes entendam seu propósito.
O objetivo da Retrospectiva da Sprint é:
Inspecione como foi o último Sprint em relação a pessoas, relacionamentos, proces-
sos e ferramentas;
Identifique e encomende os principais itens que foram bem e as possíveis melhorias; 
e, crie um plano para implementar melhorias na maneira como a equipe Scrum faz 
seu trabalho.
No final da Retrospectiva 1a da Sprint, a equipe Scrum deveria ter identificado me-
lhorias que serão implementadas na próxima Sprint ” (SCRUM GUIDES, 2020, p. 7-10).
Certo! Já vimos como se faz a sequência a partir das histórias do usuário e como 
o dono do produto determina a Sprint junto com a equipe, agora vamos entender 
o que tem dentro da sprint, quais são, por exemplo, os componentes quebrados em 
tarefas/atividades para o time SCRUM poder trabalhar no desenvolvimento.
23
UNIDADE Planejamento Ágil 
Vejamos esse meu exemplo de um projeto:
Fazer consulta
de apartamentos
pela web
Fazer interface
do usuário
Executar testes
unitários
Criar 
componentes
de validação
Integrar com
sistema de
reserva
Executar testes
aceitação
Título: “Consulta de Apartamentos”
Como cliente de negócio, eu quero consulta os apartamentos pela web.
para facilitar a reserva
Pontos: 8 Prioridade: Alta
Figura 4 – Exemplo de composição de cartões de história em tickets de trabalho
Fonte: Adaptado de MARQUES; SOARES, 2015
A figura acima demonstra o trabalho a ser realizado a partir da história “já 
quebrados” em tarefas. “Fazer consulta de apartamentos pela web” e as atividades 
que envolvem isso, ou seja, fazer a interface do usuário, criar os componentes de 
validação, integrar com o sistema de reserva, executar os testes unitários e executar 
os testes de aceitação. Cada um desses tickets tem um membro que escolheu 
executá-lo, no tempo de duração da sprint. É assim que vamos desenvolvendo cada 
iteração e fazendo as reuniões diárias para ver se o que foi prometido está evoluindo 
e vai ser entregue. Isso vai se repetindo até o final. No nosso exemplo, claro, vamos 
tomar como base que esse cartão também representa a sprint toda. Na maioria das 
vezes, vários cartões de história de usuários são contemplados em uma sprint, mas 
a essência é essa. Você deve proceder nessa maneira de decomposição para que o 
time de desenvolvimento SCRUM saiba o que fazer e saiba o que entregar e o que 
se espera dele. Esses bilhetes ou post-its, se você preferir, ficam normalmente num 
quadro visual aberto, que é o KANBAN. 
Uma coisa importante para você notar é que usamos o Planning Poker ou Jogo 
do Planejamento para darmos uma estimativa aproximada da complexidade da histó-
ria em unidades chamadas pontos de história a partir de cartões contendo números 
sequenciais baseados na progressão de Fibonacci. A partir disso, claro, o time de 
desenvolvimento deverá quebrar isso em tarefas e atividades e aí sim, elas deverão 
ter seu tempo de desenvolvimento declarado. Portanto, há uma transição do que o 
time entende como complexidade traduzido em unidades de tempo que devem em 
sua totalidade respeitar o tempo de duração da sprint para entrega. Isso ocorre de 
tal forma que não há nenhuma atividade que possa durar mais que o tempo deter-
24
25
minado e fixo da sprint, se 15 ou 30 dias. Uma vez decidido o tempo da Sprint, ele 
será o mesmo até o final do projeto. 
Uma observação importante é notar que, se por um acaso, uma atividade 
durar mais que o tempo da sprint, ele deve ser quebrado em histórias menores 
para que caiba. Isso, claro, é um erro inadmissível causado pela falta de análise 
ou tempo subestimado.
Planning Poker para Determinar 
Complexidade com Cartões de Fibonacci
O Jogo do Planejamento permite-nos encontrar rapidamente um plano aproxima-
do de projeto do software e depois refiná-lo à medida que o projeto avança. 
Poderíamos dizer que o Jogo do Planejamento é uma reunião, é um ponto vital 
de iteração entre cliente e desenvolvedor.
Uma reunião acontece com a equipe trabalhando em uma pilha de cartões de 
índice que contêm as histórias do usuário e são tratados durante o Jogo de Planeja-
mento. Cartões de índice são uma ferramenta altamente eficaz. A função dos cartões 
é conectar os clientes e os desenvolvedores para atingirem seu objetivo comum, ou 
seja, o sistema. Podemos realizar as estimativas em cima desses cartões de histórias 
utilizando o Planning Poker, muito útil para as equipes ágeis. 
O jogo de planejamento é feito levando-se em consideração a expectativa de mu-
danças no projeto, inclusive, portanto um elemento de riscos.
Vamos lembrar como se joga:
Existem 3 fases do jogo do planejamento em XP: 
• Exploração: Esta é uma maneira de tentar descobrir coisas novas que o sistema 
é capaz de fazer. O propósito da fase de exploração é dar aos jogadores uma 
apreciação do que todo o sistema deve eventualmente fazer. Exploração tem 
três movimentos:
a) Escreva uma história: Negócios escreve uma história descrevendo algo 
que o sistema precisa fazer. As histórias são escritas em cartões de índice, 
com um nome e um parágrafo curto descrevendo o propósito da história ;
b) Estimar uma história: Desenvolvimento estima quanto tempo a história 
levará para implementar. Se o desenvolvimento não puder estimar a his-
tória, ela pode pedir aos negócios que esclareçam ou dividam a história ;
c) Uma história é contada: Se Desenvolvimento não puder estimar uma 
história completa ou se os negócios perceberem que parte de uma histó-
ria é mais importante do que o restante, os negócios podem transformar 
uma história em duas ou mais histórias.
25
UNIDADE Planejamento Ágil 
• Compromisso: Será tomada a decisão quanto aos passos a serem seguidos na 
realização dos requisitos. O propósito da fase de compromisso é que as empre-
sas escolham o escopo e a data da próximaversão e que o desenvolvimento se 
comprometa com a entrega. Possui 4 movimentos a saber:
a) Classificar por Valor: Negócios classifica as histórias em 3 pilhas:
I. Aquelas sem as quais o sistema não funcionará; 
II. Aquelas que são menos essenciais, mas fornecem valor comercial 
significativo;
III. Aquelas que seria bom ter.
b) Classificar por risco: Desenvolvedores classificam as histórias 3 pilhas: 
I. Aquelas que podem estimar com precisão; 
II. Aquelas que podem ser razoavelmente estimadas;
III. Aquelas que não podem estimar. 
c) Definir velocidade: Desenvolvedores informam a rapidez com que a 
equipe pode programar em tempo de engenharia ideal por mês; 
d) Escolher o escopo: A empresa escolhe o conjunto de cartões na libera-
ção, seja definindo uma data para a engenharia estar completa e esco-
lhendo cartões com base em sua estimativa e velocidade do projeto, ou 
escolhendo os cartões e calculando a data;
e) Direção: Esta é a orientação dos desenvolvedores para o requisito do 
projeto. O propósito da fase de direção é a atualização do plano com 
base no que é aprendido pelo desenvolvimento e pelos negócios durante 
o tempo. A fase de direção tem quatro movimentos:
I. Iteração: no início de cada iteração (de 1 até 3 semanas), Negócios 
selecionam uma iteração das histórias mais valiosas a serem 
implementadas. As histórias da primeira iteração devem resultar em 
um sistema que é executado de ponta a ponta;
II. Recuperação: Se o desenvolvimento perceber que ele superestimou 
sua velocidade, ele poderá solicitar a Negócios que é o conjunto de 
histórias mais valioso a ser retido no release atual com base na nova 
velocidade e nas estimativas;
III. Nova história: Se os negócios perceberem que precisa de uma nova 
história durante o meio do desenvolvimento de um lançamento, ele 
poderá escrever a história. O desenvolvimento estima a história, de-
pois o negócio remove as histórias com a estimativa equivalente do 
plano restante e insere a nova história;
IV. Reestimativa: Se o desenvolvimento achar que o plano não fornece 
mais um mapa preciso do que fazer, ele pode reestimar todas as his-
tórias restantes e definir a velocidade novamente. (BECK; ANDRES, 
2004, p. 108-110)
26
27
Em termos práticos durante um projeto real a rotina funciona assim:
• O dono do produto chega à reunião de Planejamento de Liberação com uma 
lista priorizada de coisas que precisam ser feitas, estamos falando do backlog
do produto, aquela lista às vezes num Excel, às vezes em algum software que 
auxilia nesse aspecto, como o Trello, por exemplo ;
• O dono do produto apresenta o item de maior prioridade do Backlog do produto 
para a equipe ;
• A equipe do Scrum percorre o Backlog do produto para decidir qual o recurso 
que levará menos tempo para ser entregue - esse recurso é avaliado como 1. 
Preste atenção! A equipe SCRUM apenas localizou para desenvolver um recur-
so muito fácil de se realizar e determinou que aquela “complexidade vale 1” ;
• A equipe Scrum pode fazer perguntas para esclarecer os requisitos de recursos. 
É normal e saudável perguntar porque em sistemas o que menos interessa para 
todos são os “achismos” e “sub entendimentos”, tem que perguntar. Sua dúvida 
não respondida, porque você achou irrelevante, pode comprometer todo o pro-
jeto, se não, haver um retrabalho indesejado para corrigir ;
• Cada membro do Scrum escolhe um cartão que considera representar o tama-
nho do elemento em relação ao elemento que valoriza aquele recurso pedido 
pelo dono do produto ;
• Se os membros escolherem uma grande variedade de números para o recurso, 
discutem o recurso e depois reproduzem novamente. O tempo da discussão é 
de três minutos ; 
• A equipe Scrum continua jogando até que eles tenham um consenso quanto ao 
número de pontos que o recurso deve ser concedido ;
• O dono e a equipe do produto repetem o processo para que tenham o suficiente 
do Backlog do produto estimado para 2 ou 3 Sprints. Aqui normalmente 
fazemos para 2 sprints. Tratar o backlog do produto inteiro seria demasiado 
estressante e improdutivo. Vamos focar no tempo presente e no futuro mais 
próximo o possível ;
• Sempre há muita discussão quando as equipes começam a usar o planejamen-
to do pôquer para estimar o trabalho, pois 1 ponto representa 1 hora. Os 
pontos não têm relação com o tempo, são simplesmente uma ponderação para 
demonstrar o tamanho em relação ao recurso de linha de base de complexidade 
que combinamos lá em cima (o recurso avaliado como 1 ponto). O mais impor-
tante sobre o jogo do planejamento é que ele faz a equipe Scrum e o Product 
Owner falarem, para que todos tenham um entendimento comum dos requisitos 
e tamanho dos recursos.
O processo do jogo é simples, veja as figuras a seguir na sequência.
27
UNIDADE Planejamento Ágil 
Tabela 2 – Sequência da dinâmica de uma roda com Planning Poker
Descrição Dinâmica
Baseado na progressão de Fibonacci (0,1,2,3,5,8,13,21,34...) ou num misto de Fibonacci com números grandes múltiplos de 10.
A notificação gera uma complexidade subjetiva que busca consenso com as outras concepções individuais da equipe buscando 
uma coletiva.
Sempre aplicada a uma história de usuário ou a um recurso.
É uma medida relativa de esforço, complexidade e risco. 
Quando estimar, levar em consideração estas três variáveis.
O benefício do “Planning Poker” são os embates de ideias. A prática é muito simples e gera muito engajamento das pessoas.
Grupo de Desenvolvimento
Cada um seleciona uma carta
contendo sua estimativa e a 
deixa virada sobre a mesa.
“Pessoal, qual
o tamanho dessa
história de 
usuário aqui?”
Fazer consulta
de apartamentos
pela web
Fazer interface
do usuário
Executar testes
unitários
Criar 
componentes
de validação
Integrar com
sistema de
reserva
Executar testes
aceitação
Título: “Consulta de Apartamentos”
Como cliente de negócio, eu quero consulta os apartamentos pela web.
para facilitar a reserva
Pontos: ? Prioridade: AltaDono do produto
A
3
8
3
20
13
B
C
DE
Figura 5
Fonte: Adaptado de SOARES, 2015
Vamos nessa rodada trabalhar com esse cartão de história que leva em consideração todos os itens que compõem a tarefa, portanto, 5 
atividades. O importante aqui é que a equipe SCRUM vire as cartas ao mesmo tempo para evitar o efeito “manada” ou “Maria vai com as 
outras”, isso é bom, pois gera impressões realistas da dificuldade.
A
5
E
5
B
5
C
8
D
3
E
8
B
13
D
3
A
Rodada 1
A e o Sr. C, precisam discutir a história, e 
por que suas estimativas estão tão distintas.
A e o Sr. C precisam discutir a 
história e porque suas estimativas
estão tão distintas.
• “A” percebe que esqueceu algumas tarefas
 importantes e que deveriam ser incluídas na história.
• “C” percebe que, com design que “A” apresentou, 
 a história pode ser menor de 20 min. 
• Houve convergência, ainda que parcial.
• Eles concordam que uma estimativa de valor 5 deve estar 
 próxima o bastante do esforço e partem para a próxima
 história, até terminarem todas.
Rodada 2...n
3 C
20
Depois de 3 minutos de conversa, 
um novo “round” de estimativa 
é feito para a mesma história.
Figura 6
Fonte: Adaptada de SOARES, 2015
Para resolver essa história do usuário, foram necessárias 2 rodadas, poderiam ser mais, mas não se aconselha, pois demanda tempo e a 
média de investimento de tempo para cada cartão de história de usuário deve estar entre 3 e 5 minutos. Isso mesmo! Depois vamos para 
a próxima história, e depois outra, e assim por diante, até que acabemos os 2 sprints que precisamos.
Você pode reforçar seu estudo sobre o jogo do planejamento vendo esse vídeo.
UNIVERSIDADE SCRUM. Estimativas, Planning Poker e Velocidade, disponível em: 
https://youtu.be/YLA9zB2uV_I
28
29
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
O Papel do Produtct Owner
https://youtu.be/7lhnYbmovb4
Product Backlog
https://youtu.be/dTw4EIC5ZSo
Refinamento do Backlog de Produto - Série Scrum Foundation eLearning
SCRUM ALLIANCE.Refinamento do Backlog de Produto . Série Scrum 
Foundation eLearning . Legendas em Português.
 https://youtu.be/CXUUHqOqjIM
Estimativa
https://youtu.be/V6T9gPCwwNw
 Webinar: Estimativas com Planning Poker
O objetivo deste webinar é apresentar uma visão geral de uma técnica de estimativas 
de projetos de software muito usada por equipes ágeis, o Planning Poker .
https://youtu.be/Y0uqIwVNeJk
29
UNIDADE Planejamento Ágil 
Referências
BECK, K.; ANDRES, C. Extreme Programming Explained: Embrace Change. 2. 
ed. Boston: Addison-Wesley Professional, 2004. 218 p.
LUNA, B. de. Essa é uma User Story de amargar, conheci uma garota meu 
irmão eu vou lhe falar. 2019. Disponível em: <https://listadeluna.substack.com/p/-
-essa-uma-user-story-de-amargar-conheci>. Acesso em: 20/01/2020.
ROUSE, M.; BRUNSKILL, V-L. Sprint: (desenvolvimento de software). 2014. 
Disponível em: <https://searchsoftwarequality.techtarget.com/definition/Scrum-
-sprint>. Acesso em: 20/01/2020.
SCRUM GUIDES. O Scrum Guide: planejamento de sprint. 2020. Disponível em: 
<https://www.scrumguides.org/scrum-guide.html>. Acesso em: 20/01/2020.
VENTURA, P. Epic, Feature e User Story (Epico, Funcionalidade e História de 
Usuário): o que são e como se relacionam estes três artefatos no contexto de um 
product backlog. 2019. Disponível em: <https://www.ateomomento.com.br/epic-
-feature-e-user-story/>. Acesso em: 20/01/2020.
30