Como criar um Product Backlog? - Mirelly Nogueira
Você notou na figura que representa o Ciclo do Scrum, que o Product Backlog é algo que magicamente está pronto?
Você já foi em cursos sobre o Scrum onde os instrutores explicam todas as cerimônias, papéis e artefatos, e quando chega no Product Backlog, passam voando?
O que os instrutores não contam a vocês (e para mim também) é que para o Product Backlog aparecer assim pronto, é necessário muito trabalho e o principal ator é o Product Owner (PO).
Como começar o Product Backlog?
O Product Backlog é o detalhamento das funcionalidades do produto. É a parte mais importante do Scrum, sem ele não há Scrum. Para iniciar o trabalho existe uma etapa denominada de "Preparação".
A etapa de preparação consiste no Product Owner definir junto ao cliente o Produto e seu Roadmap. Geralmente usamos o método de Lean Inception, que além de colaborativo, provê alinhamento do grupo de pessoas sobre o produto mínimo viável (MVP) a ser construído.
O MVP é uma versão simples para um produto que pode ser negociado sem maiores problemas. Ou seja, ele determina quais são as características básicas necessárias ao produto funcional para que ele agregue valor e possa ser comercializado pela empresa – para, em seguida, receber upgrades de acordo com os feedbacks dos early adopters (primeiros usuários do produto).
Com isso, nasce as primeiras estórias de usuário ou user story se preferir, que irão compor o seu Product Backlog.
O que é uma user story? Como fazer?
Uma estória de usuário pode ser caracterizada como uma curta e simples descrição da necessidade do cliente.
Normalmente é contada a partir da perspectiva de quem precisa da nova necessidade, sendo geralmente um usuário, cliente do sistema ou representante de negócios do cliente.
Uma estória de usuário deve explicar bem para quem, o que e por que está sendo criada. Isso é importante, principalmente, para desenvolvedores que poderão construir os sistemas com menor dificuldade e maior qualidade, entendendo os objetivos e necessidades do cliente de forma mais rápida.
É normal escrever uma estória de usuário em post-it's, fichas ou notas onde o espaço é escasso justamente para ser breve e objetivo.
Concluída a etapa de preparação, inicia-se o release planning. Onde é definido um plano de alto nível que possibilita a visão a longo prazo do que será feito, quais recursos serão implementados e quando serão concluídas.
Para criar um Release Planning você precisará dos seguintes itens:
1) Datas de início e fim dos Sprints;
Papel do Scrum Master, planejar o Release planning e levantar as datas de início e fim da sprint, bem como feriados e férias previstas dentro do time.
2) Product Backlog escrito e priorizado;
O Product Owner já terá escrito as estórias de usuário na etapa de "Preparação". Cabendo agora a priorização e mensurar junto com o time a quantidade de esforço que será necessário em cada estória.
3) Velocidade Média do Time (envolve quantidade de pessoas no projeto);
A velocidade do time é a quantidade de pontos de estórias que eles conseguem fazer por sprint. Se for um time novo, você não terá essa métrica, partindo assim de uma estimativa que será ajustada ao longo do tempo, quando o time passa a se conhecer mais.
Paramos por aqui…
Desse ponto em diante, inicia-se as cerimônias e sprints do Scrum. Partes estas que você sempre ouve nos treinamentos.
A ideia desse artigo era te apresentar essa parte inicial que geralmente não é dita a você.
Para montar o Product Backlog do produto mais importante: Você. Eu usei essas etapas, fiz o Lean Inception para definir minha visão de futuro da vida profissional, pessoal e emocional (meu MVP está descrito nestas fichas rosas maiores) e criei meu backlog (post it's menores). E semana passada já movimentei duas estórias para o "Fazendo", que possuem 13 e 5 pontos, respectivamente.