PBB e Histórias de Usuário

O PBB (Product Backlog Building) também é um ótimo método para a identificação de histórias de usuário. Mas, antes lembre-se (Figura 1).

Após a construção do Canvas PBB (problemas, expectativas, propósito, personas, funcionalidades e PBIs), propõe-se que seja feito um mapeamento entre as personas, benefícios de funcionalidades e itens de backlog (PBIs) (cartões) (Figura 2) (Figura 3).

Fique atento aos benefícios identificados para cada funcionalidade, pois eles irão indicar o valor de negócio de cada história de usuário (Figura 4) (Figura 5).

Exemplos de Identificação de Histórias de Usuários (card)

Os exemplos, abaixo, apresentam a relação entre personas e funcionalidades (retiradas de um Canvas PBB). Cada uma das funcionalidades é detalhada em um conjunto de histórias de usuário, representadas pelos seus cards (cartões).

Persona: Palestrante

Funcionalidade 1: Publicar trabalho

• História 1.1: Eu, como palestrante, quero acessar a área de trabalho para gerenciar de forma privada.
• História 1.2: Eu, como palestrante, quero realizar a publicação de trabalho para disponibilizar conteúdo.
• História 1.3: Eu, como palestrante, quero linkar a apresentação externa para integrar trabalhos.

Persona: Participante

Funcionalidade 2: Participar de evento

• História 2.1: Eu, como participante, quero localizar evento disponível para visualizar programação.
• História 2.2: Eu, como participante, quero efetuar a inscrição no evento para consumir conteúdo.
• História 2.3: Eu, como participante, quero registrar check-in no evento para confirmar presença.

Persona: Organizador

Funcionalidade 3: Organizar evento

• História 3.1: Eu, como organizador, quero definir programação do evento para divulgar a grade.
• História 3.2: Eu, como organizador, quero divulgar evento nas mídias para atrair público.
• História 3.3: Eu, como organizador, quero convidar coorganizadores do evento para facilitar organização.

Histórias de Usuários, Critérios de Aceitação e BDD

Após a identificação das histórias de usuários é preciso que sejam estabelecidos seus critérios de aceitação. Para tanto, é possível que seja utilizada uma lista de critérios ou, a técnica BDD (Behavior Driven Development).

É importante destacar que, o backlog de projetos ágeis é flexível e deve ser constantemente refinado ao longo do tempo. Neste sentido, o estabelecimento dos critérios de aceitação ou dos BDDs deve ser feito como uma das primeiras atividades de cada Sprint. Onde, a equipe de desenvolvimento, juntamente com o Dono do Produto (ou Líder da StartUp) chegam a um acordo e combinam o que deverá ser entregue em cada história.

Ao final da Sprint, durante a atividade de Avaliação das Entregas, presente na Fase de Execução do Guia para o Desenvolvimento de Produtos e Soluções (GPS), o Dono do Produto deve verificar se cada um dos critérios de aceitação ou BDDs estão satisfeitos no produto entregue.

Critérios de Aceitação

São consideradas descrições textuais, as quais expressam as condições para o aceite (validação) de uma história de usuário. Ou seja, são “os combinados” firmados entre o Dono do Produto ou Líder da StartUp e equipe de desenvolvimento, para o aceite de uma história de usuário. Cada história poderá possuir uma lista de critérios, a qual indica quando uma história de usuário está concluída e funcionando (ver Definição de Pronto). A partir dos critérios de aceitação, todos os envolvidos podem saber se a história está completa.

Exemplo de Critérios de Aceitação

História de Usuário (Cartão): Eu, como cliente, quero poder sacar dinheiro no caixa eletrônico para evitar a fila do banco.

Critérios de Aceitação:

• O cliente com saldo suficiente consegue sacar dinheiro da sua conta.
• O cliente sem saldo suficiente não consegue sacar dinheiro da sua conta.
• O cliente com saldo suficiente não consegue sacar dinheiro da sua conta se o caixa eletrônico não tiver dinheiro suficiente para o saque.

Behavior Driven Development (BDD)

BDD é uma especificação em linguagem natural utilizada para validar os critérios de aceitação de uma história de usuário. Segue a perspectiva de desenvolvimento orientada a especificações. Com a utilização de cenários de BDD a lista de critérios de aceitação pode ser substituída por um ou mais cenários. A escrita de um cenário é estruturada, como segue:

• Cenário (título do cenário)
• Dado que (contexto inicial)
• Quando (evento ou ação realizada)
• Então, (resultado esperado)

Cabe destacar que os cenários devem ser escritos utilizando dados concretos que simulem uma situação real, e não de maneira genérica.

Exemplo de BDD

História de Usuário (Cartão): Eu, como cliente, gostaria de sacar dinheiro no caixa eletrônico para evitar a fila do banco.

Cenário (BDD):

• CENÁRIO: Saque disponível.
• Dado que o cartão é válido e a conta tem saldo maior que R$ 500,00
• Quando o cliente solicitar o saque de R$ 500,00
• Então, o caixa eletrônico deve dispensar R$ 500,00.

Referências Bibliográficas

• Aguiar, F. e Caroli, P. Product Backlog Building: Um guia prático para a criação e refinamento de backlog para produtos de sucesso. Editora Caroli, RJ. 2021.
• Aguiar, F. Scrum PBB. Disponível em: http://www.productbacklogbuilding.com/slides/ScrumPBB.pdf