4. Product Owner: Gestión ágil de productos

La responsabilidad del Product Owner es crucial en Scrum, fungiendo como el principal enlace entre las partes interesadas y el equipo Scrum, con la meta de maximizar el valor generado a través del desarrollo del producto. Un Product Owner posee la autoridad y el conocimiento profundo necesarios para articular y defender las necesidades y expectativas de los stakeholders con precisión. En este capítulo, exploraremos las responsabilidades, habilidades y actividades de un Product Owner. Esto brindará una comprensión ampliada que complementa lo ya discutido en el modelo Core de Scrum, orientándote en cómo un Product Owner puede liderar efectivamente la visión del producto a través de colaboración efectiva, liderazgo estratégico y toma de decisiones basada en datos. Puntos clave de este capitulo: - Comprender la importancia estratégica de la responsabilidad del Product Owner en el desarrollo de productos ágiles. - Identificar las habilidades cruciales que un Product Owner necesita cultivar para liderar con eficacia. - Profundizar en las actividades específicas y diarias que definen la labor del Product Owner. - Analizar cómo un Product Owner puede funcionar como un puente eficaz entre el equipo Scrum y las partes interesadas, garantizando una entrega de valor maximizada.

4.1 - Gestión ágil de producto

La gestión de productos, o "Product Management" en inglés, es una disciplina que se centra en guiar el desarrollo, la estrategia y la entrega de productos.

La gestión de producto se pueden manejar con enfoque tradicional o con enfoque ágil: El Agile Product Management (Gestión ágil de producto) está diseñado para entornos y mercados que cambian rápidamente, donde la adaptabilidad y la respuesta rápida son esenciales. Mientras que el Product Management tradicional puede ser más adecuado para industrias o productos donde los requisitos son menos volátiles y el desarrollo puede planificarse con bastante antelación.

Muchas empresas modernas están adoptando un enfoque ágil, al reconocer los beneficios de la adaptabilidad y la iteración rápida.

La gestión ágil de producto permite establecer estrategias para crear productos en un entorno ágil, manteniendo un enfoque adaptable para que la organización y el equipo propiamente puedan responder rápidamente a la retroalimentación de los clientes y crear mejores productos.

A diferencia de las técnicas de desarrollo tradicionales, la gestión ágil se centra en la adaptabilidad, permitiendo que el equipo responda rápidamente a la retroalimentación de los clientes.

👉 Tip para el Product Owner
Valora más una entrega temprana y frecuente que esperar hasta que el producto esté "perfecto".

Beneficios de la gestión ágil de producto

La gestión ágil proporciona un enfoque más flexible en comparación con la planificación y el desarrollo tradicional, lo que permite que se construyan productos en incrementos cortos.

Algunos beneficios clave de la gestión ágil de productos:

👉 Tip para el Scrum Master
Anima al equipo a adoptar una mentalidad de mejora y aprendizaje constante, utilizando cada sprint y retroalimentación como una oportunidad de crecimiento.

Ecosistema de la gestión ágil de producto

Cada producto requiere un enfoque único y personalizado, tiene sus propios objetivos y retos, lo que se traduce en una gestión de productos basada en lograr la conexión entre las expectativas de negocio, una gran experiencia de usuario y el aprovechamiento de la tecnología.

El diseño y la investigación de la Experiencia de Usuario aseguran que el producto esté alineado con las necesidades y expectativas del usuario y del negocio. Las Expectativas de Negocio definen la dirección y los objetivos, proporcionando un marco dentro del cual el diseño y la tecnología deben operar. La Tecnología es el medio que permite que las expectativas respecto a la Experiencia de Usuario y del negocio se materialicen, proporcionando soluciones que cumplan con las expectativas del usuario y los objetivos de negocio.

👉 Tip para el equipo
En escenarios de desarrollo de software es importante implementar técnicas de Integración Continua y Entrega Continua (CI/CD) para acelerar el proceso de desarrollo y despliegue.

La gestión ágil de producto en una organización

El enfoque jerárquico en comparación con el enfoque de la gestión ágil de producto abarca diferencias sustanciales en cómo se organizan, operan y toman decisiones las organizaciones:

