Conheça o processo Criar Histórias de Usuário - SBOK SCRUMstudy

Conheça o Processo Criar Histórias de Usuário no Gerenciamento Ágil de Projetos

Conheça o Processo Criar Histórias de Usuário no Gerenciamento Ágil de Projetos

Neste artigo, apresentaremos o processo Criar Histórias de Usuário, da fase Planejar e Estimar do Scrum de acordo com o Scrum Body of Knowledge, da SCRUMstudy. A fase Planejar e Estimar é composta por 5 processos. Além da fase Planejar e Estimar, existem ainda outras 4 fases: Iniciar, Implementar, Revisão e Retrospectiva e Release.

Carreiras Site Campus

Propósito do Processo Criar Histórias de Usuário

Este processo tem por objetivo absorver a noção de alto nível do escopo do projeto construída na fase Iniciar apresentada pelo SBOK quanto ao Scrum e refinar esta noção e quebrá-la em partes menores. Quando começamos a trabalhar nos épicos, que são grandes entregas, estas entregas ainda não tem uma forma clara. A partir do momento em que criamos as histórias de usuário, os épicos se tornam tangíveis, pois eles agora podem ser desenvolvidos dentro de ciclos de produção menores, gerenciáveis, a partir de uma abordagem cartesiana.

Se para construir um avião precisamos de uma asa e para construir uma asa precisamos de flaps e de design, então podemos agora criar este avião dentro de ciclos curtos de iteração onde primeiro entregaremos o design, depois os flaps até chegarmos no ciclo final da construção da asa onde vamos integrar todas estas partes. Isso é desenvolver os épicos, o backlog do produto, planejar a entrega (ou release) e posteriormente refinar os épicos e o backlog por meio das histórias de usuário até que possamos partir para a ação. Está claro? Deixe seus comentários. Antes de partirmos para ação, contudo, ainda será preciso comprometer as histórias de usuário. Acompanhe o próximo artigo desta série, onde falaremos sobre o tema – neste, falaremos apenas das histórias de usuário!

Conheça o Processo Criar Histórias de Usuário no Gerenciamento Ágil de Projetos

Entradas

Time Central Scrum*

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Entrada obrigatória neste processo!

Backlog Priorizado do Produto*

Já descrito no artigo sobre o processo Criar o Backlog Priorizado do Produto, clique aqui para conferir.

Entrada obrigatória neste processo!

Critérios de Pronto*

Já descrito no artigo sobre o processo Criar o Backlog Priorizado do Produto, clique aqui para conferir.

Entrada obrigatória neste processo!

Personas*

Já descrito no artigo sobre o processo Criar o Backlog Priorizado do Produto, clique aqui para conferir.

Entrada obrigatória neste processo!

Stakeholders

Já descrito no artigo sobre o processo Criar a Visão do Projeto, clique aqui para conferir.

Épicos

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Requisitos de Negócio

Já descrito no artigo sobre o processo Criar o Backlog Priorizado do Produto, clique aqui para conferir.

Leis e Regulamentos

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Contratos Aplicáveis

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Recomendações do Scrum Guidance Body

Já descrito no artigo sobre o processo Criar a Visão do Projeto, clique aqui para conferir.

Ferramentas

Expertise de Escrever Histórias de Usuário*

De acordo como SBOK:

O Dono do Produto, com base na sua interação com os stakeholders, conhecimento do negócio e expertise, e inputs do time, desenvolve as Histórias de Usuário que formarão o primeiro Backlog Priorizado do Produto para o projeto. O Backlog Priorizado do Produto representa a soma total do que deve ser concluído para o projeto. O objetivo deste exercício é criar as Histórias de Usuário elaboradas e refinadas que podem ser aprovadas, estimadas e comprometidas pelo Time Scrum. Às vezes, o Dono do Produto pode trazer um Analista de Negócios para ajudar a escrever as Histórias de Usuário. Embora o Dono do Produto seja o responsável principal por escrever as Histórias de Usuário, um Workshop de Escrita da História de Usuário pode ser realizado.

Ferramenta obrigatória neste processo!

Workshops de Histórias de Usuário

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Reuniões de Grupos de Usuário

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Reuniões de Grupos de Foco

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Entrevistas

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Questionários

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Métodos de Estimativa de Histórias de Usuário

De acordo com o SBOK:

Todas as ferramentas utilizadas no processo de Aprovar, Estimar e Comprometer as Histórias de Usuário podem ser usadas na criação de estimativas de alto nível para os Épico(s) quando o Backlog Priorizado do Produto é criado e podem ser utilizadas também na Criação de Histórias do Usuário. Algumas destas ferramentas são importantes e melhor descritas no link acima para o processo de Aprovar, Estimar e Comprometer as Histórias de Usuário:

1. Reuniões de Grupo de Usuários

2. Planejamento Poker

3. Fist of Five Pontos para a Estimativa de Custos

4. Outras Técnicas de Estimativa

Expertise do Scrum Guidance Body

Já descrito no artigo sobre o processo Desenvolver os Épicos, clique aqui para conferir.

Saídas

Histórias de Usuário*

Uma história de usuário definirá, essencialmente, “quem”, “o quê” e “como”. Podem ser escritas em um pedaço adesivo de papel (post-it) ou em um software, mas são simples. Elas vão representar os desejos e necessidades do cliente. Quando estes desejos um necessidades são muito grandes, vão levar tempo demais para fazer, são consideradas épicos. Épicos são quebrados em histórias de usuário menores, para melhor gerenciar o trabalho. É das histórias de usuário que podemos estimar as tarefas, que vão resultar na entrega daquela história de usuário.

Este conjunto de itens (épicos, histórias de usuário e tarefas) comporão o backlog priorizado do produto, que deve ser gerenciado pelo Dono do Produto. Apesar de todo o time e também partes interessadas poderem participar da construção destas histórias e épicos, é papel do Dono do Produto se responsabilizar por elas. Se ninguém mais escrever, ele deve escrever e garantir que os interesses dos clientes estejam representados nestas histórias e épicos. Com o passar do tempo, as histórias serão refinadas e isso nos levará também ao refinamento do backlog do produto.

Confira um exemplo de história de usuário, de acordo com o SBOK:

Formato da História de Usuário:

Enquanto <papel/persona>, Eu deveria ser capaz de solicitar um <requisito> afim de que adquirir um <benefício>.

Exemplo de uma História de Usuário:

Enquanto administrador do banco de dados, eu deveria ser capaz de reverter um número selecionado de atualizações, para que a versão desejada seja restaurada.

Lembre-se, também, de revisar o conceito de persona. Personas são as pessoas que supostamente escreveram cada história de usuário. Uma persona pode ser um administrador de empresas interessado em mais faturamento, enquanto outra pode ser um gerente de estoques preocupado com a eficiência dos processos. É preciso criar e refinar as personas, também.

Saída obrigatória neste processo!

Critérios de Aceitação da História de Usuário*

Critérios de aceitação são criados pelo Dono do Produto a partir dos interesses do cliente e não podem ser modificados quando o time de desenvolvimento iniciar a construção daquela história de usuário ou épico. Enquanto o time trabalha, o Scrum Master deve garantir que o Dono do Produto não modifique estes critérios. Se necessárias modificações, então deve ser interrompida a Sprint.

Os critérios de aceitação devem ser registrados juntos com a história de usuário. Se estão sendo utilizados papéis adesivos, como post-its, então o Dono do Produto pode escrever os critérios de aceitação no verso da história de usuário ou épico.

Critérios de aceitação devem ser SMART – específicos, mensuráveis, alcançáveis (fazíveis), realistas e tangíveis. Se forem abstratos, devem ser refinados pelo Dono do Produto. Um exemplo de critério de aceitação pode ser “determinada funcionalidade deve estar disponível 95% do tempo e permitir que todas as requisições de clientes sejam atendidas dentro dos termos contratuais da empresa e deve ser vinculada com as funções A, B e C”. Também precisamos trabalhar com a definição de pronto, afinal de contas, o que é pronto no projeto em pauta? 100% funcional? 90% funcional? Mas o que é funcional? Pense nisso!

Saída obrigatória neste processo!

Backlog Priorizado do Produto Atualizado

Já descrevemos esta atualização no item sobre as histórias de usuário, a primeira das saídas deste processo. Enquanto você cria histórias de usuário, está naturalmente refinando e atualizando o backlog do produto – considerando que você seja o Dono do Produto ou que esteja administrando este esforço.

Personas Atualizadas ou Refinadas

De acordo com o SBOK:

As Personas são inicialmente criadas durante o processo de Desenvolver os Épico(s). Enquanto as Histórias de Usuário estão sendo escritas, o Time Scrum pode chegar a uma decisão coletiva de que algumas dessas Personas iniciais são inadequadas e precisam ser refinadas. Normalmente, se o refinamento de Personas for necessário, este será feito próximo ao final do processo de Criar as Histórias de Usuário.

Deixe seus comentários!


#
Compartilhe!
Fale com o Site Campus!

Tags: , , , ,