Histórias e regras de negócio

Oi Cassia,

a intenção das histórias é apenas ter informação suficiente para que um time entenda a linha geral da funcionalidade que vão desenvolver -- por exemplo, para estimar o esforço necessário para fazê-la.

Quem for realmente pôr a mão na massa e fazer a história é responsável por ir atrás de mais informação e chegar aos detalhes.

Em suma, a história é um convite para uma conversa. Ela dá a noção do que tem que ser feito para o time todo, mas os pormenores de execução estarão apenas com quem pegar aquela história para fazer.

Sim, entendi, Cecilia. É bem aquele template padrão de história.

Mas, este momento de se "pegar a história para fazer" seria após a planning, certo? Neste instante já existiria este detalhamento? Estas informações ficariam fora da história? Seriam documentações complementares?

Sim, "pegar a história para fazer" seria na hora do desenvolvimento da história, fora do planning.

Nesse instante, o desenvolvedor correria atrás dos detalhes. Minha preferência aqui é por uma interação mais direta entre desenvolvedor e usuário, tanto porque isso cria um relacionamento entre essas partes, quanto porque assim há menos perda de informação e mal entendidos. Por isso, a história é um convite para uma conversa.

Se seu contexto não permite essa conversa (e você tentou melhorar isso e realmente não tem como), documentações complementares podem fazer esse papel.

Nota: vale notar que eu chamo de Desenvolvedor qualquer pessoa que crie incrementos para o produto. Programadores, analistas, testers, DBAs, arquitetos ou qualquer outra divisão de papéis que você use... todos eles são desenvolvedores, para mim.

Geralmente o detalhamento das histórias é feito pelo próprio PO ou temos outros clientes envolvidos neste processo?

E, pensando nesta dinâmica, poderemos ter bastante histórias sendo "descobertas" ao longo das sprints, certo? Pois com o detalhamento de algumas durante o desenvolvimento podem surgir outras não pensadas ainda. Na prática, isso não faz com que o número de histórias aumente muito? (comparando o que tínhamos na primeira planning e a entrega final)

O detalhamento é feito, preferencialmente, com o envolvimento de clientes, para evitar um efeito telefone-sem-fio. Quanto mais passos há para transmitir uma informação, mais chance há de ela vir errada.

Mesmo com essa dinâmica, não deve ser frequente aparecerem histórias novas no detalhamento de outras. Se isso acontecer, é porque não tínhamos informação o bastante sequer para estimá-la durante o planning. Como eu mencionei na primeira resposta, a história já deve ter esse nível de detalhamento -- apenas, não é necessário entender tudo aos mínimos detalhes para não levar esses sustos.

Se esse a história não estiver clara o bastante para ser estimada, é uma falha do PO. Ele tem o trabalho de refinar os itens mais prioritários do backlog antes do planning.

Quanto ao número de histórias inicialmente planejado ser muito diferente do número final, isso não necessariamente quer dizer que o trabalho aumentou: note que uma história grande pode se tornar N histórias menores sem perda. E, ao quebrar histórias em menores, é bastante comum descobrirmos, também, itens não tão necessários e eliminá-los.

Descobrir novas histórias não é ruim: é um sinal de que estamos mais perto do que realmente agrega valor para o projeto e seus usuários. Toda adição de história nova reavalia a prioridade das outras e, por isso, temos uma visão frequente do Custo vs Ganho dos itens que virão a seguir. Fazer ou não os itens novos levantados é uma questão de estratégia de negócios.

Boa noite pessoal, aproveitando o tópico. Em relação a esse item onde a história é um convite para uma conversa e nesse caso os detalhes são revelados àquele que irá pegar a tarefa só que fora do planning, não sei se entendi bem essa questão, pois depois do planning já não é o momento em que a sprint é iniciada, ou seja, o desenvolvimento em si? Nesse caso o tempo já estaria correndo, não? Dentro disso também não é comum quebrar as histórias em tarefas técnicas e elas possuírem esses detalhes que foram mencionados na documentação complementar? Confesso que essa questão de história X tarefa tem me confundindo um pouco pois para mim aquilo que é desenvolvido seria uma tarefa(técnica) e uma história poderia ter uma ou mais tarefas. Não sei se vocês trabalham com essa divisão história X tarefa ou não.

Obrigado!

Oi Jhonatas, boa tarde.

Uma história já é um item de desenvolvimento e deve vir detalhada. Existe a possibilidade dela ser quebrada em histórias menores justamente por às vezes precisarem de mais detalhes - isso é normal acontecer justamente porque o time às vezes pode enxergar algo a mais ou até mesmo um detalhamento mais técnico que outros não conseguiram enxergar antes. É importante que o PO entenda e passe realmente a visão do projeto para que o time entenda a linha de raciocínio. Outra parte importante são as reuniões que dão feedback em relação ao que está sendo considerado como DONE. Nessas reuniões os desenvolvedores saberão o que se passa na cabeça dos stakeholders e a cada entrega, a equipe conseguirá seguir um caminho mais próximo do objetivo desejado pelo cliente. É necessário confiança no trabalho individual dos desenvolvedores nessa hora e entregar valor.