Antes de começar falando como montar um Product Backlog (PB), você sabe o que ele é e representa em um projeto?
Quem é o responsável por ele?
Como o Scrum master auxilia nesse processo?
Bom, o Product Backlog é um artefato do framework Scrum, é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos requisitos para qualquer mudança a ser feita no produto/Serviço.
Costumamos dizer que o Product Backlog é um artefato vivo, porque ele nunca está completo. No início do desenvolvimento estabelecemos os requisitos inicialmente conhecidos e entendidos, onde, ele acaba sendo dinâmico, mudando constantemente para identificar o que o produto necessita e ser mais apropriado ao projeto.
“Se um produto existe, seu Backlog do Produto também existe.” Scrum Guide
O Responsável pela criação e priorização do Product Backlog é do Product Owner, o Scrum Master o auxiliar caso necessário, além de atuar como um facilitador garantindo que o escopo e domínio do produto sejam entendidos por todos do time, ajuda no gerenciamento efetivo do PB e garante que o Product Owner o priorize de forma que maximize o valor para o cliente.
Agora você deve estar se perguntando: Ok, entendi o que ele é, mas por onde começo?
O Scrum Guide não define regras, técnicas ou ferramentas para isso, comenta que deve ser claro e entendível para o time Scrum. Então, vou lhes contar como eu costumo fazer e tenho êxito.
1º passo: Se você não tem uma visão do que será o produto/serviço, aconselho que faça um Design Thinking, Design Sprint ou Lean Inception.
Por exemplo, não costumo seguir esses três métodos ao pé da letra, mas faço uma ou mais reuniões se necessário com os stakeholders e parte do time e monto o Canvas de negócio, Personas, Jornada das personas e com isso uma matriz de features. A partir das features consigo ter uma visão do que será necessário no projeto e criar as Histórias de usuário (User Story) em cima delas.
História de usuário é uma técnica muito utilizada no mercado para escrita de requisitos, que vem do Extreme Programming. É de responsabilidade do Product Owner, ele não tem, necessariamente, que utilizar e até pode delegar, mas não delargar, e cada uma representa apenas um item do Product Backlog. A história deve ser bem clara e entendível que até mesmo pessoas de fora do time Scrum que tenham minimamente entendimento do que é o produto entendam qual valor aquela história irá entregar.
O Product Owner não precisa ter conhecimento técnico, apenas escrever boas histórias e o INVEST, criado pelo Bill Wake, auxilia com isso, tendo em vista que é um lembrete de boas práticas para um entendimento claro do que uma história precisa ter/ser.
O INVEST, inclusive, é recomendado por Mike Cohn.
Independente (I) – As histórias precisam ser o mais independente possível, ou seja, que não tenha dependência com outra. Assim elas podem ser repriorizadas com mais facilidade e no caso de estimada não precisar alterar. Lembrando que uma história é uma funcionalidade de ponta a ponta que traz valor ao cliente.
Negociável (N) – Histórias não são contratos, seus detalhes serão negociados e definidos entre o time Scrum e pessoas de negócio se necessário.
Valiosa (V) – Precisam representar valor ao cliente, e se for necessário quebrar, é importante lembrar que a história menor deve ter o mesmo valor ao produto e que uma história é uma funcionalidade de ponta a ponta e não apenas uma parte de um trabalho técnico.
Estimável (E) – O Time de desenvolvimento deve possuir detalhes o suficiente, tanto técnico como de negócio, para estimar o esforço em transformar uma história em uma parte da funcionalidade do produto. Claro que o time não precisa acertar sempre essa estimativa. Caso o time não utilize estimativa, os detalhes são importantes para dividir de forma que fiquem pequenas o suficiente para serem desenvolvidas na sprint.
Pequena (P) – História pequenas e bem detalhadas podem ser colocadas em desenvolvimento, tendo uma melhor precisão na estimativa, permitindo uma melhor priorização do Product Backlog e evitando que mais histórias entre na sprint, passando a capacidade do time.
Testável (T) – Testar é fundamental para verificar se a história está pronta, ou seja, foi transformada em parte do produto como algo de valor. A validação é feita pelos critérios de aceite e regra de negócio.
Agora vamos ver um exemplo de como ficaria um item do Product Backlog feito com História de Usuário e o INVEST (Lembrando que isso não é uma regra, apenas prática de mercado).
Vamos imaginar que temos que construir um produto de e-commerce de vendas de roupa e o cliente quer que o pagamento seja feito por boleto.
Partindo do princípio de que todas as features foram levantadas, pegamos o pagamento de boleto como exemplo.
“Como um cliente (Usuário final), eu quero que seja disponibilizado pagamento por boleto bancário, para pagar meu pedido.”
Veja que é uma história pequena, objetiva, independente, estimável e traz valor para o cliente final.
Agora, um exemplo de uma história que não é pequena e nem independente:
Quando pensamos em “formas de pagamento”, podemos ter boleto, cartão de débito e cartão de crédito, além de todas as bandeiras de cartões. Sendo assim, poderíamos levar isso como um Épico, onde, dentro dele estaria diversas histórias para cada cartão com sua respectiva bandeira.
Depois de concluir todas as histórias de usuário do seu Product Backlog (ou parte delas para o início do desenvolvimento) vem o Refinamento.
O Refinamento é a ação de adicionar detalhes, estimativas e ordem aos itens do Product Backlog, este processo é contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos itens, normalmente, só são refinados os itens que entrarão na próxima Sprint e o Time de Scrum decide como e quando o refinamento está “Pronto”.
Este refinamento usualmente não consome mais de 10% da capacidade do Time de Desenvolvimento. Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do Product Owner.
Também como boa prática de mercado é utilizado uma ferramenta chamada 7 dimensões do produto, onde, você tem os Autores, Ações, Regras de negócio, Dados, Interfaces, Ambiente e Qualidade. Ela auxilia o time em um direcionamento de detalhamento e não é necessário utilizar todas as dimensões.
Vamos continuar com o exemplo do boleto, se fossemos refinar essa história, como ficaria?
“Como um cliente (usuário final), eu quero que seja disponibilizado pagamento por boleto bancário, para pagar meu pedido.”
Autor e Ação já temos descrita na própria história:
Autor – Cliente (usuário final).
Ações – Disponibilizar pagamento por boleto no e-commerce.
Regra de negócio
- O boleto gerado tem um prazo máximo de 3 dias para o vencimento.
- O produto só pode começar a ser processado após a confirmação do pagamento do boleto.
Qualidade – Critério de aceite
- O cliente pode escolher a data de vencimento do boleto, desde que o prazo máximo seja 3 dias.
- Não pode gerar boleto para o mesmo dia se for mais que 17:00 horas.
O Refinamento da história de usuário acima é apenas um exemplo de como usar a ferramenta a seu favor para detalhar, fazendo com que o time de desenvolvimento tenha um entendimento claro do que precisa ser feito naquele item em especifico e uma transparência de quando o item atende a definição de concluído acordada entre todos.
Como dito anteriormente, o Scrum não dita nem técnicas e nem ferramentas, mas esse processo de criação de Product Backlog é muito usado no mercado e tem surtido muitos cases de sucesso.
Espero ter me feito entender e de alguma forma ter contribuído para um melhor entendimento do que é e como criar um Product Backlog.
Fico à disposição para ajudar naquilo que puder.
Amanna Monteiro
