Desde el 2011 la guía de scrum presentó un interesante cambio, pasó de definir que el backlog debía ser priorizado a que el backlog debe ser ordenado. Y todo esto ¿Por qué?
Fuente: https://www.scrumguides.org/revisions.html
Según la scrum.org, el cambio fue para darle más flexibilidad al Product Owner a la hora de maximizar el valor según sus propias y únicas circunstancias.
¿Qué significa esto?
No quiere decir que lo hayamos estado haciendo mal pero este cambio obedece a clarificar la actividad que realiza el Product Owner y lo que debe reflejar el Product Backlog. El Product Backlog debe reflejar el orden en que entregaremos elementos que maximizan el valor de lo trabajado por el equipo. Por ende, la labor del Product Owner es mantener esta lista ordenada.
Al decir priorizar se podía confundir con que en el backlog iba primero lo más “importante”, usualmente esta priorización se hace usando el modelo Kano o MoSCoW. Los criterios para priorizar en MoSCoW y Kano podían basarse en el ojo de experto del PO, lo que los stakeholders quieren, etc. La limitación que se encontró es que no necesariamente lo que el PO considera prioritario se debe o puede hacer primero. Cuando se dice “vamos a priorizar el backlog” se puede encontrar que el negocio dice “Todo es importante”, “No me hagas decidir” o 90% de las funcionalidades son importantes. Es decir, la técnica no nos estaba ayudando a lograr el orden en que se construirá el producto. Identificar lo prioritario no implica que sea lo primero que se construirá.
Algo que me ayudó a entender mejor esto fue que luego de una sesión en la que se prioriza el backlog. Se usó la técnica MOSCOW y se tenían clasificadas las historias por Must, Have, Should and Could. El momento de descubrimiento fue cuando al planificar nos dimos cuenta de que muchas de las Must no podían realizarse aún pues se requerían de algunas historias habilitadoras que se encontraban en Should o Could. Ahí nos dimos cuenta de que la priorización no es el único factor a usar, pero sí puede contribuir en el ordenamiento.
Una analogía que podemos usar de ejemplo es cuando queremos diseñar nuestra casa de ensueño probablemente para algunos será prioridad tener una habitación amplia y una piscina. Pero, no necesariamente se comenzará a construir en ese orden.
Podemos deducir que si priorizamos el backlog respondemos a la pregunta ¿Cuáles son las necesidades más importantes? (Agregan valor y no debemos descuidar), mientras que si usamos un enfoque de ordenamiento buscaremos responder a la pregunta ¿Qué deberíamos hacer primero?.
¿Qué otros factores influyen para ordenar un backlog?
Algunos que he podido identificar y recopilar de diversos autores son:
- Valor de negocio, ¿Cuánto está dispuesto a pagar el cliente por esta funcionalidad?.
- Riesgo, ¿Cuál es el riesgo de implementar estas historias después?.
- Aprendizaje, ¿Que aprenderemos de esta historia que ayude a ser más eficientes en otras?.
- Cost of Delay (Costo de retraso), ¿Cuánto nos cuesta dejar esta historia para después?
- Tiempo de Aplicación, ¿Cuánto demoramos en ver los resultados de esta historia?.
- Tiempo, ¿Cuánto demoramos en implementar la historia?.
Como podemos ver existen muchos factores que pueden afectar el orden en que trabajaremos y que nos permita maximizar el valor que entregamos.
¿Te interesa saber cómo dar un numero a estos factores y así facilitar el ordenamiento del backlog?.
Déjame saberlo en los comentarios para elaborar una explicación de cómo estos factores se aplican a la hora de ordenar el backlog.
Gracias por leer este articulo.
Quedo atento a tus comentarios o dudas que me permitan mejorarlo.
No olvides suscribirte para tener en tu correo los próximos artículos.
Si deseas contactarme dale clic a la imagen de la lado
