Priorización y objetivos a mediano plazo
En otro artículo del blog ya escribí sobre cómo podemos priorizar en nuestra vida privada mediante "Ahora" y "Después". Las compras planificadas no se clasifican en categorías como: ¿Qué necesitamos comprar? ¿Qué deberíamos comprar? ¿Qué podríamos comprar y qué no vamos a comprar en absoluto? A continuación, explicaré cómo implementar fácilmente la planificación con "Ahora" y "Después" y cómo trabajar simultáneamente hacia una visión más amplia del producto.
Una visión a mediano plazo del producto (aproximadamente tres meses) ha demostrado ser bastante útil. Al comienzo de un nuevo trimestre, el Product Owner debe establecer un objetivo y decir: "Quiero haber alcanzado este punto en tres meses". Este objetivo se establece junto con el equipo y los stakeholders. Sin embargo, la visión final de un producto recae únicamente en el Product Owner.
El Product Owner no debe aferrarse demasiado a esta visión; también puede modificarse. Pero sin un objetivo temporal claro, los temas urgentes que surgen justo antes de las reuniones de Sprint Planning influirían rápidamente en la priorización. Sin una visión clara, los temas urgentes siempre recibirían más atención que los temas estratégicamente importantes.
¿Qué factores debo considerar?
Cuando tengo que decidir entre diferentes ideas para una visión a mediano plazo, prefiero hacerlo de manera formal, de modo que pueda explicar y justificar mi decisión. Uno debería poder decir: "He decidido concentrarme en esto en lugar de en otra cosa" y presentar los hechos en los que se basó esa decisión.
Sin embargo, el Product Owner primero debe clasificar las User Stories al comienzo de cada Sprint en "Ahora" o "Después". Esto ayuda a decidir en qué ítems trabajar en el próximo Sprint. En lugar del enfoque formal y bien explicable, el Product Owner debe considerar los siguientes cuatro puntos para cada Product Backlog Item:
Qué tan valioso será el feature
El efecto de aprendizaje que se producirá con este feature
El riesgo asociado a este feature
El costo del feature
Los ítems se ordenan primero según el punto 1, es decir, por su valor. Hasta ahí, es un método de priorización muy tradicional. Sin embargo, este Backlog recién ordenado se reorganiza luego según los puntos 2 a 4. Dependiendo de cuánta influencia ejerzan estos factores, se mueven los features individuales hacia arriba. Pero primero, permitan que explique de qué se tratan estos factores:
El segundo factor se refiere a cuán grande es el efecto de aprendizaje al desarrollar un feature determinado. Esto puede significar, por ejemplo, que se aprende algo sobre la tecnología utilizada (algo no es tan sencillo como se suponía) o se descubre cómo reaccionan los usuarios ante una nueva interfaz. Si a través de un determinado Backlog Item se puede aprender algo importante, se lo mueve hacia arriba en el Product Backlog para que pueda desarrollarse en el próximo Sprint.
En cuanto al riesgo, prefiero desarrollar los features más riesgosos lo antes posible. Así se puede conocer qué impacto tiene ese riesgo. Por lo tanto, estos ítems también se incluyen en el próximo Sprint. Sin embargo, si existe la posibilidad de evitar un riesgo por completo (por ejemplo, eliminando el feature), el ítem no se incluye en el próximo Sprint. En el mejor de los casos, se puede proceder de la misma manera en los Sprints siguientes y así evitar el riesgo por completo.
El último factor se refiere a los costos. Algunos features tienden a ser más económicos si se realizan lo antes posible. Se vuelven más costosos cuanto más se posponen. Incluir estos ítems en el próximo Sprint puede mantener los costos bajos.
Utiliza estos cuatro factores para seleccionar los ítems de los próximos Sprints y crea una visión a mediano plazo (tres meses). Así podrás realizar una buena priorización de "Ahora" y "Después" para alcanzar el objetivo general.
