Como fazer o Product Backlog
O 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 modelo tradicional de gestão de projetos, […]
O 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 modelo tradicional 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”.
Para te ajudar a combinar a gestão convencional com um framework mais ágil preparamos esse artigo onde descrevemos como fazemos aqui na Project Builder para criar nosso Product Backlog. Confira:
Uma mudança muito clara no mindset é que no início do projeto o Product Backlog não precisa estar completo. Podemos ter uma visão macro do produto e dos requisitos esperados. Conforme avançamos no projeto, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Para melhor estruturar o Product Backlog nós utilizamos as chamadas estórias — itens do Product Backlog — elas contém a descrição detalhada dos requisitos de cada solicitação a ser implementada. Em nossas estórias incluímos os seguintes campos:
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 estórias.
Nome
Um nome curto e descritivo para a estó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 estórias. Normalmente usamos de 2 a 10 palavras.
Importância
Definir qual é importância dessa estó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 estó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 estó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 estória.
Como demonstrar
Em alto nível criamos uma descrição de como a estó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
Quaisquer outras – breves – informações, esclarecimentos, referências a outras fontes de informação etc.
Aqui na Project Builder já tentamos outros campos, mas ao final do dia os seis campos citados acima eram os únicos realmente utilizamos Sprint após Sprint. Normalmente fazemos isso em um projeto no Project Builder, onde agrupamos em uma única fase todas as estórias do Product Backlog.
Oficialmente o Product Owner é o responsável pelo documento, mas nós não queremos deixar os outros usuários de fora. Várias vezes um desenvolvedor acessa a fase para esclarecer algo ou para alterar uma estimativa. Se você for utilizar o Excel, é importante que a planilha esteja compartilhada via Dropbox ou Google Docs.
Preparamos um exemplo de planilha que você pode baixar para utilizar na sua empresa.
Nos conte como está seu Product Backlog.
O 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 modelo tradicional de gestão de projetos, […]
O 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 modelo tradicional 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”.
Para te ajudar a combinar a gestão convencional com um framework mais ágil preparamos esse artigo onde descrevemos como fazemos aqui na Project Builder para criar nosso Product Backlog. Confira:
Uma mudança muito clara no mindset é que no início do projeto o Product Backlog não precisa estar completo. Podemos ter uma visão macro do produto e dos requisitos esperados. Conforme avançamos no projeto, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.
Para melhor estruturar o Product Backlog nós utilizamos as chamadas estórias — itens do Product Backlog — elas contém a descrição detalhada dos requisitos de cada solicitação a ser implementada. Em nossas estórias incluímos os seguintes campos:
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 estórias.
Nome
Um nome curto e descritivo para a estó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 estórias. Normalmente usamos de 2 a 10 palavras.
Importância
Definir qual é importância dessa estó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 estó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 estó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 estória.
Como demonstrar
Em alto nível criamos uma descrição de como a estó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
Quaisquer outras – breves – informações, esclarecimentos, referências a outras fontes de informação etc.
Aqui na Project Builder já tentamos outros campos, mas ao final do dia os seis campos citados acima eram os únicos realmente utilizamos Sprint após Sprint. Normalmente fazemos isso em um projeto no Project Builder, onde agrupamos em uma única fase todas as estórias do Product Backlog.
Oficialmente o Product Owner é o responsável pelo documento, mas nós não queremos deixar os outros usuários de fora. Várias vezes um desenvolvedor acessa a fase para esclarecer algo ou para alterar uma estimativa. Se você for utilizar o Excel, é importante que a planilha esteja compartilhada via Dropbox ou Google Docs.
Preparamos um exemplo de planilha que você pode baixar para utilizar na sua empresa.
Nos conte como está seu Product Backlog.