5 Erros ao Dividir User Stories e Como Evitá-los

Antes de iniciar uma iteração, as User Stories selecionadas precisam ser pequenas o suficiente para serem concluídas dentro dessa iteração. Por isso, dividir User Stories é uma habilidade essencial para times ágeis.

Ainda assim, todos nós já enfrentamos dificuldades ao dividir User Stories. Muitas dessas dificuldades surgem de uma série de erros bastante típicos. Neste artigo, você vai descobrir quais são os cinco erros mais comuns ao quebrar User Stories e como evitá-los.

Erro #1: Dividir histórias é tarefa do Product Owner

No topo da lista de problemas ao dividir User Stories está a crença de que o splitting de stories é tarefa exclusiva do Product Owner. Quando um Product Owner divide as User Stories sozinho, é bastante provável que as "Sub Stories" resultantes não sejam divididas de forma muito útil.

Como a maioria dos Product Owners tem pouca ou nenhuma experiência técnica, frequentemente dividem uma User Story em cinco stories menores, por exemplo, das quais uma contém 99% do trabalho. Dividir uma story dessa forma não ajuda em nada. Da mesma forma, um Product Owner sem conhecimento técnico pode criar stories com dependências que impedem a equipe de concluí-las em uma iteração.

Embora o splitting de stories não deva ser visto como tarefa exclusiva do Product Owner, o P.O. deve definitivamente estar envolvido. A responsabilidade também não deve recair apenas sobre a equipe de desenvolvimento. Para dividir stories de forma ideal, o Product Owner precisa participar.

O Story Splitting é, portanto, uma tarefa de toda a equipe. No entanto, isso não significa que toda a equipe deva estar envolvida todas as vezes. Significa apenas que não devem ser sempre as mesmas uma ou duas pessoas responsáveis por isso.

Em vez disso, talvez dois membros da equipe ajudem o Product Owner a dividir uma ou duas stories. Mais tarde, outros membros da equipe podem ajudar o Product Owner com outra story.

Minha recomendação seria discutir o Story Splitting no Daily Scrum. O Product Owner menciona, por exemplo, que nos próximos dias três User Stories precisam ser divididas para o próximo Sprint. Alguns dos desenvolvedores podem ter tempo para ajudar, e já no Daily Scrum pode-se combinar um horário para discutir as stories.

Erro #2: Dividir Stories por caminhos técnicos

Mesmo que eu sempre diga às equipas que a equipa de desenvolvimento deve ser envolvida na divisão de User Stories, isso pode levar a outro problema: dividir User Stories com base em questões técnicas em vez de funcionais.

Certamente já conheces este problema. Frequentemente, estas stories são escritas assim:

„Como programador, eu quero…"

Descrevem a funcionalidade mais da perspetiva da equipa do que da perspetiva do utilizador final ou dos stakeholders.

Isso pode levar a stories como estas:

• Como utilizador, quero um back-end que faça isto e aquilo.
• Como utilizador, quero um front-end que também faça isto e aquilo.
  Uma boa story deve abranger toda a tecnologia ou pelo menos o suficiente para entregar uma funcionalidade. Dividir stories ao longo de fronteiras técnicas cria stories que, individualmente, não conseguem entregar valor real ao utilizador. Um front-end (por exemplo, uma interface de website) não serve de nada ao utilizador sem um back-end correspondente (camada intermédia e/ou base de dados).

Para evitar esta armadilha, deves tentar fazer a divisão ao longo de um caminho através da story.

Para isso, convém pensar em quais caminhos existem no código da equipa de desenvolvimento. Frequentemente há um caminho que define o que acontece quando tudo corre bem. Normalmente também há um caminho para cada erro que pode ocorrer.

Também podes pensar em quais caminhos o utilizador percorre na story a ser dividida. Tomemos como exemplo o processo de pagamento num carrinho de compras online, pois isso afeta qualquer site de e-commerce. No checkout, o comprador pode escolher um método de envio, por exemplo entre entrega no dia seguinte, dentro de 2 dias ou uma opção de envio mais lenta.

Como a seleção do método de envio aumenta o esforço da story, convém considerar não incluir esta funcionalidade na versão inicial. Nesta primeira versão, todos receberiam o envio mais lento, sem a opção de entrega mais rápida. Desenvolver apenas este caminho simplifica a interface de utilizador (o utilizador não precisa de ter várias opções de envio à escolha). Além disso, reduz o número de casos de teste, etc. Fazer uma divisão ao longo de um caminho seria uma boa opção num caso assim.

Erro #3: Formular a solução na story

Outro erro comum é formular a solução já na story. As melhores User Stories focam-se mais no que deve ser feito, e não em como deve ser feito.

Por exemplo, neste momento quero pendurar um quadro no meu escritório. Se pedisse a alguém para fazer isso por mim, poderia dizer-lhe como quero que seja feito. Poderia explicar que quero o quadro fixado com um parafuso de cabeça redonda de ⅜". Se fizer isso, defini muito claramente como a tarefa deve ser executada. A menos que os detalhes sejam particularmente importantes por alguma razão, é melhor dizer apenas o que deve ser feito: „Quero que o quadro seja pendurado de forma segura na parede, mais ou menos neste local."

Incluir a solução na story acontece frequentemente quando as stories são divididas em partes demasiado pequenas. Quanto mais pequenas as stories se tornam, menos há para dizer sobre elas e esses detalhes de implementação acabam por se infiltrar.

