Gestión de Productos con Scrum: Guía Completa + Ejemplos
Scrum no es nada nuevo en el ámbito de la gestión de productos. La mayoría de nosotros utilizamos Scrum en nuestras empresas y tratamos de navegar por los roles y principios de este marco para alcanzar nuestros objetivos.
Desafortunadamente, es común que las empresas interpreten mal los principios de Scrum y los utilicen de forma incorrecta, privando así a los usuarios de muchos beneficios de Scrum.
Así que esta encantadora pequeña guía está dedicada a ayudarte a hacer un mejor uso de este marco, explicando de qué se trata, por qué existen diferentes roles en Scrum, cuáles son las responsabilidades en la gestión de productos y cómo destacar en la colaboración interfuncional.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
¿Qué Es Scrum En La Gestión De Productos?
A muchos de nosotros nos gusta debatir sobre el rol de un product manager dentro de la realidad de los procesos Scrum y la metodología Agile (en otras palabras, qué hace el PM en un equipo Scrum). En vez de solo explicarlo, pienso que es más fácil simplemente mostrarte dónde está el PM en el organigrama del equipo.
Sin embargo, para esta guía quiero abordar este tema desde la dirección opuesta y mostrar cómo Scrum se integra en tu realidad como profesional de la gestión de productos y cómo puede ayudarte a alcanzar tus metas de producto.
Quiero empezar hablando del efecto de los principios fundamentales del marco Scrum sobre la efectividad de nuestro trabajo.
Probablemente el principio más valioso de Scrum para nosotros es la entrega constante de valor a los usuarios. Cuanto más rápido pueda la gente resolver problemas, mejor funcionará tu producto. Además, obtienes acceso a comentarios tempranos de personas que han usado la funcionalidad en un escenario real.
La segunda ventaja que obtienes con Scrum es la flexibilidad. Si la realidad del mercado cambia, puedes adaptarte rápidamente renovando por completo tu backlog de producto y entregando nuevas funcionalidades a tu equipo en el siguiente sprint (esto es algo para lo que la IA en la planificación de sprints puede ayudar).
Estas dos cosas son muy difíciles (o casi imposibles) de hacer con marcos tradicionales como Waterfall, donde todo está definido en alcance y los usuarios acceden al producto únicamente al final de el ciclo de vida del desarrollo de software.
Ejemplos de Éxito de Producto Gracias a la Integración de Scrum
Tras haber trabajado con equipos Scrum durante años, tengo una preferencia evidente por este marco Agile. Así que no tomes mis palabras como dogma. En su lugar, veamos casos reales en los que cambiar a Scrum ayudó a los equipos de producto a triunfar más rápido.
Microsoft Visual Studio: La principal herramienta de edición de código de este gigante tecnológico era famosa por sus ciclos repetitivos de infierno productivo, con versiones llenas de errores y lanzamientos muy infrecuentes. Desde el momento en que su equipo de producto empezó a aprovechar Scrum, la empresa experimentó un notable aumento en la estabilidad del producto junto con ciclos de lanzamiento mucho más frecuentes—restableciendo así su competitividad en el mercado.
Spotify: La adopción de Scrum por nuestro querido servicio de streaming musical es una de las más famosas de la industria. A Spotify le costaba adaptarse y escalar lo suficientemente rápido para resolver sus desafíos de proceso... hasta que la empresa adoptó Scrum. Pero lo que distingue a Spotify es el desarrollo de su propio modelo de gestión de proyectos basado en Scrum, que consistía en grupos de equipos Agile autónomos con acceso a toda la experiencia necesaria para experimentar rápidamente e incorporar el feedback de los usuarios.
ING: El gigante bancario holandés fue de las primeras instituciones financieras en darse cuenta de que el futuro de la banca es digital. También reconocieron que sus procesos de gestión de proyectos tan tradicionales no eran viables para el desarrollo de software. Por eso, adoptaron rápidamente metodologías lean y Scrum y, como era de esperarse, se convirtieron en líderes en banca digital.
Roles Clave En La Gestión De Productos Con Scrum
Si tú, como PM, decides que Scrum es el camino a seguir, aquí tienes un resumen rápido de los roles clave de este marco para ayudarte a diferenciar entre tu papel como product manager y el propietario del producto en Scrum.
Déjame comenzar con los roles. Un equipo Scrum típico está compuesto por las siguientes personas:
- Scrum master: Esta persona ayuda al equipo a seguir las reglas de Scrum y optimizar sus procesos.
- Product Owner: Representa al negocio y los usuarios dentro del equipo Scrum. Los Product Owners son responsables del backlog y establecen los objetivos del sprint y las prioridades de las historias.
- Scrum team: Tus desarrolladores, diseñadores, QA y otros especialistas que construyen el producto.
Sobre el equipo Scrum, puedes tener muchos otros tipos de especialistas ahí. El concepto de equipos multifuncionales asume que el equipo es independiente en cuanto a acceso a experiencia profesional. Por ejemplo, si tu producto está muy orientado al análisis de datos, podrías tener un analista de datos en el equipo también.
Product Manager vs. Product Owner: ¿Cuál es la diferencia?
La definición de product owner que di antes puede confundirte un poco, ya que suena mucho a lo que normalmente hace un product manager.
Entonces, en este caso, ¿cuál es la diferencia entre product manager y product owner?
Para entender la diferencia, primero veamos las responsabilidades clave de cada uno.
Product Managers
- Realizan el descubrimiento del producto y entienden las necesidades y los problemas de los clientes.
- Definen la visión del producto y la dirección que seguirá el equipo.
- Idean soluciones de producto que puedan satisfacer las necesidades de los clientes.
- Lideran el proceso de entrega del producto.
- Mejoran el producto en pequeños incrementos basándose en la retroalimentación de los clientes y la toma de decisiones basada en datos.
- Gestionan la visión y la ejecución del producto a nivel interno y transversal en la empresa.
Product Owners
- Crea y mantiene el product backlog.
- Sirve como única fuente de verdad en términos de estrategia, diseño y lógica de negocio para el equipo Scrum.
- Prioriza los elementos del product backlog y aporta claridad al equipo sobre qué es importante.
- Define los criterios de aceptación de las funcionalidades y acepta los resultados del sprint en base a ellos.
- Desbloquea a los miembros del equipo aclarando requerimientos y resolviendo incidencias relacionadas.
- Participa en los eventos Scrum y actúa como la voz del negocio y los clientes dentro del equipo.
Como podemos ver, la mayoría de nosotros hacemos cosas que aparecen en ambas listas. Esto es bastante normal y común, ya que muchos actuamos como product managers y owners al mismo tiempo.
La diferencia principal entre ambos es que la gestión de producto es una profesión y conjunto de habilidades, mientras que la ownership de producto es un rol dentro del equipo Scrum.
¿Pero qué significa eso?
Significa que el product owner no tiene que ser un product manager. En una startup pequeña, donde tienes al CEO junto a tres desarrolladores, el CEO asumirá el rol de product owner brindando a los desarrolladores un backlog priorizado.
La situación opuesta también es posible. Puedes ser product manager y no product owner. Yo soy un buen ejemplo de ello, ya que uno de mis antiguos equipos no usaba Scrum. Sin Scrum, no hay product owner en el equipo. Sin embargo, sí seguíamos principios Lean y Ágiles.
Para darte un entendimiento más claro de la diferencia entre ambos, aquí tienes una comparación lado a lado de lo que hacen.
Pero ¿cuál era el objetivo de tener un rol especial en el equipo Scrum? ¿No podrían simplemente colaborar con product managers que no son parte del equipo? Realmente me gusta cómo Teresa Torres lo responde.
Así que la principal razón de que haya un rol específico de producto en el equipo Scrum es aportar conocimiento y experiencia interna sobre el producto y reforzar aún más su multifuncionalidad.
Cómo interactúa el Product Manager con los equipos Scrum
Suponiendo que hayas decidido tomar el camino de Scrum, necesitarás saber cómo ser miembro del equipo y cómo colaborar con tu gente. Déjame darte una breve visión general de eso para cada evento Scrum y artefacto.
- Daily Scrum (también conocidas como reuniones de pie): El trabajo más importante que realizas durante estas reuniones con tiempo limitado es responder a las preguntas relacionadas con el producto de tu equipo de desarrollo y eliminar obstáculos.
- Reunión de planificación de Sprint: Aquí, eres la persona que establece el objetivo del Sprint definiendo claramente tus expectativas en términos de las funcionalidades que esperas entregar.
- Retrospectiva de Sprint: Los procesos que utilizas para entregar prioridades y requerimientos al equipo pueden hacer que sean eficaces o no. Así que puedes usar esta reunión para recopilar retroalimentación del equipo y mejorar tus procesos.
- Revisión de Sprint: Aquí, tu tarea es aceptar las funcionalidades terminadas del Sprint y brindar retroalimentación al equipo sobre su trabajo.
- Refinamiento del producto (también conocido como grooming): Eres el responsable de esta reunión y debes usar el tiempo dedicado a ti para discutir las prioridades y detalles de las historias de usuario que tienes para el equipo. Anima siempre al equipo a desafiar tus requisitos y a encontrar “errores de producto” que hayas dejado pasar.
- Product Backlog: Es tu responsabilidad gestionar el product backlog y mantenerlo limpio y priorizado, ya que ellos construirán su Sprint en base a él.
- Sprint Backlog: Este no te pertenece. Tu principal punto de colaboración es guiar al equipo para que elija las historias correctas en el Sprint backlog para asegurar que puedan alcanzar tu objetivo de Sprint.
Aparte de esto, realizarás otros tipos de trabajo de producto, como la gestión de partes interesadas o el descubrimiento de producto. Como miembro del equipo Scrum, tu tarea es mantener al equipo informado de las necesidades tanto de los stakeholders como de los usuarios, después de que las hayas aclarado.
Por ejemplo, si tienes una entrevista con un usuario y descubres que la experiencia de usuario de tu flujo de acceso es generalmente confusa, es importante compartir esta información con el equipo para asegurarte de que presten atención a esa parte en los siguientes sprints.
Mejores Prácticas para la Gestión de Producto en Scrum
Aunque la gestión de producto parece sencilla cuando se mira a través de la lente de Scrum (y del desarrollo Ágil en general), cometemos muchos errores comunes durante nuestro trabajo dentro de equipos auto-organizados.
Así que aquí tienes un par de buenas prácticas en Scrum que pueden ayudarte a evitarlos:
- Establece expectativas claras: El mayor error que puedes cometer es dar a tu equipo prioridades y requisitos vagos. La falta de claridad es una de las causas principales de retrasos en el desarrollo y de tensiones entre tú y el equipo. Muy pronto veremos en detalle cómo lograr esto.
- No abuses de la adaptabilidad: Tener la capacidad de cambiar de rumbo es genial, pero solo puedes hacerlo en tu product backlog, no en el sprint backlog. En cuanto empieza el sprint, por favor, no añadas ni elimines historias. Esto confunde los planes y el progreso de tu equipo y conduce a sprints sin terminar.
- Crea un ambiente emocionalmente seguro: Eres miembro del equipo, no su jefe. Por lo tanto, no presiones a tu equipo para que asuma compromisos mayores o termine antes. Las guías de Scrum en todos lados, incluida la de Scrum.org, ponen gran énfasis en mantener relaciones saludables con tus compañeros, ya que es uno de los pilares del trabajo en equipo efectivo.
Estas tres mejores prácticas son las más importantes según mi experiencia. Pero, si quieres más consejos sobre flujos de trabajo Ágil y buenas prácticas de Scrum para gestores de producto, asegúrate de revisar nuestra guía aparte sobre gestión de productos Agile.
Gestión efectiva del Product Backlog
Como mencioné antes, proporcionar claridad a tu equipo es una de las tareas más cruciales de una persona responsable de producto. La buena noticia es que tu product backlog probablemente es la mejor herramienta para lograrlo. Así que, aquí tienes un par de consejos sobre gestión del product backlog que pueden ayudarte:
Groomings: Por muy bien que escribas tus historias de usuario, dejarás “errores” ahí, y querrás que tu equipo de desarrollo los revise y te los señale. También existe el hecho de que no eres desarrollador y podrías escribir requisitos difíciles de implementar. De nuevo, tu equipo te lo dirá durante el proceso de grooming.
Técnicas de priorización: Aprovecha los numerosos marcos de priorización para entender qué funcionalidades son más relevantes que otras. Mi favorito es MoScoW por su simplicidad.
Alineación con la hoja de ruta y visión: Los épicos e historias de tu backlog deben representar los objetivos generales del producto y los indicadores que quieres alcanzar. Así que asegúrate de revisar constantemente tu hoja de ruta al añadir algo al backlog.
La señal más evidente de que una organización carece de claridad es cuando recorres la organización y preguntas a diferentes personas cuáles creen que son los criterios de éxito para lo que debe entregarse como el próximo gran hito, y empiezas a escuchar distintas versiones.
Alineando a los interesados en Scrum
La esencia del rol de un product manager en Scrum es que, básicamente, eres el enlace de conexión entre el equipo autoorganizado y el mundo exterior, ya sean usuarios, interesados u otros equipos.
Así que, además de realizar tus tareas habituales de gestión de interesados como PM, también necesitas transmitir esa información de vuelta a tu equipo y viceversa. También habrá situaciones en las que debas comunicar información del equipo de vuelta a los interesados.
Un buen ejemplo es la aparición de retos técnicos, como problemas con la integración continua, que pueden afectar al plazo o alcance de una funcionalidad determinada. Esto es algo que debes discutir con los interesados y, o bien aceptar el nuevo plazo/alcance, o buscar una solución diferente (por ejemplo, reforzando el equipo con más experiencia en esa materia).
También hay ocasiones en las que tu equipo puede proponer una idea interesante para una funcionalidad o solución que valga la pena añadir al roadmap. De nuevo, transmites esa información a los interesados y decidís si finalmente la añadís a vuestro plan o no.
La importancia de la planificación ágil del roadmap en Scrum
Aunque no es directamente parte de Scrum, los roadmaps ágiles son una de las herramientas que hacen posible Scrum. Al fin y al cabo, ¿cuál es el sentido de la planificación iterativa si se utiliza el método Waterfall para tu producto en lugar de un roadmap ágil?
En ese caso, lo que llamas estrategia de producto Scrum sería simplemente dividir un plan predefinido y fijo con el SDLC clásico en partes de 2 semanas (o del tiempo que duren tus sprints). Así que, para que Scrum tenga sentido para tu equipo, debes hacer una planificación interactiva Ágil y crear un roadmap que sea capaz de cambiar con el tiempo.
Ahora bien, para casar adecuadamente tu roadmap ágil con los procesos Scrum de tu equipo, esto es lo que te sugiero hacer:
- Enlaza los elementos del roadmap (normalmente Épicas) con las historias de usuario del backlog de producto. Así, hay una conexión directa entre tu trabajo táctico (historias) y tu estrategia (roadmap).
- Preséntale el roadmap a tu equipo Scrum. Así, sabrán hacia dónde va el producto y podrán tener las próximas funcionalidades en mente al diseñar la arquitectura del frontend o backend.
- Aprovecha herramientas especializadas como Jira, Monday.com y Clickup para optimizar tu planificación de roadmap y la gestión del backlog.
En cuanto al último punto, esas tres herramientas son las que personalmente he utilizado. Sin embargo, hay muchas otras herramientas de gestión de producto que puedes considerar utilizar en su lugar.
More Articles
- IA en investigación de usuarios: Cómo la inteligencia artificial está transformando la obtención de conocimientos de usuario
- Lanzar Productos Pensados para lo Global sin Dolor de Cabeza: Cómo Integrar la Localización en tu Flujo de Trabajo de Producto
- La IA en la Planificación de Sprints: Cómo la IA Mejora la Eficiencia del Equipo
Retos en la gestión de productos con Scrum
Si bien Scrum es un gran marco para alcanzar los objetivos de tu producto, utilizar este marco tiene sus propios desafíos, tales como:
- Tu equipo o tus stakeholders pueden no entender de qué se trata Scrum. Esto, obviamente, puede conducir a problemas importantes en la adopción de Scrum, como negarse a utilizar ciertos artefactos. Recomiendo adelantarse a esto mostrando el 'estado final' deseado de cómo se verá el equipo y el flujo de trabajo cuando el marco esté completamente implementado.
- Las personas (y tú) pueden confundirse sobre tu papel dentro y fuera del equipo. Cada empresa para la que he trabajado a lo largo de mi carrera tenía su propia interpretación de lo que debía ser un Product Owner de Scrum. Lo mejor es dejar claro qué es y qué no es para tu equipo.
- El alcance de las funcionalidades en las que trabajas tiende a expandirse sin fin. No es de extrañar que esto facilite caer en el temido "scope creep". Los equipos Scrum deben ser implacables para decidir qué asumir y a qué decir 'no'.
- La hoja de ruta puede descarrilarse fácilmente. Al tener un equipo relativamente independiente que puede elegir en qué trabajar, podrías terminar con ellos construyendo cosas que no están en tu hoja de ruta. Mantener siempre en claro el objetivo final es fundamental para evitar este problema.
Aunque estos desafíos son bastante comunes, la buena noticia es que solo le toma al PM un par de sprints comprender el proceso Scrum y superar la gran mayoría de ellos. Para quienes quieren formalizar su experiencia, aprender cómo convertirse en Scrum Master puede brindar a los líderes una ventaja creíble para guiar a sus equipos con este marco de trabajo.
Conclusión
Scrum es uno de los mejores regalos para los product managers que existen. Gracias al equilibrio entre ser ágil a largo plazo y estricto en iteraciones cortas, puedes evitar el caos de un proceso de desarrollo ágil sin un marco definido, y al mismo tiempo mantener la capacidad de cambiar el rumbo del producto según la respuesta del mercado.
Esperamos que hayas disfrutado de nuestra guía. Si es así, no olvides suscribirte a nuestra newsletter para más recursos y guías sobre gestión de productos, además de los últimos pódcast, entrevistas y otros puntos de vista de líderes del sector y expertos.
FAQ:
¿Cuál es el rol de un Product Manager en Scrum?
Los product managers, que suelen desempeñar el papel de product owner en el equipo Scrum, son responsables de proporcionar claridad al equipo, compartiendo los planes, prioridades y requisitos funcionales necesarios del producto.
¿En qué se diferencia Scrum de otras metodologías Ágiles en la gestión de productos?
A diferencia de Kanban u otros marcos Ágiles, Scrum es más estructurado y tiene reglas claras sobre cómo organizar el trabajo dentro del equipo utilizando sus eventos (reuniones diarias, sesiones de refinamiento, etc.) y artefactos (sprint backlog, product backlog, etc.).
¿Cuáles son los desafíos comunes en la gestión de productos Scrum?
El desafío más común es que tu equipo y los stakeholders malinterpreten las reglas y artefactos del marco Scrum e intenten modificar sus reglas antes de que la empresa haya intentado adaptarse a este nuevo marco.
¿Puede un Product Manager ser también Product Owner?
Sí. Product Manager es una profesión. Product Owner es un rol en un equipo Scrum. La mayoría de las veces, el Product Owner en el equipo es un Product Manager. A veces, especialmente en startups pequeñas, los CEOs pueden asumir el rol de Product Owner en el equipo.
