Cuarto principio: Priorización basado en valor al negocio
El concepto de priorización no es nuevo para la gestión de proyectos, en el modelo predictivo se propone el uso de múltiples herramientas de priorización, entre ellas priorizar los objetivos en base a costo, tiempo y alcance, para saber, en caso de que se tenga que mover alguno de estos elementos, a cuál darle mayor importancia.
El marco de referencia de Scrum se guía por la finalidad de ofrecer el máximo valor empresarial en un mínimo período de tiempo, y una de las herramientas más eficaces para entregar el mayor valor en el menor tiempo posible es la priorización. Scrum utiliza la priorización basada en valor (Value-based Prioritization) como uno de los principios básicos que impulsa la estructura y funcionalidad de todo su marco de referencia, cuya finalidad es entregar un producto o servicio valioso para el cliente en forma oportuna y continua.
Es responsabilidad del Dueño de Producto priorizar la lista de los requisitos necesarios para llevar el proyecto con éxito. Él recibe todos los requerimientos del negocio del cliente y los escribe en forma de historias de usuario viables, y trabaja con el cliente y el patrocinador para entender los requerimientos del negocio que proporcionan el máximo valor empresarial. El Dueño de Producto tiene que comprender lo que quiere el cliente y valorar para organizar las historias de usuario, según su importancia relativa. En ocasiones, un cliente puede ordenar que todas las historias de usuario sean de alta prioridad. Aunque este pudiera ser el caso, incluso una lista de alta prioridad de historias de usuario también debe ser priorizada dentro de la lista misma, esto implica determinar la importancia de cada historia de usuario e identificar los requisitos de alto valor.
Al mismo tiempo, el Dueño de Producto debe trabajar con el Equipo de Desarrollo para entender los riesgos y la incertidumbre del proyecto, ya que estos pueden tener consecuencias negativas. Esto riesgos se deben de tener en cuenta al priorizar las historias de usuario con enfoque basado en el valor. En este proceso, el Equipo de Desarrollo también es responsable de notificar al Dueño de Producto sobre las dependencias que surgen de la implementación, las cuales deben tenerse en cuenta durante la priorización. Esta puede basarse en una estimación subjetiva del valor proyectado del negocio o la rentabilidad, o puede basarse en los resultados y análisis del mercado utilizando herramientas, incluyendo, pero sin limitarse a, entrevistas del cliente, encuestas y modelos financieros y técnicas analíticas.
Esta priorización se registra en el documento llamado Backlog Priorizado del Producto, considerando las siguientes variables:
- Valor
- Riesgo o incertidumbre
- Dependencias
De esta forma, la priorización resulta en entregables que satisfacen los requisitos del cliente con el objetivo de ofrecer el máximo valor de negocio en el menor tiempo posible.
Quinto principio: Time boxing
El tiempo es uno de los limitantes más importantes en la gestión de un proyecto, para hacer frente a esta restricción, Scrum introduce un concepto de Time-boxing, que propone fijar una cierta cantidad de tiempo para cada proceso y actividad en un proyecto.
Esto garantiza que los miembros del Equipo de Desarrollo no ocupen demasiado o muy poco tiempo para un trabajo determinado, y que no desperdicien su tiempo y energía en un trabajo para el cual aún no tienen claridad. Algunas de las ventajas del Time-boxing son las siguientes:
- Proceso de desarrollo eficiente
- Menos gastos generales
- Alta velocidad para los equipos
El Time-boxing puede utilizarse en muchos procesos de Scrum, por ejemplo, en el proceso de Realizar Daily Standup, la duración de dicha reunión tiene un time-box asignado. También puede utilizarse para evitar la mejora excesiva de un elemento (por ejemplo, hacer chapa de oro, término que indica la incorporación de características o refinamientos costosos e innecesarios en un producto o servicio).
Time-boxes de Scrum
El marco de referencia de Scrum sugiere utilizar los siguientes time-boxes:
Sprint
El Sprint es el corazón de Scrum. Es un bloque de tiempo de un mes o menos, en el cual se crea un Incremento de producto “Terminado” utilizable y potencialmente desplegable.
Es altamente recomendable que los Sprints tengan siempre la misma duración, pero no es obligatorio. Cada Sprint comienza inmediatamente después de la finalización del Sprint anterior.
El Sprint es un bloque de tiempo contenedor que incluye a los demás eventos de Sprint, de la siguiente forma:
El Sprint se limita a un mes de duración debido a que, si el Sprint es demasiado largo, la definición de lo que se está construyendo podría cambiar. No hay que olvidar que los problemas complejos no se conocen completamente, por lo que se aprende a lo largo de su realización y los cambios pueden ser frecuentes; una duración reducida del Sprint ayuda a que los cambios sean asimilados de mejor forma.