Cadastre-se

Cadastre-se para acesAcesse conteúdos exclusivos que só usuários cadastrados no site tem acesso.

Fases de um projeto – As 5 etapas e suas características

O gerenciamento de um projeto vem acompanhado de grandes desafios e com o objetivo de minimizar tais desafios. Assim, projetos são normalmente divididos...
HomeProjetosAgilBacklog do Produto - O que é, como construir e priorizar

Backlog do Produto – O que é, como construir e priorizar

Backlog do Produto, ou Product Backlog, é uma lista ordenada de tudo o que é necessário para chegar ao produto final de um projeto de desenvolvimento de software. Em outras palavras, são as “coisas” que devem ser desenvolvidas para chegar àquilo que foi acordado entre todos os envolvidos no projeto — quase uma “lista de desejos”.

Um dos pontos mais importantes presentes no framework Scrum refere-se a criação e manutenção do Backlog do Produto, ou Product 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.

Backlog do Produto

O Backlog do Produto ou 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 Central de Downloads 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 Backlog deverá crescer e mudar na medida em que se conhece o produto e os clientes.

Característica do Backlog do Produto

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.

Backlog do Produto

Durante a reunião Sprint Planning, o Product Owner prioriza os itens do Backlog do Produto 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 Backlog do Produto para o Backlog da Sprint.

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.

gp4us

Conceitualmente, o time inicia do topo da lista priorizada do Backlog do Produto 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 Backlog do Produto pode ser mantido em uma planilha Excel. Um exemplo de um projeto real é apresentado abaixo.

Essa planilha Excel mostra cada item do Backlog do Produto 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 Scrum.

To 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

A criaçã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:

gp4us - Backlog do Produto

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:

gp4us - Backlog do Produto

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 é possível garantir essa condição, tais como servidores, links de acesso, arquitetura do site etc.

Critérios para o Backlog do Produto

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

O requisito 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.

Pode-se 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

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 Backlog do Produto 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.

gp4us

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, 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

  1. Quaisquer outras – breves – informações, esclarecimentos, referências a outras fontes de informação etc.

Exemplo:

IDNomeImportânciaEstimativaDemonstrarNotas
Depósito2116Logar-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 diagrama UML

Priorização do Backlog do Produto

Mantenha o Product Backlog atualizado

Histórias que não estejam mais alinhadas à visão do produto devem ser descartadas do Backlog do Produto.

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 Backlog do Produto, 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 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.

Isso porque 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 do Product 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 Backlog do Produto.

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

Tão importante quando entender os conceitos existentes por traz de um Backlog do Produtoé 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

  • https://www.projectbuilder.com.br/blog/saiba-o-que-e-backlog-e-como-estipular-tempo-para-cada-um/
  • 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.pdf;
  • http://blog.myscrumhalf.com/2014/04/10-dicas-para-melhorar-a-priorizacao-do-product-backlog/

O que é um Backlog do Produto?

Backlog do Produto, ou Product Backlog, é uma lista ordenada de tudo o que é necessário para chegar ao produto final de um projeto de desenvolvimento de software. Em outras palavras, são as funcionalidades que devem ser desenvolvidas para chegar àquilo que foi acordado entre todos os envolvidos no projeto.

Como definir um Backlog?

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.

Pense na aplicação do algoritmo de ordenação “por bolhas” (Bubble Sort) para priorizar o Backlog do Produto: compare os dois itens do topo e troque-os de posição se estiverem na ordem errada.

O que compõe um Produto Backlog?

A criação do Backlog do Produto é construído através do desdobramento das características-chave, estabelecidas na Visão do Produto, em:

  • Requisitos Funcionais;
  • Requisitos não-funcionais.
Backlog do Produto - Passo a passo como construir e priorizarBacklog do Produto - O que é, como construir e priorizar

Este site utiliza cookies para melhorar a sua experiência de navegação. Ao continuar navegando, assumiremos que você consente com isso. Fique à vontade também para ler nossa Política de privacidade. Mais informação

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close