scrum

1. Product Backlog
Um dos pontos mais importantes presentes no framework Scrum refere-se a criação e manutenção
doProduct Backlog. Este contem a relação de todas as atividades que serão realizadas pelo Time de
Desenvolvimento para a entrega do incremento sob a definição de pronto.
Vários são os conceitos por trás deste artefato, o que pretendemos explorar neste artigo.
Vamos lá ?
Introdução
O Product Backlog é uma lista de funcionalidades desejadas de um produto, ou seja, os requisitos que
um cliente espera receber ao final do projeto, descrito com sua própria linguagem. O ponto central do
Scrum é a criação do Product Backlog, é nele que o projeto começa.
Diferente do modelo tradicional de gestão de projetos, onde precisamos fechar o escopo para poder
começar a executar, no Scrum acredita-se que o início do projeto não é o melhor momento para isso.
Afinal nesse ponto ainda não conhecemos suficiente o projeto e precisamos avançar um pouco mais
em algumas hipóteses antes de ter tanta “certeza”.
Quando um projeto é iniciado não há nenhum esforço abrangente, que demanda muito tempo, para
escrever todas as tarefas ou requisitos previsíveis. Normalmente, tudo o que é óbvio consta do projeto,
o que, quase sempre, é mais que suficiente para o primeiro Sprint. A partir daí, o Product Backlogdeverá
crescer e mudar na medida em que se conhece o produto e os clientes.
Características Chave
Para o planejamento eficaz da nossa primeira entrega, precisamos desdobrar as características chave
do produto, programadas para o primeiro Release, em requisitos ou histórias. Na sequência do
processo, esses requisitos são priorizados e estimados, assim como são definidos os perfis e
quantidade dos integrantes do Time de Projeto. Dessa forma é possível, ao final do processo de
planejamento, obter prazos e estimativas de custo para o projeto.

2. Durante a reunião Sprint Planning, o Product Owner prioriza os itens do Product Backlog e os descreve
ao Time de Desenvolvimento que por sua vez determina quais itens ele conseguirá concluir no próximo
Sprint e passa estes itens do Product Backlog para o Sprint Backlog. Ao fazê-lo, o time desdobra cada
item em uma ou várias tarefas de Sprint Backlog para que seja possível um compartilhamento de
atividades mais efetivo.

3. Conceitualmente, o time inicia do topo da lista priorizada de Product Backlog e desenha uma linha logo
abaixo do item que o time considerar ser o último possível de se concluir durante o Sprint. Na prática,
não é incomum ver um time selecionar, por exemplo, os cinco itens mais importantes e dois itens que
estão abaixo na lista, mas associados aos cinco iniciais.
O Product Backlog pode ser mantido em uma planilha Excel. Um exemplo de um projeto real é
apresentado abaixo. Essa planilha Excel mostra cada item do Product Backlog com uma priorização
genérica (Muito Alta, Alta, etc.) feita pelo Product Owner.
As estimativas são realizadas pelos desenvolvedores, mas é notório que são muito imprecisas e
somente são utilizadas para uma grosseira alocação de tarefas nos vários Sprints.
Priorização
Em um artigo publicado por James O. Coplien, publicado em 3 de agosto de 2011 no site da Scrum
Alliance, mas que ainda gera comentários, trata das mudanças na versão atualizada do Guia do
Scrumno que tange a priorização do backlog do produto ou como James explica: ordenação.
Priorizar uma lista significa ordenar seus itens pela importância de cada um em relação aos outros. As
prioridades guiam a comparação dois-a-dois dos itens na lista. Pense na aplicação do algorítmo de
ordenação “por bolhas” (bubble sort) para priorizar o backlog do produto: compare os dois itens do
topo e troque-os de posição se estiverem na ordem errada. Passe, então, para o próximo par e
continue percorrendo a lista até que todos os itens estejam nas posições corretas. Priorização e
ordenação andam de mãos dadas. Todas as comparações são locais, ou seja, são restritas a uma
otimização local.
De forma mais ampla, a equipe Scrum e o Product Owner precisam considerar todo o backlog ao
ordenar seus itens, a fim de otimizar o valor ou o retorno sobre o investimento (ROI). A maioria das
pessoas normalmente acha que o ROI tem prioridade, entretanto você deve pensar o ROI como o
resultado de longo prazo decorrente da ordenação correta de todo o backlog, ao invés da simples soma
do ROI dos itens individuais. Isto é verdade, de certa forma, porque o ROI de um item isolado depende
de sua posição no backlog.
Requisitos

