É dia de revisão da sprint. O gráfico de capacidade do dia de planejamento está todo verde e ninguém está acima de 100%. Ainda assim, o quadro mostra quatro itens de trabalho em “Em Revisão” e a sprint termina hoje. Se você é um Scrum Master ou gerente de projetos, provavelmente já passou por isso.
O planejamento de capacidade da sprint no Jira mostra quem tem tempo disponível, mas não quanto tempo o trabalho fica parado entre as pessoas. É geralmente nessa espera que os dias perdidos se acumulam. Este artigo mostra para onde esses dias vão e como planejar contornando isso, usando o Activity Timeline e o Timepiece - Time in Status for Jira.
Principais pontos: O planejamento de capacidade diz quem tem tempo disponível. Ele não diz quanto tempo o trabalho fica parado. Uma tarefa de 4 horas pode levar 6 dias para ser concluída e ainda parecer estar tudo bem no gráfico de capacidade. Para cumprir o prazo da sua sprint, monitore ambos: a capacidade no Activity Timeline e o tempo de espera no Timepiece.
O que o planejamento de capacidade da sprint no Jira realmente mede?
A maioria dos planos de sprint dá errado antes mesmo de começar. Alguém se compromete com mais do que tem tempo para fazer, um feriado que ninguém contabilizou consome dois dias, e a equipe só descobre isso no meio do caminho. O planejamento de capacidade serve para você identificar isso logo no dia do planejamento.
O planejamento de capacidade compara dois números. A carga de trabalho é o esforço estimado atribuído a um membro da equipe. A capacidade é o tempo que essa pessoa tem: suas horas de trabalho menos férias, licenças médicas e feriados. Ao somar isso para toda a equipe, você obtém a capacidade do time, o limite máximo do que uma sprint pode comportar.
O ActivityTimeline constrói isso a partir dos seus dados do Jira:
- Carga de trabalho vem da estimativa restante nos itens de trabalho atribuídos, distribuída ao longo das datas em que estão agendados.
- Itens de trabalho podem assumir essas datas a partir da sprint, para que apareçam na linha do tempo de cada pessoa durante o período da sprint.
- Abaixo de cada pessoa, um indicador de carga de trabalho mostra se ela está sobrecarregada, com pouca carga ou equilibrada.
Você pode ver quem está sobrecarregado e redistribuir o trabalho antes que a sprint comece, e não depois que alguém ficar para trás. Para a configuração, veja os guias do ActivityTimeline sobre planejamento de capacidade no Jira e planejamento de sprint no Jira.
O Gráfico de Capacidade da Equipe soma os dados do time: capacidade total, capacidade utilizada, capacidade restante e taxa de utilização para o período que você escolher. A capacidade restante indica quanto espaço ainda existe quando surge um trabalho não planejado, permitindo que você aceite ou recuse demandas com base em números.
O desenvolvedor agendado com 130% de carga e a sprint que coincide com um feriado da equipe são dois exemplos de como o planejamento de capacidade da sprint no Jira detecta problemas precocemente. Cada um que você identifica no dia do planejamento é um prazo que você não precisará justificar depois.
Cargas de trabalho verdes, sprint vermelha: onde o plano falha?
Aqui está uma história de exemplo de uma sprint. Ela tinha uma estimativa de 4 horas e foi agendada na linha do tempo do desenvolvedor no ActivityTimeline. A equipe registrou 4 horas nela. No entanto, ainda levou 6 dias úteis para ser concluída. (Os números são uma ilustração.)
A estimativa estava correta: 4 horas planejadas, 4 horas registradas. Mas os status "A fazer", "Em revisão" e "Aguardando QA" consumiram 4,5 dos 6 dias, e a maior parte disso foi tempo de espera.
O planejamento de capacidade não estava errado. O Activity Timeline calcula a carga de trabalho a partir da estimativa restante e das datas agendadas de cada item de trabalho. Uma mudança de status, por si só, não altera nenhum dos dois; portanto, a história adicionou as mesmas horas planejadas enquanto aguardava revisão quanto enquanto alguém trabalhava nela. O indicador de carga de trabalho de ninguém ficou vermelho.
Essa é a diferença entre esforço e tempo decorrido. Esforço são as horas de trabalho: 4. Tempo decorrido é o tempo do calendário desde o início até a conclusão, incluindo a espera: 6 dias. O planejamento de capacidade mede o esforço. O prazo da sua sprint é baseado no tempo decorrido.
Para onde vai o tempo entre os status?
Resposta curta: para a espera. O tempo de cada item de trabalho se divide em duas partes:
Tempo de execução: alguém está trabalhando nele.
Tempo de espera: ele fica em um status e ninguém está trabalhando nele.
Um plano de capacidade conta as horas estimadas de trabalho, que é basicamente o tempo de execução. O tempo de espera não consome as horas de ninguém, por isso nunca aparece no plano. Mas ele ainda consome dias do calendário.
A eficiência de fluxo mostra quanto do tempo total foi tempo de execução: tempo de execução dividido pelo tempo total. Na história acima, a equipe registrou 4 horas ao longo de 6 dias úteis (seis dias de 8 horas, 48 horas úteis). Se você considerar o tempo registrado como tempo de execução, isso resulta em uma eficiência de fluxo de cerca de 8%. Nos outros 92% do tempo, a história estava em espera. Em um caso como este, reduzir a espera economiza mais dias do que trabalhar mais rápido jamais poderia.
A espera tende a se acumular em alguns lugares:
- Revisão de código: O código está escrito, mas o revisor está ocupado com outras tarefas.
- Transferência para QA: O item de trabalho está pronto para teste, mas fica em "Pronto para QA" até que um testador esteja livre.
- Aprovações: O item de trabalho não pode avançar até que um gerente, equipe de segurança ou cliente dê o sinal verde.
- Outra equipe: O item de trabalho depende de algo que outra equipe precisa entregar primeiro.
- Refação: O controle de qualidade encontra um problema e devolve o item de trabalho, fazendo com que ele passe pelas mesmas filas novamente.
Cada um desses pontos é um gargalo no fluxo de trabalho. A Atlassian descreve um gargalo como qualquer ponto em um fluxo de trabalho onde a capacidade é limitada, fazendo com que o trabalho se acumule. Para encontrar os seus, você precisa saber quanto tempo o trabalho passou em cada status.
Como encontrar gargalos no fluxo de trabalho com o Timepiece?
A maioria das equipes já tem um palpite sobre onde o trabalho trava. "As revisões são lentas." "O controle de qualidade está sempre atrasado." A parte difícil é provar isso e saber quantos dias de atraso isso custa.
A boa notícia é que o Jira registra cada mudança de status com um carimbo de data/hora. Mas ele mostra esse histórico um item de trabalho por vez. Em espaços gerenciados pela empresa, o gráfico de controle traça o tempo que os itens de trabalho passaram nos status selecionados, com uma média e um desvio padrão. Isso indica que o trabalho está lento. No entanto, ele não mostra todos os status lado a lado, nem quem estava com o trabalho. Assim, a retrospectiva é baseada na memória, e a solução depende de quem argumenta melhor.
Timepiece - Tempo no Status para Jira da OBSS transforma esse histórico em relatórios. Ele lê as mudanças de status que o Jira já armazena, cobrindo sprints passados assim que você o instala, sem que ninguém precise registrar nada. Veja o que ele responde:
Qual status consome a sprint?
O relatório de Duração do Status mostra o tempo que cada item de trabalho passou em cada status. Use colunas consolidadas para agrupar status em "espera" e "em andamento" (quais contam como espera depende do seu fluxo de trabalho) e, em seguida, ordene pela coluna de espera. Sua retrospectiva pode começar com números, não com sentimentos.
É um padrão ou apenas uma semana ruim?
O relatório de Média agrupa os resultados por sprint, mês ou outro campo, como tipo de tarefa. Se o status "Em Revisão" está lento em todas as sprints, vale a pena corrigir. Se houve um pico apenas uma vez, provavelmente não.
Com quem o trabalho ficou parado?
A Duração do Responsável por Status mostra o tempo por pessoa em cada status, e a Duração do Grupo faz o mesmo para grupos de usuários, como desenvolvedores ou testadores. Se a maior parte do tempo "Em Revisão" está com um único revisor, isso aponta para a carga de trabalho, não para uma pessoa lenta. Os dados mantêm a conversa focada no processo, e não em culpar alguém.
Os números são justos?
Um calendário personalizado exclui fins de semana, feriados e horas fora do expediente. Sem isso, um trabalho entregue na sexta-feira à noite parece um atraso de todo o fim de semana, e a equipe para de confiar no relatório. O guia da OBSS para excluindo horas fora do expediente mostra a configuração.
Com que frequência o trabalho retorna?
O relatório de Contagem de Status mostra quantas vezes cada item de trabalho entrou em cada status, para que ciclos como QA voltando para Em Andamento fiquem evidentes.
E você não precisa esperar pela retrospectiva. As regras de destaque coloram os itens de trabalho cujo Tempo de Ciclo ultrapassa um limite definido por você, e os alertas enviam uma mensagem por e-mail, Slack ou Microsoft Teams quando um limite é atingido. Você pode desbloquear o trabalho enquanto ainda há tempo na sprint.
O que você ganha ao usar ambos os aplicativos?
O Timepiece mostra onde o trabalho fica parado. Ele não mostra se as pessoas nessa etapa têm disponibilidade. A Linha do Tempo de Atividade mostra. Analise-os em conjunto e você saberá qual solução precisa aplicar:
- O revisor aparece sobrecarregado na Linha do Tempo de Atividade: É um problema de capacidade. Redistribua o trabalho para alguém com disponibilidade ou planeje o tempo de revisão para a próxima sprint.
- O revisor tem disponibilidade, mas o trabalho continua parado: É um problema de processo. Analise a passagem de bastão: como as revisões são solicitadas, quem as assume e quando.
Esse é o valor de ler ambos: você concentra esforços na solução que corresponde à causa real, e não na que parece correta durante a retrospectiva.
Planejamento de Capacidade de Sprint com Fluxo: Um Workflow que se Sustenta
Use as duas visualizações como um ciclo:
- Planeje a capacidade da sprint na Linha do Tempo de Atividade como de costume. Verifique os indicadores de carga de trabalho e o Gráfico de Capacidade da Equipe, e considere as ausências.
- Durante a sprint, observe o tempo em cada status no Timepiece. Desbloqueie o trabalho que está parado há mais tempo do que o habitual.
- Após a sprint, compare as horas planejadas com as horas reais no gráfico de Planejado vs. Realizado da Activity Timeline. Ele compara o tempo agendado com o tempo registrado, indicando se suas estimativas estavam corretas, e não se o trabalho avançou rapidamente.
- Use o que você aprendeu para o próximo planejamento. Por exemplo, reserve um tempo de revisão para as pessoas que mais revisam tarefas.
Uma desvantagem: para uma equipe pequena com um quadro compartilhado, uma olhada diária no quadro pode dizer a mesma coisa. A configuração com duas ferramentas compensa quando vários projetos compartilham as mesmas pessoas, pois as filas ficam mais difíceis de identificar visualmente.
Quais métricas você deve analisar em conjunto?
Um número isolado raramente revela o que deu errado. Coloque uma visualização de cada aplicativo lado a lado e o motivo pelo qual um sprint atrasou geralmente se torna muito mais claro.
Os números mostram onde procurar. Sua equipe pode explicar por que aconteceu.
Descubra para onde foram os dias do seu sprint
Um gráfico de capacidade verde significa que sua equipe tinha tempo disponível. Isso não significa que o trabalho avançou. Quando um sprint atrasa e ninguém estava sobrecarregado, os dias perdidos geralmente estão em uma fila: aguardando revisão, controle de qualidade ou aprovação.
A capacidade mostra o esforço, o fluxo mostra o tempo e seu prazo está no calendário.
Quer ver para onde foram os dias do seu sprint? Ambos os aplicativos possuem um teste gratuito no Atlassian Marketplace:
- Experimente o Activity Timeline para planejar a capacidade do sprint com base na disponibilidade real.
- Experimente o Timepiece - Time in Status for Jira para ver quanto tempo o trabalho aguarda em cada status.
Não tem certeza se sua fila é um problema de pessoas ou de processo? Leia o artigo complementar no blog da OBSS.