Enfoque Jerárquico Enfoque de gestión ágil de producto
Toma de decisiones Las decisiones vienen desde los niveles superiores de la organización y se transmiten hacia abajo.
Demora en la toma de decisiones por necesidad de aprobación en múltiples niveles.
Decisiones descentralizadas tomadas por Product Owner en colaboración con su equipo y stakeholders.
Se promueve la autonomía y la toma de decisiones basadas en datos.
Estructura Departamentos o divisiones con roles claramente definidos. Equipos multifuncionales centrados en productos o características específicas.
Comunicación Comunicación vertical (de arriba hacia abajo y viceversa).
Silos de información y desafíos en la comunicación.
Comunicación abierta y transparente entre todos los niveles y departamentos.
Respuesta al cambio Los cambios suelen ser más lentos y requieren aprobación en varios niveles. Los cambios pueden implementarse rápidamente en función de la retroalimentación del usuario y las métricas del producto.
Cultura Centrada en procesos, estructuras y cumplimiento de tareas asignadas. Centrada en el valor para el cliente y negocio, y la entrega continua de características útiles.

Principios de la gestión ágil de producto

Riesgos de no adoptar la gestión ágil de producto

¿Qué debo evitar en el Agile Product Management (Gestión ágil de producto)?

El Product Management es un área crucial que determina en gran medida el éxito de un producto. Sin embargo, hay ciertas trampas en las que como Product Owner puedes caer y que se deben evitar:

Actores involucrados en la gestión ágil de producto

En la gestión ágil de producto existen actores complementarios al equipo Scrum, que son necesarios y usualmente definidos en las organizaciones para cubrir todas las necesidades y requerimientos de las partes interesadas:

Equipo Scrum:

En su concepción más básica, Scrum se centra en cómo un equipo puede trabajar de manera eficiente para entregar productos de alta calidad en ciclos iterativos y rápidos. Para hacerlo, Scrum establece tres responsabilidades: Product Owner, Developers y Scrum Master. Cada uno contribuye al flujo ágil de trabajo.

Sin embargo, cuando se trabaja con Scrum en un entorno empresarial real, con múltiples productos, interdependencias y expectativas de diversas partes interesadas, rápidamente nos damos cuenta que existen muchas otras consideraciones que no son cubiertas por el equipo Scrum.

Actores organizacionales o del cliente:

El equipo Scrum no trabaja totalmente aislado: existen roles adicionales, a menudo anclados en la estructura organizacional o en las necesidades del cliente, que desempeñan funciones críticas para asegurar que los esfuerzos del equipo Scrum se mantengan alineados con los objetivos del negocio y las expectativas del cliente.

Estos roles organizacionales o del cliente actúan como puentes, facilitando la comunicación, alineación y toma de decisiones entre el equipo Scrum y el ecosistema empresarial más amplio en el que operan. Entre los roles adicionales comúnmente podemos encontrar:

👉 Tip para el Product Owner
Asegúrate de mantener una comunicación fluida con los actores externos al equipo (Business Managers, Line Managers, Analistas de Negocio) para garantizar que la visión del producto esté alineada con los objetivos de negocio.

4.2 - El Product Owner y los eventos

En Scrum, cada evento (ceremonia) está diseñado con un propósito específico para maximizar la transparencia, la colaboración y la eficiencia. El Product Owner, es fundamental para representar la voz del cliente y los intereses del negocio, y desempeña un papel crucial en estos eventos.

Su responsabilidad va más allá de simplemente definir y priorizar el trabajo; es el vínculo esencial que asegura que el equipo esté trabajando en las características más valiosas, alineando la entrega de producto con los objetivos del negocio.

En esta sección, exploraremos en detalle cómo el Product Owner se involucra en cada evento, qué se espera de él y cómo su aporte activo puede influir positivamente en la dinámica y los resultados del equipo Scrum.

El Product Owner en la Planificación del Sprint

Caso práctico: Durante la planificación del sprint, el equipo está indeciso sobre qué funcionalidades priorizar. El Product Owner, Carlos, comparte recientes feedbacks de clientes y argumenta: "Nuestro principal competidor acaba de lanzar una funcionalidad similar, y debemos responder". Desglosa los elementos del Product Backlog, aclarando cualquier duda. Luego, al definir el Sprint Backlog, surge un debate sobre la carga de trabajo. Carlos, con base en la prioridad y la visión del producto, guía al equipo para acordar un Sprint Goal centrado en el impacto y valor para el usuario.

