Fala Pessoal, tudo bom?
Vocês já tiveram dificuldade no refinamento de histórias? Principalmente em tempos de home office, no qual muitas vezes não temos a possibilidade de ter um contato mais próximo ou mesmo nem conhecemos as pessoas envolvidas no desenvolvimento do produto.
Bom, depois de algum tempo pensando, resolvi escrever sobre esse tema e talvez ajudar quem precisasse, apresentando justamente com um caso real e prático.
Chegou o dia do refinamento, e agora ?
Contexto
Entrei em um time que estava atuando há algum tempo com Scrum, no começo eu entendi todo o ambiente, sistema e característica desse time. Uma de minhas primeiras ações foi olhar as métricas já existentes e me deparei com o seguinte cenário na estimativa (em pontos). Planejado X Realizado, conforme gráfico abaixo:
Obtive informações que na Sprint 26 o time estabilizou, não houve turnover e a passagem de conhecimento aparentemente não teve muito impacto no planejado e inicialmente no realizado. Questionei o motivo de uma variabilidade de 42% nas entregas e entendi problemas em coisas como Definition of Ready incompleto, mudanças de prioridades, prazos agressivos e situações administrativas, etc.
Passei a perguntar para as pessoas qual era o critério dos pontos planejados e as respostas que escutei foram: “Ah! Porque 5 é maior que 3 então resolvi assim…” Ou mesmo quando questionado o time não se sentia confortável em dar uma opinião.
Pensando em melhoria contínua, optei por fazer um acordo de trabalho com o time e estabelecer algumas pequenas regras simples para estimar a complexidade das histórias.
Conhecimentos técnicos que foram chaves para construção da Solução
Cynefin – Um framework sensemaking no qual definido pelo seu criador David Snowden: “Como fazemos o sentido do mundo para que possamos agir nele” e maiores detalhes sugiro uma série de videos públicados pelo Vítor Massari no link abaixo:
T-Shirt Size – Conceito extremamente simples para estimativas, no qual classificamos uma demanda em P, M e G (podendo até ter uma maior granularidade como PP, P, M, G e GG).
Sequencia de Fibonacci – “Na matemática, os números de Fibonacci são uma sequência ou sucessão definida como recursiva pela fórmula: F(n + 2) = F(n + 1) + F(n) , com n ≥ 1 e F(1) = F(2) = 1 . Os primeiros números de Fibonacci são: 1, 1, 2, 3, 5, 8, 13, 21”
Entrando no contexto de agilidade, a sequencia de Fibonacci é utilizada em um ferramenta chamada Planning Poker.
O Planning Poker nos ajuda de forma relativa estimar por meio de um simples jogo e para maiores detalhes também sugiro a leitura do link a seguir.
https://www.metodoagil.com/planning-poker/
E agora? O que eu fiz?
Bom galera, chega de enrolação! O que realmente eu fiz e quais os resultados?
Em um sessão de mentoria com o Vitor Massari (sim, a mesma pessoa do vídeo) conversamos sobre essa dor e desenhamos um modelo. Juntamos todos os conceitos apresentados anteriormente. Cynefin, T-Shirt size e Fibonacci e cheguei na seguinte ferramenta visual:
Conhecemos os conceitos e agora vamos as explicações e como aplicar.
- Ambiente Claro, Complicado e Complexos – Eu tenho conhecimento total do meu requisito? Preciso de ajuda, seja interna ou externa. Restrições técnicas? E por último, tenho conhecimento do negócio?
- P, M e G – Vamos estimar relativamente nossas demandas.
- Sequencia de Fibonacci – Vamos enriquecer ainda mais nossas estimativas e descobrir nossa capacidade de entregas.
Menção ao Edson Sousa (https://agileplanningboard.com/) que também foi uma das grandes fontes para construção dessa ferramenta.
Aplicando a ferramenta.
Eu costumo aplicar o processo no refinamento (meu foco principal) e em algumas oportunidades na planning. O processo é simples e segue os seguintes passos:
- PO apresenta o requisito ou a história para o time;
- Agilista coloca o primeiro ponto para o time, temos o entendimento funcional e técnico da história? Ou precisamos de alguma ajuda? Ajuda essa que pode ser um especialista externo, conhecimento de alguma tecnologia nova ou infra necessária. Caso o time resposta Sim para o entendimento, estamos no domínio claro caso não estamos no complicado e se nem mesmo o PO consegue explicar a história, estamos no complexo e essa história não entra na Sprint.
- Agora que sabemos em qual domínio estamos, vamos pensar no tamanho relativo da atividade (P, M ou G) e por fim naturalmente temos o valor da sequencia de fibonacci. Vale ressaltar que após identificar o domínio, ainda jogamos o planning poker, porém com um universo menor de possibilidades.
4. MAIS IMPORTANTE!!! Sugiro colocar post ti´s na ferramenta visual e criar um senso de comparação.
Exemplo: História 1 está como ‘G’ pontuação 3, o PO apresenta uma segunda história e com ajuda do agilista o time deve pensar, será que isso é mais trabalhoso, igual ou menos que a história 1 e a partir da comparação definir as próximas.
Vide imagem abaixo.
Gosto de comentar quando apresentei essa ferramenta o processo foi experimental, também acordei os conceitos e como aplicar, nada foi imposto ao time e tudo foi dentro da maior transparência possível.
Vamos aos resultados e Conclusão
Após adoção da ferramenta e 5 Sprints rodadas temos um resultado, vamos ao gráfico de velocidade abaixo:
Falando de resultados, tivemos alguns problemas relacionado a Definition of Done da Sprint 31 e por consequência nenhuma entrega, já nas sprints posteriores sem entender o negócio e olhando apenas para os número conseguimos claramente ver um fluxo de trabalho coeso e o mais importante Previsível.
Porquê não fazer um forecasting com as novas iniciativas ou mesmos sinalizar a intenções de produtos.
Quem disse que projeto ágil não tem cronograma?
Disclaimers importantes
- Já que sprint 31 não houve entrega por motivos externos, por consequência a sprint seguinte apresentou maiores resultados;
- Longe de mim criar um método, meu objetivo aqui é ajudar e mostrar um caso prático de Dor x Ação de melhoria contínua;
- A figura que foi desenhada pode ser adaptada para o que melhor funciona dentro do contexto de cada time.
