Mostrando entradas con la etiqueta #PO. Mostrar todas las entradas
Mostrando entradas con la etiqueta #PO. Mostrar todas las entradas

domingo, 9 de abril de 2023

¿Cómo maximizar el valor del producto? ¡Priorizando!

Resumen: Realizar una buena priorización es clave para el éxito de proyectos, productos y servicios, incluso para nuestras decisiones personales. Bien sea porque eres el Product Owner (PO) de tu equipo, o un Scrum Master que ayuda al PO en la priorización del backlog, o quieras realizar mejores decisiones sobre aspectos relevantes de tu vida, acordar criterios y aplicar técnicas de priorización, facilita maximizar el valor de lo que hacemos. Una correcta priorización del backlog logra poner el trabajo en orden, asegurando que enfocamos esfuerzos y recursos en aquello que es más relevante en ese momento, sin olvidar el carácter dinámico de las prioridades. En este artículo se describen los criterios más habituales que se tienen en cuenta para priorizar los elementos del Product Backlog (PBIs), se desarrollan 2 de las técnicas más usadas en agilidad (Moscow y WSJF), se explica brevemente como estimar utilizando la serie de Fibonacci y póker planning, y para terminar, se presenta un ejemplo de cómo utilizar estos criterios y técnicas de priorización para priorizar y ordenar tus pendientes personales.

En Scrum, el Product Owner (PO) es el responsable de maximizar el valor del producto, y lo hace a partir de la adecuada gestión de los elementos del Product Backlog (PBI- Product Backlog Item), expresando claramente estos elementos y ordenándolos para alcanzar los objetivos del producto, de la mejor manera posible.

Al ordenar el Product Backlog se coloca en la parte superior los elementos más prioritarios y en la base los menos prioritarios. Al priorizar, se decide qué solucionará el equipo primero y qué solucionará después. La priorización es un principio, que en palabras de Covey significa "hacer primero, lo primero".  

La priorización es responsabilidad del PO y cuenta con la ayuda del equipo ágil. Se prioriza tanto al inicio del proyecto/producto, como en cada iteración, ya que el backlog vive en constante adaptación.

Con una correcta priorización del backlog se logra poner el trabajo en el orden que mejor maximice el valor del producto, asegurando que el equipo siempre esté desarrollado trabajo relevante y necesario, aportando la visión y la perspectiva del negocio.

Algunos de los factores más habituales que se tienen en cuenta para priorizar los PBIs son: el Valor que aporta el desarrollo al usuario, cliente o negocio, nivel de Importancia, nivel de Urgencia, Esfuerzo o tamaño del desarrollo requerido, Dificultad o Riesgos asociados al desarrollo, entre otros criterios.

A partir de los criterios de priorización han surgido distintas técnicas para priorizar los PBIs, tales como: el Método Moscow, la Matriz de Eisenhower, la Matriz de Impacto vs Esfuerzo, la Comparación en pares de Historias de Usuario, WSJF - Weighted Shortest Job First, y el Modelo de Kano, entre otros.

Describiré 2 de las técnicas más utilizadas: Moscow y WSJF.

Moscow, como la capital de Rusia, es una nemotecnia de Must, Should, Could y Won’t. que en castellano sería:

  • MUST: Lo que debemos hacer, y haremos de inmediato.
  • SHOULD: Lo que deberíamos hacer, y haremos en lo posible.
  • COULD: Lo que podríamos hacer, y haremos si nos da la capacidad. 
  • WON’T: Lo que no haremos ahora, y quizás haremos más tarde.

Su objetivo es ordenar los elementos de la lista del producto, considerando la necesidad y entrega de valor a la organización. 

La estimación del tipo de Requisito es responsabilidad principal del PO, y junto al equipo acuerda los criterios que aplicará para establecer cuando un requisito es esencial, importante o deseado, son mejoras, o características que el producto o proyecto no tendrá por ahora.