👉 Tip para el Product Owner
La preparación es clave: Asegúrate de entender muy bien los elementos del Product Backlog que has pre-seleccionado para discutir en la Planificación del Sprint, y ten a mano toda la información relevante para aclarar cualquier duda que puedan manifestar los Developers.
También asegúrate de que las historias de usuario y las tareas estén bien definidas, claras y priorizadas. Las más prioritarias deben tener suficiente detalle para que el equipo pueda trabajar en ellas.

El Product Owner en el Daily

Nota aclaratoria: Si el Product Owner está trabajando activamente en los elementos del Sprint, entonces participa como un Developer, de lo contrario no participa en este evento.

En caso que el Product Owner participe del Daily, es posible que pueda:

Caso práctico: Durante un Daily, el equipo de desarrolladores discute un desafío relacionado con una historia de usuario. No están seguros de cómo implementar una funcionalidad específica. Laura, la Product Owner, quien ocasionalmente asiste a los Dailies, rápidamente comprende la confusión. Después del Daily, aparta a los miembros del equipo involucrados y proporciona una aclaración detallada con ejemplos del comportamiento esperado, resolviendo el desafío. Además, toma nota para mejorar la descripción de historias similares en el futuro.

👉 Tip para el Product Owner
Si decides asistir al daily, escucha activamente pero evita interrumpir o desviar la conversación a menos que sea estrictamente necesario. Si escuchas sobre desafíos o problemas relacionados con el Product Backlog, toma notas para refinar y mejorar el Backlog después del daily.
Si ves que hay confusiones o malentendidos sobre el Product Backlog, busca un espacio después del Daily para resolver las dudas.

El Product Owner durante el desarrollo del Sprint

Caso práctico: Mientras el equipo está a mitad de camino en el Sprint actual, Tomás, el Product Owner, ya está en conversaciones con un stakeholder sobre las características de un futuro elemento que se desarrollará para el siguiente sprint. Tras obtener un entendimiento claro, programa una reunión de refinamiento con dos Developers para abordar este elemento. Laura, una de las Developers, sugiere una implementación que podría simplificar el trabajo. Tomás ajusta el elemento en el Product Backlog. Cuando llega el momento de la planificación del siguiente sprint, este elemento se discute con mayor fluidez y claridad, gracias a la planificación en paralelo que Tomás llevó a cabo.

👉 Tip para el Product Owner
Inicia el refinamiento y priorización de los elementos de los próximos sprints con anticipación, esto garantiza que estén listos cuando llegue el momento de la Planificación. Al trabajar en paralelo, es crucial que tanto el equipo como las partes interesadas tengan una visión clara del producto y cómo encajan las piezas.

El Product Owner en la Revisión del Sprint

Caso práctico: Durante la revisión del sprint se presenta una funcionalidad de una aplicación de e-commerce. Un stakeholder clave menciona que, aunque la funcionalidad es lo que se pidió, el diseño podría ser más intuitivo para usuarios no técnicos. Laura, la Product Owner facilita el diálogo, para entender mejor la situación y añade esta observación al Product Backlog. Adicionalmente se encuentra un elemento en deuda técnica, por lo que Laura, reajusta el Product Backlog según el feedback recibido.

👉 Tip para el Product Owner
Si se identifica deuda técnica, trata de comprender su origen y considera estrategias para gestionarla en futuros sprints. También asegúrate de registrar las observaciones y feedback para que puedan ser considerados en futuras decisiones y planificaciones.

El Product Owner en la Retrospectiva del Sprint

Caso práctico: En la retrospectiva, Miguel, el Product Owner, resalta cómo el equipo logró superar un desafío técnico particular durante el Sprint. Sin embargo, surge que algunos Developers sintieron que no se comunicaron suficientemente bien los objetivos de negocio detrás de ciertas tareas. Patricia, una Developer, menciona que esto llevó a algunas decisiones técnicas que, de haber tenido toda la información, habrían sido diferentes. Miguel reconoce esta brecha y propone sesiones breves de alineación antes de cada Sprint para garantizar que el contexto del negocio esté claro. El equipo acuerda intentarlo en el próximo Sprint y evaluar su efectividad en la siguiente retrospectiva.