4. A elaboração do Backlog do Produto é realizada através do desdobramento das características-chave,
estabelecidas na Visão do Produto, em:
 Requisitos Funcionais;
 Requisitos não-funcionais.
Vejamos:
Requisitos funcionais
De uma maneira geral, são funções do produto que podem ser descritas, priorizadas e estimadas. Vou
concentrar a explicação, inicialmente, na forma de descrição desses requisitos. Requisitos também são
conhecidos no mundo ágil como histórias.
Uma história descreve uma necessidade ou situação futura, a qual o cliente pretende alcançar através
da utilização do produto a ser desenvolvido. Normalmente, a descrição de uma história ou requisito
utiliza a seguinte estrutura:
Através dos exemplos acima, conseguimos visualizar necessidades ou situações futuras, a partir de
três pontos de vista diferentes (quem): cliente, atendente e gestor da loja. Na segunda coluna (o que),
é informada a necessidade ou situação futura desejada e, na terceira coluna (para que), sua finalidade.
Uma história, para ser considerada completa, precisa ser formada por essas três partes: quem, o que
e por que. Entretanto, não é uma receita de bolo. Podemos descrever requisitos de outras formas,
como mostrado no exemplo abaixo:

5. Requisitos Não Funcionais
São aspectos subjetivos relacionados à história. Vamos considerar o seguinte requisito: consulta a
posição atualizada do acervo de filmes com tempo de resposta satisfatório. A dúvida usual neste
tipo de requisito é: o que é tempo de resposta satisfatório ?
Trata-se de uma condição que pode gerar várias interpretações. Para mim, tempo de resposta
satisfatório pode ser algo entre dois a três segundos, entretanto, dependendo do perfil do usuário,
podem existir tolerâncias maiores ou menores. Por este motivo, a única forma de resolver este problema
é transformar um requisito não funcional, ou a parte não funcional do requisito, em algo funcional
(objetivo).
Para tanto, precisamos definir o que é “tempo de resposta satisfatório”. Se nossos clientes/usuários
estabelecem uma tolerância máxima de 2 segundos como tempo de resposta satisfatório, conseguimos,
através dessa informação, derivar outros requisitos funcionais necessários para garantir essa condição,
tais como servidores, links de acesso, arquitetura do site etc.
Critérios
Segundo o modelo INVEST, criado por Bill Wake, para um requisito fazer parte do Backlog do Produto,
deve respeitar os seguintes critérios:
Ser independente
Orequisito deve possuir capacidade para atender a necessidade ou situação futura informada pelo
cliente, sem depender de outro requisito. Essa condição é fundamental para garantir flexibilidade
durante o ciclo de desenvolvimento do produto.
Ser negociável
Enquanto não for convertido em produto, o requisito deve permitir alterações, como mudança de
prioridade, aumento/redução da sua abrangência e desdobramento em outros requisitos, podendo
inclusive ser reescrito ou mesmo descartado, desde que mantido o valor esperado pelo cliente final, na
entrega do produto.
Ser priorizado (Valuable)
O requisito deve, obrigatoriamente, assegurar a entrega de valor para o cliente, caso contrário, seu
desenvolvimento poderá representar desperdício de esforço para o Time de Projeto. Por este motivo, o
requisito é priorizado pelo Dono do Produto, de acordo com o valor agregado ao negócio/cliente final.
Ser estimado

