Um limite de trabalho em andamento é uma das mudanças de processo mais baratas que uma equipe pode fazer: escolher um número, escrevê-lo no board, concordar em não iniciar novo trabalho além dele. O Azure Boards permite tranquilamente que você rotule uma coluna com um limite. O que ele não faz sozinho é dizer, sprint após sprint, se a equipe realmente está dentro desse número ou se está silenciosamente acima dele há três semanas enquanto todos olhavam para as colunas do board em vez de contar.
O que "em andamento" realmente significa
Um limite de WIP só é honesto se "em andamento" significar algo específico. Um item conta como em andamento se tiver um sinal real de início de trabalho, uma transição mapeada para em andamento, ou uma Data de Ativação, no momento medido ou antes dele, e ainda não estiver concluído nesse momento. Simplesmente ser criado e deixado parado no sprint não conta como iniciado; um backlog de itens intocados parados em um sprint não deve inflar silenciosamente uma contagem de WIP que deveria medir trabalho ativo.
Monitor de WIP: um número, um selo
A visão Monitor de WIP do Agile Gauge é restrita à equipe selecionada na barra superior do hub e mostra um único número de "em andamento agora" para o sprint em curso, além de um selo, Acima do limite, Perto do limite, ou Sem limite definido, exibido apenas quando precisa de atenção. Nada extra é mostrado quando tudo está bem, o que é intencional: uma tela que alguém verifica diariamente não deveria precisar ser lida com atenção para saber se algo está errado.
Onde o limite realmente fica
O limite em si é definido na Configuração e salvo para você, para aquela equipe: vale a pena saber isso antes que um desentendimento aconteça, porque é uma configuração pessoal, não uma compartilhada por toda a equipe. Duas pessoas na mesma equipe podem definir cada uma um número diferente e cada uma verá o seu como salvo; a Configuração informa isso claramente ao lado do campo. Se um colega de equipe relata ver um limite diferente do seu para a mesma equipe, isso não é um bug: significa que a equipe ainda não concordou de fato em um único número, apenas que cada um de vocês digitou algo separadamente.
O status é avaliado em três faixas: acima do limite é "acima do limite"; em 80% do limite ou mais, mas não acima dele, é "perto do limite": exatamente no limite ainda conta como "perto", não "acima", já que só ultrapassar estritamente deveria acionar o aviso mais forte. Sem limite definido é um estado próprio e distinto, nunca tratado silenciosamente como "saudável" só porque não há nada para comparar.
O que realmente conta para o número
Apenas os tipos de item de trabalho que sua organização configurou para contar nas métricas contam para o WIP: por padrão, trabalho planejado como histórias e itens de backlog de produto, bugs, e itens de pesquisa. Tarefas e outros tipos são excluídos por padrão, a menos que uma equipe os adicione deliberadamente na Configuração, já que contar cada subtarefa junto com cada história tende a fazer o WIP parecer muito pior do que o gargalo real que a equipe está tentando enxergar.
Escolhendo um número que vale a pena manter
A parte mais difícil de um limite de WIP raramente é a ferramenta: é chegar a um acordo sobre o número em si. Um limite definido alto demais nunca realmente restringe nada, e a equipe nunca descobre o que ele deveria ter evitado. Um limite definido baixo demais vira uma regra que ninguém segue em uma semana, o que é pior do que não ter limite nenhum, porque ensina à equipe que limites são decorativos. Uma forma razoável de começar é ficar próximo do que a contagem real de itens em andamento da equipe tem sido recentemente, o próprio gráfico de tendência do Monitor de WIP mostra exatamente isso, e apertá-lo gradualmente conforme a equipe fica confortável em ficar abaixo dele, em vez de escolher um número de um material de treinamento e esperar que ele sirva.
Também vale a pena combinar, em voz alta, o que acontece quando a equipe atinge o limite: alguém termina alguma coisa antes de iniciar o próximo item, ou o limite é silenciosamente ignorado "só desta vez"? Um limite aplicado de forma inconsistente ensina à equipe que ele é opcional, o que anula todo o propósito de tê-lo: o número na Configuração só cumpre seu papel se a equipe realmente concordou em respeitá-lo.
Lendo a tendência, não só o dia de hoje
A contagem de um único dia responde "estamos acima agora", mas não "isso está piorando". Abaixo do limite e do selo, um gráfico de barras mostra o em-andamento-no-ponto-médio para os últimos até oito sprints, com o limite de WIP desenhado como uma linha de referência quando há um definido. Uma equipe que ocasionalmente fica um pouco acima do limite parece muito diferente de uma que vem subindo constantemente há dois meses: o mesmo número diário poderia pertencer a qualquer uma das duas equipes, mas o gráfico as diferencia.
Limites conhecidos
O Monitor de WIP é restrito a uma equipe por vez: não há uma tabela com todas as equipes nesta visão, nem exportação em CSV. O histórico é limitado aos últimos oito sprints, e o limiar de "perto do limite" é fixo em 80%, não configurável por equipe nesta tela. Nenhum dos blocos aqui também se aprofunda em uma lista de itens de trabalho, exceto o botão do banner "sem limite definido", que leva direto à Configuração: o Monitor de WIP foi criado para responder a uma pergunta rapidamente, não para ser um navegador geral de itens.
Chegando lá
Duas coisas precisam ser configuradas uma vez: quais tipos de item de trabalho contam nas métricas, e o limite em si, ambos na Configuração. Depois disso, o Monitor de WIP lê o sprint atual da sua equipe toda vez que você o abre: não há nada para recalcular manualmente, e nada que fique desatualizado entre um stand-up e outro.
O Agile Gauge começa em $20 por mês para até 2 usuários. Comece uma avaliação gratuita de 14 dias: todos os recursos, sem cartão.