Acabei de ministrar um workshop sobre histórias do usuário, com muita interação, e em mim fica a percepção do quanto é curioso para um iniciante entender onde elas moram, o que comem, como e quando elas nascem, do que se alimentam, onde dormem e o quanto agregam valor.
Em meio a tantos artigos e temas correlatos, desde User Stories, sua narrativa e critérios de aceitação, 3C, INVEST, MoSCoW, User Story Mapping, User Story Points, Planning Poker, Example Mapping, Releases Plan, Inceptions, etc. De tabela, também leem sobre DoR, BDD e Gherkin, documentação ágil, DoD.
Independente da metodologia e abordagem, é essencial termos materializado e acessível informações sobre nosso (1) propósito, missão, visão e direcionadores estratégicos, (2) portfólio de produtos e serviços, (3) portfólio de projetos, (4) Roadmap, (5) Release Plan ou Delivery Plan com as próximas features, (6) Product Backlog, (7) História do Usuário e demais registros para especificação mínima necessária de cada item a ser construído, finalmente (8) Definition of Done ou o famoso pronto!
As nossa histórias, enquanto histórias com narrativa e critérios, materializam-se no momento (7), pois serão parte da especificação que servirá de insumo ao momento (8), a entrada necessária para que a equipe de desenvolvimento faça o seu melhor possível, com mínimo retrabalho e desperdício, otimizando ao máximo seu Cycle Time, o tempo necessário total desde que um ítem é iniciado até o seu término (done).
(1) Propósito – Conhecer nossa missão, visão e objetivos estratégicos é fundamental para que todo o capital intelectual da organização esteja empenhado a contribuir para o mesmo. Este é o principal fundamento do conceito de OKR, este conhecimento permite que áreas, times e profissionais direcionem o valor que geram.
(2) Portfólio de produtos e serviços – Tanto quanto nosso propósito e objetivos, conhecer minimamente nosso portfólio de produtos e serviços geram em cada um de nós maior senso de pertença e direcionamento, a partir do entendimento maior da relação causa e efeito entre objetivos, soluções oferecidas e contextualização.
(3) Portfólio de projetos – Sempre me lembra o PMRank do Ricardo Vargas, visões estratégicas sobre iniciativas que demandam projetos ou operações. Nome, informações gerais e critérios mínimos utilizados para perceber valor, dimensionar em nível zero e priorizar. Como critério, temos como exemplo os campos de um Lean Project Canvas, critérios comparativos entre projetos candidatos para priorização e sequenciamento.
(4) RoadMap – Prioriza temas de negócio de uma iniciativa, produto ou serviço, podendo ser objetivos de negócio e milestones. Ao usar temas de negócios, objetivos ou metas, estamos ainda bem acima de uma história de usuário. É imperativo termos uma visão estratégica de portfólio, mas tanto quanto termos uma visão de milestones para cada iniciativa, produto ou serviço … pautando o foco no maior valor a cada passo.
(5) Release plan | Delivery Plan – Pode chamar como queira quando percebemos qual o conjunto de funcionalidades que comporá a próxima release ou entrega. Quer seja baseada em um milestones, conjunto de características funcionais que compõem um MVP, MMP, MMF ou mesmo incremento. É nosso próximo Release de curto prazo, desdobrando temas e objetivos em épicos e features.
Durante um Release Plan ou Delivery Planning Meeting, o nosso product backlog é contruído de forma bastante suscinta, algumas informações e combinações que nos levam a compreender a complexidade de cada item, eventualmente estimando-os em pontos ou TShirt size, mas jamais redigindo histórias tão cedo.
Não é incomum termos diferentes opções de granularidade em nosso Release Plan, mas mesmo quando a unidade é equivalente a uma história do usuário, mesmo a chamando assim, temos tão somente sua nomeação, jamais sua narrativa e critérios, que serão detalhados mais adiante no último momento responsável.
Em 15 anos de Agile, jamais escrevi histórias durante um planejamento, elas serão redigidas quando da construção de sua especificação ou DoR (Definition of Ready). Quer no Scrum ou Kanban, a redação acontece quando estamos realizando a análise, design ou especificação … nosso último momento responsável.
O último momento responsável neste quesito diz respeito a não antecipação do detalhamento de algo que não será realizado tão cedo, no Kanban a especificação via de regra é o primeiro passo ao retirarmos um item do product backlog e iniciarmos sua especificação, no Scrum é o DoR, via de regra um sprint antes.
(6) Product Backlog – Independente de qual a técnica e ferramenta utilizada para a sua construção e evolução, o product backlog conterá épicos, features ou a identificação de histórias (não seu detalhamento, até que o mesmo faça-se necessário). O objetivo é ter cada um destes itens registrados, de forma a priorizá-los e refiná-los a medida que aproximam-se do topo (próximos a serem desenvolvidos).
(7) História do Usuário – Novamente trago cito “último momento responsável” e “Definition of Ready”, pois ambos carregam em si o propósito de detalhar ou especificar quando realmente este detalhamento torna-se útil e necessário … no sprint anterior ou ao entrar no fluxo em uma primeiro passo de análise ou especificação. Aqui teremos a narrativa, os critérios, que provavelmente junto a UX e SQA detalharão o necessário aquilo que está prestes a ser desenvolvido.
(8) Done! – O input ao desenvolvimento é este DoR ou especificação, mitigando desperdícios e retrabalho, garantindo que os desenvolvedores façam seu melhor no menor tempo com qualidade e valor. O termo que sempre uso é a especificação mínima realmente necessária, evitando tanto desperdícios na geração de um detalhamento inócuo, evitando tolher os desenvolvedores em sua alçada, mas oferecendo a eles as informações necessárias que otimizem o tempo de desenvolvimento até o Done aceito.
DUAL TRACK (Jeff Patton)
Na abordagem Kanban, em fluxo contínuo, o timing é fácil de compreender, pois a especificação, design ou análise é usualmente o primeiro passo de cada ítem do product backlog ao entrar em fluxo (cycle time), dali seguindo para uma fila aguardando desenvolvimento, por exemplo, e assim adiante. Na comunidade Scrum eu curto demais a assertividade da proposta Dual Track do Patton.
Em Scrum e na maioria dos métodos em escala, sempre defendi algo semelhante à proposta de Dual Track do Jeff Patton. A cada passo em um Time Scrum, trabalhamos concomitantemente com a especificação daquilo que logo vai ser desenvolvido (DoR), ao mesmo tempo que algo está sendo desenvolvido (DoD), um só time mantendo-se em fluxo constante, cruzado, de especificação, construção e validação.
Em consultorias é fácil as vezes demonstrar que muitas das dores pertinentes ao retrabalho, desperdícios e ociosidade gerada pela troca forçada decorrente de impedimentos diz respeito a fragilidade da especificação, da inexistência de acordos e políticas relativas a esta especificação ou Definition of Ready. Muitas vezes nenhum trabalho adicional é gerado, apenas reiteramos e reforçamos estes conceitos e acordos, de forma a evitar entrar em desenvolvimento com muitas incógnitas ou falta de clareza mínima necessária.
É preciso garantir as reuniões, refinamentos e aprovações da especificação antes de entrar em desenvolvimento, porque novas reuniões, cenários e acordos tendem a conflitarem com o fluxo ou serem interpretados como impedimentos temporários, dificultam o WIP e exigindo improvisos que via de regra estendem o nosso tempo de desenvolvimento e geram atritos desnecessários.
Quanto às técnicas de construção e refinamento das histórias, já tenho diferentes posts e compartilhamento de experiências nas lives e artigos, dando visibilidade do trabalho em equipe necessário para esta especificação, de técnicas como a de example mapping para estabelecer as condições, profundidade, nomenclatura, em especial no início de um projeto, estabelecendo políticas e acordos essenciais para uma comunicação assertiva, equilibrando o explícito e o tácito, alçadas e condições a serem aferidas a cada ciclo de melhoria contínua.
Posts complementares
Jorge Horácio "Kotick" Audy 