Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Backlog de Producto. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Backlog de Producto. Mostrar todas las entradas

martes, noviembre 28, 2023

Los artefactos Scrum: un enfoque unificado para el éxito del producto

 

Fuente: https://www.linkedin.com/feed/update/urn:li:activity:7132793258551726080/

He tenido el privilegio de guiar a numerosos equipos y empresas a través de implementaciones exitosas de Scrum. Una de las preguntas más comunes que encuentro es: "¿Cuál es el artefacto principal en Scrum: el Product Backlog, el Sprint Backlog o el Incremento?"

En una encuesta reciente en LinkedIn realizada por Scrum Inc., a manera de trivia, el 74 % de los encuestados, incluyéndome, indicaron que los tres artefactos son igualmente críticos para el éxito de Scrum. Esto se alinea con mi propia experiencia, donde he sido testigo de cómo cada artefacto desempeña un papel distinto pero complementario a la hora de impulsar el desarrollo de productos.

Pero qué pasa con quienes dieron respuestas diversas: el 13% estaba a favor del Product Backlog, el 6% optó por el Sprint Backlog y otro 6% creía que el Incremento era el más crucial. Este último parece tener sentido, después de todo, se trata del objeto final de la iniciativa de producto, ir creándolo en pequeñas partes, pero ni siquiera tuvo una mayoría favorecedora dentro de los artefactos individuales.

La ilusión de la separación: un nombre inapropiado

Si bien cada artefacto posee sus propios méritos disímiles, la verdadera magia de Scrum radica en su interacción sinérgica. El Product Backlog proporciona una visión general, el Sprint Backlog traduce esa visión en tareas procesables y el Increment manifiesta esas tareas en valor tangible.

Es definitivo: la noción de que un artefacto reina sobre los demás es un error. Es como afirmar que los cimientos, las paredes o el techo de una casa son más importantes que los demás. Cada componente juega un papel crucial en la integridad de la estructura. De manera similar, cada artefacto Scrum contribuye al éxito general del proceso de desarrollo del producto.

El Product Backlog: la brújula visionaria

El Product Backlog sirve como base de Scrum y representa la visión en constante evolución del producto. Es una lista ordenada de características, requisitos y mejoras que definen el estado deseado del producto. Continuamente refinado y actualizado, el Product Backlog guía los esfuerzos del equipo, asegurando que estén alineados con la dirección estratégica del producto.

El Sprint Backlog: la hoja de ruta táctica

El Sprint Backlog, derivado del Product Backlog, traduce la visión del producto en tareas procesables para un solo sprint. Es una lista dinámica de historias de usuario, errores, tareas y otros elementos de trabajo que el equipo se compromete a completar durante el sprint. El Sprint Backlog proporciona enfoque y claridad, lo que permite al equipo ofrecer valor tangible al final de cada sprint.

El Incremento: la expresión concreta del progreso

El Incremento, la culminación de cada sprint, representa el producto funcional que está potencialmente disponible para los clientes. Es la manifestación tangible de los esfuerzos del equipo, que muestra las capacidades en evolución del producto y permite que se proporcione retroalimentación temprana para una mejora continua. El Incremento sirve como un faro de progreso, motivando al equipo y validando la dirección del producto.

Adoptando la naturaleza entrelazada de Scrum

El verdadero dominio de Scrum radica en reconocer la interconexión de estos artefactos. No son entidades aisladas sino más bien elementos interdependientes que se entrelazan para formar el tejido del éxito de Scrum. Descuidar un artefacto inevitablemente afecta a los demás, lo que dificulta la capacidad del equipo para entregar valor de manera consistente.

Cuando aceptamos el significado colectivo de los artefactos Scrum, liberamos el verdadero potencial del framework. Normalmente, capacito a los equipos para que naveguen por las complejidades del desarrollo de productos con agilidad, enfoque y mejora continua. Juntos, el Product Backlog, el Sprint Backlog y el Increment forman la piedra angular del éxito de Scrum, lo que permite a los equipos ofrecer productos que deleitan a los clientes e impulsan el crecimiento y la innovación en las empresas.

En mi experiencia, los intentos de aislar un artefacto como el más crucial a menudo conducen a una comprensión incompleta del enfoque holístico de Scrum. Cada artefacto juega un papel indispensable y su integración armoniosa forma la base del éxito de las iniciativas Scrum.

Estos instrumentos no son meras herramientas; son el alma de Scrum, son las expresiones tangibles de una mentalidad ágil. Encarnan los principios de mejora continua, colaboración y adaptabilidad, transformando el proceso de desarrollo de productos en un viaje de experiencias y evolución continuas.

Entonces, la próxima vez que reflexiones sobre la importancia relativa de los artefactos Scrum, recuerda que no son entidades aisladas sino hilos interconectados que tejen el tapiz del éxito de Scrum.

viernes, enero 21, 2022

Plantilla en Mural para el User Story Conversation Canvas


Las buenas historias de usuario estimulan, en el buen sentido, la conversación entre los involucrados (por ejemplo, Dueño de Producto y miembros del equipo). Además, las historias de usuario ven, o dejan ver, la funcionalidad desde la perspectiva del negocio, específicamente desde el Valor que la historia proporciona al negocio.

Como su nombre lo indica, este User Story Conversation Canvas es un medio de comunicación, un instrumento para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. En el fondo, es una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.

Con este lienzo cualquier persona involucrada, el Dueño de Producto, el equipo en pleno o solo un miembro de este, el Scrum Master, incluso un usuario, puede encontrar la ayuda que necesita para describir adecuadamente los aspectos más relevantes de una historia de usuario, desde las personas que están o se verán involucradas durante la definición, evolución, desarrollo y puesta en marcha de la historia, hasta el resultado esperado y las métricas asociadas a la historia, pasando por el contexto de la misma. Pero, sobre todo, podrá encontrar el soporte que necesita para preparar conversaciones fantásticas sobre los elementos que componen el producto.

Las sesiones de refinamiento, la planificación y la revisión son tres de los escenarios principales donde podemos usar este Lienzo para Conversar Sobre Historias de Usuario. Pero se puede usar en muchas otras circunstancias: el dueño de producto hablando con los usuarios y otros interesados, los miembros del equipo de desarrollo, para acordar y sincronizar el trabajo a realizar, el Scrum Master y el Dueño de Producto, en conversaciones alrededor del producto, del backlog, al aplicar patrones para dividir las historias, entre otros escenarios.

¡Cuando se trata de historias de usuario, el énfasis es en la Conversación!

Para saber más sobre Historias de Usuario, los criterios INVEST de las historias y otros aspectos no menos relevantes sobre el tema, puedes visitar mi serie de artículos “Historias de usuario altamente efectivas” en mi Gazafatonariohttp://bit.ly/lashistoriasdelucho.

Descarga el lienzo y la guía completa en alta definición aquí:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

Y para estos tiempos de trabajo virtual he desarrollado esta plantilla en Mural para que puedas trabajar de manera colaborativa con historias de usuario y con el lienzo para conversar sobre historias de usuario. Para ir a la plantilla, ve a la parte superior de la siguiente imagen y toca en "start from template" o en el icono de Mural.

martes, enero 11, 2022

Cinco formas de mejorar tu desempeño con historias de usuario

 

Imagen tomada de Pixabay

Las historias de usuario no son para escribirlas

La pregunta que debes hacer no es “¿cómo escribir mejores historias de usuario? El objetivo no debe ser escribir historias de usuario. Cámbiala más bien por ¿cómo mejorar mis conversaciones con historias de usuario? Las historias de usuario son un instrumento de comunicación social y sabemos que la forma más efectiva de comunicar información es la conversación, ojalá cara a cara. La forma más efectiva de evolucionar las historias de usuario es vía conversaciones, primero entre los usuarios e interesados y el Product Owner y luego, entre este y los miembros del equipo.

Puedes leer mi artículo Las historias de usuario como instrumentos de negociación para saber más sobre este tema. Clic aquí para leerlo.

Las historias de usuario te ayudan a encontrar tu por qué

Las historias de usuario son una herramienta para iniciar el descubrimiento del producto con el usuario, consumidor o cliente, no es para finalizarlo. De esta manera, tanto el Product Owner, como los desarrolladores (quienes hacen el trabajo finalmente) deberían ver las historias de usuario como algo que describe el por qué están haciendo lo que hacen, no precisamente qué están haciendo. Como siempre, si un usuario no estuvo involucrado en el descubrimiento y desarrollo de las historias de usuario, estas quizás no sean historias de usuario del todo; quizás sean más bien “quimeras imaginadas”.

Conoce a los usuarios

Por eso, mi primerísima recomendación, concisa, si eres responsable de las historias de usuario, es: habla con las personas que tienen la necesidad, el problema, indaga por el problema detrás del problema, la causa raíz. Esto aumentará tu comprensión de lo que se necesita y por qué. Acompaña esta práctica con un conocimiento profundo y empático del usuario o consumidor: quién es, qué hace, con quién lo hace, qué información intercambia y cómo lo hace, son algunas de las cuestiones a escudriñar si quieres tener éxito con historias de usuario.

En mi artículo Qué hay de "usuario" en las historias de usuario profundizo sobre este asunto. Clic aquí para leerlo.

Las historias de usuario y el product backlog

Una historia de usuario no está sola, aislada del resto del producto. Así que es importante pensar sobre ella como un componente de primer orden del product backlog. Y en este punto, es de mucha importancia considerar la transparencia del backlog. Recordemos que transparencia significa que todos los interesados, usuarios y equipo comparten el mismo significado de las cosas, por ejemplo, qué significa que algo está terminado.

Las cosas así, las historias de usuario deben ser transparentes y estar disponibles para todos los interesados, para que estos tengan visibilidad de lo que está haciendo el equipo, en qué orden y por qué. En particular, resuelve preguntas como:

- ¿Los interesados saben cómo acceder a las historias de usuario?

- Cuando acceden a las historias de usuario, ¿el contenido los ilustrará o los confundirá?

En mi artículo El extraño caso de las historias de usuario técnicas pongo de manifiesto que una “historia de usuario técnica” es una práctica disfuncional. Clic aquí para leer el artículo. Este otro artículo también te puede dar ideas al respecto: Buenas y “malas” historias de usuario. Clic aquí para leerlo.

Desarrollo de producto dirigido por hipótesis y experimentos

Las historias de usuario son hipótesis. Trátalas como tal. Haz experimentos y comprueba esas hipótesis. La última línea de defensa es el consumidor final, el usuario. Mientras tanto, no dejarán de ser eso precisamente: supuestos o conjeturas. En este apartado entran en escena las entregas tempranas y frecuentes y, sobre todo, la retroalimentación directa que logres de los clientes o usuarios. Es de esta manera que podrás adaptarte al entorno y tomar mejores decisiones en el futuro inmediato que beneficien a los usuarios. Para lograrlo, tus historias de usuario deben ser realmente pequeñas. Piensa que solo tienes algunas horas para implementarlas o construirlas, hasta unos muy pocos días, dos o tres a lo sumo.

En este apartado, una anotación especial para desarrolladores de software: si todavía te encuentras con el escenario de “mini cascadas”, es decir, primero un “subequipo” desarrolla la historia y luego otro “subequipo” prueba la historia, entonces tus historias de usuario deben ser aún más pequeñas. No te imaginas cómo sufren los analistas de prueba mientras esperan a que desarrollo les entregue las historias para empezar a probar cuando el final del sprint ya está encima. Como siempre, el mejor antídoto contra todo esto, es empezar a cambiar radicalmente las técnicas de desarrollo, incursionando en TDD, BDD y automatización, entre otras. Pero tengo que confesarlo, esto es más fácil decirlo que hacerlo. Por eso hago toda esta recomendación especial.

Quieres saber más

Estos y otros temas de interés hacen parte de mi curso de historias de usuario. En febrero estaré facilitando una nueva edición del curso. Toda la información en https://bit.ly/cursohu.


jueves, abril 01, 2021

Sobre multifuncionalidad y la creación de un incremento de producto

Image by Alexandr Ivanov from Pixabay 

Sobre multifuncionalidad y la creación de un incremento de producto

O de las minicascadas en el Sprint y de cómo deshacernos de ellas

“Todos los patrones de conjuntos fijos son incapaces de adaptabilidad o flexibilidad. La verdad está fuera de todos los patrones fijos”. -Bruce Lee

De dónde venimos

Todos hablamos de que un equipo Scrum es un equipo multifuncional y autogestionado. En nuestro contexto, multifuncional significa que el equipo en pleno suma todas las habilidades y capacidades necesarias para producir un incremento de producto al final de cada iteración. En la práctica eso es más fácil decirlo que hacerlo posible. ¿Qué sucede cuando conformamos un equipo cuyos miembros, en el mejor de los casos, dominan solo una pequeña parte de ese espectro de multifuncionalidad necesaria para hacer el trabajo?

Estos escenarios son mucho más comunes de lo que creemos. Solo para mencionar uno de estos: pensemos en una empresa que viene trabajando con prácticas tradicionales de gestión en las últimas décadas y cuya área de Tecnología cuenta con proveedores externos: unos para desarrollar el software y otros para realizar las pruebas de este. Y tanto las personas de un proveedor como del otro no se hablan sino a través de procesos y herramientas, como un bug tracker o actas formales de entrega y recepción de partes del producto.

Es muy probable que en esos equipos prime la alta especialización: el así llamado desarrollador de front-end, el analista de requisitos, el desarrollador de back-end, el arquitecto del software, de un lado. El analista de pruebas funcionales, el de pruebas no funcionales, el automatizador de pruebas, lo que sería un gran avance, del otro lado. Seguramente cada uno de estos equipos incluya uno o más gestores de esto y de lo otro. Incluso la empresa para la cual trabajan, el cliente, cuente con sus propios roles y responsabilidades dentro de todo este intrincado ecosistema de trabajo.

Imaginemos ese escenario: aquí los unos y los otros son de organizaciones diferentes. Pensemos en que ahora esa empresa quiere hacer las cosas usando enfoques ágiles y lean y prácticas como Scrum e historias de usuario. Además, quiere aprovechar el conocimiento que tienen sus proveedores actuales y decide invitarlos a embarcarse en un viaje que los llevará por los caminos ignotos de la agilidad: una nueva forma de pensar y de hacer las cosas, nuevos comportamientos, conceptos y preceptos muy distintos a los que venían usando, “metodologías” con poca información sobre el cómo hacer las cosas. Nuevos roles. ¡Y un solo equipo!

Para dónde vamos

Image by Merhan Saeed from Pixabay 

Entonces esto de la autogestión y la multifuncionalidad no ocurre mágicamente por la intervención de un Scrum Master o de un agente de cambio con alguna etiqueta específica. Es fácil decir o proponer que el tamaño de los elementos del product backlog se encuentren en un rango, por ejemplo, entre 1/10 a 1/6 de la velocidad “conocida” del equipo. Pero una cosa es contar con un equipo cuyos jugadores dominen más de una especialidad, sino todas, a hacerlo en un equipo donde eso no ocurre ni ocurrirá durante algún tiempo. Adquirir habilidades T toma tiempo, aunque los beneficios son evidentes una vez que se consigue. Pues bien, una primera recomendación es reducir aún más el tamaño de las historias de usuario.

Es algo para tener en cuenta cuando se hace refinamiento o, simplemente, cuando se dividen elementos del product backlog en piezas más pequeñas. Eso es necesario porque el trabajo en el sprint será una minicascada: si se trata de desarrollo de software, por ejemplo, primero se realizará el trabajo de diseño y programación y luego se hará el trabajo de pruebas o de aseguramiento de la calidad. Incluso es posible que, en cada una de esas breves fases, haya etapas más pequeñas que se lleven a cabo de manera secuencial.

Las cosas así, no será posible cumplir la promesa de tener elementos del product backlog (alias las historias de usuario) terminados durante los primeros días del sprint. Esto, como sabemos, sube la presión y el estrés sobre el equipo y sobre los interesados y usuarios, representados por el Product Owner. Es un hecho: llegar a la mitad del sprint o más allá, independientemente de su duración, sin que ninguna historia de usuario alcance la Definición de Terminado, aumenta la ansiedad e inicia un ciclo nocivo de sucesos que derivan en resultados pobres, pero, sobre todo, en desmotivación y en una baja de energía en el equipo.

Estas son algunas recomendaciones de experimentos que he encontrado útiles para despejar esas nubes cenizas que arremeten contra el trabajo colaborativo:

·       Historias de usuario más pequeñas.

·       Menos historias de usuario.

·       Sprints de dos o de tres semanas. Siempre podemos disminuir la duración más adelante.

·       Un refinamiento que “mire” dos o, mejor, tres Sprints hacia adelante.

·       Manejo de expectativas con los usuarios e interesados, vía la Product Owner o el Scrum Master o alguna otra persona del equipo o muy cercana a este.

·       Ordenamiento por valor del product backlog, más que hacer priorización. Es decir, ordenar uno a uno, por valor e impacto para el negocio, para los usuarios o clientes, cada historia de usuario. Muchas veces la priorización se hace por grupos de elementos. El ordenamiento se hace de manera individual. Esto asegura que en cada sprint se entregue Valor, aunque este sea en pocas cantidades.

·       Foco en una historia a la vez y concentrarse en su finalización.

·       Promover la colaboración, el trabajo en equipo, la inteligencia colectiva.

Pero lo más importante y crítico es poner en marcha un plan de desarrollo de competencias que faculte a las personas para adquirir habilidades T en principio y, más adelante, habilidades Pi. Esto toma tiempo, requiere de una inversión considerable, pero es lo que va a permitir hacer las cosas de una manera diferente de una vez por todas y para siempre. Un plan que incluya:

·       Adquisición de nuevas prácticas y, si es necesario, de nuevas herramientas.

·       Trabajo en pares.

·       Usar el patrón Swarming o Enjambre. Esto es, todo el equipo, o casi todo, trabajando en una única historia de usuario a la vez. Más sobre este patrón en: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/.

·       Pasantías.

·       Acompañamiento y mentoría.

·       Autoestudio.

·       Potenciación de habilidades.

·       Práctica. Kata. Kata. Kata.

Los beneficios de desarrollar este plan no girarán solo en torno al aumento de la productividad del equipo, sino también a la entrega de mayor valor en cada iteración, al incremento de la calidad, a la mayor satisfacción y felicidad de usuarios o consumidores finales, y también contribuirán a energizar al equipo, a su bienestar, a menos estrés y a más motivación.

¿Qué te parecen estas ideas? Por favor, cuéntamelo en el foro.


---

*Crédito de la imagen de la sección "De dónde venimos": silhouettes by Gerd Altmann from Pixabay 

jueves, septiembre 10, 2020

Planificar historias de usuario en tareas


El trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint. Este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.

En particular, en esta presentación  muestro algunos ejemplos de cómo descomponer historias de usuario de un backlog de producto en tareas de un backlog de sprint. También explico algunas prácticas y guías a tener en cuenta a la hora de la planificación.

Estas y otras ideas, en la presentación que puedes ver y descargar aquí.



viernes, marzo 13, 2020

Sobre el Incremento de Producto y el Refinamiento

Imagen de mohamed Hassan en Pixabay
Llegan algunas preguntas de colegas a mi buzón:

En el review:

¿A quién se le hace la entrega el incremento?

¿Este incremento debe ponerse en producción antes o después del review? (Si es antes, ¿qué pasa si el PO no lo avala o si es después, sería una tarea del siguiente Sprint?)

En el refinamiento:

¿En qué momento se contextualiza al equipo de trabajo sobre una funcionalidad o cambio sobre las funcionalidades pactadas? Es que entiendo que el refinamiento puede ser en cualquier momento entre todo el equipo.

¿Debería existir un día en el Sprint para refinar? ¿Eso no distrae al equipo de desarrollo?

Veamos algunas ideas al respecto:

Sobre la entrega del incremento

En la Revisión del Sprint se presenta el incremento del producto funcionando. El responsable de entregar este  incremento de Valor es el Equipo Scrum en pleno. ¿A quiénes se hace la entrega? A un grupo de interesados en el producto: patrocinadores, usuarios finales o consumidores, jefes, alta gerencia, personas de mercadeo y ventas, publicidad, operaciones u otras áreas que tengan que ver con el producto, entre otros. Tampoco se trata de una reunión “amplia” con mucha gente, se trata de algunos “interesados clave” invitados por el Dueño de Producto.

Esta es una reunión informal, no de seguimiento. El Dueño de Producto ya debe tener conocimiento previo de lo que se va a entregar, de su estado (solo se entrega producto terminado), de la calidad, etcétera. Después de todo, se supone que el Dueño de Producto está trabajando con el equipo de Producto de manera cotidiana. 

Dos aspectos clave de la reunión son que:

  • El Dueño de Producto explica qué elementos del backlog de Producto se han “Terminado” y cuales no se han “Terminado”; y
  • El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;

Pero la reunión va más allá. Es en este momento cuando siempre sugiero volver a leer la guía de Scrum.

Además de lo que dice la guía de Scrum, Jorge ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Sobre el incremento

Imagen de Gerd Altmann en Pixabay
El incremento debe estar probado y funcionando, es decir, debe ser potencialmente distribuible, que se pueda poner en producción. Este incremento cumple la Definición de “Terminado” del Equipo Scrum. Debe representar en buena medida la meta del sprint. En la práctica, no concibo un Incremento de Valor que no aporte en un altísimo porcentaje hacia el cumplimiento del objetivo del Sprint.

Normalmente el incremento se pone en producción después de la Revisión. Es posible que sea antes pero es algo difícil en los entornos actuales. Este asunto de la puesta en producción tiene su propia complejidad porque, si no estamos en un entorno con cultura DevOps, donde haya automatización y herramientas, el incremento quizás se tenga que entregar a un equipo externo y este, a su vez, deberá pasar por uno o más comités de "Paso a Producción", entre otras restricciones y, las cosas así, el paso final puede tardar desde algunas horas, hasta algunos días o semanas. En cualquier caso, es el Dueño de Producto quien autoriza el paso, al menos por el lado del producto. Ya los demás comités y áreas harán lo suyo.

Importante: el objetivo del Equipo Scrum es entregar un incremento de producto en cada Sprint. Que tenga valor para el negocio, los usuarios o consumidores. Es decir, que genere retorno de la inversión, que haga ganar más dinero, que minimice costos, que mejore procesos, que evite más costo de la demora innecesario, entre otros aspectos. Si tu equipo no lo está logrando, es tiempo de una retrospectiva cuyo foco sea precisamente este de la no entrega de valor.

Sobre el refinamiento

Imagen de Gerd Altmann en Pixabay 
La contextualización sobre una funcionalidad o cambio en las funcionalidades pactadas se hace, precisamente, durante el refinamiento. Es el mejor momento.

El refinamiento es una tarea diaria del Dueño de Producto, con su equipo de producto, con los usuarios, con los interesados, con los consumidores finales, etcétera. Y, de tanto en tanto, durante el Sprint, se reúne con el equipo para contarles sobre las funcionalidades que vienen en los dos siguientes Sprints. 

Scrum nos sugiere que podemos usar hasta un 10% del tiempo del sprint para el refinamiento. Pero el equipo debe o debería estar completo con el Dueño de Producto a bordo. Para que todos vayan con el mismo conocimiento a las siguientes planificaciones y refinamientos. 

Sobre cuándo hacer el refinamiento

Se puede seleccionar un día del sprint o dos, dependiendo de la duración del mismo. Por ejemplo, sesiones de 2 horas o de 4 horas máximo vienen bien. Se recomienda que sean a mediados del sprint, nunca al principio y mucho menos al final. De hecho, el equipo puede tomar este tiempo como un "respiro" de sus tareas más complejas de desarrollo, así que puede ser beneficioso. Lo que no puede suceder es que se hagan tres o más reuniones de refinamiento en el sprint, que sean breves, eso no. Aunque es cuestión de experimentar, no creo que este último sea el camino, eso sí puede distraer al equipo, puede hacer que pierdan el foco continuamente, en fin, veo algunas desventajas en hacerlo así. Una o dos sesiones máximo.

Más sobre refinamiento en:

Purga ágil de producto
http://www.gazafatonarioit.com/2016/06/purga-agil-de-producto.html

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto
http://www.gazafatonarioit.com/2017/06/sobre-el-backlog-de-producto-el.html

En este mismo Gazafatonario.