Refinamiento del Product Backlog.
El refinamiento del Product Backlog es el acto de añadir detalle, estimaciones y orden a los elementos del Product Backlog . Se trata de un proceso continuo, en el cual el Product Owner y el Development Team colaboran acerca de los detalles de los elementos del Product Backlog . Durante el refinamiento del Product Backlog, se examinan y revisan sus elementos, el Equipo Scrum decide cómo y cuándo se hace el refinamiento, este usualmente consume no más del 10% de la capacidad del Development Team.
Sin embargo, los elementos del Product Backlog pueden actualizarse en cualquier momento por el Product Owner o a criterio suyo.
¿Cuándo hacer Refinamiento?.
- Descubrimiento de nuevos elementos, cambio o eliminación de existentes.
- Priorización de elementos.
- Descomposición de elementos que se implementarán en el siguiente Sprint.
- Estimación de tamaño de elementos nuevos o corrección de tamaño de elementos existentes.
- Comunicación cara a cara
Los elementos del Product Backlog de orden más alto son generalmente más claros y detallados que los de menor orden.
Se realizan estimaciones más precisas basándose en la mayor claridad y detalle; cuanto más bajo es el orden, menor es el detalle. Los elementos del Product Backlog de los que se ocupará el Development Team en el siguiente Sprint tienen una granularidad mayor, habiendo sido descompuestos de forma que cualquier elemento puede ser terminado dentro de los límites del bloque de tiempo del Sprint.
Los elementos del Product Backlog que pueden ser terminados por el Development Team en un Sprint son considerados “preparados” o “accionables” para ser seleccionados en una reunión de Planificación de Sprint.
Los elementos del Product Backlog normalmente adquieren este grado de transparencia mediante las actividades de refinamiento descritas anteriormente.
El Development Team es el responsable de proporcionar todas las estimaciones. El Product Owner podría influenciar al Equipo ayudándoles a entender y seleccionar soluciones de compromiso, pero las personas que harán el trabajo son las que hacen la estimación final.
En cualquier momento, es posible sumar el trabajo total restante para alcanzar el objetivo.
El Product Owner hace seguimiento de este trabajo restante total al menos en cada Revisión de Sprint.
El Product Owner compara esta cantidad con el trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del trabajo proyectado en el tiempo deseado para el objetivo.
Esta información se muestra de forma transparente a todos los interesados. Varias prácticas de proyección sobre tendencias se han utilizado para predecir el progreso, como trabajo consumido (burndown), avanzado (burnup) y flujo acumulado (cumulative flow); estas se han revelado como útiles, sin embargo, no remplazan 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 con miras al futuro.
Priorización Basada en el Valor.
El marco de Scrum es impulsado por el objetivo de ofrecer el máximo valor empresarial en un periodo de tiempo mínimo.
Factores de la Priorización.
El Product Owner (PO) debe de traducir las entradas y las necesidades de los proyectos de los Stakeholders para crear el Prioritized Product Backlog. Por lo tanto, se prioriza basado en la creación de valor, y se hace teniendo en cuenta que:
- Se liberen primero los elementos de mayor valor.
- Se evalúe si el elemento es realmente requerido.
- Se evalúen alternativas con menor tiempo/costo.
Priorizando Elementos.
- Responsabilidad del Product Owner.
- Es recomendado el involucramiento de todo el Scrum Team.
- Permite retrasar las decisiones sobre los elementos de menor prioridad.
- Se considera el valor, el conocimiento, la incertidumbre, el riesgo, la posibilidad de liberación y las dependencias.
- Se pueden agrupar elementos del Product Backlog para facilitar la priorización.
Conocimiento, incertidumbre y riesgo:
- Entre menos conozcamos sobre un producto mayor incertidumbre se tiene.
- A mayor incertidumbre mayor es el riesgo.
- Los elementos inciertos y de alto riesgo, deben tener alta prioridad.
Posibilidad de liberación:
- La habilidad para liberar incrementos de producto temprana y frecuentemente debe influenciar las decisiones de priorización.
Dependencias:
- Las dependencias entre algunos elementos del Product Backlog no se podrán evitar.
- Los elementos de los que se depende deben ser implementados primero.