👉 Tip para el equipo
La Retrospectiva NO es un espacio para culpar, sino para identificar oportunidades de mejora.

4.3 - Las Historias de Usuario

Las Historias de Usuario (User Story) son la forma recomendada en entornos ágiles para escribir los requisitos del producto desde la perspectiva del usuario. Dado que son afirmaciones breves, simples y fáciles de entender, resultan en una mejor comunicación entre los Stakeholders y el equipo Scrum.

Una de las principales ventajas de las Historias de Usuario es su estructura simplificada y orientada a la acción. Debido a que se centran en entender "¿quién solicita la funcionalidad?", "¿qué necesita/requiere?" y "¿por qué o para qué lo necesita?", las Historias de Usuario proporcionan una vista clara y contextualizada de lo que se espera, eliminando ambigüedades comunes en los requisitos tradicionales.

Los criterios de aceptación, que acompañan a cada Historia de Usuario, definen las condiciones específicas que deben cumplirse para que la historia se considere satisfactoriamente implementada o desarrollada. Actúan como una guía para el equipo, aterrizando las expectativas del Product Owner sobre el comportamiento o funcionalidad que debe tener esa historia. Mientras que, la Definición de Terminado (DoD) es la que establece cuándo una historia o tarea se considera completa en su totalidad.

Las Historias de Usuarios centran la atención en los usuarios finales, por lo que no utilizan un lenguaje técnico, con el fin de facilitar el entendimiento para los usuarios y asimismo ofrecer un contexto suficiente para guiar el esfuerzo de los Developers.

Mike Cohn, uno de los pioneros en el desarrollo ágil, menciona que "Las historias de usuario permiten a los equipos trabajar en un lenguaje compartido, y eso hace que toda la experiencia de desarrollo sea más orientada al usuario y al valor. En lugar de ser una mera lista de tareas, las historias son llamadas a la acción para resolver desafíos específicos para los usuarios".

Estructura de una Historia de Usuario

Las Historias de Usuario suelen expresarse como una frase simple y breve que cumple con la siguiente estructura:

Como: Describe el Rol del Stakeholder que solicita (o usaría) la funcionalidad o requerimiento.

Quiero: Describe la necesidad o requerimiento del usuario, por lo general, es una frase corta.

Para: Describe el beneficio esperado por el Stakeholder una vez se desarrolle el requerimiento

Ejemplos de Historias de Usuario

Como: Cliente, Quiero: pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito, Para: evitar el desplazamiento hasta la sucursal de pago.

Como: Supervisor de ventas, Quiero: consultar un listado de los pedidos de venta que han sido registrados y aún no han sido procesados, Para: Tener un reporte detallado a la mano.

Como: Ejecutivo de cuenta, Quiero: consultar los datos de un cliente suministrándole al sistema únicamente su documento de identidad o código de cliente, Para: facilitar el proceso de búsqueda y reducir el tiempo de atención.

Como: asesor de ventas, Quiero: disponer de una diadema inalámbrica, Para: poder levantarme regularmente de mi puesto y disminuir el estrés y el cansancio.

Componentes adicionales de una Historia de Usuario

Una Historia de Usuario puede tener componentes adicionales que permitan mejorar su entendimiento tanto para el usuario como para los Developers. Estos componentes también garantizan una ejecución precisa y acorde a las expectativas. Usualmente estos componentes son:

1. Criterios de aceptación (detalle técnico)

Microsoft define a los criterios de aceptación como las condiciones que un producto de software debe satisfacer para ser aceptado por un usuario, cliente o stakeholder.

Para Google, son estándares pre-establecidos o requerimientos que un producto o proyecto debe satisfacer.

Cada historia de usuario debe ir acompañada de sus criterios de aceptación. Estos criterios son esenciales para garantizar que todos en el equipo tengan el mismo entendimiento de lo que se espera. Ayudan a delimitar el alcance de una historia y a definir cómo se verificará que se ha cumplido con la necesidad o requerimiento descrito.

Concretamente en Scrum, se los define como un conjunto de sentencias redactadas de tal manera que conduzcan a una respuesta clara de "aceptado/rechazado". Detallan las especificaciones técnicas de cada Historia de usuario o Tarea.

