A diferencia de lo que mucha gente piensa, el WSJF (Weighted Shortest Job First) no fue creado por Scaled Agile. La técnica para ayudar a priorizar features fue creada por Don Reinertsen y muy popularizada por Scaled Agile Framework® (SAFe®).
La técnica WSJF tiene en cuenta no solo el costo de la demora (COST OF DELAY, COD), sino también la duración del trabajo, en el que el tamaño de la obra se puede utilizar como un proxy como veremos más adelante.
COSTO DEL RETRASO (COST OF DELAY)
Considere el siguiente ejemplo. Insatisfecho con retrasos en las entregas, el director del proyecto decide que puede reducir la variabilidad mediante la inserción de un margen o seguridad de búfer en su horario. Reduce la incertidumbre del horario al comprometerse con un horario de confianza del 80%.
Pero, ¿cuál es el costo de este búfer? El director del proyecto en realidad está cambiando el tiempo del ciclo por variabilidad.
Solo podemos saber si este es un buen compromiso, si cuantificamos el valor del tiempo de ciclo y el beneficio económico de la variabilidad reducida.
En nuestra experiencia, ninguna sensibilidad es más reveladora que el costo del retraso.
Si no podemos cuantificar el beneficio, no podemos generar apoyo para grandes decisiones.
Necesitamos el costo de demora para evaluar la eficiencia con el menor desperdicio en el flujo de desarrollo del producto, el beneficio de tamaños de lote más pequeños y el valor de reducir la variabilidad.
También debemos señalar que el costo de demora y otras variables se pueden calcular en cualquier momento, no solo al final del proyecto.
LA TÉCNICA WSJF
Cuando la duración del proyecto y los costos de demora son diferentes, tenemos la situación más compleja y común.
En tales casos, Reinertsen sugiere que la mejor estrategia es calcular primero el trabajo más corto ponderado (WSJF).
Para esto, la prioridad se define en función de la duración de un trabajo y su costo de retraso.
La siguiente imagen demuestra la utilidad de esta métrica para la priorización en un contexto donde la duración del trabajo y el costo del retraso son diferentes para los tres proyectos de la cartera.
Reinertsen describe un modelo integral para priorizar trabajos basado en la economía del flujo de desarrollo de productos, donde los trabajos que pueden ofrecer el mayor valor (o costo de retraso) y la duración más corta se seleccionan primero para su implementación. Este modelo admite algunos principios adicionales del flujo de desarrollo de productos, que incluyen:
- Tener una visión económica
- Ignore los costos varados
- Tome decisiones financieras continuamente
- Utilice reglas de decisión para descentralizar la toma de decisiones y el control
- Si puede cuantificar solo una cosa, cuantifique el costo del retraso
La búsqueda de valores absolutos tanto para el costo del retraso como para la duración del trabajo en cada proyecto o iniciativa puede resultar bastante costosa.
Por lo tanto, Scaled Agile Framework® (SAFe®) entiende que tres elementos contribuyen al costo de la demora:
- Valor del usuario empresarial : ¿Nuestros usuarios prefieren esto o aqello? ¿Cuál es el impacto de los ingresos en nuestro negocio? ¿Existe una sanción potencial u otras consecuencias adversas si nos demoramos?
- Crítica del tiempo : ¿Cómo disminuye el valor del usuario/negocio con el tiempo? ¿Existe un plazo fijo? ¿Nos esperarán o cambiarán a otra solución? ¿Hay algún hito en el camino crítico afectado por esto?
- Valor de activación de oportunidades o reducción de riesgos : ¿Qué más hace esto por nuestro negocio? ¿Reduce el riesgo de esta entrega o de una futura? ¿Tiene valor la información que recibiremos? ¿Esta función abrirá nuevas oportunidades comerciales?
Además, considerando que la idea es mantener un flujo continuo, debes tener un portafolio de proyectos con cantidad suficiente para elegir.
WSJF EN SAFE
SAFe sugiere comparar los elementos de la lista de proyectos entre sí, utilizando la secuencia de Fibonacci modificada, la misma recomendada para el evento de planificación de iteraciones de Scrum.
De esta manera, el costo del retraso relativo se puede calcular de la siguiente manera:
Entonces necesitas comprender la duración del trabajo.
Esto puede ser bastante difícil de determinar, especialmente al principio, cuando puede que no se sepa quién hará el trabajo o asignará la capacidad a los equipos.
SAFe, nuevamente, indica un representante que se puede utilizar para este propósito: Tamaño del trabajo.
En sistemas con recursos fijos, el tamaño del trabajo es un buen representante de la duración.
Además, también sabemos cómo estimar el tamaño del artículo aplicando la secuencia de Fibonacci modificada.
Por lo tanto, al combinar la definición de WSJF propuesta por Reinertsen con las propuestas de SAFe de costos de demora y horas de trabajo, llegamos a la siguiente fórmula:
Aplicando esta fórmula a cada proyecto en la cartera, encontraremos un orden sugerido de priorización donde el WSJF más grande tendrá prioridad sobre aquellos con el WSJF más bajo.
CONCLUSIÓN
Sin embargo, no debemos simplemente calcular un número y seguirlo sin tener en cuenta otros aspectos importantes y conocidos como, por ejemplo, la dependencia entre proyectos.
Otro fenómeno importante que proporciona la técnica WSJF es el incentivo para dividir los proyectos en proyectos más pequeños.
En varios casos en los que se da por primera vez la aplicación de la técnica WSJF para priorizar el portafolio, se genera un gran malestar por la percepción de que un proyecto importante pierde prioridad sobre otros ítems del portafolio por proyectar una duración que resulta en un valor bajo para su WSJF, como explica Roberto Baptista en otro artículo de nuestro Blog sobre funciones innovadoras con WSJF .
La reflexión sobre este factor promueve un camino natural para reducir la duración de los proyectos, para permitir un mayor valor (costo de retraso) en la menor duración.
La ganancia indirecta se convierte en la creación de un Portafolio Lean, con la recolección de retroalimentaciones más rápidas en el mercado, aumentando la frecuencia de entregas de valor a la empresa.
¿Te gustó el artículo? Compártelo en Redes Sociales y ayúdenos a difundir este conocimiento a la Comunidad Agile Latinoamericana.
¡Hasta la próxima!
Este artículo fue publicado íntegramente en la Revista Mundo Project Management en el número 90 (19 / dic / 20 y ene / 20).
