Analisando a saúde de uma User Story
Este artigo aborda um problema que passamos no time em que atuo como Agile Coach, como fizemos para identificá-lo e a ação de melhoria proposta.
O time trabalha usando o método Kanban, com classe de serviço e com limite de WIP (work in progress). Utilizamos apenas o board do Jira(ferramenta que adotamos) pois temos pessoas remotas no time.
Vínhamos com entregas constantes, melhorando a cada semana, mas tivemos alguns acontecimentos: um dos integrantes foi alocado temporariamente em outro time, pouco tempo depois outro entrou em período de férias e em meio a essas mudanças iniciamos o desenvolvimento de um novo épico.
Diante disso o cenário se inverteu: passamos a não ter mais entregas constantes, piorando a cada semana.
Percebemos que no nosso lead time, as user stories estavam levando mais tempo do que o normal, ultrapassando muito nossa média. Poderíamos usar os acontecimentos recentes para justificar essa demora nas entregas, mas tínhamos que reagir. Porém para isso era necessário entender melhor o nosso cenário e quais eram os reais problemas.
Usamos várias métricas para medir nosso desempenho e acompanhar nossa evolução, e para descobrir os gargalos no desenvolvimento, usamos o gráfico de workflow.
Só que neste caso não bastava descobrir apenas os gargalos no desenvolvimento mostrados no gráfico de Workflow acima, tínhamos que entendê-los. Para isso precisamos do histórico de desenvolvimento da user story, com mais detalhes.
Com base no gráfico de workflow, criamos uma nova análise adicionando as idas e vindas da user story no fluxo de desenvolvimento, sempre contabilizando os dias.
Conseguimos identificar por fim um comportamento que se repetiu em algumas user stories. Conforme uma user story voltava para desenvolvimento devido a um bug encontrado em teste, ela ficava na fila de ‘A Desenvolver’, e não era imediatamente atendida. Às vezes a mesma ficava por dias esperando até que alguém a pegasse novamente para corrigir o problema.
Isso ocorria porque sempre dávamos foco para as user stories que estavam em WIP (work in progress), e mesmo nos comunicando internamente que uma user story havia voltado porque tinha sido encontrado um bug, ela acabava por sumir do nosso radar.
Decidimos adotar três ações para que esse problema não voltasse a ocorrer. A primeira foi adicionar a flag de impedimento na user story para esses casos (feature existente no Jira) e na observação detalhar os motivos. A segunda foi reforçar a comunicação desses casos para o time, avisando na nossa ferramenta de comunicação e na daily. E por fim, garantir que o Agile Coach fica-se policiando o board para que uma user story que caísse nessa condição não fosse esquecida.
Como Agile Coach, sei que esse tipo de cenário deveria ser levantado e discutido na daily, pois é esse o momento que o time usa para se planejar de acordo com as prioridades, mas às vezes algo passa despercebido. Por isso devemos reforçar o auxílio de formas visuais para ajudar o time a enxergar como está o cenário e não se desviar das prioridades.