El Product Owner es el responsable de redactar los criterios de aceptación para cada Historia de Usuario en conjunto con el cliente y/o los interesados, para posteriormente confirmarlos con los Developers antes de iniciar el desarrollo. Esta confirmación se realiza durante la Planificación del Sprint.

Los criterios de aceptación ayudan a los Developers a entender el funcionamiento del producto, de manera que estimarán mejor el trabajo necesario, además de servir como guía para tomar decisiones más acertadas de acuerdo con lo que se espera de cada Historia de Usuario.

Un criterio de aceptación debe poder probarse o testearse. Cuando no es posible probar algún criterio de aceptación es un claro indicio de una mala redacción.

Se debe tener en cuenta que al probar una Historia de Usuario frente a un criterio de aceptación se obtiene una respuesta binaria: Cumple o No cumple; no existe el concepto de cumplir parcialmente un criterio de aceptación.

Algunos beneficios de contar con buenos criterios de aceptación:

👉 Tip para el Developer
No esperes hasta la Planificación del Sprint para hacer preguntas. Si un criterio de aceptación no especifica algo, no lo asumas. Es mejor preguntar y obtener claridad.
Si durante el desarrollo encuentras que un criterio de aceptación no es viable o requiere mucho más trabajo del estimado, comunica esto al Scrum Master lo antes posible.

Una manera opcional de construir los criterios de aceptación es la siguiente:

Cuando (Rol) hace (Acción) consigue (Resultado / Comportamiento esperado)

Veamos un ejemplo:

Historia de Usuario: Como cliente, quiero pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria o tarjeta de crédito, para evitar el desplazamiento hasta la sucursal de pago.

Criterios de Aceptación:

👉 Tip para el Product Owner
En la discusión de las historias de usuario, puedes emplear la técnica de las 3 C's: Card (Tarjeta), Conversation (Conversación) y Confirmation (Confirmación). Esta técnica ayuda a mantener la simplicidad, ya que la información se mantiene ligera (tarjeta), se clarifica a través del diálogo (conversación) y se verifica (confirmación).

2. Estimaciones

Las estimaciones se refieren al tiempo o esfuerzo necesario para completar una Historia de Usuario o una tarea. Los equipos Scrum a menudo usan puntos de historia, horas o días para estimar la complejidad y el esfuerzo necesario.

Es muy importante realizar la estimación del trabajo requerido para desarrollar las Historias de Usuario y las tareas relacionadas, de esta manera se logran planificaciones más precisas.

La estimación NO es determinada por el cliente o el Product Owner, sino que son los Developers en conjunto con el Scrum Master y el Product Owner, quienes definen las estimaciones ya que ellos son quienes ejecutarán directamente el trabajo necesario.

👉 Tip para el Product Owner
Recuerda que las estimaciones son relativas y no deben interpretarse como compromisos rígidos. Sirven como guías basadas en la información y experiencia actual del equipo.

Para garantizar una estimación más precisa, se pueden considerar elementos como:

Uno de los problemas más comunes con la estimación de las Historias de Usuario, es sólo se estimar la dificultad (puntos de historia), o sólo estimar la duración (horas / días); por lo que es altamente recomendable estimar los dos. Muchos equipos prefieren unificar esto mediante una relación entre los puntos de historia y la duración, es decir que para cada punto de historia se asigna un tiempo determinado.

👉 Tip para el Scrum Master
Si sientes que las estimaciones consistentemente no reflejan el esfuerzo real de los Developers, aborda el tema en la retrospectiva del sprint. Analiza y ajusta el proceso de estimación en conjunto con el equipo según sea necesario.

El manejo que se da a los puntos de historia es específico de cada equipo, y es crucial entender que las estimaciones están íntimamente ligadas a la experiencia, conocimientos y dinámicas específicas de cada equipo, por lo que NO es recomendable comparar diferentes equipos basados en sus estimaciones: Incluso si dos equipos trabajan en el mismo producto o en productos similares, su ritmo de trabajo puede variar.

En Scrum el ritmo de trabajo también se conoce como la "velocidad" y se basa en cuántos puntos de historia, en promedio, un equipo puede completar en un Sprint. La velocidad no solo se basa en la capacidad de producción; también se ve influenciada por la comunicación dentro del equipo, las herramientas disponibles, las interrupciones externas, entre otros factores.

