Crear el Backlog Priorizado del Producto
En este proceso se refinan y se crean las épicas, y después se priorizan para crear un Backlog Priorizado del Producto para el proyecto. En este punto también se establecen los criterios de terminado.
Métodos de priorización de historias del usuario
A continuación, se presentan algunas de las técnicas que se utilizan para dar prioridad a las historias de usuarios o requerimientos en el Backlog Priorizado del Producto sobre la base del valor de negocio:
- Esquema de priorización MoSCoW: El esquema de priorización MoSCoW obtiene su nombre de la versión en inglés de las frases: “Debe tener” (Must have), “Debería tener” (Should have), “Podría tener” (Could have) y “No tendrá” (Won’t have). Las etiquetas están en orden de prioridad decreciente con historias de usuario con características de “debería tener”, siendo aquellas sin las que el producto no tendrá valor, e historias de usuarios con características de “gustaría que tuviera” siendo aquellas que, a pesar de que sería bueno tener, no se es necesario incluir.
- Comparación por pares: En esta técnica, la comparación por pares (Paired Comparison) es una técnica donde se prepara una lista de todas las historias de usuario en el Backlog Priorizado del Producto. Después, cada historia de usuario se toma en forma individual y se compara con otras historias en la lista, una a la vez. Cada vez que se comparan dos historias de usuario, se toma una decisión en cuanto a cuál de las dos es más importante. Por medio de este proceso, se puede generar una lista priorizada de historias de usuario.
- El método de los 100 puntos: El método de los 100 puntos (100-Point Method) fue desarrollado en el 2003 por Dean Leffingwell y Don Widrig. Dicho método implica otorgar 100 puntos al cliente a fin de que los pueda utilizar para votar por las características que consideren más importantes. El objetivo es dar más peso a las historias de usuarios que son de mayor prioridad en comparación con las otras historias de usuario disponibles. Cada miembro del grupo asigna puntos a las diversas historias de usuarios, dando más puntos a las que opinan son más importantes. Al finalizar el proceso de votación, la priorización se determina calculando el total de puntos asignados a cada historia de usuario.
Backlog priorizado del producto
El Dueño de Producto desarrolla un Backlog Priorizado del Producto que contiene una lista priorizada de los requerimientos del negocio y de los proyectos escritos en forma de épica(s), que son historias de usuario de alto nivel. El Backlog Priorizado del Producto se basa en tres factores principales: valor, riesgo o incertidumbre y dependencias. También se le conoce como Backlog Priorizado del Producto del riesgo ajustado, ya que incluye riesgos identificados y evaluados relacionados al proyecto.
- Valor: Es la responsabilidad del Dueño de Producto asegurar primero la entrega de los productos que ofrezcan el mayor valor. Incluso un producto de gran valor no puede ser parte del primer lanzamiento si hay otros productos de mayor valor que son suficientes para un primer lanzamiento.
- Riesgo o incertidumbre: Entre mayor incertidumbre exista, más riesgoso es el proyecto. Por lo tanto, es importante que se les dé mayor prioridad a los productos de mayor riesgo en el Backlog Priorizado del Producto. Los productos que llevan un mayor nivel de riesgo también requerirán acciones de mitigación de riesgos. Cuando estas acciones se priorizan en comparación al backlog, el resultado es un Backlog Priorizado del Producto del riesgo ajustado. Tratar con riesgos al principio del proyecto no garantiza que el proyecto tenga éxito, pero sí mejorará la capacidad del equipo para hacer frente a los riesgos.
- Dependencias: Generalmente no es posible crear un Backlog Priorizado del Producto donde no existen dependencias entre las historias de usuarios. Los requerimientos funcionales a menudo dependen de otros requerimientos funcionales, incluso los no-funcionales. Estas dependencias afectan la forma en que se priorizan las historias de usuario en el Backlog Priorizado del Producto. Existen 2 formas comunes para resolver las dependencias:
- Dividir una sola historia en varias partes
- Combinar historias interdependientes
- Dependencias: Generalmente no es posible crear un Backlog Priorizado del Producto donde no existen dependencias entre las historias de usuarios. Los requerimientos funcionales a menudo dependen de otros requerimientos funcionales, incluso los no-funcionales. Estas dependencias afectan la forma en que se priorizan las historias de usuario en el Backlog Priorizado del Producto. Existen 2 formas comunes para resolver las dependencias:
Criterios de terminado
Los criterios de terminado son un conjunto de reglas que se aplican a todas las historias de usuarios. Es importante contar con una definición clara de terminado, ya que elimina la ambigüedad de los requisitos y ayuda a que el equipo se apegue a las normas obligatorias de calidad. Esta clara definición se utiliza para crear los criterios de terminado, que son un resultado del proceso de Crear el Backlog Priorizado del Producto. Una historia de usuario se considera terminada cuando se demuestra al Dueño de Producto y es aprobada por este, quien juzga con base a los criterios de terminado y a los criterios de aceptación de las historias de usuario.
Ejemplo:
Proyecto: Diseñar las nuevas variantes de un popular auto deportivo en la empresa LRA, S.A.
Criterios de terminado:
-El diseño es aprobado por la división de Excelencia Técnica.
-El prototipo pasa todas las pruebas de túnel de viento por instrucciones por la división de Aerodinámica.
-El diseño es aprobado para la producción por la división de Propiedad Intelectual.
-Las expectativas de diseño de seguridad son corroboradas en el informe de Diseño de Seguridad de la División de Seguridad.
-El informe de estimación de costos del diseño es aprobado por la división de finanzas.
Realizar la planificación del lanzamiento
En este proceso el equipo principal de Scrum revisa las historias de usuario en el Backlog Priorizado del Producto para desarrollar un cronograma de planificación del lanzamiento, que es esencialmente un programa de implementación por fases que se puede compartir con los interesados del proyecto. En este proceso también se determina la duración del sprint.
Sesiones de planificación del lanzamiento
Las sesiones de planificación del lanzamiento se llevan a cabo para desarrollar un plan del lanzamiento. Dicho plan define cuándo las distintas series de funcionalidades útiles serán entregadas al cliente. En Scrum, el objetivo principal de una sesión de planificación de lanzamiento es hacer que el Equipo de Desarrollo cuente con una visión general de los lanzamientos y del calendario de entrega del producto que están desarrollando para que puedan alinearse con las expectativas del Dueño de Producto y los interesados relevantes (principalmente el patrocinador. Muchas organizaciones tienen una estrategia relacionada al lanzamiento de los productos, otras prefieren un despliegue continuo, donde se produce un lanzamiento después de la creación de la funcionalidad útil especificada. Algunas otras, prefieren un despliegue por etapas, donde los lanzamientos se hacen en intervalos predefinidos. Dependiendo de la estrategia de la organización, la sesión de planificación del lanzamiento en los proyectos puede estar guiada por la funcionalidad, donde el objetivo es hacer un lanzamiento una vez que se ha desarrollado un conjunto predeterminado de funcionalidades; o bien, la planificación puede estar impulsada por la fecha en la que ocurre el lanzamiento en una fecha predefinida. Dado que el marco de referencia de Scrum promueve la toma de decisiones iterativa basada en información en vez de una planificación anticipada y detallada como en el estilo tradicional de gestión de proyectos, las sesiones de planificación de lanzamiento no necesitan un plan detallado de lanzamiento para todo el proyecto. El plan de lanzamiento puede actualizarse constantemente a medida que la información relevante está disponible.
Métodos de priorización del lanzamiento
Los métodos de priorización del lanzamiento se utilizan para desarrollar un plan del lanzamiento. Estos métodos son específicos a la industria y organización, y generalmente son determinados por la alta gerencia de la organización.
Cronograma de la planificación del lanzamiento
Un cronograma de planificación del lanzamiento (Release Planning Schedule) es una de las salidas más importantes del proceso de Realizar la planificación del lanzamiento. Un cronograma de planificación del lanzamiento indica cuáles entregables serán entregados al cliente, así como los intervalos planificados y fechas para los lanzamientos. Tal vez no exista un lanzamiento programado al final de cada iteración del sprint, en ocasiones, un lanzamiento puede planificarse después de completar un grupo de iteraciones del sprint. Dependiendo de la estrategia de la organización, las sesiones de la planificación del lanzamiento en los proyectos pueden estar guiadas por:
- La funcionalidad, donde el objetivo es la entrega una vez que se ha desarrollado un conjunto predeterminado de funcionalidades.
- La fecha, donde el lanzamiento se da en una fecha predefinida.
El entregable se debe lanzar cuando ofrezca suficiente valor empresarial para el cliente.
Duración del sprint
Con base en las diversas entradas, incluyendo los requerimientos del negocio y el cronograma de planificación del lanzamiento, el Dueño de Producto y el Equipo de Desarrollo deciden la duración del sprint para el proyecto. Una vez determinada, la duración del sprint generalmente permanece igual durante el proyecto. Sin embargo, la duración del sprint puede cambiar si lo consideran apropiado el Dueño de Producto y el Equipo de Desarrollo. A principios del proyecto se puede seguir dando la experimentación para encontrar la mejor duración del sprint. Si más adelante en el proyecto hay un cambio en la duración del sprint, normalmente significa que se puede reducir debido a mejoras en el entorno del proyecto.
Si los requisitos del proyecto son generalmente estables y no se esperan grandes cambios en un futuro próximo, la duración de un sprint se puede ajustar de 4 a 6 semanas. Esto les proporciona estabilidad a los miembros del Equipo de Desarrollo para trabajar en los requisitos del Backlog Priorizado del Producto durante largos periodos de tiempo sin tener que pasar por los procesos de Crear historias de usuario, Estimar historias de usuario y Comprometer historias de usuario, Identificar tareas, Estimar tareas y otros procesos relacionados que se llevan a cabo para cada sprint.
Sin embargo, si los requisitos del proyecto no están muy bien definidos, o si se esperan cambios considerables en un futuro inmediato, la duración del sprint puede ser relativamente corta, de 1 a 3 semanas. Esto les brinda estabilidad a los miembros del Equipo de Desarrollo para trabajar en sprints más cortos y entregar resultados, los que se pueden evaluar por el Dueño de Producto y los interesados al final del sprint. Esto también proporciona la flexibilidad suficiente para que puedan aclarar los requisitos y realizar cambios en el Backlog Priorizado del Producto al final de cada sprint.
Sin embargo, es importante tener en cuenta que el cambio esperado no es el único factor que se utiliza para determinar la duración del sprint. Otros factores que también deben tomarse en cuenta son:
- El tiempo real para realizar su trabajo (si el proyecto o entorno corporativo necesita un tiempo específico para realizar tareas de forma, eso podría determinar la duración del sprint).
- La fecha prevista para su lanzamiento (la duración del sprint debe tener en cuenta las fechas de lanzamiento para el producto o el servicio en general).
- Cualquier otro factor que determine el Dueño de Producto o el Scrum Master que deben tenerse en cuenta al determinar la duración del sprint.