Esta abordagem foi desenvolvido pela EximiaCo para otimizar a criação de user stories em seus times de engenharia, elementos cruciais em metodologias ágeis de desenvolvimento de software para comunicar e documentar requisitos. A abordagem da EximiaCo busca simplificar a navegação e compreensão do backlog, o entendimento das demandas, tanto por pessoas técnicas e não técnicas, e garantir que cada história capture claramente as necessidades dos usuários e os critérios necessários para sua satisfação.
Descrição Geral
Este framework de construção de user stories apoia product owners (P.Os.), tech leads e membros de equipes de desenvolvimento em geral na criação de histórias de usuário claras, concisas e focadas no valor. De maneira resumida ele enfatiza um título expressivo, uma descrição padronizada e critérios de aceite detalhados. Esta abordagem assegura que todos os membros da equipe compreendam quem é o usuário (persona), o que ele deseja (feature) e por que deseja (resultado esperado), além de fornecer uma lista de verificações para garantir a entrega conforme o necessário.
Origem e Desenvolvimento
Organizado pela EximiaCo consolidando e adaptando práticas estabelecidas no mercado, esse framework surge da necessidade de facilitar o trabalho de explicitar as demandas de negócio para os times de engenharia de uma forma estruturada, melhorar o planejamento dos produtos de software, simplificar a comunicação entre os membros das equipes de desenvolvimento e de alinhar as expectativas dos stakeholders. Inspirado nas melhores práticas de metodologias ágeis e na experiência acumulada pela empresa tanto nos desenvolvimento dos próprios softwares, bem como no trabalho junto as maiores empresas de tecnologia a qual atualmente apoia.
Componentes de uma User Story
- Título Expressivo: Serve como um resumo eficaz da user story, facilitando a navegação pelo backlog.
- Descrição Estruturada:
- Baseia-se no formato “Eu, como [persona], quero [funcionalidade], para [resultado esperado]”, esclarecendo o objetivo da história.
- Além da frase no formato acima, importante construir um parágrafo explicativo que ajuda a contextualizar toda demanda e torná-la mais fácil de compreender.
- Eventuais sugestões técnicas podem ser adicionadas nessa descrição. Essa situação é comum quando aquele que está criando a user story possui uma visão técnica do produto.
- Critérios de Aceite: Incluem verificações funcionais e não funcionais que confirmam se os requisitos da história foram atendidos.
- Resultado esperados: Os benefícios que se pretende obter com a entrega dessa user story ou o que perdemos ao não tê-la concluída. Essa parte compõe os compromissos assumidos entre área técnica e de negócio.
- Anexos: Arquivos complementares para o entendimento dos requisitos, pode ser um mockup, uma interface de referência, um fluxograma, um diagrama, um desenho de arquitetura, etc.
Metodologia e Abordagem
A metodologia proposta pelo framework da EximiaCo para a construção de user stories é caracteristicamente incremental, enfatizando um processo evolutivo que parte de uma visão inicial mais ampla e genérica para uma compreensão detalhada e refinada. Este processo segue a lógica de que, quanto mais uma user story avança no board, mais elaborada e detalhada ela deve se tornar. Inicialmente, as stories são criadas com apenas um título expressivo, o que permite a rápida formação de um corpo inicial de backlog.
Essa abordagem inicial serve para mapear de maneira ampla as necessidades e características do projeto, permitindo uma visão geral das funcionalidades desejadas sem a necessidade de detalhamento imediato. À medida que essas user stories são priorizadas e se aproximam da execução, elas passam por um processo de refinamento. Nesta etapa, a equipe aprofunda cada história, detalhando a descrição com base na estrutura “Eu, como [persona], quero [feature], para [resultado esperado]”, e definindo os critérios de aceite, que incluem aspectos funcionais e não funcionais essenciais para a validação do trabalho concluído.
Este processo de refinamento deve ser liderado por um especialista de domínio ou product owner e quando necessário contar com a colaboração de desenvolvedores, designers, arquitetos de software e, sempre que possível, stakeholders e usuários finais. Essa colaboração assegura que as user stories reflitam com precisão as necessidades dos usuários e os objetivos do negócio, ao mesmo tempo em que promove um entendimento comum entre todos os envolvidos sobre o que será desenvolvido e entregue.
Além de facilitar a gestão do backlog e a priorização das tarefas, essa abordagem incremental ajuda a equipe a adaptar-se a mudanças no escopo ou nas prioridades do projeto com maior agilidade. Stories mais detalhadas e próximas da execução podem ser adaptadas ou refinadas com base em feedbacks contínuos, garantindo que o produto final esteja alinhado com as expectativas dos usuários e os objetivos do negócio.
Esta metodologia enfatiza a importância de um processo iterativo e adaptativo na definição de requisitos, promovendo uma maior precisão na entrega e um alinhamento mais efetivo entre as necessidades dos usuários e os objetivos de desenvolvimento.
Aplicabilidade e Casos de Uso
Este framework é particularmente útil em ambientes que adotam metodologias ágeis, como Scrum ou Kanban, onde a rapidez e a flexibilidade na gestão de requisitos são cruciais. Ele pode ser aplicado em projetos de qualquer escala, desde startups até grandes corporações, em diversos setores.
Benefícios e Vantagens
- Melhora na Comunicação: Facilita o entendimento comum dos objetivos do projeto.
- Eficiência no Backlog: Torna a navegação e priorização das histórias mais intuitiva.
- Qualidade e Satisfação do Usuário: Assegura que os produtos finais atendam às necessidades e expectativas dos usuários.
Limitações e Considerações
A principal limitação está na necessidade de treinamento e adaptação das equipes ao formato específico proposto pelo framework. Além disso, é crucial manter o backlog atualizado e bem organizado para que o framework seja efetivo.
Também vale ressaltar que o processo de concepção de uma demanda em muitos casos pode exigir ser mais amplo e envolver outras etapas, principalmente quando é um projeto novo e inovador. Essa etapas podem podem incluir entrevistas com usuários, pesquisas, avaliação de concorrentes, avaliação de experiência de usuário, etc.
Comparação com Outros Frameworks
Diferentemente de abordagens mais genéricas ou menos estruturadas, o framework da EximiaCo destaca-se pela sua especificidade no formato da descrição e nos critérios de aceite. Isso pode oferecer vantagens em termos de clareza e foco no usuário final, comparado a outros métodos que podem ser mais flexíveis, mas potencialmente menos direcionados.
Implementação e Adaptação
Para implementar este framework, recomenda-se começar com workshops de treinamento para familiarização das equipes e na sequência a estruturação de um enabling team capaz de facilitar a adoção da prática nos times de desenvolvimento.
Recursos Adicionais
Para aprofundamento, a melhor fonte são os especialistas em metodologia e engenharia de software da EximiaCo.
Perguntas Frequentes (FAQS)
- Por que não utilizar o template COMO QUERO PARA no título da user story?
Utilizar títulos claros e distintos para as user stories é crucial para garantir que a equipe possa navegar rapidamente e compreender o backlog. Embora o template COMO QUERO PARA seja útil para auxiliar que não se esqueça detalhes importantes na descrição da user story, aplicá-lo diretamente nos títulos pode resultar em títulos parecidos devido a padronização. Isso dificulta a rápida identificação de uma user story específica, pois torna todos os títulos visualmente semelhantes, além de em muitos casos sobrecarregar o título com detalhes que seriam melhor explorados no corpo da história.
- O Product Owner ou especialista de domínio deve escrever a user story sozinho?
Para ser mais produtivo é importante que o P.O., na maior parte dos casos consiga avançar com a construção das user stories de maneira autônoma, porém existem situações onde é recomendável que o P.O. inicie a escrita com suas percepções, mas envolva outras pessoas para alcançar um refinamento mais adequado, como por exemplo, em demandas muito técnicas, convém envolver outras pessoas do time como desenvolvedores, arquitetos ou líder técnico.
- Qual o tamanho ideal de uma user story?
Embora diversos fatores, incluindo a complexidade e o escopo, influenciem o tamanho de uma user story, é aconselhável mantê-las compactas. Isso não apenas simplifica o monitoramento do progresso do desenvolvimento, mas também aumenta a agilidade do fluxo de trabalho frente a mudanças imprevistas e diminui potenciais riscos. Como regra prática, na maioria dos casos, uma user story ideal deve ser dimensionada para exigir aproximadamente de 1 a 3 dias para sua implementação. Esse tamanho promove uma abordagem iterativa e flexível, facilitando ajustes e refinamentos rápidos, o que é essencial para manter a equipe alinhada e focada em entregar valor de maneira eficiente.