¿Por qué no comparar equipos basados en estimaciones? Comparar equipos basados en sus puntos de historia o velocidad puede llevar a interpretaciones erróneas. Si un equipo A completa 50 puntos de historia en un Sprint y el equipo B completa 30 puntos, no significa necesariamente que el equipo A sea más productivo o eficiente. Puede que el equipo B esté manejando tareas más complejas o enfrentando desafíos que el equipo A no tiene. Comparar equipos de esta manera puede llevar a decisiones injustas y a presiones innecesarias, lo que puede afectar negativamente la moral y la productividad.

A continuación se muestra un ejemplo de ello:

Supongamos que tenemos dos equipos, Equipo A y Equipo B, ambos trabajando en diferentes funcionalidades del mismo producto.

El equipo A, con base en sus experiencias anteriores y en la comprensión que tienen sobre su capacidad y velocidad de trabajo, definió la siguiente tabla de estimaciones:

estimacion1

Por otro lado, el equipo B, que puede tener una composición diferente en términos de habilidades, experiencia y conocimientos técnicos, definió la siguiente tabla de estimaciones:

estimacion2

Durante la sesión de estimación, el Equipo A asigna 5 puntos a una historia de usuario específica, mientras que el Equipo B asigna 8 puntos a una historia similar. Esto no significa necesariamente que el Equipo B vea la historia como más complicada o que sean menos eficientes. Es posible que el Equipo B, basado en experiencias pasadas, considere ciertos riesgos o complejidades adicionales que el Equipo A no ha experimentado. Por otro lado, el Equipo A puede tener un experto en una herramienta o tecnología relevante que reduce la percepción de esfuerzo.

Si bien ambos equipos trabajan en el mismo producto, tienen distintas experiencias, habilidades y contextos que influyen directamente en cómo ven y estiman el trabajo.

👉 Tip para el Developer
Primero la calidad: No sacrifiques la calidad de tu trabajo para cumplir con una estimación. Si una historia de usuario necesita más tiempo del estimado para ser completada adecuadamente, es mejor discutir esto con el Scrum Master para ajustar el plan que entregar un producto inferior.

3. Prototipos, Diagramas, etc

Los prototipos, diagramas o esquemas de una Historia de Usuario nos sirven para mostrar un acercamiento al resultado que se espera obtener cuando los Developers ejecuten su trabajo, de esta manera se puede probar el producto antes de construirlo para identificar posibles errores y generar un mejor entendimiento para los Developers.

Prototipo: Es una representación preliminar de un producto, que muestra cómo se verá y funcionará, sin necesidad de que esté completamente funcional. Puede ser desde un boceto en papel hasta una versión interactiva digital.

Diagrama: Son representaciones gráficas que muestran las relaciones entre diferentes componentes, actores o flujos de un sistema o proceso.

Estos elementos visuales sirven como herramientas de comunicación entre el equipo, el Product Owner y los stakeholders, y pueden ser vitales para reducir la ambigüedad y mejorar la calidad del producto final.

👉 Tip para el equipo
Un prototipo no tiene que ser perfecto ni estar completo: La idea es que sea una representación aproximada que pueda modificarse fácilmente en función de los comentarios recibidos.

Beneficios de usar prototipos:

👉 Tip para el equipo
No todos los elementos o características necesitarán un prototipo o diagrama. La decisión de cuándo usarlos dependerá de la complejidad de la historia, los recursos disponibles y las necesidades del equipo y los stakeholders.
Es importante recordar que, aunque estas herramientas son valiosas, deben usarse de manera estratégica para maximizar su valor sin desperdiciar esfuerzos en detalles innecesarios.

Épicas

Una épica es una gran pieza de trabajo que se puede desglosar en un conjunto de tareas más pequeñas (historias de usuario) que estan relacionadas entre sí. Puede considerarse como un contenedor para historias de usuario que están relacionadas y que, una vez completadas, cumplirán un objetivo o función más grande y más complejo.

Algunas ideas de las que se podrían definir las épicas son: • Módulos. • Componentes. • Hitos. • Entregables. • Funcionalidades.

