Cuando éramos pequeños, y estábamos aburridos (o callados), mi abuela, manchega de pura cepa, enseguida solía decir eso de «gente parada malos pensamientos» o sino lo de «cuando el diablo no tiene nada que hacer con el rabo mata moscas».
Tenía la teoría, bastante contrastada y validada por muchas generaciones, de que cuando los niños se aburren acaban, o están, haciendo alguna.
Aquello de que aburrirse durante largos periodos no es sano para la mente, y no es exclusivo de los niños, que te voy a contar que no hayas visto y sufrido de alguien que se aburría…
Hoy te quería hablar de diversas actividades para que el Product Owner no se aburra. No es que yo me encuentre por ahí Product Owners jugando al Street Fighter en el móvil, pero si que cuando no tienen muy claro a qué dedicar su tiempo durante un Sprint buscan entretención en actividades varias, seguramente importantes, pero que pudieran hacer olvidar otras, más entretenidas, a la vez que útiles para el equipo.
Así que, ¿Actividades que debieran tener muy muy entretenido a un Product Owner…? Vamos con algunas…
Debiera estar entretenido creando Historias de Usuario
Cuando digo crear Historias de Usuario, digo crear Historias de Usuario, no crear cualquier cosa y meterla en un Backlog, lo que incluye que lo que el Product Owner meta en el Backlog, de cara a próximos Sprints, no sean Epics, y que esas Historias sean «end-to-end» (sino raras Historias son), etc. Esto entretiene bastante. Crear Historias es un gran entretenimiento.
Ah, y puedes incluir aquí, para mayor entretención, complementar esas Historias con BDD – Gherkin.
Debiera estar entretenido creando Historias de Usuario… casi que constantemente
Lo digo porque hay quien le da por crear un montón, decenas, centenares, de historias antes de que se empiece el desarrollo y luego se olvida de ello y se dedica a otras cosas. No, no. Hay que estar entretenido en esto siempre, el Dual-Track, ¿recuerdas (Interiorizando el significado del Dual-Track)? el mismo equipo trabaja con un ciclo de creación, que suele recaer en el equipo técnico y otro de descubrimiento, que suele recaer en el Product Owner.
Debiera estar entretenido validando, también, constantemente
¿Los Product Owner sólo aparecen en el Planning y en Sprint Review? (o ni eso) ¿Se aburren mientras? Entonces… que validen frecuentemente, en vez de esperar al final, eso, además, evita cascadas, y os llevará a Historias más pequeñas, que antes se terminen y antes se validen, a flujo continuo, a un desarrollo más en paralelo y a un montón de ventajas.
Debiera estar entretenido negociando con los Stakeholders
Y digo negociando, porque es de suponer que el Product Owner negocia, no acata, vamos que tiene capacidad de decisión para, frente a muchos Stakeholders, priorizar, decidir, poner qué si haremos y qué no.
Debiera estar entretenido con los Definition of Ready
Definition of Ready, ese acuerdo al que llegamos de los mínimos que debiera tener una Historia para ser «desarrollable». Hay quien mete aquí cosas como los UX necesarios para que se pueda empezar a trabajar en la Historia. Y otros como mínimos de «calidad» en las Historias. Todo aquello que el Product Owner debiera preocuparse que está, antes de empezar en un Sprint con esas Historias.
Bueno, hay más cosas en las que un Product Owner pude entretenerse, pero, al menos, que no deje de practicar la diversión que suponen las anteriores.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Hola Javier,
cuidado con el último párrafo, se te ha pegado el formado de header. Estos editores javascript los carga el diablo. 🙂
En el post se muestra una versión empequeñecida del PO, que no se ocupa de muchos aspectos de negocio como:
– Gestión del presupuesto
– Inteligencia competitiva
– Definición y seguimiento del valor generado
– Seguimiento e interlocución con clientes
– Optimización del «renevue»
– Etc.
Esto viene del posicionamiento del PO como un mero «proxy». Me permito referenciar un artículo que escribí sobre esto.
https://www.scrum.org/resources/blog/what-proxy-product-owner-why-it-found-so-often
Si el PO es pleno, puede estar tan ocupado que de hecho, en vez de aburrirse, tenga que delegar aspectos funcionales y técnicos como documentar las funcionalidades y los criterios de aceptación.
Bueno, almenos así lo vemos desde Scrum.org.
¡Saludos! (y suerte en el meetup del viernes, no podré acudir)
Alex Ballarin @ http://www.itnove.com
Hola,
Gracias por el aviso. Ya lo arreglé.
De lo del post, si pero, porque siendo todo un «depende», yo creo que parte de la lista que pones puede hacerla un PO… o no.
No veo de dónde puede venir que sea obligatorio que el PO haga «gestión del presupuesto» o «interlocución con clientes», por ejemplo. Puede ser que sí, y puede ser que no. Y no hacer ese tipo de cosas no crea obligatoriamente un PO Proxy.
Saludos
Javier,
Solo quería destacar aspectos más estratégicos y propios de un PO «pleno» qué escribir items del Backlog, o bien definir/validar las pruebas de aceptación.
Por supuesto no es obligatorio que las haga todas, el alcance de sus responsabilidades es muy contextual, pero si le preguntas al PO sobre quién hace las cosas de esa lista y te responde que la mayoría las hace «el negocio», probablemente sea un proxy.
¡Saludos!
Alex Ballarin
Javier,
Solo quería destacar aspectos más estratégicos y propios de un PO «pleno» qué escribir items del Backlog, o bien definir/validar las pruebas de aceptación.
Por supuesto no es obligatorio que las haga todas, el alcance de sus responsabilidades es muy contextual, pero si le preguntas al PO sobre quién hace las cosas de esa lista y te responde que la mayoría las hace «el negocio», probablemente sea un proxy.
¡Saludos!
Alex Ballarin
Hola Javier,
¿Qué tan grande crees que puede ser el backlog? La pregunta va, por el hecho de que el PO debe estar entretenido creando historias, ¿qué tantas historias es realmente bueno que se cree?, si también mencionas que si se tienen demasiadas, quizas para cuando se priorice alguna y entre a desarrollo ya no se tenga claro de lo que se quería con esa historia.
Saludos.
El Backlog, lo más pequeño en lo que refiere a HU. Entretenido creando las del siguiente Sprint, no las de el año que viene.
Este articulo, muy bueno como todos los que escribe, me va ha ayudar mucho. Ahora mismo soy lo que llamariamos un Product Owner junior, ya que solo tengo un anio de experiencia.
El equiop con el que trabajo ha pasado de 7 miembros a solo 3 en 1 mes debido a la fuerte demanda de developers que hay aqui en Toronto, por lo cual la velocidad del equipo asi como los futuros sprints que tenia mas o menos estructurados se tendran que adaptar.
Me ha pasado lo que comenta, he estimado y desarrollado demasiadas User Stories y ahora me «aburro» un poco, asi que me viene muy bien estos puntos que comenta para poder continuar trabajando.
Un saludo y no deje de escribir, este blog es una lectura diaria obligada como referente agile.