6. O requisito deve apresentar condições para que seu prazo de desenvolvimento/entrega possa ser
estimado. Caso o requisito não ofereça essas condições, em virtude, por exemplo, do seu tamanho,
deverá ser desdobrado em requisitos menores, até que possa ser adequadamente estimado.
Ser pequeno (Small)
Este critério está diretamente relacionado ao anterior. O requisito deve estar descrito de uma forma que
permita sua estimativa com certo nível de certeza (quanto menor, melhor). Outro aspecto a ser
observado é que a duração prevista do requisito não deve ultrapassar o prazo de execução dos ciclos
de trabalho estabelecidos para o projeto (Sprints).
Ser inspecionado (testable)
O requisito propriamente dito ou sua descrição deve prover as informações necessárias para que possa
ser inspecionado/testado pelo cliente final. Requisitos que não podem ser validados elevam os níveis
de risco do projeto e podem ocasionar problemas graves em etapas mais avançadas do projeto.
Conforme mostrado até aqui, fica evidente que a elaboração de requisitos não é uma tarefa simples,
principalmente para quem não está habituado a planejar projetos dessa forma. Por este motivo, acredito
que seja melhor explorar um pouco mais o tema, para assegurar o correto entendimento dos conceitos
e práticas relacionadas à elaboração e gestão do Backlog do Produto.
User Story
Para melhor estruturar o Product Backlog utiliza-se o conceito de User Stories, que contém a descrição
detalhada dos requisitos de cada solicitação a ser implementada.
Segundo Mike Cohn:
User Story é uma pequena e simples descrição de uma funcionalidade dita da perspectiva da pessoa
que deseja a nova capacidade, usualmente um usuário ou um cliente do sistema.
Ou seja, deve conter as necessidades dos usuários ou dos clientes, e não as funcionalidades do
sistema. Trata-se de uma mudança de paradigma quando comparado ao modelo criado pelo
PMI(Project Management Isntitute) para gestão de projetos. E é esse um dos papéis do Product Owner:
traduzir as necessidades do cliente, através do Backlog do Produto, em uma linguagem não-técnica
compreensível por todas as pessoas envolvidas no projeto.

7. Exemplo:
Cada User Storie pode ser composta por:
ID
Uma identificação única, apenas um número com auto-incremento. O objetivo disto é evitar que, ao
mudarmos seu nome, percamos o controle sobre as histórias.
Nome
Um nome curto e descritivo para a história. Por exemplo; “Layout do Relatório”. O nome tem que ser
explicativo o bastante, para que os membros do time e o Product Owner entendam minimamente sobre
o que estamos falando, e específico o suficiente para distingui-la das demais histórias. Normalmente
usamos de 2 a 10 palavras.
Importância
Definir qual é importância dessa história na perspectiva do Product Owner (em relação ao cliente). Por
exemplo: 10 ou 150. Quanto mais pontos mais importante.
Estimativa inicial
Estimativas preliminares que o time dá sobre quanto tempo será necessário para concluir uma
determinada história, se comparada as demais. Cada empresa trabalha sua estimativa de uma forma,

8. mas normalmente dá-se uma pontuação que está diretamente relacionada à complexidade da tarefa e
que servirá como base para se calcular quantos dias / horas / pessoas serão necessárias para entregar.
Se a pontuação estiver muito alta, uma dica interessante é quebrar a tarefa em duas atividades, desta
forma ficará mais fácil acertar na estimativa. A unidade está ligada a pontos por história e geralmente
corresponde mais ou menos a “relação homem/dias” ideal.
Faça a pergunta: Em X dias nós apresentaremos uma implementação pronta, demonstrável e testada?
Se a resposta for “com 3 pessoas trancadas em uma sala levará aproximadamente 4 dias” então a
estimativa inicial é de 12 pontos por história.
Demonstração
Em alto nível criamos uma descrição de como a história será demonstrada na apresentação da Sprint. É
simplesmente uma especificação de teste. “Faça assim, então faça aquilo e, então, isso deverá
acontecer.”
Notas
Quaisquer outras – breves – informações, esclarecimentos, referências a outras fontes de informação
etc.
Exemplo:
ID Nome Importância Estimativa Demonstrar Notas
1 Deposito 21 16
Logar-se no
sistema para
abrir a pagina
de deposito,
depositar R$
60,00 ir para a
pagina de saldo
verificar se
houve um
aumento de R$
60,00.
Necessário
diagramam
UML
Priorização
Mantenha o Product Backlog atualizado
Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do Product
Backlog. Quanto menor for o conjunto de histórias que devem ser priorizadas, mais simples será a
tarefa. Por mais que seja difícil “desapegar” de uma história pensada e, até certo ponto, especificada,
é importante que isso seja feito, pois ela estando no Product Backlog, mesmo que com uma prioridade
baixa, pode influenciar na priorização das demais histórias e alterar o rumo do produto.
Dê importância à Definição de Pronto
A definição de história preparada é outro fator que pode auxiliar bastante na priorização. Sem ela, a
equipe de desenvolvimento pode não saber estimar corretamente uma história, passando uma falsa

9. noção de tamanho da história para o Product Owner, que irá tomar decisões sobre priorização com
base em uma informação pouco confiável.
Conhecimento, incerteza e risco de histórias
Como esses fatores influenciam diretamente o sucesso do produto, histórias com baixo grau de
conhecimento e alto grau de incerteza e risco devem ter uma prioridade alta, pois quanto antes forem
desenvolvidas, antes pode-se perceber o melhor caminho a se seguir, caso contrário pode não haver o
tempo necessário para desenvolver a história e colher os frutos do aprendizado do desenvolvimento da
mesma.
Qual a influência da história na próxima release?
Histórias que permitam um lançamento mais rápido do produto também devem estar no topo doProduct
Backlog. Por exemplo, em um software de geração de nota fiscal, a geração da nota em si é muito mais
importante que o cadastro dos produtos, logo, ela deve possuir uma maior prioridade.
Atenção ao tamanho das histórias
Lembre-se, a história deve ser pequena suficiente (s de small do INVEST) para ser independente e
agregar valor para o software e para o cliente, dessa forma, busque uma uniformidade no tamanho das
histórias, de modo que o Product Backlog, principalmente em seu topo, possua apenas histórias na
menor unidade possível, e a medida que avançamos, podemos encontrar histórias maiores. Assim,
evitamos que a equipe estime histórias muito grandes, que possuem maior risco de apresentar
surpresas em seu desenvolvimento e que possuem estimativas mais suscetíveis a erros.
Atenção à dependência entre as histórias
Apesar da definição de que as histórias devem ser independentes (i de independent do INVEST), muitas
vezes não conseguimos evitar a dependência entre as histórias. Nesse caso a melhor opção é deixar
visível essa dependência, com uma anotação, uma cor diferente, qualquer coisa que chame a atenção
para isso. Se a história A depende da história B, não agrega valor para o negócio fazer a A antes da B
e isso deve estar visível para todos os envolvidos no Projeto.
Ouça todos os interessados no Projeto
A decisão sobre a prioridade do Product Backlog é única e exclusiva do Product Owner, entretanto, ele
deve ouvir todos os interessados (stakeholders) no Projeto para auxiliar o seu processo de tomada de
decisão. Isso é importante pois o produto sendo desenvolvido não deve agradar somente ao PO, mas
sim à todos os envolvidos no Projeto, principalmente interessados e clientes.
Utilize Técnicas de Priorização
Novamente, apesar da decisão sobre as prioridades definidas ser única e exclusiva do Product Owner, a
utilização de técnicas, como a técnica de KANO pode ser bastante útil quando existe dúvida na
prioridade de um pequeno conjunto de histórias. Uitlize as técnicas de priorização como sua aliada para
ajudar a resolver esses pequenos conflitos.
Considere a priorização por temas
Como falei na dica #6, a dependência entre histórias muitas vezes é inevitável. Dessa forma, agrupar
as histórias dependentes em um uma e priorizar o tema também pode ajudá-lo, assim a priorização
pode ser dividida em 2 passos, primeiro se prioriza os temas e, em sequência, as histórias dentro de
cada tema, evitando assim que histórias de um mesmo tema fiquem espalhadas por todo o Product
Backlog.
Se mantenha atualizado!!!
Como sempre, nunca pare de estudar e se atualizar. A cada dia novas técnicas aparecem, e, estarmos
de cabeça aberta para absorver novos conhecimentos é sempre importante para nos ajudar a melhorar
nosso trabalho.
Conclusão

10. Tão importante quando entender os conceitos existentes por traz de um Product Backlog é saber
trabalhar de forma correta na criação e manutenção do mesmo.
A definição das estimativas das estórias é responsabilidade do Time de de Desenvolvimento com apoio
do Scrum Master e Product Owner trabalhando juntos na busca dos objetivos estabelecidos e
produtividade esperada de coerência e produtividade.
Referências Bibliográficas
 http://scrumex.com.br/blog/?p=1091
 http://imasters.com.br/artigo/20133/agile/o-backlog-do-produto-e-a-arte-da-user-story/
 http://www.projectbuilder.com.br/blog-pb/entry/projetos/como-fazer-o-product-backlog
 http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/aula12_SCRUM%20na%20pratica.pdf
 http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/aula12_SCRUM%20na%20pratica.pdfhttp://blo
g.myscrumhalf.com/2014/04/10-dicas-para-melhorar-a-priorizacao-do-product-backlog/