Se puede decir que una épica es un nivel de agrupación por encima de las historias de usuario que permite clasificarlas por funcionalidades, módulos, subsistemas, etc.

Las épicas:

El propósito de identificar épicas es ayudar a gestionar y organizar el trabajo del Product Backlog de manera más efectiva. Se trata de simplificar la complejidad y proporcionar una visión clara del objetivo final, permitiendo a los equipos trabajar de manera más coordinada y eficiente.

Recomendaciones sobre las épicas:

Ejemplo de épica: Renovar la experiencia de pago del sitio web para simplificar el proceso de compra y reducir el abandono del carrito.

Historias de Usuario derivadas de la Épica:

... (y así sucesivamente, hasta que todas las facetas de la renovación de la experiencia de pago estén cubiertas).

Guía para identificar épicas sin morir en el intento ☝

4.4 - Refinamiento del Product Backlog

Estamos a puertas de iniciar con el desarrollo del producto, tenemos una comprensión general del producto y contamos con un Product Backlog que contiene elementos cortos y concretos. Tú como Product Owner los entiendes claramente, pero: ¿el resto del equipo también los entienden?

El refinamiento del Product Backlog es una actividad continua en la que el equipo Scrum colabora con las diferentes partes interesadas para crear un entendimiento compartido sobre lo que el producto hará y no hará (historias de usuario y tareas), sobre el esfuerzo que requerirá su implementación (estimaciones) y el orden en que lo hará (priorización).

El equipo puede llevar a cabo el refinamiento paralelamente al desarrollo del actual sprint, con esto se logrará que la planificación del siguiente sprint sea muchísimo más eficiente.

Si bien el Product Owner lidera el proceso de refinamiento del Product Backlog, es vital que cuente con la colaboración activa de los Developers y el Scrum Master. Esta colaboración multidisciplinaria no solo enriquece el proceso con diversas perspectivas y habilidades, sino que también promueve un entendimiento compartido y una toma de decisiones más informada, lo que es esencial para el desarrollo exitoso del producto.

¿Por qué es importante el refinamiento del Product Backlog?

Caso de estudio: ¿Por qué deberíamos refinar? En una reconocida empresa de software, la omisión del refinamiento del Product Backlog llevó a consecuencias graves. Sin una adecuada claridad y detalle en los ítems del backlog, el equipo de desarrollo frecuentemente enfrentaba obstáculos en la implementación, resultando en retrasos significativos y una acumulación de tareas mal definidas. Esto no solo generó frustración entre los miembros del equipo, sino que también impactó negativamente en la satisfacción del cliente debido a entregas de productos por debajo del estándar esperado. Este caso resalta la necesidad vital de la inclusión activa y continua del Product Owner, el Scrum Master y los Developers en el proceso de refinamiento del backlog para asegurar un flujo de trabajo fluido y entregas exitosas.

👉 Tip para el Product Owner: Mantener una lista de "ítems de refinamiento listos para discusión
Estos ítems pueden ser abordados en las sesiones con el equipo. Esto garantiza que siempre haya un flujo constante de ítems listos para ser trabajados y que las sesiones de refinamiento sean eficientes y focalizadas. Además, no dudes en retirar elementos que ya no añaden valor, manteniendo así un Backlog limpio y centrado en las prioridades actuales.

¿Qué se hace en el refinamiento del Product Backlog?

Algunas de las cosas que se puedan hacer en el refinamiento son:

👉 Tip para el Product Owner: No olvides involucrar a todo el equipo Scrum en el proceso de refinamiento.
Aunque como Product Owner tienes la responsabilidad de mantener y priorizar el Product Backlog, el conocimiento y la perspectiva de los Developers y del Scrum Master pueden ayudar a enriquecer los ítems del backlog, proporcionando detalles técnicos y apuntando posibles obstáculos desde una etapa temprana, facilitando una entrega más fluida y exitosa del producto.

¿Cuándo es el mejor momento para el refinamiento del Product Backlog?

El refinamiento del Product Backlog es una actividad continua, no solo para el Product Owner, sino para todo el equipo. El Product Owner puede refinar los elementos del Product Backlog en cualquier momento, dentro o fuera de una reunión, dependiendo de lo que sea más conveniente para el equipo.

Nota: La forma y momento en que se haga el refinamiento depende del equipo Scrum.