Imaginemos que estamos a construir um multibanco que deve dispensar dinheiro. Este é um exemplo típico de livros sobre requisitos de software. Este exemplo pretende deixar claro que não se deve assumir automaticamente que o novo multibanco precisa de um cartão e um código PIN para autenticação, só porque sempre foi assim. Talvez neste caso queiramos usar um scanner de íris.

Faz sentido começar com uma story mais simples como „O utilizador autentica-se", onde o „como" não é especificado em detalhe. Claro que, à medida que esta story vai sendo decomposta, em algum momento alguém terá de dizer se será usado um scanner de íris ou um leitor de cartões clássico com introdução de PIN. Portanto, se perceberes que a tua equipa tem muitas especificações sobre o „como" numa story, verifica se as stories são mais pequenas do que deveriam ser.

Erro #4: Um Spike para cada story

O objetivo de um spike é mais a aquisição de novo conhecimento do que nova funcionalidade. Spikes são frequentemente usados para reduzir risco e incerteza em uma story. Quando os membros do time ainda não conhecem uma nova tecnologia ou se sentem inseguros com ela, podem usar um spike para aprender mais sobre o assunto.

Separar um spike de uma story pode ser uma boa abordagem. Assim você reduz a incerteza da story inicial, e ela provavelmente será mais rápida de implementar. Um spike também pode ajudar o Product Owner e o time a descobrir como dividir melhor uma story, caso ela ainda seja muito grande após o spike. Separar spikes de stories é uma boa ideia em alguns casos. Os times só precisam ter cuidado para não se tornarem muito dependentes de spikes e não terem um spike para cada story. Isso não seria uma boa ideia.

Quando os spikes são mais úteis:

Spikes são mais úteis quando há um alto nível de incerteza em uma story e o Product Owner e o time concordam que essa incerteza deveria ser resolvida antes de implementar a story. Se uma story tem um nível normal e cotidiano de incerteza, não deveria haver um spike.

Um certo nível de incerteza existe em toda story. Os usuários vão gostar se for feito dessa forma? O design vai funcionar bem? A nova ferramenta vai funcionar tão bem quanto nos prometeram? Esse tipo de perguntas surge em toda story. O objetivo não é eliminar a incerteza completamente. Na maioria dos casos, isso é praticamente impossível.

Spikes só deveriam ser usados quando a User Story tem um nível de incerteza tão alto que não seria aconselhável começar a story sem o conhecimento obtido pelo spike.

Times que separam spikes das stories com muita frequência geralmente têm medo de dar uma estimativa errada. Muitas vezes esses times temem ser punidos ou pelo menos criticados se levarem mais tempo em uma story do que haviam estimado anteriormente. Isso acontece frequentemente em culturas onde estimativas são confundidas com compromissos. Para resolver isso, você deveria ou conscientemente dar menos valor às estimativas ou trabalhar para criar uma maior sensação de segurança, para que os times não precisem ter medo de que as estimativas possam ser usadas contra eles.

Erro #5: Todas as regras precisam ser implementadas desde o início

Às vezes, User Stories são difíceis de implementar porque há muitas regras a considerar. Essas regras são frequentemente chamadas de regras de negócio, porque normalmente surgiram das operações do dia a dia. Mas às vezes também são determinadas pelo sistema.

Aqui está um exemplo para ilustrar:

Imagine que você trabalha na equipe de desenvolvimento de um banco que concede créditos hipotecários. Sua equipe está desenvolvendo um app que os clientes podem usar para solicitar uma hipoteca. Talvez no seu banco exista a regra de que ninguém pode ter mais de 10 milhões de dólares em empréstimos pendentes. Essa regra vale tanto para quem quer fazer uma grande hipoteca quanto para quem já tem um empréstimo de 5 milhões de dólares e quer fazer um segundo de 6 milhões.

O app provavelmente usará essa regra para que ninguém possa solicitar um empréstimo que ultrapasse o máximo permitido no total (independentemente de ser o primeiro, segundo ou terceiro empréstimo dessa pessoa).

Uma regra assim aumenta o esforço para concluir a User Story, já que o app precisa consultar os empréstimos existentes, somar esse valor ao novo empréstimo solicitado e, por fim, verificar se o total não ultrapassa 10 milhões de dólares.

Se essa regra deixa a Story tão grande que dificilmente será concluída em uma iteração, essa regra deveria ser flexibilizada (ou omitida) na primeira iteração e retomada na próxima. E claro, um time não deveria fazer release de um produto que viole as regras de negócio.

Alguns times cometem o erro de acreditar que todas as regras de negócio precisam ser implementadas desde o início. Isso pode levar o Product Owner e o time a dividir a User Story de forma desfavorável. Na próxima vez que você quiser dividir uma Story, procure formas de implementá-la parcialmente, omitindo uma regra inicialmente. Desde que você não pretenda fazer release oficial do resultado desse Sprint, omitir uma regra pode ser uma boa forma de dividir uma Story.

Conclusão: Evitando erros no User Story Splitting

A maioria dos times diz que dividir User Stories é um dos seus maiores desafios. Neste artigo, descrevi os cinco erros mais comuns dos times e apresentei sugestões de solução. A melhor forma de evitar esses erros é praticar mais a divisão de Stories.

Os 3 principais métodos com os quais você consegue dividir praticamente qualquer Story eu expliquei neste artigo:

• Caminhos
• Regras
• Spikes

Torne-se um Scrum Master certificado ou Certified Product Owner e confira nossos treinamentos ágeis. Também oferecemos uma variedade de eventos informativos gratuitos, Deep Dives e cursos para iniciantes!