Framework Ágil WSJF

O Weighted Shortest Job First (WSJF) ajuda-o a priorizar o trabalho equilibrando o custo do atraso contra a dimensão do trabalho. Esta framework oferece o máximo valor com recursos limitados em ambientes de rápida mudança.

Priorização WSJF numa casca de noz

Criar uma conta Ducalis gratuita

Cálculo WSJF

Pontuação WSJF = (Valor de Negócio + Criticidade Temporal + Redução de Risco) / Dimensão do Trabalho

Critérios

Valor para o Utilizador/Negócio classifica os trabalhos pela sua importância para os utilizadores e pelo impacto potencial na receita.

Criticidade Temporal classifica os trabalhos por urgência—como o valor decai ao longo do tempo ou quantos clientes pode perder ao adiar.

Redução de Risco e Capacitação de Oportunidades destaca trabalhos que podem não trazer receita imediata mas beneficiam os resultados a longo prazo. Algumas soluções eliminam riscos técnicos ou legais e poupam dinheiro mais tarde.

Duração do Trabalho (também chamada story points, feature points, esforço ou dimensão relativa) mede a complexidade de implementação. Com esta estimativa, números mais pequenos são melhores.

Avaliação

1. Avalie cada critério na escala Fibonacci: 1 (sem impacto), 2, 3, 5, 8, 13, 21 (maior impacto).

2. Execute sessões de priorização colaborativa com equipas de cinco a onze pessoas.

3. Avalie tarefas antes de cada evento de planeamento de iteração (sprint).

4. Normalize diferentes pontuações através de discussão com colegas de equipa.

5. Divida iniciativas com Dimensões de Trabalho '21' e '13' em projetos mais pequenos (refinamento de backlog).

6. Reinicie as pontuações de avaliação a cada cinco iterações (Program Increment) para refletir o ambiente de rápida mudança.

Aplique o modelo de priorização Ducalis pronto a usar

Não é necessário personalizar critérios, fórmulas e escalas. Use-os como modelo base para iniciar a reunião.

Nota

WSJF não é apenas uma fórmula—é parte de uma framework de fluxo de trabalho abrangente para empresas. A magia acontece quando muda a sua abordagem de tomada de decisão: execute sessões de priorização colaborativa, defina expiração de pontuações, especifique critérios e explique descrições de tarefas aos colegas de equipa. Este artigo fornece ferramentas para criar esse hábito de priorização e mudar a sua mentalidade.

Definição de WSJF

WSJF significa Weighted Shortest Job First—uma framework de priorização para priorizar backlogs calculando o Custo de Atraso (CoD) relativo e a dimensão do trabalho (um proxy para a duração). O CoD calcula-se como uma soma: Valor para Utilizador/Negócio + Redução de Risco e Capacitação de Oportunidades + Criticidade Temporal. Faz parte da metodologia SAFe.

As prioridades do backlog são continuamente atualizadas com base nas pontuações de prioridade WSJF. A framework convenientemente e automaticamente ignora custos irrecuperáveis, um princípio fundamental da economia Lean.

Num sistema baseado em fluxo, a priorização contínua de tarefas para atualizar prioridades fornece os melhores resultados económicos para:

• Sequenciação de trabalho ao empurrar vitórias rápidas para a frente
• Equilíbrio do maior resultado financeiro enquanto reduz recursos investidos
• Atualização regular de CoD e Dimensões de Trabalho para refletir o ambiente de rápida mudança

O que é SAFe?

A Scaled Agile Framework (SAFe), segundo ScaledAgile.com, é um sistema para implementar práticas Agile, Lean e DevOps em escala. Pega nas melhores ideias da entrega ágil de produto e expande-as a toda a empresa para fornecer agilidade empresarial. SAFe é a framework mais popular para empresas líderes porque funciona: é confiável, personalizável e sustentável.

Atualiza constantemente e tem versões. Em 2022, a versão mais recente é 5.1, e SAFe cobre sete áreas principais da empresa:

• Agilidade de Equipa e Técnica
• Entrega Ágil de Produto
• Entrega de Solução Empresarial
• Gestão Lean de Portfolio
• Agilidade Organizacional
• Cultura de Aprendizagem Contínua
• Liderança Lean-Ágil

Resultados prometidos:

• +50% tempo de chegada ao mercado mais rápido
• +50% redução de defeitos
• +35% aumento de produtividade
• +30% de colaboradores mais felizes e envolvidos

