PBI vs História do Usuário

Recentemente, um item foi adicionado ao Backlog do Produto pelo proprietário do produto, que diz "Quando vou à página de login da página x, vejo um erro. Quero que esse erro seja removido".

Parece-me que este não é um caso de uso e não deve ser um PBI (Item de Backlog do Produto). No entanto, quando discuti o assunto, o scrum master me disse que as histórias de usuários não são PBIs e, um PBI poderia ser um relatório de bug, uma tarefa, uma história de usuário, qualquer coisa e literalmente qualquer item que devesse ser tratado primeiro.

Eu não tenho certeza sobre isso. Também não consigo encontrar uma boa definição de PBI na web . Então, minha pergunta é: que tipo de coisas podem entrar no Backlog do produto como itens? Um item de lista de pendências de produtos é mapeado para uma história de usuário? Eles são os mesmos?

Um item de lista de pendências de produtos é mapeado para uma história de usuário? Eles são os mesmos?

Não necessariamente, mas em geral, eles fazem. Como seu scrum master disse, outras coisas também podem ser itens de lista de pendências de produtos. No entanto, depende de como o seu SCRUM funciona. Algumas equipes têm uma lista de pendências separada, que também é levada em consideração para sprints, enquanto outras mantêm essas coisas na lista de pendências do produto.

Dois logs separados tornam mais difícil para o proprietário do produto priorizar tarefas, pois agora dois logs devem ser levados em consideração para o próximo sprint. Mas eles oferecem uma supervisão melhor e ambos podem ser priorizados separadamente.

Então, minha pergunta é: que tipo de coisas podem entrar no Backlog do produto como itens?

Isso pode ser qualquer coisa que faça parte da visão do produto e da jornada para o produto que você deseja criar. Ele geralmente contém requisitos (histórias de usuários), mas também pode conter ações ou itens técnicos que não pertencem diretamente ao produto (por exemplo, "Compre um novo servidor para a equipe de desenvolvimento", "Criar anúncio para o produto"). A lista de pendências deve evitar detalhes desnecessários e não deve tentar gerenciar coisas técnicas. O backlog do produto pode conter qualquer coisa que agregue valor ao produto.

Não existe o único Scrum verdadeiro. Às vezes, as listas de pendências separadas são a melhor maneira de gerenciar o produto; outras, elas estão apenas no caminho. Descubra o que funciona melhor para você.

Ao trabalhar com bugs, nós os adicionamos ao backlog e os chamamos de histórias de bugs . Ao adicionar correções de erros ao backlog dessa maneira, fica claro que não é apenas a correção de erros. Podemos adicionar outras tarefas para garantir que os testes automatizados sejam gravados e a verificação feita. Também torna mais explícito que o Departamento de Defesa deva ser seguido.

Nunca usamos o termo PBI (embora nossa ferramenta de registro em atraso os chame assim), sempre são histórias de usuários, histórias de bugs ou simplesmente histórias .

É principalmente apenas a escolha da terminologia da sua equipe e desde que você tenha certeza do que realmente não importa.

Todas as respostas acima falham ao referenciar o documento de origem autoritativo para a estrutura Scrum: O Guia Scrum .

Lista de produtos pendentes

Há uma seção que descreve o Backlog do produto e os itens, geralmente chamados de PBIs, contidos nele.

O Product Backlog lista todos os recursos, funções, requisitos, aprimoramentos e correções que constituem as alterações a serem feitas no produto em versões futuras.

Mas não é fixo como um plano de projeto.

O Backlog do Produto evolui conforme o produto e o ambiente em que será usado. O Backlog do produto é dinâmico; muda constantemente para identificar o que o produto precisa ser apropriado, competitivo e útil.

História do usuário

O termo história do usuário nunca aparece no The Scrum Guide porque

é uma estrutura na qual você pode empregar vários processos e técnicas.

Usar uma história de usuário é apenas uma técnica possível para gravar os PBIs.

ADICIONALMENTE: Embora seja comum visualizar o formato "Como eu quero, para que", ele pode ser contrário à sua intenção original . Esse formato problemático também foi abordado no Agile 2017 .

A @Falcon explicou bem isso. Uma página que tem uma definição formal é: http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog O que você descreveu não deve ser colocado no backlog do produto de acordo com essa descrição, pelo menos.

Há um mal-entendido comum de que apenas histórias de usuário são permitidas em um Backlog do Produto. Por outro lado, o Scrum é neutro em técnicas de requisitos. Como afirma o Scrum Primer ,

Os itens do backlog do produto são articulados de maneira clara e sustentável. Ao contrário do mal-entendido popular, o Backlog do Produto não contém "histórias de usuários"; simplesmente contém itens. Esses itens podem ser expressos como histórias de usuários, casos de uso ou qualquer outra abordagem de requisitos que o grupo considere útil. Seja qual for a abordagem, a maioria dos itens deve se concentrar em agregar valor aos clientes. *

• Especificações distintas de alterações e adições ao produto são denominadas PBIs (Product Backlog Items), que juntos formam o Backlog do Produto.
• Cada PBI descreve algo que os Desenvolvedores podem desenvolver e fornecer para agregar valor às partes interessadas relevantes quando Concluído (consulte Definição de Concluído).
• A parte interessada mais comum é o mercado ou seu representante - o Dono do Produto.
• No entanto, um PBI pode descrever um trabalho que reduz os custos para a empresa ou reduz o esforço para a Equipe de Desenvolvimento, ou uma ferramenta que ajuda a Equipe Dono do Produto a realizar melhor seu trabalho.
• Um PBI pode descrever qualquer coisa que tenha valor potencial para uma parte interessada.

Uma história (do usuário) é um formato padrão útil para itens de lista de pendências. A lógica por trás disso é "se ninguém se importa com isso, não perca tempo com isso". Também permite que o OP avalie a urgência do item, pois define para quem você o fará e quão ruim é.

No seu caso, o bug pode ser facilmente formatado como uma história.

• Como usuário
• Quero poder fazer logon na página X (e não receber um erro)
• para não perder tempo, ficar chateado e perder a fé no produto

Parece que vale a pena algum esforço.