Es vital destacar que la planificación en Scrum ocurre de manera paralela Mientras los Developers están inmersos en la construcción del actual incremento de producto, el Product Owner se encuentra activamente trabajando en el refinamiento de los próximos elementos del backlog, identificando nuevas oportunidades y ajustando prioridades, garantizando así un flujo constante y eficiente de trabajo para futuros sprints.

4.5 - Técnicas y herramientas útiles para el Product Owner

Herramienta 1: User stories mapping (Mapeo de historias de usuario)

Esta técnica es vital para organizar y visualizar de manera clara y estructurada los elementos del Product Backlog, agrupándolos según su funcionalidad y dependencia, lo que a su vez facilita su proyección a lo largo del tiempo.

El proceso de mapeo se desarrolla típicamente en sesiones de trabajo que duran entre 2 y 4 horas. Durante estas sesiones, se utiliza un lienzo y post-its para facilitar la categorización y priorización de los elementos que integrarán el producto.

Una de las grandes ventajas de este método es que asiste en la programación de los sprints, proporcionando una perspectiva clara para los stakeholders sobre qué se realizará y cuándo, aunque sea de manera aproximada.

La técnica de Mapeo de Historias de Usuario (User Stories Mapping) sirve como una herramienta crucial para estructurar y definir el MVP (Producto Mínimo Viable), permitiendo una visualización clara de las funcionalidades esenciales que deben ser implementadas en primera instancia para satisfacer las necesidades centrales del cliente.

¿Cómo construir el mapa de historias?

Antes de comenzar, es fundamental establecer el estado objetivo del producto (Product Goal), ya que esto determinará el contexto dentro del cual se desplegará el producto. Posteriormente, es necesario identificar las funcionalidades o componentes principales que constituirán el producto, conocidos como "épicas".

Pasos para crear un Mapa de Historias de Usuario

  1. Definición del Product Goal: Establece claramente el objetivo principal del producto que guiará todas las decisiones futuras, recuerda basarte en el problema que se pretende solucionar.
  2. Identificación de Épicas: Determina las grandes funcionalidades o componentes que conformarán el producto.
  3. Creación de Historias de Usuario: Desarrolla historias de usuario que describan cada función desde la perspectiva del usuario.
  4. Organización de Historias: Organiza las historias de usuario identificadas en una estructura visual, categorizándolas según su funcionalidad y dependencia.
  5. Priorización: Establece las prioridades de las historias de usuario, decidiendo cuáles deben abordarse primero basándote en su valor y complejidad.
  6. Revisión y Ajustes: Durante las sesiones de refinamiento del Product Backlog, revisa y ajusta el mapa según sea necesario, incorporando los aprendizajes y cambios que surjan durante el desarrollo.

Herramienta 2: Técnica para priorizar - MoSCoW (Must have, Should have, Could have, Would have)

La técnica MoSCoW es un método efectivo para priorizar los elementos del Product Backlog, ayudando a discernir lo esencial de lo deseable. Aquí está desglosada en sus componentes:

Este enfoque facilita la toma de decisiones durante el refinamiento del backlog, permitiendo una distribución más estratégica de los recursos y esfuerzos del equipo.

¿Cuándo aplicar MoSCoW en Scrum?

La técnica MoSCoW puede aplicarse en varias etapas del ciclo de Scrum:

Herramienta 3: Modelo Kano

El Modelo Kano es una herramienta útil para identificar y categorizar las necesidades del cliente en el desarrollo del producto. Se clasifica en las siguientes categorías:

Al aplicar el Modelo Kano, el Product Owner puede obtener una comprensión más profunda de lo que realmente desea el cliente, lo que puede ayudar a priorizar de manera efectiva las funcionalidades en el Product Backlog.

Herramienta 4: Customer Journey Maps (Mapas del Viaje del Cliente)

El Customer Journey Map es una herramienta visual que representa la experiencia total del cliente con un producto o servicio desde el primer contacto hasta la interacción final. Ayuda a comprender las necesidades, las emociones y los obstáculos que el cliente podría enfrentar en cada etapa. Aquí está su estructura general:

El uso de los Customer Journey Maps permite al Product Owner:


Otras herramientas / técnicas útiles para el Product Owner