"The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product... The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases".
Una sutíl pero importante diferencia respecto a las primeras ediciones de la Scrum Guide es que ahora el Product Backlog es definido como una lista "ordenada" en lugar de "priorizada". En mi opinión, con esto se está reconociendo que el orden en el cual se coge el trabajo desde el Product Backlog no depende sólo de la importancia o valor del ítem de trabajo, sino que existen además otros factores que pueden/deben ser considerados para establecer en conjunto dicho orden.
Por otra parte, también es importante destacar que el Product Backlog no sólo incluye nuevos requisitos para el producto, sino también mejoras en requisitos ya implementados, y/o correcciones de fallos. Así también, la granuralidad de los ítems en el Product Backlog puede ser muy diferente. Además, podemos encontrar en el Product Backlog ítems con una descripción muy general y/o preliminar, y otros ítems ya definidos con suficiente detalle como ser implementado. Antes de poder incluir un ítem en una iteración éste debería tener una granuralidad tal que su implementación se pueda hacer en pocos días (mi recomendación es menos de una semana).
Cuando un producto comienza a ser desarrollado, en general, no se tienen muchos ítems en el Product Backlog, siendo además la mayoría del tipo "nuevo requisito". En la medida que se realizan entregas del producto y mientras más utilización/éxito tenga, la cantidad de ítems en el Product Backlog irá incrementando y comenzarán a ser mucho más numerosos los ítems correspondientes a mejoras y correcciones de fallos. El objetivo a mediano y corto plazo NO es el vaciar el Product Backlog (dependerá de nuestra capacidad para implementar ítems y del ritmo de generación de nuevos ítems). Lo realmente importante es realizar una gestión efectiva del Product Backlog, asegurándos que en todo momento esté ordenado y preparado para coger ítems e incorporarlos en una nueva versión del producto.
A continuación, un pequeño paréntesis para comentar dos técnicas para priorización de características: el Kano Model y MoSCoW.
El Kano Model es una técnica para clasificar las características de un producto según el grado de satisfacción que generan en el cliente. En este modelo las características del producto se clasifican en:
- Dissatisfier – Must be’s – Cost of Entry
- Satisfier – More is better – Competitive
- Delighter – Latent Need – Differentiator
- M: "We MUST have this", debemos tenerla.
- S: "We SHOULD have this", deberíamos tenerla.
- C: "We COULD have this", podríamos tenerla.
- W: "WON’T have this now", ahora no la queremos pero podríamos quererla más adelante.
Estas clasificaciones nos pueden ayudar a ordenar globalmente los ítems del Product Backlog, especialmente al iniciar el desarrollo de un producto (cuando todo el contenido del Product Backlog se refiere a la incorporación de nuevos requisitos). Sin embargo, dichas clasificaciones incluyen solo tres o cuatro categorías, por esto, de todas formas habría que realizar un análisis más detallado o complementario para determinar un número de orden que diferencie en mayor medida a los ítems (que pueden ser decenas o cientos para un producto enfrentado a un intenso o continuo mantenimiento), y para pasarlos a implementación siguiendo dicho orden . Así pues, lo más adecuado en cuanto a priorización de ítems en el Product Backlog es utilizar un número de orden, el cual reflejaría una combinación de criterios aplicados para determinarlo.
... fin del paréntesis
El "Grooming del Product Backlog" se refiere al conjunto de acciones realizadas sobre el Product Backlog, ellas son:
- Preparar ítems. Para incluir un ítem en un Sprint debe estar suficientemente definido, estimado (si se trabaja con estimación de ítems) y tener un tamaño relativamente pequeño. En la medida que un ítem está en o se acerca a los primeros puestos de la lista del Product Backlog se hará más urgente que dicho ítem esté preparado.
- Poner un número de orden a un nuevos ítem. Periódicamente hay que revisar el Product Backlog para asignar un número de orden a los nuevos ítems dentro del contexto de los ya ordenados.
- Cambiar el número de orden de ítems. Los ítems se irán definiendo y estimando, entrarán nuevos ítems, y obviamente también, se podrían cambiar las prioridades en el negocio. Es importante revisar periódicamente el orden asignado por si es necesario cambiarlo.
- Seleccionar ítems del Product Backlog para incluirlos en una próxima versión del producto. Si el Product Backlog está preparado esta acción consiste simplemente en coger los primeros ítems de la lista según el número de orden y considerando el trabajo que puede ser abordado según la capacidad del equipo. Si un ítem no está adecuadamente preparado hay mayor riesgo en su implementación y consecuentemente en desajustes que pueda provocar en el Sprint o entrega.
- Desestimar o eliminar ítems. Aquellos ítems que han quedado obsoletos deben quitarse del Product Backlog. Si el ítem ya ha tenido algo de trabajo de preparación o si interesa mantener registro de la existencia del ítem, lo adecuado sería desestimarlo en lugar de eliminarlo.
- Valor, importancia o prioridad para el negocio. Este criterio a priori debería ser fácil de establecer, y consistiría en tener una correcta percepción del valor específico que aporta al cliente/usuario cada cambio en el producto. El problema es que aunque dicha percepción es correcta en un determinado momento, luego con el paso del tiempo su valor relativo puede cambiar. Muchas veces la noción de valor está ligada a qué tan reciente es la propuesta de cambio. Es por ello que las "ideas felices" conviene que reposen un tiempo en el Product Backlog para que estabilicen su valor relativo. Estudios de uso de funcionalidades en un producto suelen mostrar que algunas funcionalidades, en las cuales se invirtió mucho esfuerzo de desarrollo con la creencia que iban a ser muy utilizadas, no son prácticamente utilizadas por los usuarios. Esto es uno de los síntomas claros de errores en la valoración de los cambios en un producto.
- Frecuencia de uso de funcionalidad. Aunque este aspecto suele estar correlacionado con otros criterios, conviene evaluarlo por separado. Las funcionalidades muy utilizadas suelen ser importantes en términos de valor. Cuando se trata de un ítem de corrección de fallo, la frecuencia de uso de la funcionalidad asociada conlleva una criticidad del ítem y la correspondiente urgencia por resolver el fallo. Excepcionalmente, por ejemplo, cuando se trata de ítems diferenciadores (según la clasificación en el Kano Model), un ítem asociado a una funcionalidad poco usada puede aún ser prioritario cuando se considera además su aporte a una estrategia de marketing.
- Urgencia. Tiene más relevancia durante el mantenimiento cuando ítems de menor valor puede que tengan que implementarse cuanto antes. Por ejemplo, esto ocurre con las correcciones de fallos que tienen una alta severidad (lectura recomendada: Fallos, defectos y errores y su gestión en un contexto ágil). A veces, ciertos ítems tienen una fecha comprometida y la urgencia se ve indirectamente reflejada en el tiempo restante para que se cumpla el plazo comprometido.
- Riesgo. El riesgo está asociado al nivel de certeza que se tiene del esfuerzo asociado a un ítem. El riesgo de implementación de un ítem depende de diversos factores, tales como: la experiencia del equipo, los desafíos tecnológicos, la complejidad, el impacto de posibles fallos, etc. Los ítems con mayor riesgo pueden alterar el desarrollo del producto por esto, en general, conviene que se aborden cuanto antes.
- Esfuerzo. Frecuentemente hay ítems que independiente de otros criterios, requieren muy poco esfuerzo de implementación. Estos ítems podrían incluirse en cualquier momento en el próximo sprint (incluso añadirse directamente en el sprint actual). Al respecto, vale la pena mencionar la "Regla de los 2 minutos" de GTD (Getting Things Done de David Allen) que nos recomienda algo así como:"toda acción que se pueda realizar en menos de 2 minutos hazla ya!, gastarás más en gestionarla dentro del trabajo pendiente". Por otra parte, ítems que requieren mucho esfuerzo (denominados Epics, o Historias de Usuario Épicas) pueden requerir un particionamiento previo en sub-ítems y una organización entre ellos en términos de interdependencias. Un nuevo requisito o una remodelación de cierta envergadura puede en este sentido ser tratada como un proyecto que agrupa un conjunto de ítems (similar al término Theme) y que podría irse desarrollando a lo largo de varios sprints (aunque no se incluyan en la entrega al cliente hasta tener terminados algunos o incluso todos los ítems del proyecto). Es importante destacar que la estimación (o no estimación) de los ítems en el Product Backlog es una cuestión que debería estar decidida para cada producto o servicio encargado al equipo, y dependerá principalmente de cuán rígido se establezca el compromiso o previsión de entregas con el cliente. Además, cuando se opta por estimar, se tienen varias alternativas respecto a cómo hacerlo. Lectura recomendada: "Estimación en un proyecto ágil", Parte I y Parte II.
- Tipo de usuario al cual va dirigido el cambio asociado al ítem. Esto permite (cuando se desee) orientar una entrega hacia ciertos tipos de usuario, para esto se localizan en el Product Backlog ítems dirigidos a cierto tipo de usuario y se arma un grupo poniéndoles un número de orden igual o consecutivo para que entren juntos a un sprint.
- Origen del ítem. Aunque quien decide el contenido del Product Backlog es el Product Owner, es importante conocer cuál fue el origen del ítem. Un ítem puede ser solicitado por una determinada persona de contacto en un cliente donde está instalado el producto o incluso por algún miembro del equipo. Las solicitudes (y correspondientes ítems) pueden tener mayor o menor prioridad dependiendo de quien realiza la solicitud. Con esta información y de forma estratégica se puede hacer un "gesto" de servicio hacia un determinado solicitante.
- Tipo del ítem. Básicamente la clasificación podría ser: Nuevo Requisito, Mejora, Corrección de Fallo y Otros. En el caso de Correcciones de Fallos, es útil también conocer la severidad del fallo, si existe un atajo o workaround y la versión desde la cual está presente dicho fallo. lectura recomendada "Fallos - Defectos - Errores y su gestión en un contexto ágil".
- Parte de la estructura del producto que se verá afectada por el ítem. Es importante conocer las partes del producto que se verán afectadas por el ítem. El análisis de impacto del cambio parte precisamente del conocimiento de esta información. Además, cuando se va a decidir realizar un cambio en una parte del producto podrían "de paso" hacerse otros cambios pendientes, o por el contrario, el ítem podría postergarse para cuando se pudiesen hacer más cambios en conjunto en la misma área.
- Proyecto. Como se comentó antes en el factor Esfuerzo, los ítems de gran tamaño pueden dividirse y organizarse en proyectos que duran varias iteraciones. En este caso es importante reconocer fácilmente cuáles ítems pertenecen a un mismo proyecto y convenientemente agruparlos asignándoles el mismo número de orden o números consecutivos según se desea que se cojan para ser incluidos en un sprint.
- Relaciones de dependencia entre ítems. Si un ítem requiere de otro para su implementación es necesario que este último se implemente primero, es decir, que tenga un número de orden menor o igual. Al cambiar el número de orden de un ítem se debe verificar que no se producen inconsistencias respecto de las dependencias asociadas al ítem.
- Fecha de creación del ítem. Normalmente los ítems más nuevos suelen tenerse más presente que otros más antiguos. Por otra parte, revisando los ítems más antiguos se puede detectar que ya están obsoletos. También es importante la fecha de creación para asegurar, en lo posible, una no postergación indefinida de un ítem.
- Fecha de límite. Se refiere a la fecha límite para entregar el ítem. Es acordada con el cliente, y puede ser necesaria cuando en el producto o servicio NO se trabaja con sprints o proyectos (los cuales ya conllevarían una fecha de entrega para el ítem).
- Estado de preparación del ítem. Es importante conocer si el ítem ya está definido o en general, qué tan preparado está el ítem para poder ser incluido en el próximo sprint.
La visualización del Product Backlog (y del contenido de cualquier Sprint) es otro aspecto importante. La opción más utilizada es tener una lista con facilidades para aplicar ordenamientos y filtros según los criterios indicados antes. En nuestro enfoque y herramienta TUNE-UP (www.tuneupprocess.com), además de dicha tradicional lista, hemos incorporado otras dos opciones: una lista de las relaciones de entre los ítems de trabajo dentro del Product Backlog (o dentro del Sprint) incluyendo también relaciones con otros ítems en otros Sprints, y una vista que muestra un un grafo que representa la estructura del producto, remarcando las partes que son afectadas por los ítem dentro del Product Backlog (o dentro de un Sprint). La siguiente figura muestra esta vista, en la cual se ha seleccionado el nodo "Product Graph" y en el grid de la derecha se remarcan los 2 ítem de trabajo que afectan a dicho nodo en la versión 1.2.9, además de mostrar todos los ítems de trabajo que han afectado o afectarán a dicho nodo.
Patricio Letelier
linkedin.com/in/letelier
agilismoatwork.blogspot.com
www.tuneupprocess.com
Muy buen artículo, hay una buena bajada a tierra de como debe gestionarse un backlog de producto y me ha sido de mucha utilidad.
ResponderEliminarGracias.