Neste artigo, vamo-nos focar na fundação—a framework de tomada de decisão WSJF.

Transferir modelo WSJF gratuito:

Como calcular WSJF

Fórmula WSJF

A framework Weighted Shortest Job First (WSJF) ajuda-o a decidir que tarefa escolher a seguir para entregar o máximo valor com recursos limitados ao encontrar um equilíbrio entre Custo de Atraso (CoD) e Dimensão do Trabalho num mundo de rápida mudança.

Calcular pontuação WSJF

Pontuação WSJF = Custo de Atraso / Dimensão do Trabalho

Calcule CoD, que define três tipos de questões de desenvolvimento de produto que deve observar.

Custo de Atraso = Valor Utilizador-Negócio + Criticidade Temporal + Redução de Risco | Valor de Capacitação de Oportunidades

Avalie cada critério com uma escala de 1, 2, 3, 5, 8, 13, 21.

Princípios de estimativa:

• A estimativa WSJF visa compreender o nível de incerteza, não calcular horas ou dinheiro (o que é quase impossível). É por isso que estimamos probabilidade em vez de tempo exato para realizar uma tarefa específica. Chama-se avaliação relativa.

• Como o objetivo principal é entregar valor em cada iteração, a mediana da sequência será "uma iteração."

• Uma iteração = duas semanas. A nossa base de planeamento. Calculamos números de story point para uma iteração de duas semanas.

• Program Increment (PI) = cinco iterações (dez semanas). Segundo a SAFe, PI é uma caixa de tempo durante a qual um Agile Release Train (ART) entrega valor incremental na forma de software e sistemas a funcionar e testados. A equipa inteira realiza algo grande para o produto. Por outras palavras, a organização lança uma grande atualização, após a qual devem reavaliar o seu backlog, pensar e discutir prioridades mais uma vez.

Personalização

Isto é apenas uma recomendação, e é livre de personalizar a abordagem de qualquer forma que seja confortável para a sua equipa. Mais tarde neste artigo, cobrimos como compreender melhor e personalizar os critérios precisamente para as suas necessidades de negócio.

Valor para Utilizador-Negócio (UBV)

Novas funcionalidades e inovações que impulsionam o seu produto para a frente. Por exemplo, opções de login de segurança empresarial ajudam a evitar reclamações de grandes clientes, o que leva a vendas.

O Valor para Utilizador/Negócio (UBV) classifica os seus trabalhos pela sua importância relativa para o utilizador (Priorização de Desejabilidade) e impacto potencial na receita (Priorização Financeira). Neste ponto, estima quão eficaz é esta solução na promoção da sua Métrica Estrela Polar. Como muitos fatores podem influenciar o UBV, comece a pensar no impacto empresarial e aumente a sua confiança de que tudo funcionará.

Questões a responder: Qual é uma métrica vital do produto que pode atualizar? Quão importante é isto para os utilizadores? Qual é o impacto na receita?

Avaliação de Valor para Utilizador-Negócio com sequência Fibonacci

• 1 ponto: nenhum valor para utilizador-negócio; esta tarefa está relacionada com outra coisa
• 2 pontos: o menor impacto empresarial e confiança
• 3 pontos: baixo impacto empresarial e confiança
• 5 pontos: impacto empresarial moderado, confiança moderada
• 8 pontos: alto impacto empresarial e confiança
• 13 pontos: impacto empresarial muito alto e confiança
• 21 pontos: o maior impacto empresarial e confiança

Criticidade Temporal (TC)

Avalie a urgência. As iniciativas têm prazos justificados como novos regulamentos, reporte fiscal, promoções sazonais, etc.

A Criticidade Temporal classifica os trabalhos por urgência. Estima como o valor decairá ao longo do tempo ou quantos clientes pode perder se demorar.

O nosso cronograma de estimativa é de uma iteração (duas semanas) a um Program Increment (PI) (dez semanas). Em cada ciclo PI, executamos uma nova sessão de reavaliação (após expiração de pontuação) e decidimos como a urgência mudou.

Questões a responder: Quão urgente é para o negócio? Os utilizadores esperarão ou mudarão para outra solução? Existe um prazo fixo?

Avaliação de Criticidade Temporal com sequência Fibonacci

• 1 ponto: não é uma tarefa crítica no tempo
• 2 pontos: pode esperar até ao próximo ciclo de estimativa (após expiração de pontuação a cada cinco iterações)
• 3 pontos: pode esperar quatro sprints (cerca de oito semanas)
• 5 pontos: urgência moderada, pode esperar três sprints (cerca de seis semanas)
• 8 pontos: pode esperar dois sprints (cerca de quatro semanas)
• 13 pontos: pode esperar um sprint (cerca de duas semanas)
• 21 pontos: a maior urgência, deve levar esse item para o próximo sprint

Redução de Risco | Valor de Capacitação de Oportunidades (RR | OE)

Tarefas para evitar ou reduzir riscos tecnológicos ou empresariais. Os exemplos incluem refatoração de código, atualização de base de dados, segurança ou auditoria fiscal—algo que deve fazer para garantir o funcionamento saudável de um produto.

A Redução de Risco e Capacitação de Oportunidades ajuda-o a destacar trabalhos que podem não trazer receita imediatamente mas beneficiam a longo prazo. Algumas soluções eliminam riscos técnicos ou legais e poupam-lhe dinheiro mais tarde. Outras podem abrir portas para melhorias futuras que aumentarão significativamente o número de clientes potenciais.

Questões a responder: Se a tarefa começa com alguma descrição de risco, quão grande será o impacto desse risco? Que probabilidade?

Avaliação de Redução de Risco com sequência Fibonacci

• 1 ponto: não fornece qualquer redução de risco
• 2 pontos: reduzir a probabilidade de um risco mínimo, probabilidade de gravidade mínima
• 3 pontos: reduzir a probabilidade de um risco baixo, probabilidade de gravidade baixa
• 5 pontos: reduzir a probabilidade de risco moderado, probabilidade de gravidade moderada
• 8 pontos: reduzir a probabilidade de um risco moderado-alto, probabilidade de gravidade alta
• 13 pontos: reduzir a probabilidade de um risco muito alto, probabilidade de gravidade muito alta
• 21 pontos: pode reduzir o risco de um evento de alto impacto, um desastre que é mais provável acontecer

Dimensão do Trabalho (Duração do Trabalho)

A Dimensão do Trabalho é o único fator negativo e classifica os trabalhos pela complexidade de realização. É impossível alcançar o maior ROI sem considerar os custos das horas-pessoa necessárias. A duração também é chamada story points, feature points, esforço ou dimensão relativa.

Questões a responder: Quanto tempo levará a implementação? Existem dependências que podem torná-la mais demorada?

Avaliação de Dimensão do Trabalho com sequência Fibonacci (story points)

• 1 ponto: não é necessário qualquer esforço. Não podemos dividir por zero, portanto a nossa estimativa de Dimensão do Trabalho deve começar em 1.
• 2 pontos: a base de estimativa. 80% de probabilidade de que um dia é suficiente para codificar e um dia para testar e validar para uma iteração de duas semanas.
• 3 pontos: uma tarefa cerca de um quarto dos esforços do seu sprint
• 5 pontos: algo metade da sua iteração. 80% de probabilidade de que a tarefa levará 5 dias úteis a codificar e um dia a testar e validar para uma iteração de duas semanas.
• 8 pontos: 80% de probabilidade de que uma tarefa será desenvolvida e testada dentro de duas semanas (uma iteração/sprint)
• 13 pontos: entre uma e duas iterações
• 21 pontos: "estimativas Buzz Lightyear," algo que leva dois sprints ou até mais ("até ao infinito e mais além"). Pela minha experiência prática a trabalhar com equipas, estará a avaliar muitas ideias que excedem uma iteração e devem ser divididas em partes mais pequenas.

A fórmula final para calcular a pontuação WSJF:

Pontuação WSJF = (Valor de Negócio + Criticidade Temporal + Redução de Risco | Capacitação de Oportunidades) / Dimensão do Trabalho

Personalize critérios para a sua equipa

Na framework Scrum padrão, a estimativa de story point de cada equipa—e a velocidade resultante—é uma preocupação local e independente. Aqui está um ponto de partida para o seu processo de avaliação. Pode aplicá-lo a partir do modelo WSJF Ducalis e modificar as descrições de critérios.

Não existe uma única definição correta para uma escala. Se você e a sua equipa estiverem confusos com algum termo—mude-o! Ducalis é bastante flexível nesse aspeto.

Iterações

O núcleo dos processos ágeis são os blocos de construção básicos chamados iterações ou sprints. Cada iteração é uma caixa de tempo padrão de comprimento fixo onde as Equipas Ágeis entregam valor incremental.

Evento de planeamento de iteração (Product Increment)

Cada iteração deve começar com uma lista clara de prioridades. Antes desse planeamento, deve ter um backlog avaliado. As equipas podem frequentemente passar a semana inteira entre ciclos de desenvolvimento para avaliação, priorização e planeamento. Depois, implementam valor em iterações curtas (sprints).

Ducalis pode poupar essa semana inteira para a sua equipa através de um processo de avaliação assíncrono. Defina um dia de planeamento, e Ducalis fará o resto. Pode acompanhar o progresso de avaliação com o relatório de progresso de avaliação da equipa.

Para motivar os seus colegas de equipa a avaliar a tempo, ofereça apoio com mensagens encorajadoras. Aceda às definições de hábito de priorização e defina uma mensagem recompensadora para colegas de equipa que terminem a sua avaliação a tempo antes da próxima reunião de planeamento de iteração.

O poder da reavaliação

As principais prioridades, urgência e valores empresariais são produtos perecíveis. Há tanto input—novos pedidos de clientes, bugs, dívidas técnicas, novos regulamentos, ideias elegantes e muito mais.

A ideia inteira de SAFe é adaptar-se de uma nova forma a um mundo em rápida mudança. O ambiente de uma empresa muda a cada cinco iterações (um PI). Portanto, é altamente recomendado reiniciar as pontuações de avaliação.

Num sistema baseado em fluxo, atualizar continuamente as prioridades fornece os melhores resultados económicos. A sequenciação de trabalho em vez do retorno teórico e individual sobre o investimento do trabalho produz o melhor resultado num contexto de fluxo.

Um benefício lateral da reavaliação de backlog é o grooming/refinamento de backlog. Ao pensar sobre cada item do backlog, terá algumas ideias sobre como fundir, atualizar ou remover a sua tarefa, pois algumas informações terão ficado desatualizadas por algum motivo. Pela experiência de hi.ducalis.io, removemos 2% a 5% dos nossos itens de backlog em cada ciclo de reavaliação.

Para configurar ciclos de reavaliação:

1. Clique em Meeting in # days (Reunião em # dias).
2. Desloque para baixo até à secção de expiração de pontuação.

Por defeito, as pontuações de avaliação da sua equipa expirarão após iniciar o próximo ciclo PI.

Por defeito, o sprint tem duas semanas de duração. Personalize-o na secção de hábitos de priorização.

Dica profissional

Se as suas pontuações expiraram e não terminou o PI anterior, pode sempre restaurar as suas pontuações e estender o período de priorização.

Priorização colaborativa

A estimativa ágil é um desporto de equipa. Cada equipa ágil compreende cinco a onze membros. Convide a sua equipa ágil (equipa multifuncional) para o processo de priorização.

Quando uma equipa estima o product backlog, não sabe quem trabalhará em cada tarefa. As equipas normalmente determinam isso durante o planeamento de iteração (sprint).

É por isso que a equipa ágil inteira avalia cada item do product backlog.

Reduzir viés

A equipa inteira precisa de compreender a lógica por trás da atribuição de story points para alcançar uma prática consistente. Todos os membros da equipa votam sem serem influenciados por outros membros da equipa. Pressão externa ou trabalho de equipa insuficiente pode rapidamente inflar story points, afetando previsões.

Por vezes, as reuniões de priorização podem ser lideradas pela pessoa mais ruidosa na sala. Isto significa que podem interferir uns com os outros durante a sessão de avaliação. Deixe todos priorizarem ao seu próprio ritmo.

Escolha 'O Impacto Certo'

Falámos sobre o impacto empresarial no início do artigo. Mas que respostas obterá se perguntar a diferentes funções: uma pergunta simples "Qual é a coisa mais impactante que devemos fazer a seguir?" Por exemplo, aposto que um programador lhe dirá "base de dados mais rápida," um vendedor dirá "um pedido de funcionalidade para o maior cliente," e um gestor de produto perguntará "nova mensagem de retenção," etc.

É quase impossível comparar qual é mais impactante. No entanto, é uma boa coisa a considerar para cada equipa ágil e precisamente o que Ducalis pode gerir para si.

Recolha diferentes opiniões

As frameworks de priorização são ótimas para manter emoção e política fora de uma decisão para que possa confiar em factos. No entanto, quando prioriza sozinho, ainda está enviesado. Peça emprestada a técnica de poker planning para priorização. Com Ducalis, convide cada membro da equipa para a priorização.

Para convidar colegas de equipa:

1. Abra as definições de critérios.
2. Convide colegas de equipa para a sua equipa de avaliação partilhada.

Isto fornece a cada colega de equipa a sua lista de avaliação para estimativa independente.

Especifique critérios para cada função

Digamos que precisa de desenvolver uma nova funcionalidade para o seu website. Tem pelo menos três funções—designer UX, front-end e back-end—todos têm uma Dimensão de Trabalho diferente para essa funcionalidade. UX precisa de uma Dimensão de Trabalho de 3 dias, o front-end precisa de um dia e o back-end precisa de cinco dias. Qual é a Dimensão de Trabalho para o projeto total?

O problema não é o cálculo; a sua equipa deve encontrar um espaço de tempo para discuti-lo. Num mundo remote-first, isso significa mais uma chamada Zoom e discussão. Mais trabalho à volta do trabalho.

Ducalis pode gerir isso para si com uma abordagem de priorização assíncrona.

Para atribuir critérios por função:

1. Abra as definições de Critérios.

2. Atribua a cada utilizador um critério para estimar de acordo com a sua especialização.

   

Depois disso, cada membro da equipa avaliará itens de backlog com o seu conjunto de critérios, pelos quais são responsáveis por estimar.

Quando todos participam, aumenta o compromisso

O efeito colateral da priorização colaborativa é que os colegas de equipa compreendem melhor o que se passa com o produto. Sabemos que desafios, pedidos e ideias temos e por que alguns são mais importantes que outros. Aumenta a moral e o envolvimento da equipa.

Normalize pontuações

Ocorre um pouco de normalização através da prática regular, ajudando a garantir que todos na equipa fazem as mesmas suposições por trás do dimensionamento. Por exemplo, se uma pessoa dimensiona um item como "2", mas outra pessoa o dimensiona como "8," dado que partilham capacidades semelhantes, interpretaram o requisito de forma diferente ou abordaram-no de diferentes direções. Quando isto acontece, os Programadores colaboram com o Product Owner para clarificar suposições e concordar num tamanho. (Isto não precisa de ser um consenso—as pessoas podem concordar em discordar.)

Enquanto uma equipa está a aprender o que a escala Fibonacci significa para eles, com o seu conjunto único de competências, permanência e conhecimento de domínio, é útil comparar novos pedidos a trabalho concluído com semelhanças partilhadas. Por exemplo, quando um novo item recebe um valor de story point de 5, compare-o com coisas semelhantes com o mesmo tamanho e ajuste os pontos em conformidade.

Com Ducalis, pode verificar rapidamente o relatório de alinhamento da equipa para obter um mapa de calor de desacordos. Esta é outra ferramenta para priorização assíncrona em vez de executar uma sessão de poker planning, onde a maioria das estimativas não precisará de qualquer discussão.

Divida em partes mais pequenas

Um dos maiores mal-entendidos sobre WSJF é que pode focar a sua equipa apenas em tarefas fáceis (frutos fáceis de apanhar). Em vez disso, quanto menor a Dimensão do Trabalho para uma tarefa específica, maior a pontuação de prioridade e maior a tarefa será classificada.

Use uma matriz para fatiar o seu backlog em peças e decidir o que fazer com as suas tarefas.

Através da prática de refinamento—dividir o trabalho em partes mais pequenas e valiosas—os Programadores continuam a ganhar perceção. À medida que cada pedido se torna mais pequeno e mais é conhecido, revisitam continuamente o tamanho. Portanto, é bom fornecer três pontos de contacto para ajudar a equipa com o design emergente, desenvolvimento e dependências.

Conselho prático

• Não tente ser demasiado preciso. Se tem uma tarefa de uma hora, não tenha medo de definir uma base para um dia. Tudo será compensado e equilibrado a longo prazo.

• Arredonde estimativas para o próximo valor.

• No entanto, a decisão final permanece com o profissional de produto responsável por sequenciar os itens no backlog em questão. Fatores como prazos regulamentares, fragilidade do sistema legado ou construção de uma fundação para funcionalidades futuras podem ser desafiantes de colocar em termos financeiros mas ainda precisam de ser considerados.

Recursos relacionados

• Modelo WSJF Google Sheets

---

hi.ducalis.io não está associado com a Scaled Agile Framework ou SAFe. Leia a sua visão e manifesto em https://www.scaledagileframework.com/