Como pessoa de Produto (Product Manager, Product Owner, APM, analista, etc.) em um time de produto digital, uma das nossas atividades frequentes é a escrita de User Stories que, reunidas e devidamente bem priorizadas, compõem o nosso backlog.
As User Stories (ou histórias de usuário) surgiram do Agile, mais precisamente do framework Extreme Programming (EX), ainda na década de 80. Desde aquela época já se percebia a necessidade de conseguir representar os objetivos do produto na visão de alguma de suas personas, ou seja, conectar da melhor maneira possível o objetivo com o valor a ser entregue.
Estamos nos referindo, sem mais delongas, a uma forma de descrever, clara e coloquialmente, as potencialidades de um software como objetivo do produto. O exemplo mais comum seria a construção de features (funcionalidades). É através da simplicidade e empatia com o usuário final que conseguimos nos colocar em seu lugar para descrever uma vontade e ainda demonstrar como aquilo seria valoroso para ele. E isso normalmente pode ser feito numa única sentença, em padrão muito famoso e utilizado:
“Como [persona], eu [quero] para que [valor]”
- Persona: figura bem caracterizada do usuário e/ou cliente que utiliza diretamente ou sofre impactos do uso do produto. Entender suas características e necessidades é essencial, principalmente quando buscamos atender um nicho específico;
- Quero: desejo, normalmente representado na forma de alternativa a resolução de um problema, o que se quer alcançar. É o objetivo;
- Valor: o que aquele objetivo soluciona, resolve ou como melhora a vida da persona.
Além disso, identificamos e pontuamos critérios de aceite que devem ser seguidos como requisitos para entrega. Ou seja, só a partir da validação de todos os critérios de aceite que podemos considerar aquela história como completa.
Parece simples, mas a escrita de uma boa User Story requer dedicação. Isso porque leva um tempo para se mapear e entender os problemas e possíveis soluções na hora de solucionar a dor de um usuário. Na verdade, a User Story é a síntese de uma das tarefas mais desafiadoras do negócio: o processo de Discovery.
No dia-a-dia, a user story serve de base para entendimento conjunto e para deixar todos do time na mesma página de entendimento. Dela se realizam os refinamentos técnicos e por fim, a associação das tarefas e subtarefas pelos desenvolvedores, que seguirão para etapa de delivery(entrega).
O princípio INVEST
INVEST é um acrônimo para independent, negotiable, valuable, estimable, small e testable. Foi trazido pela primeira vez em um artigo de 2003, por Bill Wake. A ideia é utilizar a palavra como checklist e visão, validando se a história na qual estamos trabalhando atende aos requisitos de cada letra:
- Independent (Independente): cada história de usuário deve ser independente das demais. O ideal é que cada uma possa ser planejada e implementada não importa a ordem. Lembrando que um dos valores do Agile é justamente a adaptabilidade, por isso ter histórias independentes entre si as torna mais fáceis de se trabalhar;
- Negotiable (Negociável): ainda lembrando da adaptabilidade, a história deve ser maleável. Nela nos concentramos na essência, os detalhes devem ficar abertos para mudanças no decorrer do tempo, principalmente quando falamos em decisões técnicas e de design. É normal que durante o ciclo de desenvolvimento muitas coisas sejam discutidas dentro de uma história, mas isso não é indispensável para priorização;
- Valuable (Valorosa): a história precisa entregar valor ao usuário final e/ou cliente. Sem valor, não há sentido aquilo ser priorizado, tão pouco desenvolvido. É necessário que esse valor não apenas exista, como esteja bem claro na história e para todos do time;
- Estimable (Estimável): não precisamos de uma estimativa exata, mas é importante ter pelo menos uma visão de quanto tempo será levado no desenvolvimento da história, pois isso acaba impactando diretamente na própria priorização e implementação.
- Small (Pequena): normalmente os ciclos de desenvolvimento são de 2 semanas, principalmente quando falamos no uso do framework Scrum. Recomenda-se que a história seja pequena, a ponto de poder ser desenvolvida dentro de um único ciclo. Caso não seja possível, é recomendável dividi-la em mais histórias. Isso ajuda não apenas na visão e compreensão do que deve ser feito, mas também facilita na hora de estimar;
- Testable (Testável): precisamos ter clareza no objetivo, a ponto de ter clareza em como testar o sucesso da entrega, sejam testes manuais e/ou automatizados. Só assim conseguimos garantir que os critérios de aceite da história foram alcançados.
Por que Usar stories e INVEST no desenvolvimento contínuo de produto?
Quando falamos em Agilidade, é comum que muitas equipes se percam seguindo cerimônias e focando no processo, em vez de nos princípios e valores tão importantes para o sucesso da metodologia.
Quando adotamos um framework ou um modo de fazer algo, é importante analisarmos o porquê e, sobretudo, adaptarmos aquilo da melhor forma para nossa realidade. Nem sempre seguir à risca um passo a passo será a melhor forma de seu time alcançar o sucesso, pelo contrário, deve-se experimentar, analisar e buscar melhoria contínua, adaptando-se se preciso for.
As User Stories vêm desde o surgimento do Agile e têm trazido resultados positivos no desenvolvimento de software. Isso porque, antes das metodologias ágeis, seguia-se majoritariamente o método Waterfall (cascata), que limita o desenvolvimento a um escopo rígido a ser realizado em uma sequência e em prazo determinado.
Quando falamos em produto digital, diferentemente de projeto, lidamos com algo contínuo, que está sempre melhorando e se adaptando enquanto durar seu ciclo de vida. Dessa forma, não faz sentido lidar com escopos definidos e imutáveis, precisamos poder nos adaptar rapidamente ao contexto acelerado que é o de tecnologia da informação.
Assim, através da gestão de backlog com User Stories, podemos focar no mais importante: a entrega de valor, sempre tendo em vista a adaptabilidade e as personas como centro da nossa visão.
Referências e recomendações:
Domine Product Discovery
Quer saber mais sobre User Stories e dominar outras estratégias e ferramentas que vão te dar uma visão de especialista em Discovery de produto? O Curso de Product Discovery da PM3 tem mais de 30 horas de conteúdo e, além de contar com cases reais do mercado brasileiro, te proporciona a melhor experiência de aprendizado para atuar em uma das áreas que mais cresce no Brasil.
Leia também:
