Como montar um Product Backlog?

Recebo muitas dúvidas sobre o ágil, Scrum, Kanban e outros frameworks. No nosso dia a dia na Sunsetti, vemos muitos times com dificuldades logo no início da aplicação do Scrum e por isso, deixo aqui nossa experiencia de como montar um Backlog do produto.

  • Por onde começar a montar um product backlog? Como faço isso? Tem que ser com histórias de usuário? Tem outras formas de fazer?
  • Como priorizar? No que podemos nos basear para que isso seja feito de forma coerente?
  • Quem é responsável? Quem pode ajudar?

Fazendo um dê / para do que aprendemos com a engenharia de software (ES): dividir os sprints (na grande maioria das vezes) em duas semanas – onde, na ES fala que não tem como entregar valor percebido com prazo menor do que esse.

Respondendo a primeira pergunta “Por conde começar a montar um product backlog?” Tudo se inicia de uma visão de produto (documento onde temos praticamente um business case daquele produto que vamos trabalhar e que foi escolhido de forma estratégica pela empresa). Aqui espera-se ver para quem esse produto está destinado (público / cliente-alvo); que os mesmos estão insatisfeitos ou que tem a necessidade de…; o que será ele; diferente do que temos hoje no mercado (da própria empresa e concorrentes) e qual diferencial. Depois disso, construímos o PB com itens necessários para desenvolver o que é necessário.

Seguindo a ordens das perguntas, as próximas são “como faço isso? Tem que ser com histórias de usuário? Tem outras formas de fazer?”

Geralmente nós usamos as famosas histórias de usuários (users stories) que facilita, e muito, a vida do time Scrum, pois deixa claro para quem estamos trabalhando, qual ação necessária e o porquê. Acredite, isso ajuda muito, pois dependendo o produto que vamos trabalhar, tem usuários que podem ter x opções de acesso enquanto tem outros que não podem ter a mesma visão.

Existem outras formas de construir este artefato (documento) PB, umas delas pode ser com os próprios itens como requisitos lá da engenharia de software, como costumamos montar em projetos tradicionais. Há também várias técnicas para se chegar nesta construção, uma delas que se tornou muito conhecida é a inception, onde reúne várias ferramentas (principalmente de marketing), como mapa de empatia com a criação de personas, jornadas do cliente, features e outros. Também podemos trabalhar com roads maps e muitas outras técnicas de mercado que facilite a elaboração do mesmo.

Depois que temos o PB construído até a parte que conseguimos enxergar (sim, não precisamos criar um PB gigantesco e passar meses tentando imaginar o produto inteiro – lembre-se de um dos valores do ágil: respostas as modificações mais do que seguir um plano) temos um passo de extrema importância para a agilidade, que é:

Como priorizar? No que podemos nos basear para que isso seja feito de forma coerente?

Priorização é parte fundamental para conseguimos fugir do “cascágil” que está acontecendo muito por aí, ou seja, geralmente os times Scrum estão trabalhando com todos os eventos certinho, como está no Scrum Guide, porém, o PB está priorizado em ordem de facilidade. O que temos que fazer aqui e na minha visão é o mais desafiador é encontrar quais requisitos (histórias dos usuários ou outra técnica) são os mais valiosos ao nosso cliente. O que os nossos clientes estão esperando receber em um menor espaço de tempo. Aqui trabalhamos o famoso MVP (em português: mínimo produto viável) – o que faz sentido e o que tem valor de mercado para focarmos e desenvolvermos de forma prioritária. Isso faz toda diferença!

Agora, quem é responsável? Quem pode ajudar?

Essa é uma responsabilidade do Product Owner (PO) e quem pode auxilia-lo é o Scrum Master (SM) – também conhecido como o líder servidor / líder coach que colabora com todos no time para que o Scrum seja adotado conforme está escrito no Guia.

Vou parar por aqui, mas em outros artigos traremos mais e mais detalhes sobre esse mundo maravilhoso do ágil com frameworks que entregam com esse mindset.

Espero que tenha gostado de ficar até aqui comigo e que realmente isso faça sentido para você e sua equipe.

Grande abraço e até mais!

Adriane Colossetti – Família Sunsetti

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

© 2020, Sunsetti. Todos os direitos reservados.