Atualmente qualquer empresa que queira adotar o Scrum como framework precisa saber o que é e como fazer um Product Backlog. No artigo de hoje iremos explicar tudo o que você precisa saber para entender o que é e como construir um Product Backlog
O que é um Product Backlog
Product Backlog
Bom, começaremos definindo de uma forma sucinta, O Product Backlog é uma lista priorizada da funcionalidade desejada do produto.
Ele fornece uma compreensão centralizada e compartilhada do que construir e da ordem na qual construí-lo.
Itens do Product Backlog
O Product Backlog é composto de itens do Product Backlog ou PBIs.
A maioria dos PBIs são recursos, itens de funcionalidade que terão valor tangível para o usuário e o cliente. Eles geralmente são escritos como histórias de usuários (ou, às vezes, casos de uso ou testes de forma livre).
Outros PBIs incluem defeitos que precisam de reparo, melhorias técnicas, trabalho de aquisição de conhecimento e qualquer outro trabalho que o PO considere valioso.
Características de um bom Product Backlog
Os bons compartilham características semelhantes, que Mike Cohn e Roman Pichler capturaram com o acrônimo DEEP:
Detalhado Apropriadamente
Os itens do backlog do produto serão diferentes em seu nível de detalhe. Aqueles em que trabalharemos mais cedo, aqueles que estão no topo da lista de produtos, serão mais detalhados. Aqueles em que não vamos trabalhar ou algum tempo serão menos detalhados.
Queremos refinar (adicionar detalhes a) itens do backlog à medida que eles sobem em prioridade, adicionando detalhes de maneira justa e justa no tempo.
Emergente
O Backlog do produto é um documento vivo, que muda constantemente conforme o produto é desenvolvido ou mantido. À medida que a equipe e o PO aprendem mais sobre o produto e o mercado, eles podem adicionar novos itens, descartar alguns e alterar outros.
A natureza emergente do backlog do produto não é apenas esperada, mas é um sinal de uma carteira de produtos saudável e funcional.
Estimado
Cada backlog de produto deve ter uma estimativa de tamanho que corresponda ao esforço necessário para desenvolver esse item. O PO usa essas estimativas para ajudar a determinar a prioridade de um item de lista de espera do produto. Idealmente, a maioria dos itens na parte superior do backlog do produto terá tamanho de sprint, pequeno o suficiente para ser trabalhado durante um único sprint.
Priorizado
Um backlog de produto deve ser uma lista priorizada de PBIs, mas nem todo PBI precisa ser priorizado. Recomendação é priorizar sobre um valor de lançamento de PBIs.
Grooming
O Grooming é composto de três atividades principais:
- criar e refinar PBIs,
- estimar PBIs e
- priorizar
Essas atividades ocorrem durante todo o esforço de desenvolvimento do produto.
Grooming é um esforço colaborativo liderado pelo PO (o tomador de decisões) e inclui participação significativa do ScrumMaster, da equipe de desenvolvimento e das principais partes interessadas internas e externas.
No Scrum, grooming pode acontecer muitas vezes, mas na maioria das vezes acontece inicialmente durante o planejamento de lançamento, após as revisões de sprint, e como parte regular de cada sprint (ad hoc, semanal ou uma vez por sprint, dependendo do que faz sentido para o Product Owner e equipe).
Definição de Ready
O resultado final do grooming deve ser que os itens no topo do backlog estão preparados para serem movidos para um sprint.
Algumas equipes formalizam esse estado usando uma lista de verificação pronta para itens do product backlog.
Exemplos de Definição de Preparado (ready)
- O valor comercial é claramente articulado
- Os detalhes são suficientemente compreendidos
- Dependências são identificadas; não existem dependências de bloqueio
- A equipe possui equipe adequada em relação ao PBI
- Estimado e pequeno o suficiente para ser concluído durante o sprint
- Os critérios de aceitação são claros e testáveis
- Os critérios de desempenho, se houver, são definidos e testáveis
- A equipe entende como demonstrar o PBI concluído
Gerenciamento do fluxo
Um bom product backlog permite que a equipe Scrum atinja um fluxo de entrega rápido e flexível na presença de incerteza.
Gerenciamento de fluxo de liberação: O Grooming suporta o planejamento de release contínuo, o fluxo de recursos em um release. Cada lançamento pode ser visualizado por duas linhas que percorrem o backlog do produto, particionando-o em três áreas distintas:
- deve ter,
- bom ter e
- não ter.
Os PBIs acima da linha superior são aqueles que devem estar no lançamento. Aqueles que estão entre a linha superior e a linha inferior são os que seriam “legais de ter”. E os recursos que estão abaixo da linha inferior provavelmente não chegarão ao lançamento.
Gerenciamento de Fluxo de Sprint: A preparação do product backlog deve garantir um bom fluxo de sprint. Imagine ele como um pipeline por meio do qual os recursos do produto fluem em sprints, onde são projetados, construídos e testados pela equipe.
Observe que, como um recurso proposto se aproxima do final do pipeline, ele se torna progressivamente menor e mais refinado.
No momento em que um recurso sai do pipeline de backlog do produto, ele deve estar pronto – detalhado o suficiente para que a equipe possa compreendê-lo e se sentir confortável em entregá-lo durante um sprint.
Quais e quantos products backlog?
Product Backlog
Observe que, como um recurso proposto se aproxima do final do pipeline, ele se torna progressivamente menor e mais refinado.
No momento em que um recurso sai do pipeline de backlog do produto, ele deve estar pronto – detalhado o suficiente para que a equipe possa compreendê-lo e se sentir confortável em entregá-lo durante um sprint.
Grandes produtos – backlog hierárquicos
Sempre que possível, é preferivel um backlog de produto, mesmo para um produto grande como o Microsoft Office. No entanto, às vezes isso não é prático. Nesses casos, algumas organizações usam backlogs hierárquicos, que têm um backlog no topo que descreve e prioriza os recursos de grande escala do produto.
Esse backlog de nível superior é gerenciado pelo proprietário do produto principal.
Em seguida, abaixo do backlog de nível mais alto, há vários backlogs de área, cada um descrevendo uma área de recurso específica e gerenciados por um proprietário de produto designado.
Múltiplas equipes - um product backlog
A regra de um produto e um backlog foi desenvolvida para permitir que todas as equipes do produto compartilhem um product backlog
Isso otimiza a economia porque todos os recursos competem pela prioridade em relação a todos os outros recursos, garantindo que os recursos de prioridade mais alta da perspectiva de produto completo sejam identificados e priorizados de acordo.
Então, se todas as nossas equipes são intercambiáveis, qualquer equipe pode trabalhar em qualquer PBI em um backlog, garantindo que os itens de maior prioridade sejam sempre desenvolvidos primeiro.
Uma equipe - múltiplos produtos
Se uma empresa tiver vários produtos, ela terá vários products backlog. A melhor maneira de lidar com vários é atribuir uma ou mais equipes para trabalhar exclusivamente em cada um.
Se impedimentos organizacionais tornarem isso impossível, e uma equipe precisar trabalhar em vários produtos simultaneamente, considere a fusão dos PBIs dos produtos afetados em um backlog de product.
Isso exigiria que os proprietários de produtos de cada backlog afetado se unissem para alcançar uma única priorização para todos os itens futuros.
Bom, com isso você já tem um bom entendimento sobre o assunto. Obvio que para montar ele completo existem outras questões como histórias de usuário, requisitos não funcionais, nível de detalhe, mas isso fica para um próximo artigo!
Quer entender mais sobre como fazer um product backlog? Entre em contato conosco e leve o Scrum para a sua empresa!
Conclusão
Fique por dentro de nossos conteúdos se cadastrando na nossa newsletter semanal! Clique aqui!
