Por que temos histórias pequenas no Kanban?

Avelar Leão, Agile Expert e Trainer na K21

Este post não tem tags.

Compartilhe:

Um dos objetivos de um bom PO é ajudar o time a trabalhar com histórias pequenas, ou melhor dizendo, histórias de duração curta. Conforme falamos nesse outro post, um dos grandes desafios de um PO é o fatiamento das histórias. Para entender o quão curtas estão as execuções dessas fatias, uma boa forma é medir isso por uso de uma métrica chamada Leadtime.

Leadtime é o tempo decorrido desde o momento onde se decide desenvolver ou construir um produto até o momento em que este produto foi disponibilizado para o seu cliente final. Ou segundo o David Anderson, “from the commitment to the time at your customer gets value from there”.

Quando começamos a medir o leadtime das histórias desenvolvidas pelos nossos times, é muito comum encontrarmos valores bem diversos. Algumas histórias são bem curtas, sendo desenvolvidas em alguns poucos dias. Já outras são muito grandes chegando a demorar meses.

Sistemas Kanban amadurecidos devem sempre buscar trabalhar com lotes pequenos. As conhecidas “small batch”. Mas sabemos que até alcançar esse nível de maturidade, teremos histórias de tamanhos diferentes em nosso backlog.

Mas o que fazer quando nos deparamos com esse cenário? Como Peter Drucker já nos disse “Se você não pode medir, não pode gerenciar”. Então, nosso primeiro passo é medir. Quando encaramos esse tipo de problema, sentimos a necessidade de entender o tamanho dos itens do nosso backlog. Uma forma comum de fazer isso é categorizar nosso backlog em histórias pequenas, médias e grandes.

Esta categorização das histórias em pequeno/médio/grande pode nos ajudar muito. No primeiro passo de medição devemos tentar entender quais os limites de Leadtime para cada tamanho de nossas histórias. Por exemplo, podemos definir que uma história pequena é algo que demora até 1 dia, uma média, algo que demora até 4 dias e uma grande algo que demora mais que isso. É importante achar valores pertinentes para o seu time, com uma amostragem de algumas (entre 20 e 30) histórias já é possível observar um padrão, sempre desconsiderando os thresholds.

Você pode também, antes de iniciar uma atividade, discutir com seu time e categorizar essa atividade em pequeno, médio e grande. Ao final da atividade, calcule o leadtime da mesma e reatribua com base no tamanho realizado.
Faça esse exercício por tempo suficiente até você ter uma boa massa de dados, isso vai ajudar o seu time a entender melhor o tamanho e ser capaz de prever com maior exatidão antes mesmo de começar uma atividade.

Com passar do tempo, podemos estipular a política de não trabalhar em atividades grandes, ou seja, atividades grandes precisam ser fatiadas em atividades pequenas e médias. E depois podemos abandonar inclusive as atividades médias, passando a ter todas as atividades do mesmo tamanho aproximado.

Uma das grandes vantagens de ser capaz de fatiar bem as suas histórias e garantir que todas são do mesmo tamanho é a previsibilidade com base estatística. Adeus longos planejamentos. Ao receber uma demanda, apenas fatie em pequenas atividades e você será capaz de dar um prazo usando estimativa otimista e pessimista, ou análise de histograma.

Quer saber mais sobre como fatiar histórias? Conheça nosso treinamento de Certified Product Owner!

Se interessou por Kanban e leadtime? Venha conhecer mais no nosso treinamento de Kanban!

Sobre o autor(a)

Agile Expert e Trainer na K21

Trabalha com Métodos Ágeis desde 2009, atuou como disseminando práticas de engenharia ágil e como gestor tornou-se um evangelizador das práticas da Gestão 3.0 e coleciona variadas experiências na média gestão e na gestão de pessoas e equipes.

No headers found for the table of contents.

Artigos relacionados

Um pouco do que foi o evento Product to Rescue em 9 de Julho 2024   Foco no problema Manter o foco no problema pode ser Old School mas ainda está em alta. Ficamos muito presos em problemas inexistentes ou…

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…