• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Product Ownership

Product Owner, improvisación o adaptación

La agilidad no ha parado de extenderse en los última década e incluso las organizaciones que miraban con recelo todo este movimiento están dando sus primeros pasos y viendo cómo pueden sumarse, aumentando así su competitividad. ¿Cómo está conviviendo en estas compañías mentalidades tan diferentes? ¿Cómo están respondiendo los Product Owners a las necesidades?(Extra: ¿qué es la transformación digital?)

Emma es una project manager en una gran compañía. Una telco internacional que solo en España cuenta con más de 10.000 trabajadores entre internos y externos. Ella trabaja en la parte que en su empresa llaman legacy. En otras muchas esta parte de la compañía la llaman waterfall o tradicional. Trabajan como siempre lo han hecho y ahora tienen que convivir con una parte “agile” (el uso de las comillas no es una casualidad) que ha surgido en la compañía y ha empezado a trabajar de otra manera.

Para gestionar la parte que le toca en toda esta gran maquinaria, Emma necesita cuadrar dependencias, esfuerzos y fechas. Cuando interactúa con equipos que están en la party legacy de la empresa, se entienden. Todos hablan el mismo idioma. Pero cuando se dirige a las nuevas estructuras ágiles y sus Product Owners recibe un: “No tenemos fecha concreta. Nosotros trabajamos en agile, así que no tenemos fechas”. Emma está frustrada y, con razón, duda sobre la operatividad – e incluso la profesionalidad – de los equipos ágiles.

La planificación (continua) es clave 

Existe un falso mito alrededor de la agilidad y la planificación. Analicemos por encima Scrum, por ejemplo:

  • El Product Backlog contiene el futuro del producto. Debe estar ordenado, refinado, estimado y con él es sencillo conocer cuáles serán los siguientes pasos.
  • En la Sprint Planning se crea un plan para alcanzar nuestro Sprint Goal durante el Sprint. 
  • La Daily Scrum es un evento para crear un plan de las siguientes 24h, una vez inspeccionado como va el plan del Sprint. 
  • La Sprint Review es un evento de negocio que pertenece al Product Owner dónde se analiza la situación actual del producto, del mercado, obtendremos feedback de los Stakeholders y re-planificamos el futuro de nuestro producto y lo plasmamos en el Product Backlog.
  • La Sprint Retrospective es una oportunidad para el Scrum Team de planificar acciones de mejora en el Definition of Done, procesos, herramientas o personas. 

Como podemos comprobar existe una planificación continua. La clave del éxito de la agilidad en entornos complejos no reside en la falta de planificación. Reside en darle más importancia a la planificación en sí misma, a las conversaciones, a la transparencia que subyace tras cada planificación, que al plan en sí mismo y estar dispuesto a actualizar el plan con cada nuevo descubrimiento que nos pueda aportar una ventaja competitiva. (Extra: Cómo Scrum nos ayuda a alcanzar la agilidad de negocio)

Planificando tendré oportunidad de adaptación

Tener una planificación es básico para poder desarrollar un producto o un servicio de forma profesional. El tipo de respuestas que se ven en desarrollos “ágiles” como el que le daban a Emma “Es que trabajamos en agile y no sabemos cuándo vamos a tener nada” demuestra que no es un desarrollo agile en absoluto y falta product ownership. Es un desarrollo donde se está improvisando. Improvisar y adaptar no es lo mismo. Inspeccionar y adaptar es la clave de la agilidad y eso solo puede ocurrir cuando tengo un plan, y soy capaz de modificar mi plan según las necesidades del mercado. 

Una respuesta a Emma en un entorno ágil podría ser: “Emma, con lo que sabemos hoy y con los datos históricos que tenemos, creemos que estará este día X. Cada dos viernes es nuestra Sprint Review y damos transparencia sobre la situación que tenemos y siguientes pasos. Pásate si estás interesada. Además, en este lugar está nuestro Product Backlog y release plan actualizado”. Bastante diferente, ¿no crees?

La falta de Product Ownership

Según mi experiencia el gran mal que azota a las empresas es la falta de liderazgo del producto. Muchas llamadas comienzan con “es que no sale el trabajo”, “es que los equipos no están comprometidos”, “es que no se hacen las cosas bien”. 

Cuando escarbas descubres que no existe nada relacionado con la gestión del producto (métricas de valor, releases maps, estrategia y visión de producto alineada con estrategia y visión de compañía) o gestión de la demanda. Esto hace que todo el mundo corra, pero en círculos. Todos están exhaustos, muchas horas trabajadas, mucha presión y nada de valor generado. ¿Os suena esta sensación que todos hemos tenido?

En muchos casos puedes ver un Agile Coach que corre a trabajar para que el equipo esté unido, tengan dinámicas divertidas y buena comunicación. En mi experiencia puedo decir que me he cruzado con equipos con más necesidad de tener una gestión de producto bien aterrizada, profesionalizada y bien ejecutada que con necesidad de mejorar sus interacciones sociales. Eso es algo que se alcanza cuando el equipo (incluyendo al Product Owner) se relacionan alrededor de un objetivo claro y ponen todo su conocimiento y esfuerzo al servicio del beneficio de sus clientes y, por tanto, del revenue para la empresa.

El empoderamiento del Product Owner

Un Product Owner de una gran aseguradora se quejaba de que no tenía ningún tipo de poder de decisión sobre el producto, que le gustaría poder tomar más decisiones y tener más responsabilidad. Yo le pregunté que dónde podría ver sus diferentes horizontes de planificación, sus futuras entregas a los clientes y como esperaba que esas entregas impactaran en las métricas de negocio. “No tengo nada de eso” fue la respuesta.

Para crear productos de alto valor el Product Owner debe estar empoderado. Y aquí hay un contrato de dos partes. La empresa, claro está, debe darles capacidad de maniobra y libertad. Pero no hay que olvidar que el Product Owner debe ganarse la confianza. Tener al menos una visión de producto, un roadmap, un release map y qué métricas vamos a tomar para ver si el valor del producto es el esperado, eso es básico. Sentarse a pedir más responsabilidad con todo este plan bajo el brazo suele ser más sencillo.

Conclusion

El Product Ownership brilla por su ausencia en el desarrollo ágil de productos. Esto nos lleva a falta de planificación e improvisación que suele terminar en desastre. Este “Product Management Vacuum” ocasionado, en muchas ocasiones, por tener Product Managers (o Product Owners) más enfocados en gestión de personas, en planes de proyecto y en cumplir hitos que en tener una visión, generar valor y validar que, con los usuarios reales, que esto está ocurriendo.

El foco de un Product Owner debe estar en las tres V: Visión, Valor y Validación. Una vez que tengamos esto, podemos empezar a trabajar en un desarrollo ágil de producto que permita alcanzar agilidad empresarial a toda la organización.

Si quieres saber más sobre Product Ownership:

  • Los 10 mejores libros para Product Owners
  • Nuestra academia online: Vídeos grabados y exámenes. Organizáte como quieras.
  • Nuestros cursos virtuales: Para facilitar la formación en tiempo de COVID estamos dando nuestros cursos en formato remoto.
  • Path de Scrum.org para Product Owners: Conjunto de recursos muy recomendable para todos los perfiles: Scrum Masters, Agile Coaches, Product Owners o jefes de proyecto

Net Promoter Score para medir el valor de tu Software

Uno de los errores más comunes que cometen aquellos que hacen Scrum es pensar que el Framework es el objetivo en sí mismo y lo importante es ceñirse a los eventos, role y artefactos. No podrían estar más equivocados. Si hay que reducir Scrum a una sola cosa, es entregar un incremento de software, terminado, que genere valor.

Aquellos que practican Scrum olvidan que el artefacto más importante es entregar un incremento de software potencialmente liberable al final de cada Sprint. Y el Product Owner es responsable de decidir cual es este incremento a través del Product Backlog y tiene que medir su generación de valor.

Esta semana he impartido el curso de Professional Scrum Product Owner en Madrid, y este fue uno de los temas que más tocamos como parte del trabajo del Product Owner y la labor del Scrum Master en asesorarle.

Construir software es muy caro, y a pesar de ello la mayoría de las compañías son incapaces de medir o predecir el valor que su software produceExisten muchas formas de medir valor, pero lo más importante es que exista un método a priori en la organización para hacerlo. Los famosos KPIs. Algunas empresas tienen en cuenta la facturación de su producto, mientras que otras tienen en cuenta que el número de bugs sea mínimo. Otras tienen en cuenta el Time to Market mientras que otras tienen en cuenta el beneficio por empleado. Lo importante no es cual sea la métrica, sino que esta métrica refleje el valor generado para la organización y el equipo Scrum sea consciente de ello. Las métricas tienen que definir a priori. Por ejemplo, EBMgt define tres grandes métricas compuestas de cuatro submétricas más pequeñas. Time to Market, Actual Value e Innovation Rate

Muchos equipos Scrum no tienen idea de cual es la razón por la que hacen su trabajo. ¿Satisfacer al cliente? ¿Hacer lo que el cliente pide? Me vienen muchos ejemplos a la cabeza en los que se puede hacer todo lo que el cliente pide y que al final se sienta totalmente descontento. Incluso peor. Equipos que desarrollan productos a los que nadie en la organización presta atención. No tienen valor alguno y nadie quiere plantearse por qué se hacen o dejan de hacer. No es lo que queremos conseguir con Scrum.

Net promoter score

Net Promoter Score

Si no tenéis una métrica concreta, mi sugerencia es que empecéis por usar el Net Promoter Score. El NPS® se basa en una pregunta muy sencilla, preguntarle a vuestro clientes: ¿Del 1 al 10, cómo recomendarías nuestro(s) producto(s)?

Todos los que respondan 1 a 6 se convierten en detractores, aquellos que respondan 7 u 8 son neutrales, y aquellos que responden 9 o 10 son promotores. Si restamos el número de detractores al número de promotores y nuestro NPS® es positivo… ¡Estamos generando valor! En general un NPS® de más de 50 es un indicador positivo de crecimiento. Puedes leer más sobre esta métrica aquí.

Por supuesto, el NPS es una métrica más, que hay que tomar con cautela. Cada vez que marcamos una métrica como objetivo, el sistema tiende a falsificarla. Sin embargo, es una manera barata y sencilla de empezar a medir el valor que genera vuestra organización. ¿A que esperas para ponerla en marcha?

Los elementos de una buena historia de usuario

La historia de usuario no es el santo grial que muchos creen, sino un contenedor que sirve como recordatorio de una conversación entre el Product Owner y el Development TeamUna historia de usuario es una promesa para mantener una conversación. Contrariamente a lo que mucha gente cree, el Product Backlog en Scrum está poblado por muchos tipos de requerimiento y solamente uno de ellos son las historias de usuario.

Es más acerca de la conversación que de la historia de usuario en sí misma. La conversación es lo que da las razones inherentes en la historia de usuario a lo que hay que hacer en el producto. La historia de usuario es únicamente un recordatorio de esa conversación.


3 Cs User Story

Las 3 C’s de la historia de usuario

Los elementos fundamentales de una historia de usuario son la Tarjeta (Card), la Conversación (Conversation) y Confirmación (Confirmation). Estos tres elementos son más importantes que cualquier detalle que pongamos en la historia de usuario en sí misma, y componen los elementos fundamentales de la historia de usuario. Sin ellos, la historia de usuario no está completa.

Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. Expresar un historia de usuario desde el punto de vista del desarrollador (As a developer I want…) o desde la organización (As the organisation I want to…) es una mala práctica que refleja la incapacidad de pensar en el valor para el usuario final.

Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. Esta conversación puede suceder en cualquier momento; es habitual que se produzca durante el refinamiento del Backlog o el Sprint Planning.

Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario. Muchos equipos cometen el error de no tener esta confirmación, lo cual lleva a fricciones y problemas durante el Sprint Planning.


modelo de historia de usuario

Modelo de historia de usuario

Una historia de usuario generalmente sigue un patrón definido

As a... Persona para la que se cubre una necesidad
I want... lo que queremos que ocurra, por ejemplo una características o una funcionalidad
So that... el valor que obtiene la persona de la implementación de la característica o funcionalidad.

En la primera parte de la historia de usuario, es muy útil hacer referencia a usuarios de nuestro producto, usuarios que estén descritos y estudiados usando el modelo de User Personas, que toman una serie de rasgos de múltiples usuarios y construyen una persona ficticia que haga uso de la aplicación.

En la segunda parte de la historia de usuario, se explica lo que desde el punto de vista de la persona debería de suceder, sin entrar en descripciones técnicas. Una buena historia de usuario no tiene en cuenta lo que el sistema puede hacer, sino lo que el usuario quiere obtener.

Una historia de usuario está totalmente centrada en el usuario, y no en el producto o la organización.En la tercera parte, se expresa el valor que la persona quiere obtener, lo cual ayuda a entender y refinar, o incluso cambiar la forma en la que usuario obtiene el valor esperado.

Como se puede comprobar, las historias de usuario están totalmente alineadas con la expectativa del usuario, sin tener en cuenta capacidades o restricciones de nuestro producto. Una buena historia de usuario es aquella que está construida sobre datos reales, obtenidos de los propios usuarios.

Vanesa Tejada tiene una gran presentación sobre como escribir historias de usuario


acceptance criteria

Criterios de Aceptación

Los criterios de aceptación son los detalles de una historia de usuario, y ayudan a completar el patrón de valor expresado por la misma. Los criterios de aceptación incluyen los detalles que ayudan a visualizar la película completa y mejoran el entendimiento que el Product Owner, los Stakeholders y el Development Team tienen sobre lo que se va a realizar.

Los criterios de aceptación cumplen dos funciones: Clarificar el contexto en el que ocurre la historia de usuario y facilitar saber cuando están realmente terminadas.Los criterios de aceptación también son el medio por el cual el Development Team es capaz de saber cuando un ítem del Product Backlog está terminado, y ser capaces de testar los elementos de la historia de usuario en conjunto.

Unos buenos criterios de aceptación son claros, concisos, expresan una sola cualidad del ítem del Product Backlog y en la mayoría de ocasiones son redundantes, explicando desde múltiples puntos de vista cual es la imagen finalizada de la historia de usuario.

Además, pueden contener requerimientos no funcionales, si estos no están recogidos en la Definition of Done del equipo, como velocidad de la aplicación, concurrencia o elementos de seguridad que deben ser implantados para considerar la historia de usuario terminada.


specification by example

Specification by example

Otro elemento que puede resultar de ayuda en una historia de usuario es expresar los resultados deseados mediante un ejemplo, que ayude a entender al Development Team cual es el resultado deseado al implementar una historia de usuario.

No solamente es válido para Algoritmos, sino que también puede ser muy útil en el caso de implementación de diseños en un producto ya existente. Herramientas como InVision ayudan a los especialistas en UX/UI a diseñar flujos en una aplicación que posteriormente pueden ser implementados como especificaciones en el producto final, siendo uno de los criterios de aceptación que la UI del producto sea cómo la del diseño inicial.

También puedes leer más sobre Specification by Example en el blog de Martin Fowler.

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad