- [email protected]
- + (55) 11 945 071 133
Frequentemente, encontro Agilistas, em especial Product Owners, pedindo dicas para histórias de usuários.
Até aqui, já discutimos o que são e a importância das histórias de usuários para a gestão Ágil.
Afinal, elas ajudam a esclarecer a intenção e os objetivos esperados para cada funcionalidade ou característica esperadas.
Sem falar da abertura para a participação mais ativa de colaboradores e usuários do produto ou serviço desenvolvido.
Antes de mais nada, devemos lembrar que, fora a estrutura original da metalinguagem…
não existe bala de prata para todos os cenários…
cada projeto, cada cultura corporativa, cada time tem a sua característica e seu contexto.
Por isso, devemos compreender que o processo de refinamento com User Story é um processo aberto e contínuo.
Ele por si não é um processo linear, como poderia ser sugerido na gestão mais tradicional de desenvolvimento de produtos e serviços.
Mas é um processo muito semelhante ao modelo PDCA para resolução de problemas. 😉
Assim, ele segue a mesma filosofia de aprimoramento contínuo (um dos fundamentos da gestão ágil de produtos e serviços).
Desta forma, a seguir você vai descobrir
De maneira geral, um épico é nada mais que uma necessidade ou desejo ainda um pouco abstrata.
E por isso, normalmente ele é percebido com um “requisito grande” 😊
Afinal, em uma gestão ágil, nem sempre teremos todos os requisitos tão bem definidos logo de início.
Por isso, é natural quebrarmos estas necessidades em partes menores, definindo características e condições.
Até finalmente chegarmos a definir histórias de usuários.
Por isso, manter o rastreio desta relação entre Épicos e Histórias de Usuários pode te ajudar a manter o propósito original dos desejos descritos no início do projeto.
Evitando, assim, perguntas do tipo:
“Como foi que esta história chegou aqui mesmo?”😉
Ela nada mais é do que uma ferramenta, que indica uma resolução para uma necessidade ou problema.
Atender a esta necessidade ou este problema é o seu objetivo final 😉
É uma ótima ideia que cada história de usuário tenha aderência com os seguintes conceitos:
Independente: Cada história de usuário deveria ser finalizada independentemente de outras histórias de usuário.
Negociável: Seu próprio processo de refinamento exige uma comunicação construtiva e saudável com todos os interessados pelo produto ou serviço.
Valor: Cada user story deveria entregar um valor que resolve um problema negocial para o usuário final.
Estimável: Cada história de usuário deve ter detalhes o suficiente, que permite ao time de desenvolvimento definir um prazo, ou horizonte, de execução desta mesma história.
Small (Pequeno): Mesmo que que detalhes sejam desejados, o quanto menor podermos deixar uma história de usuário melhor.
Aqui vale recordar: Ser Simples não é o mesmo que ser simplório.
Testável: Cada user story permite que a funcionalidade desenvolvida seja testada, e define como deve ser testada (lembra dos critérios de aceitação?) 😉
Em qualquer início de projeto ou serviço, teremos histórias de usuário mais refinadas, e outros nem tanto assim 😊
Por isso é natural classificá-las de acordo com a situação que se encontram.
Se estão prontas para planejamento, ou ainda se dependem de confirmação com usuários ou com a área de negócios por exemplo.
Uma relação mais comum que encontramos no mercado é a seguinte:
Como podemos observar, a “história de usuário” é uma história do????
Usuário! 😊
Ou seja, ela conta uma necessidade, um problema a ser resolvido, sob a perspectiva do usuário final daquela funcionalidade.
Ter só a descrição da metalinguagem na história de usuário em um card, pode complicar a gestão do dia-a-dia do agilita a longo prazo.
Isso porque quanto mais o projeto se desenvolve, mais e mais histórias aparecem.
Em pouco tempo passamos de algumas poucas, para centenas ou milhares de histórias de usuário.
Por isso que encontraremos em muitas ferramentas de gestão ágil, a possibilidade de colocarmos títulos curtos e únicos para histórias de usuário.
No dia-a-dia, isso facilita a identificação do que estamos operacionalizando em determinada Sprint.
Uma boa estratégia para o refinamento de histórias de usuários é captar as intenções por detrás dos requisitos.
E para entender melhor essas intenções, uma boa ideia é usar de personas para compreender as principais características e objetivos de um tipo de usuário.
Uma vez que temos uma compreensão melhor da persona, podemos não só refinar melhor as histórias de usuário…
como podemos priorizá-las de acordo com os objetivos delas.
É de bom tom já definir os critérios de aceitação no refinamento da própria história de usuário.
Isso evita muita confusão nas reuniões de Revisão e de Retrospectiva de Sprints.
Com o intuito de ajudar no planejamento técnica, é de bom costume colocar requisitos técnicos aqui também 😉
Normalmente, costuma ser o Product Owner o responsável por selecionar e refinar as histórias de usuário para o desenvolvimento do produto ou serviço.
Porém, na gestão ágil, qualquer um pode escrever e refinar uma história de usuário para o time ágil.
De fato, o melhor é que a construção e refinamento destas histórias tenham a participação de todo o time.
Assim, evitamos que a user story seja passada adiante como um ticket qualquer.
Gerando mais confusão e interrupções para o desenvolvimento do produto ou serviço.
Pense que as histórias de usuário devem ser criadas com aqueles que irão desenvolver o produto ou serviço. E não para eles.
Nem toda a atividade ou tarefa é representada por uma história de usuário.
Lembre-se que uma user story é focada no usuário/cliente daquele produto o serviço.
Por isso, não faz muito sentido escrever histórias como:
Como um Developer…
Como um Arquiteto….
Se é uma tarefa, ela é apenas isso, uma tarefa.
Que por sinal, também pode ser vinculada às histórias de usuários e até aos épicos.
Aqui, o quadro Kanban é uma das ótimas, e das mais simples, ferramentas visuais para identificarmos em que fase ou etapa cada história de usuário está.
Além de nos permitir encontrar possíveis gargalos de onde e porque certas user stories estariam limitando a produtividade do time.
Se você nunca usou um quadro como este antes, fique tranquilo/a.
Não há necessidade nem mesmo de um software para isso 😉
Basta um quadro, com colunas para cada etapa ou fase, onde você pode colar post-its (com suas histórias) nele.
E desta forma observar o fluxo de desenvolvimento de uma Sprint.
E quem sabe, até se antecipar a problemas operacionais e impedimentos da Sprint.
Se necessário for, adicione qualquer nova informação que julgar pertinente à história de usuário.
Fluxogramas, desenhos, planilhas, relatórios… não importa.
Se for para ajudar a melhorar a compreensão, eles podem ser anexados junto à user story.
Tem hora que menos é mais..
mas também tem hora que mais é necessário.
A comunicação não é uma ciência exata, podendo a informação ser processada de maneiras diferentes.
O que pode gerar falsas interpretações e muitas discussões.
E claro, que podem acabar não resolvendo o problema do usuário final.
E assim gerando maior insatisfação de clientes, internos e/ou externos.
Bom, ou você aprende a comunicar suas funcionalidades e requisitos de forma correta…
…. ou infelizmente, você corre o grande risco de continuar atrasando seus projetos e produtos
…., ou o que é pior… perder seus clientes e suas oportunidades na carreira.
Por isso preparamos uma Masterclass para te apresentar novas técnicas e métodos para refinar requisitos e tarefas.
Para te ajudar a antecipar entregas e resultados, mesmo em grandes projetos/produtos.
Na Masterclass Fatiando e Quebrando Itens de Trabalho™, você vai descobrir e dominar técnicas que executam 2 etapas…
para engajar e produzir novas entregas com resultados adiantados para seus produtos e serviços.
Confira os detalhes para participar desta Masterclass exclusiva clicando aqui 😊
Te vejo em breve
e um grande abraço!