Para cada PBI el PO estima el tipo de requisito, asignando la prioridad:

  • Los requisitos Esenciales que debe tener el producto o proyecto, como características críticas, que no tienen reemplazo o alternativa, se les asigna Prioridad 1.
  • Los requisitos Importantes y Deseados que pueden ser obtenidos de otra forma, si fuese necesario, mientras son desarrollados, y que se harán luego de la prioridad 1, se les asigna Prioridad 2.
  • Las Mejoras para el producto o proyecto, donde puede haber varias alternativas, que se analizarán y harán cuando se disponga de capacidad, y hayan sido cubiertos los requisitos de prioridades 1 y 2. A éstos se les asigna Prioridad 3.
  • Las características que se han acordado no tendrán el producto o proyecto por ahora, se les asigna Prioridad 4. Dado el carácter dinámico del backlog, esta prioridad podría cambiar con el tiempo.

WSJF - Weighted Shortest Job First - El trabajo más corto ponderado primero, permite priorizar los requisitos o PBIs que entregan más valor en el menor tiempo, en entornos donde el coste de la demora (Cost of Delay - CoD) y el esfuerzo o duración de los elementos de trabajo cambian o pueden cambiar.

Su objetivo es ordenar los elementos de la lista del producto según el impacto que tendrán para la organización y el esfuerzo que demandará su desarrollo.

Para ello, se prepara una matriz con los PBIs en la primera columna de la matriz y se añaden las siguientes columnas: Valor, Criticidad, Riesgo/Oportunidad, Coste del retraso, Esfuerzo (tamaño) y WSJF.

·      Para cada PBI el PO con su equipo de negocio estima Valor, Criticidad y Riesgo/Oportunidad y el Equipo de Desarrollo estima el Esfuerzo.

·      Se calcula el Coste del retraso (CoD) sumando el Valor del negocio, su Criticidad en el tiempo y el Riesgo/Oportunidad.

·      Se calcula WSJF dividiendo el CoD entre el Esfuerzo.

·      Se ordenan los elementos de la lista del producto de mayor a menor por su valor de WSJF. El resultado es una lista priorizada de PBIs.



¿Cómo estimar utilizando Fibonacci y Póker Planning?

La secuencia de Fibonacci comienza con los números 1 y 2, y a partir de estos, el siguiente valor es la suma de los dos anteriores, así la serie contiene los números:  1, 2, 3, 5, 8, 13, 21, permitiendo representar que algunos parámetros como el esfuerzo o el riesgo no aumentan linealmente, sino exponencialmente. Algunos equipos acuerdan utilizar como valores máximos el 13 o el 21, y en algunos casos, utilizar el valor 20 en lugar del 21.

Una de las técnicas de estimación más utilizada por los equipos es el Póker Planning, donde cada participante deberá votar en secreto por el tamaño o riesgo relativo de cada PBI, y al revelar el valor, se consensua entre todos, la estimación que será utilizada.

Se disponen de varias aplicaciones en línea para aplicar esta técnica, y si se utiliza en una reunión presencial, se utiliza un mazo de cartas. En todo caso, es una dinámica que facilita una estimación colaborativa y por consenso.

Por último, ¿podrías utilizar estos criterios y técnicas de priorización para priorizar y ordenar tus pendientes personales?

Como he compartido en otras ocasiones, la agilidad es una forma ser, acompañada de técnicas y herramientas para poner en práctica sus valores y principios. Cuando eres agilista aplicas sus prácticas en proyectos y procesos laborales y personales.

Así, por ejemplo, dado que la capacidad y los recursos son limitados, y buscando productividad y eficiencia haciendo una cosa a la vez, sí necesitamos tomar decisiones y priorizar entre varios pendientes, que pudieran ser todos importantes, podríamos experimentar haciendo una matriz WSJF:

Propósito: Mejorar y ampliar mis opciones laborales:

Pendiente

Valor

Criticidad

Riesgo/Oportunidad Laboral

CoD

Esfuerzo

WSJF

Estudiar Inglés

5

8

8

21

8

2,63

Certificarme Agile Coach

8

3

5

16

5

3,20

Certificarme PMP Agile

5

3

3

11

8

1,38

Fibonacci: 1 (muy poco), 2 (poco), 3 (medio), 5 (alto), 8 (muy alto)

En este ejemplo, WSJF, recomienda comenzar con una Certificación Agile Coach. Claro está, estas técnicas te facilitan información adicional para apoyar la toma de decisiones, pero finalmente, quien decide es la persona responsable de la priorización.

¿Cuál ha sido tu experiencia con la priorización? ¿Te parece algo trivial y sencillo, o estás de acuerdo que el disponer de criterios y técnicas de priorización ayuda a obtener un mejor resultado?

Gracias por leerme, compartir y comentar

Saludos,

María Esther Remedios

@Soy.Agile.Coach



lunes, 25 de julio de 2022

Product Owner: ¿Tiene que escribir y validar las historias de usuario? ¿Quién suple las ausencias temporales del PO?

 

El Product Owner (PO) es una pieza clave dentro del equipo Scrum, ya que es el responsable de maximizar el valor del producto en el que trabaja el equipo, gestionando y priorizando el Product Backlog (PB).

Destaca entre sus responsabilidades, la escritura de historias de usuario (HU) con criterios de aceptación que guíen y faciliten el trabajo del equipo, asegurando que el trabajo pendiente sea visible y adecuadamente comprendido por los desarrolladores. También es responsable de la validación de las HU que se desarrollen en el sprint.

El PO es una persona que representa al cliente o negocio ante el equipo Scrum. No es un grupo, ni un comité.

El PO hace equipo con usuarios y stakeholders, en quienes puede delegar tareas como la escritura y validación de HU, manteniendo la responsabilidad sobre el PB y cada uno de los elementos que lo conforman.

Por lo tanto, pueden presentarse varios escenarios:
  1. El PO escribe y valida las HU, apoyándose en usuarios y expertos del producto.
  2. El PO escribe y valida las HU donde tiene mayor dominio funcional, y delega la escritura y validación de otras HU en miembros de su equipo de negocio.
  3. El PO delega la escritura y validación de la totalidad de las HU que conforman el PB.

El PO podría facilitar que las personas que escriban HU conozcan la semántica, herramientas y buenas prácticas relacionadas con esta tarea, así como garantizar que el equipo de desarrollo pueda acceder a estos especialistas para aclarar dudas y obtener una completa comprensión de la especificación funcional.

Asimismo, el PO tiene la responsabilidad de que se realicen las pruebas de aceptación de usuarios y se validen las HU dentro de los límites de duración del sprint.

No se recomienda tener una figura intermedia entre el PO y el equipo, lo que en algunas organizaciones llaman Product Owner Proxy, dado que es una persona que no puede asumir las responsabilidades del PO, y dificulta la necesaria cercanía entre el PO y el equipo.

Para asumir plenamente sus responsabilidades, el PO debe asistir a los eventos Scrum, pudiéndose acompañar de las personas de su equipo funcional más relacionadas con la agenda del evento.

asumir plenamente sus responsabilidades, el PO debe asistir a los eventos Scrum, pudiéndose acompañar de las personas de su equipo funcional más relacionadas con la agenda del evento.

Siempre habrá que gestionar las situaciones especiales, como quién suple al PO en caso de vacaciones, formación o bajas; para no perder el ritmo del equipo o la cadencia de los sprints.

Esto depende de cada equipo y organización:
  • Hay PO que trabajan estrechamente con alguien de su equipo funcional que lo suple cuando es necesario.
  • Hay PO que dejan suficiente backlog priorizado y preparado, y las labores de coordinación las asume el Scrum Master.
  • En otros casos, el equipo de desarrollo es capaz de continuar el desarrollo del producto, con bajos riesgos, mientras se incorpora el PO.
En todo caso, es el PO quien debe gestionar cómo proceder durante su ausencia, ya que, en última instancia, la responsabilidad de que el equipo dé el mayor valor, es suya.

Comparte tu opinión y experiencia sobre este tema.

Muchas Gracias

@Soy.Agile.Coach