3 cenários que devem ser evitados ao escrever User Stories
As User Stories são frequentemente utilizadas em metodologias ágeis como alternativa para os requisitos, apesar de terem um formato extremamente compacto e simples, muitas vezes inúmeros erros são cometidos, o que dificulta atingir o objetivo de User Stories.
Lembrem que a premissa de frameworks ágeis como Scrum é: Communication over documentation. Ou seja a comunicação é o mais importante!
A pergunta que faço é: O que devemos evitar ao escrever User Stories?
1 — User Stories devem atender a um único propósito
Qual o problema que ocorre neste momento? Muitas vezes a User Story contem a palavra “e”, por exemplo:
Como cliente do e-commerce XPTO
Gostaria de filtrar produtos por preço, categoria e tamanho
Para que eu possa encontrar os produtos que desejo
Lembrem, o grande objetivo é entregar valor o quanto antes, quando acrescentamos múltiplos requisitos em uma User Story fazemos exatamente o contrário. Por isso sempre perguntem: esta User Story representa um único objetivo? Se a resposta for não, divida!
2 — Evite palavras que não gerem um único entendimento
O que isso quer dizer? São as famosas expressões como: melhoria de performance, aumento de disponibilidade, facilidade na compreensão. Evite isso a todos os custos, quando notar que está caindo nesta armadilha, pergunte: como poderei medir o resultado? Escrever a User Story neste formato!
Por exemplo:
Como cliente do e-commerce XPTO
Gostaria de visualizar os produtos de forma mais rápida após uma busca
Para que eu possa otimizar o meu tempo
A palavra mais rápida nesta User Story pode ser compreendida de diversas formas, pode ser 3 segundos para uma pessoa ou 1 segundo para outra. Então o correto seria escrever a User Story diretamente de forma que seja mensurável!
3 — SEMPRE refine a User Story com o time de desenvolvimento
A principal parte de uma User Story não é visível, pois representa a comunicação com o time. Para isso o Product Owner tem a obrigação de apresentar as User Stories para o time e juntos refinarem.
Lembrem, User Stories não são requisitos, são uma abordagem para resolver um problema, desta forma o PO não propõe soluções e sim apresenta o problema para o time de desenvolvimento e juntos definem a abordagem para resolver o problema.
Um cenário muito comum é o refinamento não ser realizado com o time, quando isso ocorre, espero por problemas!
Quer saber mais sobre este tema? Se inscreva em meu curso Como ser um Product Owner.
