BT

Como dividir User Stories

por Dan Puckett , traduzido por Michel Graciano em 29 Abr 2011 |

Muitas das novas equipes ágeis têm dificuldades em dividir suas user stories ('histórias de usuários') para obter um tamanho pequeno o suficiente de forma a trabalhar bem com técnicas de Agile. Em vários artigos, membros da comunidade Agile fornecem orientações sobre como dividir histórias de forma eficaz.

Há diretrizes gerais que podemos seguir na tentativa de dividir histórias muito longas em histórias menores? Rachel Davies recomenda quebrar cada história de modo a criar um produto que:

  1. Funciona
  2. Agrega valor
  3. Potencialmente gera feedback dos usuários

Richard Lawrence sugere as seguintes técnicas que considera úteis no processo de divisão de histórias longas:

  1. Dividir uma história de acordo com as etapas do fluxo de trabalho envolvido, talvez colocando um caso simples resumindo o fluxo como uma história, e criar histórias independentes para outras etapas do fluxo de trabalho;
  2. Dividir uma história de modo que cada variação das regras de negócio seja a sua própria história;
  3. Dividir uma história em "implementar o primeiro [X]" e "implementar o resto dos [X]s". Isto pode ser aplicado quando o esforço envolvido na execução do primeiro [X] será muito maior do que o de implementação de qualquer um dos [X]s subsequentes;
  4. Quando se deparar com uma história complexa, separar a versão mais simples da história como uma história independente;
  5. Dividir uma história baseando-se nos tipos de dados que manipula;
  6. Dividir uma história pela diferenciação entre um método simples de entrada de dados e um mais complexo;
  7. Mover as considerações sobre desempenho da história atual para uma ou mais novas histórias;
  8. Dividir uma história de acordo com criação, leitura, atualização e exclusão (CRUD), uma ou mais para cada uma dessas ações;
  9. Em última instância, criar uma história para descobrir como implementar uma funcionalidade do sistema.

Rachel Davies oferece outros detalhes sobre como dividir as histórias com relação aos dados de entrada e saída, indicando que se pode criar histórias para cada tela de entrada de informações, ou para cada elemento habilitado na interfa gráfica do sistema.

Além disso, Bob Hartman oferece as seguintes técnicas para divisão de histórias:

  • Em uma história que envolve múltiplas personas, dividi-la por persona;
  • Dividir uma história de forma que as partes de alto risco fiquem separadas das partes de baixo risco;
  • Dividir histórias de forma a maximizar o número de desenvolvedores que podem trabalhar em cada história;
  • Dividir histórias de forma a facilitar os testes;

Quais caminhos para divisão de histórias de usuários você considerou mais úteis?

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

Dividir para feedback mais ágil by Paulo Rebelo

Eu tento seguir os caminhos do Bob Hartman, aliás, histórias com pontuação maior que 8 já pedem para serem quebradas em outras menores. Mas, a técnica não é muito simples, às vezes o time se intimida em quebrar e não observa muitas vantagens, porém, sempre é possível. o Product Owner pode ajudar nisso, já que ele é o que mais entende do negócio, assim ele mesmo se beneficia de obter o feedback mais ágil do resultado de uma determinada história de tamanho menor, encurtando o tempo de desenvolvimento e facilitando os testes. Costumo incentivar a criação de histórias com entrega em 1 dia, nem mesmo necessitando de tarefas atreladas a ela.

Somente diferenciar épicos de histórias não é suficiente by Claudio Pires

Ótimo post, bem aplicado à prática do dia-a-dia! Acho que a união das abordagens "dividir histórias de forma a facilitar os testes" e "dividir uma história de acordo com as etapas do fluxo de trabalho envolvido" é perfeita! Delas, é possível derivar as outras condições desejadas de "agregar valor", "gerar feedback dos usuários" e "isolar diferentes riscos". Começarei a utilizar esses novos caminhos, para não repetir um gráfico de Sprint Burndown "flat" no início da Sprint, até começar a "queima" dos pontos.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber menssagens dessa discussão

2 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT