Índice
¿Qué es el PRODUCT BACKLOG?
El Product Backlog (o “Lista de Producto” en español) es una lista emergente y ordenada de todo lo que se conoce que es necesario que un producto o servicio cumpla.
Es uno de los 3 artefactos de Scrum. También es la única fuente de requisitos para cualquier cambio.
El Product Backlog es emergente, es decir, nunca está completo sino que es dinámico; cambia constantemente para identificar lo que el producto necesita para ser competitivo y útil en el mercado que se encuentra.
¿Qué contiene el Product Backlog?
Este artefacto contiene todas las características, funcionalidades, mejoras y correcciones (o bugs) a realizarse sobre el producto o servicio. A cada elemento del Product Backlog se lo conoce como Product Backlog Item (PBI) y tiene una descripción, un orden y una estimación. A medida que el producto es utilizado, el mercado comienza a proporcionar retroalimentación y esto hace que se convierta en una lista más larga y detallada. Por esto podemos decir que es un artefacto vivo ya que constantemente los requisitos están cambiando.
¿Quién es el responsable del Product Backlog?
El responsable del Product Backlog es el Product Owner, incluyendo su contenido, disponibilidad y priorización.
El compromiso del Product Backlog: El Product Goal
Como todos los artefactos en Scrum, el Product Backlog también contienen un compromiso asociado. El compromiso del Product Backlog es el Product Goal (u “Objetivo del Producto” en español).
El Product Goal describe un estado futuro del producto que puede servir como un objetivo para que el Scrum Team planifique. El Product Goal está en el Product Backlog. El resto del Product Backlog emerge para definir “qué” cumplirá con el Objetivo del Producto.
En la guía Scrum 2020 podemos encontrar la siguiente declaración:
Un producto es un vehículo para entregar valor. Tiene un límite claro, personas interesadas conocidas, usuarios o clientes bien definidos. Un producto puede ser un servicio, un producto físico o algo más abstracto.
Cada Sprint debería acercar el producto al Product Goal. El progreso hacia el Product Goal se analiza durante la revisión del Sprint.
El Objetivo del Producto es el objetivo a largo plazo del Scrum Team. Ellos deben cumplir (o abandonar) un objetivo antes de asumir el siguiente.
¿Quién estima los ítems del Product Backlog?
Los Developers son los responsables de proporcionar todas las estimaciones. El Product Owner podría influenciar al Equipo ayudándoles a entender y seleccionar el Objetivo del Sprint,
pero las personas que harán el trabajo son las que hacen la estimación final. Dejar que las personas comprometidas con el trabajo real hagan la estimación. En el sentido de Scrum, son los cerdos los que estiman, no las gallinas. Recordemos el patrón de Estimación Ágil: Los Cerdos Estiman.
Ejemplo de un Product Backlog
¿Cómo priorizar el BACKLOG?
El Product Owner ordena los PBI en busca de generar ROI (retorno de inversión) a largo plazo. Para ello debe considerar tanto los ingresos como los costos de cada ítem. El Product Owner, dueño del producto, tiene el poder para tomar decisiones en nombre de todos los stakeholders, aunque debería considerar todas las ideas y pedidos para de todos ellos para equilibrar la ecuación de valor.
Me parece interesante aclarar en este punto que el ROI no tiene que ser solo relacionado al dinero, sino que se trata de valor: El valor no solamente es el que comúnmente escuchamos refiriéndose al que se basa en la teoría económica del valor: intercambiar un activo por otro de igual valor.
Una empresa también puede valorar la retención de los empleados, las buenas relaciones con los clientes, una buena imagen pública o muchos otros objetivos que quedan fuera de la teoría económica del valor.
Considerando esto, podemos decir que el Product Owner debe ordenar la lista de manera tal que queden arriba los ítems que aportan mayor ROI y hacer esos primero.
¿Qué son las User Stories?
Las User Stories (o “Historias de Usuario” en español) es uno de los formatos más utilizados para redactar los Product Backlog Items (PBIs). Contienen descripciones cortas de un requerimiento escritas desde el punto de vista de la persona que lo está solicitando que por lo general es un Stakeholder o un cliente. Está compuesta por tres partes principales:
Como <tipo de usuario>, quiero <algún objetivo> para <alguna razón/propósito>.
Ejemplo:
El objetivo de usar historias escritas de esta manera es crear una conversación cara a cara sobre lo que se necesita del usuario final.
Criterios de aceptación
Una User Story también puede tener criterios de aceptación, que son las condiciones de satisfacción que ayudarán a los Developers a crear la mejor solución y poder determinar los límites del requerimiento.
Ejemplo:
- La notificación tiene que ser legible desde un teléfono celular.
- Debe expresar claramente si ese resultado significa “Aprobado” o “Desaprobado”.
- También debe incluir un enlace para ir a ver el examen en formato digital.
Principios INVEST
Los principios o criterios INVEST son una lista de 6 cualidades que nos ayudan a comprobar la calidad de una User Story:
“I”ndependent (independiente): Debe ser independiente de otras historias.
“N”egotiable (negociable): Su alcance y criterios deben ser variables. Los Developers deben poder negociar con el Product Owner estos criterios al comienzo del Sprint.
“V”aluable (valorable): Deben aportar valor real al cliente, un incremento de producto completo.
“E”stimable (estimable): Deben poder estimarse por los Developers por lo cual no deben ser demasiado grandes y debemos tener cierto conocimiento de esta a nivel negocio y técnico.
“S”mall (pequeña): Debe poder completarse dentro de un Sprint.
“T”estable (comprobable): Debe ser posible verificar que la misma está completa una vez desarrollada. Para ello debe tener claros criterios de aceptación con los cuales verificamos que esté realmente lista.
¿Cómo gestionar el Backlog con varios equipos?
Es común que varios Equipos Scrum trabajen juntos en un mismo producto. En estos casos los equipos trabajan sobre un único Product Backlog y para agrupar elementos de la lista por similitudes se suelen agregar etiquetas o atributos.
¿Qué es el Definition of Ready?
El Definition of Ready “DoR” (o Definición de Listo) es un acuerdo del Equipo Scrum para determinar si un elemento está apto para ingresar a un Sprint.
Al contrario del Definition of Done, que se aplica a elementos dentro de un Sprint en curso, el Definition of Ready apunta a elementos que están por entrar en el Sprint. Si los Developers no comprenden correctamente los PBIs el tiempo de desarrollo dentro del Sprint tiende a subir mucho y pone en peligro el cumplimiento del Objetivo del Sprint; por lo que es muy importante que se genere este acuerdo se cumpla, es decir, que no entren al Sprint PBIs que no están en estado “Ready”.
Podemos decir que el Product Backlog esta “Ready” cuando tiene suficientes PBIs en su parte superior para llenar un Sprint y que están en “Ready”.
¿Qué es el Release Plan?
El Release Plan (o Plan de Lanzamiento) es un plan que utilizamos para predecir cuándo podremos lanzar al mercado un conjunto de Incrementos de Productos que tendremos de varios Sprints con un suficiente valor para cumplir un objetivo de negocio.
Una de las preguntas que más escuchamos en cualquier proyecto es ¿cuándo va a estar listo? En cualquier momento debe ser posible calcular el trabajo total restante que hay que hacer para alcanzar el objetivo. El Product Owner es el responsable de hacer este seguimiento y lo realiza al menos una vez por Sprint en cada Sprint Review.
Para ello revisa las estimaciones de los Developers provistas para los elementos del Product Backlog y puede agrupar dichos elementos por Objetivos en base a la velocidad de su equipo. Esta información se muestra de forma transparente a todos los interesados.
Release Burndown
Si bien se ha demostrado que varias prácticas de proyección para predecir el progreso como el burn-down y burn-up release y el flujo acumulado son muy útiles no reemplazan la importancia del empirismo. En entornos complejos se desconoce lo que ocurrirá. Solo lo que ya ha ocurrido puede utilizarse para la toma de decisiones.
El PRODUCT BACKLOG y el SPRINT BACKLOG
El Sprint Backlog es otro artefacto de Scrum que se crea durante el Sprint Planning y se compone de los elementos del Product Backlog de la parte superior (lo más prioritario) seleccionados que se consideran necesarios a realizarse para cumplir el Objetivo del Sprint y los Developers consideran factible terminar según su velocidad y capacidad.
Para determinar cuántos PBIs incluir en el Sprint Backlog nos basamos en la velocidad de los últimos 3 Sprints de los Developers.
✅ Buenas prácticas
¿Qué es el Product Backlog Refinement?
El Product Backlog Refinement (o refinamiento) es el acto de añadir detalle, estimaciones y orden a los elementos de la lista. Es un proceso continuo en el cual el Product Owner y los Developers colaboran acerca de los detalles de los PBI. Durante el refinamiento, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. El tiempo de esta actividad normalmente no debe consumir más del 10% de la capacidad del Sprint en curso. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Product Owner.
Los elementos que se encuentren en la parte más alta de la lista, y por ende con mayor prioridad, deben estar más detallados que los de abajo. En el refinamiento buscamos descomponer esos elementos en elementos lo más chicos posibles. Esto ayudará a los Developers a tener una mejor estimación de los mismos. El refinamiento ayuda a que los PBI cumplan con el Definition of Ready.
⛔ Antipatrones
No tener reuniones de refinamiento
El no realizar este tipo de reuniones de refinamiento hace que cuando lleguemos al Sprint Planning, los PBIs no estén “Ready” y esto nos puede llevar a que:
- El PBI de mayor prioridad es más grande que la capacidad de los Developers para un Sprint y recién en la Planning nos tendremos que poner a intentar cortarlo en partes mas chicas lo que hará dicho evento mucho mas largo e ineficiente.
- A los Developers le falta información relevante para estimar durante la Planning y el Product Owner no la tiene en ese mismo momento sino que necesita validarlo con ciertos Stakeholders. Es mejor detectar estos problemas durante las etapas de refinamiento para poder llegar a la Planning con toda la información clara y entendida por todo el Equipo. Esto ahorrará mucho tiempo de planificación.
- Encontrar dependencias de los PBIs que no podemos resolver en la misma Planning y por ende tener PBIs bloqueados.
Product Owner ausente
Es importante que el Product Owner participe de los refinamientos, ya que como vimos más arriba es su responsabilidad el contenido y ordenamiento del Product Backlog. Si no esta presente se podrán tomar muy pocas decisiones o decisiones que luego las cambie, lo que implica re-trabajo.
Product Owner estima los PBIs
Quien tiene esta responsabilidad son los Developers.
PBIs que indican el CÓMO
Muchas veces notamos que el Product Owner define reglas dentro de los PBIs (o historias de usuario) indicando a los Developers cómo debe realizarse esa funcionalidad. Acá vale recordar que uno de los valores que tenemos en Scrum es el foco y también se aplica a los roles en Scrum. Cada rol tiene su foco y en este caso el Product Owner es el responsable del QUÉ y los Developers del CÓMO. Si el Product Owner empieza a definir el cómo, los Developers tienen a perder motivación, principalmente por falta de maestría en su trabajo. Otra consecuencia de ésto es que los Developers no generan aprendizaje sobre el feedback del cliente ya que no están comprometidos con la solución porque no fueron ellos quienes tomaron las decisiones de cómo resolver el problema.
Si le dices a la gente a donde ir pero no cómo llegar allí, los resultados te sorprenderán.
General George S. Patton
Conclusiones
Como hemos visto, el Product Backlog es un artefacto clave dentro de Scrum y es la principal herramienta que tiene el Product Owner para maximizar el valor del Producto. Si tenés alguna duda o consulta dejamela en los comentarios.
Pase mis últimos 10 años trabajando tanto en start-ups como empresas internacionales con equipos utilizando y escalando Scrum como marco principal e impulsando cambios a nivel cultural alineados con la Agilidad.
Durante los últimos 3 años dicté más de 70 entrenamientos y capacité a más de 1800 personas en Scrum y Agilidad.
Estoy certificado como Registered Scrum Trainer (RST) por Jeff Sutherland, cocreador de Scrum y cuento además cuento con las certificaciones RSM, RPO de Scrum Inc. y CSP-SM, CSP-PO, CSD y CAL de Scrum Alliance.
sin dudas, muy valioso el punto de vista del articulo!
Muchas gracias Seba!
Muy claro.
Tengo una duda, como se hace saber esa fecha de release? Por ejemplo: El producto se compone de 3 partes: una API, un backend y una app mobile. Entiendo que el product backlog se va haciendo mientras se va refinando, sin embargo, como puedo en un inicio saber cuando tendré el 20% que de mayor valor al producto?
Hola Fede, gracias por tu comentario. Muy buena tu pregunta, lo primero a considerar es priorizar por valor de negocio qué funcionalidad es la que te dará mayor retorno de inversión. Luego atacar esa funcionalidad primero haciendo un corte vertical, es decir, lograr tener esa/s funcionalidad que está con prioridad 1, funcionalidad con backend, frontend (o mobile) y api (en lugar de corte horizontal, por ejemplo haciendo una super API, segura pasando todos los criterios OWASP y super escalable pero sin front ni back, y que los interesados no puedan aportar un feedback sobre si esa funcionalidad sigue siendo importante para ellos y quizás por donde eligen seguir trabajando). Además cortar de esta manera reduce muchos riesgos a futuro y ayuda a estimar mejor las siguiente funcionalidades. Espero ayude mi respuesta. Voy a tratar de escribir sobre cómo cómo priorizar el backlog y sobre cómo realizar los cortes de manera vertical en lugar de horizontal.
No sé si eso responde lo que Federico te preguntaba.
Su duda es también mía, y tiene que ver con la eterna contradicción de cómo anticipar (al cliente sobre todo) fechas en un contexto ágil. Porque hagas corte horizontal o vertical, la reevaluación constante de prioridades hará que los 3 (según el ejemplo) grupos de funcionalidades sean variables, y la fecha de release que yo hoy dé por el top 20% de cada funcionalidad no sea verdadera en un mes, cuando por ROi o algún tipo de conveniencia se haya decidido priorizar un set diferente de PBIs para una o las tres funcionalidades. O me equivoco?
La alternativa que pienso mientras escribo es acordar una fecha de release con la foto en un momento, y consensuar con el cliente cómo quiere seguir, esto es, si con la reevaluación constante acepta que esa fecha pueda moverse, o si prefiere que cualquier enroque de PBIs que se pueda llegar a hacer asegure siempre que se cumpla con la fecha de reléase acordada al ppio, asumiendo que por ello algo de lo que él espere con urgencia podría no llegar a hacerse para el fin del reléase.
Excelentes estos papers by the way.
Muchas gracias por el comentario y el feedback. Voy a estar escribiendo un artículo sobre cómo podemos definir las fechas y armar el plan de entregas según estas dos miradas
Excelente , a leer ese articulo de fechas y entregables .. gracias
Me quedaron una dudas, entonces ¿quién es el responsable del DoR y el DoD? ¿El PO o el Dev Team?
Hola Hugo, espero que estés muy bien. En el caso del DoR lo recomendable es que el equipo completo lo acuerde. El el caso del DoD por lo general lo define y va iterando los Developers. En el caso que haya varios equipos trabajando en el mismo prducto, deben acordar a un mismo DoD.
Hola, tengo una duda. Quien es el encargado de escribir las historias de usuario, el PO o el scrum master? El Scrum master interviene en algún momento en el product backlog ? Como?
Dentro de las responsabilidades del Product Owner se encuentran 1) Crear y comunicar claramente los elementos del Product Backlog 2) Ordenar elementos del Product Backlog y 3) asegurar que el Product Backlog sea transparente, visible y comprensible. El Scrum Master puede ayudar al Product Owner a encontrar técnicas para la definición efectiva del Objetivo del Producto y para la gestión del Product Backlog.