Test Garzás: para saber cómo de sano (ágil) es el trabajo del Product Owner

Hoy, de nuevo, había empezado a escribir un post que nos hiciese pensar, reflexionar y, quizá, recordar, algunas cosas que encajan con la filosofía ágil y que se esperan de un Product Owner, y de su Product Backlog, aprovechando, de paso, que estamos añadiendo nuevo material al curso de Product Owner online. Y según lo escribía el propio formato que estaba tomando el post ya me estaba pidiendo que lo convirtiera en un nuevo… “Test Garzás”. Uno más, otro en línea con los otros “famosos” Test Garzás, estos:

– Test Garzás: para saber si trabajas entre Zombis
– Test Garzás: evalúa en 3 minutos el nivel de tu empresa desarrollando software
– ¿Qué haces testing ágil? Comprobémoslo en en 3 min., vamos con un “checklist”
– Test Garzás: ¿Trabajas orientado a equipos?

Si has hecho alguno de esos otros “Test Garzás”, ya sabrás que cada pregunta se responde con un simple “sí” o un “no”, cada “sí” suma un punto. El orden de las preguntas y su numeración es indiferente , lo que importa es la suma de “si” o “no”.

En este caso el Test, y el post, están pensados para recopilar un conjunto de malas prácticas típicas en lo que refiere al Product Owner, por desgracia, bastante frecuentes, y tiene el objetivo de eso… hacernos recordar y pensar sobre ellas.

En este caso, a diferencia de otros Test, las preguntas están planteadas al revés, en vez de ser «bueno»contestar con un «si»… lo bueno es contestar con un «no» (las preguntas son más bien anti-prácticas), por lo que lo ideal es que sacaras un cero en número de «Sis».
Haz el Test, que son 2 min., y cuéntame en los comentarios que puntuación (número de “si” o «nos») has sacado. Vamos a ello… ¡Suerte!

1 – ¿El Product Owner asigna Historias de Usuario a varios Sprints futuros?

Lo que, de ser así, tiene una pinta de cascada que no puede con ella, de haber sacado muchas historias, o items, para ir asignándolas a Sprints, con posible desperdicio, con difícil adaptación al cambio, sin hacer uso de elementos de menor detalle, como Epics o Temas. Mala pinta.

2 – ¿El Product Owner no tiene capacidad de decisión frente a los Stakeholders?

El típico Product Owner Proxy (más conocido como secretari@), que retrasa al equipo, no puede decidir, no negocio, no es operativo.

3 – ¿El Product Backlog tiene exceso de Historias de Usuario?

Similar a la pregunta número 1, Product Backlog hiper inflados, con cantidades de coas que hay que mantener, tiempo para priorizar, cosas que se quedan ahí, etc.

4 – ¿El Product Backlog tiene elementos que no se han tocado en semanas?

Más, relacionado con el anterior, aunque no igual, desperdicio puro.

5 – ¿Gran cantidad de Items en el Product Backlog estimados?

De nuevo, ese toque cascada bajo herramientas ágiles. Estimaciones de cosas que no está claro cuándo se van a hacer, si se van a hacer, etc. Desperdicio.

6 – ¿El Product Backlog tiene tareas en vez de historias?

Cierto es que, si nos vamos «al libro», el Product Bakclog tiene Items, e Items es «cualquier cosa que aporta valor», pero lo raro es que no sean Historias, historias de verdad, «end – to – end», pequeñas, funcinales, etc.

Y si ya hay tareas… ¿cómo vamos a terminar Sprints con productos potencialmente entregables? Difícilmente,

7 – ¿Se deja tiempo para trabajar la Deuda Técnica?

Se presiona tanto para meter Historias en el Sprint que no queda tiempo para tareas de limpieza de deuda técnica, lo que condicionará la velocidad en el futuro y el ritmo sostenible.

8 – ¿Las reuniones de refinamiento son correctas?

Estás son las reuniones «pre-planning» para que el «planning» no se vaya de madre (las también conocidas como Grooming). Aquí puede pasar desde que no haya, hasta que sean eternas.
.
.
Si te interesan más anti-prácticas de aplicación al Product Owner, aquí hay un recopilatorio más amplio. Y este es otro post del estilo el Product Owner del lado oscuro y otros anti-patrones

5 comentarios en “Test Garzás: para saber cómo de sano (ágil) es el trabajo del Product Owner”

  1. Hola Javier;
    Mas que el test, tengo una duda respecto a la limpieza de la deuda técnica.
    – Si lo he recogido bien, la deuda técnica, se corresponde con ajustes técnico que deben hacerse una vez finalizado un desarrollo, esto, en procesos poco eficientes.
    – Si la agilidad hace referencia a buenas prácticas durante los procesos, ¿cómo es posible que lleguemos con deuda técnica al finalizar un sprint? o ¿estoy equivocada sobre el concepto de deuda técnica?
    Un saludo y muchas gracias por tu excelentes aportes.

    1. Por muchas razones, por ejemplo, que al ir construyendo poco a poco el añadido de esta iteración hace ver mejoras que no se vieron en lo que se construyó en iteraciones anteriores, o porque en su momento nos valga un nivel de calidad, para no demorar la entrega, y validar incluso si funcionalmente tiene sentido, y luego incrementarlo, aumentar pruebas unitarias, añadir más de integración, etc.

  2. Javier, cuando hablamos de historias de Usuario, que contexto debe de tener?, entiendo que debe de ser un entregable de valor.
    Bajo esta primicia, para finalizar una historia debo de hacer una serie de tareas para tener un entregable completo.
    Me llama la atencion cuando dices que el backlog no debe de tener tareas?.

  3. La pregunta ocho parece mal formulada si lo «positivo» es contestar un No.
    ¿Las reuniones de refinamiento son correctas? No, las grooming son eternas y se hacen sobre cosas que lo mismo no entran en el siguiente sprint o ni siquiera se sabe si se van a hacer o no

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba