A menudo el número de necesidades que impactan en un producte es muy elevado. Sabemos que, para un producto dado, el Product Owner ha de ser el único referente, con tal de evitar conflictos y confusiones sobre el proceso de ideación del propio producto, y sobre los equipos que trabajan para hacerlo realidad.
Pero que el Product Owner deba ser la única persona claramente identificable no significa que esta persona esté sola ante la complejidad del producto. Todas las personas impactadas o interesadas en el producto (los Stakeholders) colaboran en la identificación, justificación y priorización de las características del producto.
En este sentido, presentamos aquí una actividad muy interesante que ayuda al Product Owner a llevar a cabo una primera priorización de un gran número de necesidades. La matriz de Eisenhower.
La priorización de necesidades aplica en reuniones específicas que sirven para este objetivo. Pueden estar dentro o fuera del proceso de ejecución del producto. Pueden llevarse a cabo antes de iniciar las acciones de construcción del producto; o una vez estas se han puesto en marcha. Por tanto, podemos englobarlo en la categoría de las reuniones de Refinement contempladas por el marco de trabajo Scrum.
La herramienta que utilizaremos en esta actividad es la Matriz de Eisenhower. Consiste en un panel que se divide en cuatro áreas. Cada una de estas áreas da una indicación sobre la importancia y la urgencia de llevar a cabo una característica o necesidad concreta del producto. Así, tenemos un panel cómo el siguiente:
De forma general, podemos establecer, sin temor a equivocarnos, que una tarea con poca urgencia y poca importancia tendrá una prioridad baja en el Product Backlog de nuestro producto. Así mismo, una necesidad catalogada como importante y urgente tendrá una priorización alta.
El resto de opciones (importancia alta pero poco urgente, o urgencia alta, pero poco importante) pueden ser objeto de debate entre los participantes de la actividad, que deberán considerar que agrupación es más prioritaria.
Como siempre, la recomendación que hago para estas actividades es de no superar 1 hora de duración. Explicar las necesidades individualmente para asegurarnos que los participantes la comprenden de una forma alineada requiere mucho tiempo. Hemos de asegurar escoger un número de actividades que no supere el tiempo de la reunión. Probablemente, es preferible hacer diversas reuniones de una duración aceptable, que garantice la correcta atención de todos los asistentes, que en una única reunión maratoniana nos deje con dudas sobre si la clasificación obtenida es realmente la correcta.
Hemos de llegar preparados a la sesión. El Product Owner ya dispone de las tarjetas con la descripción de cada una de las características o necesidades que quiere priorizar. Aparte, es recomendable tener acceso al Product Backlog por si debe aclararse alguna duda referente a alguna necesidad.
A su vez, los asistentes han tenido acceso a esta información previamente a la sesión, de forma que pueden centrarse lo máximo posible en la explicación de una necesidad sin tener que perder demasiado tiempo en poner en contexto a los participantes.
Al inicio de la sesión, el Product Owner explica las reglas de trabajo y presenta la matriz. Si es necesario, puede establecer un debate con los participantes sobre la priorización que deben de tener las necesidades que se sitúen a las áreas de poca importancia y mucha urgencia, y mucha importancia y poca urgencia.
A partir de aquí la organización de la reunión es bastante libre, y depende mucho de la complejidad de las necesidades a explicar y de la habilidad de los participantes para tomar decisiones. Una aproximación conservadora sería que el Product Owner (o la persona con más conocimiento sobre una de las necesidades) explica ésta a los asistentes y pide una decisión al grupo con el objetivo de ubicarla en el área adecuada del cuadrante. Una vez hecho esto, pasaría a la siguiente necesidad hasta finalizar todas las necesidades previstas en la sesión.
Otra aproximación más dinámica es situar las tarjetas de las necesidades sobre la mesa y pedir a los asistentes que ellos mismos escojan alguna de estas tarjetas y la sitúen en la matriz. Posteriormente, es necesario que justifiquen al resto de asistentes los motivos principales de porqué la han situado en aquella área de la matriz, pudiendo establecer un debate para llegar a un consenso, y cambiando de posición las tarjetas si fuese necesario. Si el número de asistentes es suficientemente elevado, podemos pedir la creación de grupos de trabajo que se responsabilicen de cierto número de tarjetas.
El Product Owner, que es quien modera la sesión, ha de estar disponible para resolver dudas sobre el alcance o las características de las necesidades objeto de priorización. Y vigila que el grupo se enfoca en llegar a un consenso sincero sobre cada una de las necesidades.
Es muy conveniente explicar al inicio de la sesión que el objetivo no es llegar a un consenso sobre “el esfuerzo” necesario para hacer realidad las necesidades (esto lo hará el equipo técnico más adelante). La finalidad de esta sesión es únicamente la prioridad. No confundamos “fácil/difícil” con “importante/urgente”
Cómo usar la matriz de Eisenhower para priorizar tareas? (video tutorial) Trello.com (https://blog.trello.com/es/matriz-eisenhower)
Introducing the Eisenhower Matrix Eisenhower.me (https://www.eisenhower.me/eisenhower-matrix/)
Descarga el documento (cat)