Cómo priorizar el backlog en Metodologías Ágiles

Las metodologías ágiles proponen capturar los requerimientos desde la perspectiva del usuario .Los requerimientos ágiles son expresados a través de UserStories(US), las cuales tienen un formato en particular:

Como <rol> quiero <funcionalidad> para lograr <objetivo>.

Sin embargo, una vez descrito el comportamiento esperado del sistema en un conjunto de UserStories (denominado backlog) existe un problema a resolver: en qué orden se irán implementando cada una de ellas, es decir, por dónde arrancar.

Existen distintos factores y dimensiones a considerar

• Tiempo
• Esfuerzo
• Valor Funcional
• Opinion de los stakeholders,
• Opinion del equipo de desarrollo
• Valor de Mercado, y seguramente varios más.

A partir de los mismos han surgido distintas técnicas para priorizar los UserStories del backlog.

Las siguientes describen algunas de las técnicas más comúnmente utilizadas [1,2]. Para facilitar la comparación, se introduce un pequeño ejemplo de un backlog. El mismo luego será priorizado según la visión de cada técnica. El ejemplo consiste en una aplicación de comercio electrónico, con las siguientes UserStories:

US-01. Como usuario registrado quiero poner artículos en el carrito de compras para armar mi pedido.

US-02. Como dueño del comercio quiero que las personas puedan recorrer el sitio sin estar registradas para facilitar la visibilidad del mismo.

US-03. Como dueño del comercio quiero que únicamente los usuarios registrados puedan realizar compras para lograr fidelidad.

US-04. Como jefe de finanzas quiero que los pagos con tarjeta de crédito sean seguros para evitar fraudes.

US-05. Como usuario registrado quiero hacer “check-out” del carrito para finalizar mi pedido.

US-06. Como jefe de marketing quiero que sea sencillo e intuitivo agregar          productos al carrito para que los usuarios les resulte atractiva la página.

US-07. Como jefe de marketing quiero que los usuarios puedan realizar búsquedas para que puedan encontrar los productos que desean.

Técnica Business Value&StoryPoints

Esta técnica proponer priorizar las UserStories basándose en factores como el esfuerzo y la opinión del ProductOwner, del cliente y del equipo de desarrollo, o incluso combinándolas. ElBusiness Value es un valor númerico asignada a cada UserStory (US) donde a más alto el valor, mayor valor para el cliente.

Entonces una manera de priorizar el backlog sería utilizando el Business Value de las US. Sin embargo, llevarlo acabo de manera “aislada” puede traer problemas.

Uno de ellos radica en que el cliente muchas veces se deja llevar por detalles superfluos y esto puede llevar a dejar de lado funcionalidad realmente importante.

Otro problema es que no se considera el esfuerzo que lleva implementar cada US. Esto último puede resolverse con StoryPoints, que son valores numéricos que introduce el equipo de desarrollo estimando el esfuerzo que le llevará desarrollar cada US. Luego, una manera inteligente de priorizar el backlog es utilizando el cociente Business Value/StoryPoints. Es decir, lo más sencillo de implementar que devenga en mayor interés para el usuario. Para ilustrar esta técnica, suponer los siguientes valores para las US del ejemplo:

Dados estos valores, el equipo de desarrollo dará más prioridad a las US #01 y #05, que son las referidas al manejo del carrito. Son las US que más la interesan al usuario que implican menos esfuerzo para el equipo. Luego seguirán las US #06, US#03, y US #04, para terminar con las US #07 y #02. Es importante notar que estos valores no son fijos y se pueden actualizarse al terminar cada sprint.

Técnica Urgente

En [3] proponen priorizar el backlog utilizando dos dimensiones, pero cambian el concepto de StoryPoints por otro: la urgencia en tener lista una funcionalidad. Se introducen valores de 1 a 5, donde 5 implica que esa US debe estar lista ya o de lo contrario perderá sentido, mientras que un valor 1 indica que no hay apuro en tenerla lista. También se tienen en cuenta para este valor de urgencia si la funcionalidad tiene que estar desarrollada por cuestiones contractuales, o porque de ella dependen muchas otras US, por lo debe implementarse antes. Los Business Value siguen la misma escala y se asignan valores de 1 a 5. Obtenidas todas las asignaciones, se multiplican los valores de urgencia por los de Business Value (obteniendo números entre 1 y 25) y se ubican en una tabla como la que sigue (fuente provista, [3]):

Dada esta tabla, la priorización es evidente: primeros las US en el sector rojo, luego naranja, amarillo y finalmente las verde.

Retomando el ejemplo del comercio electrónico, se pueden asumir los siguientes valores:

US Business Value Urgencia Sector

Utilizando esta técnica, el equipo de desarrollo comenzará con la US #01, y luego atacará las US #05 y #06. Finalmente, las US #02 y #04, para terminar con las US #03 y #07. Comparado con la técnica anterior, la US #06 ha adquirido mayor prioridad, ya que con esta visión que el carrito sea sencillo de utilizar ha sido catalogado como más relevante. Razones similares pueden utilizarse para justificar la mayor prioridad de la US #02 en esta ocasión. La posibilidad de navegar el sitio para usuarios invitados ha sido clasificada con un alto valor de urgencia, por lo que ha subido su prioridad final.

Otras técnicas conocidas son:

● MoSCoW: Propone etiquetar las US con:

○ M: Esta funcionalidad debe estar (MUST).
○ S: Esta funcionalidad debería estar (SHOULD).
○ C: Esta funcionalidad podría estar (COULD).
○ W: Esta funcionalidad no estará ahora, quizás en un futuro (WON’T).

Luego, las US se llevan a cabo siguiendo esta clasificación: primero las US etiquetadas con M, luego con S, en tercer término aquellas con C y finalmente aquellas con W.

● Basados en Riesgos: Esta técnica propone simplemente hacer primero las US que involucren mayores riesgos. Lo cual implica realizar un análisis de riesgo completo antes de priorizar el backlog.

Referencias: