El “Product Owner” (o propietario del producto, utilizaremos las palabras en inglés por ser de uso más popular aún en nuestro contexto) es aquella persona con una visión muy clara del producto que se quiere desarrollar, que es capaz de transmitir esa visión al equipo de construcción o creación y, además, está altamente disponible para transmitirla y tiene potestad para decidir qué se añadirá, qué no y en qué orden.

La figura del Product Owner es clave en un modelo de trabajo ágil, en su planificación y seguimiento. Es una figura que cuando no realiza correctamente su función el proyecto tiene un serio riesgo, y un problema, llegando incluso a dejar de ser ágil.

Desgraciadamente, es frecuente encontrar implantaciones erróneas, o carentes, alrededor de este rol. En ocasiones sus tareas se minimizan, en otras suelen pasarse por alto muchas de sus importantes responsabilidades, etc.

La mayoría de las veces, el negocio, los usuarios, etc. (los llamados Stakeholders), van proporcionando una cantidad de ideas a incorporar a los productos, ideas que el Product Owner irá convirtiendo en pequeños Items, donde habrá un tipo especial de Item (que describe funcionalidad) que será una de las principales herramientas del Product Owner: las Historias de Usuario (pequeñas necesidades funcionales a incorporar al producto).

La función del Product Owner es vital, debe ser quien decida qué Historias de Usuario entran en el repositorio que contiene lo que se añadirá al producto, y que llamaremos Product Backlog, cuáles no, y, además, la prioridad de las historias.

Primera aproximación al concepto de Historia de Usuario

En los frameworks ágiles, la descripción de las necesidades funcionales se realiza a partir de estas llamadas Historias de Usuario (en inglés user story) que son, principalmente, lo que el cliente o el usuario quiere funcionalmente (podrá operar con ello).

Las Historias de Usuario son una descripción breve, de una funcionalidad (típicamente de una aplicación software aunque pueden usarse en otros contextos) y cómo la percibe el usuario.

El concepto de Historia de Usuario tiene sus raíces en el framework ágil “eXtreme Programming” o programación extrema. Esta metodología fue creada por Kent Beck y descrita por primera vez en 1999 en su libro “eXtreme Programming Explained”.

No obstante, las Historias de Usuario se adaptan de manera apropiada a la mayoría de las metodologías ágiles teniendo, por ejemplo, un papel muy importante cuando se usa Scrum.

Una Historia de Usuario describe funcionalidad que será útil para el usuario de un producto.

Las Historias de Usuario no son sólo funcionalidad escrita

Y aunque normalmente las Historias de Usuario, asociadas a las metodologías ágiles, suelen escribirse en post-it o tarjetas, son mucho más que eso.

Ron Jeffries (uno de los firmantes del manifiesto ágil) comentaba que una historia no es sólo una descripción de una funcionalidad, normalmente en un post-it, una Historia de Usuario además está formada por otras dos partes más:

• La conversación que conllevan, ya que son una herramienta para interactuar.
• El cómo se confirma su implementación, las pruebas y verificación de la misma.

Son un "qué" y no un "cómo"

Conviene resaltar que las Historias de Usuario, frente a mostrar un “cómo”, sólo dicen el “qué”.

Es decir, muestran la funcionalidad que será desarrollada, pero no cómo se desarrollará. Por ello, cosas como que “el software se escribirá en C++” no es una buena Historia de Usuario.

Y es por ello que el principal conocimiento que debe tener un Product Owner es de negocio, y no técnico.