En el día a día de las organizaciones se realizan diferentes actividades prorizadas por cada individuo, o bien con base en el equipo que las ejecuta, es decir, con las áreas.  A pesar de que los equipos casi siempre acceden a cumplir con las fechas, horarios y prioridades (elementos que conforman los procesos de valor para el cliente), frecuentemente estas decisiones no son resultado de un proceso democrático, ya que se ejecutan porque son parte de las responsabilidades o fueron asignadas de esa forma; sin embargo, lo anterior no implica que los invocrados estuvieran de acuerdo o que concuerden los puntos de vista sobre las entregas.

En los equipos ágiles pasa todo lo contrario: la persona es responsable de gestionar sus actividades, priorizarlas y de cumplir con los objetivos. Además, el Product Owner es el dueño del Backlog, por lo que debe poner mayor énfasis en su gestión. Por estas razones, en la siguiente experiencia de aprendizaje revisarás de qué formas se puede priorizar el Backlog, cómo puede mostrarse el estatus del valor desarrollado y en proceso, cómo se determina el tamaño de cada Sprint y de qué forma se estima la capacidad del equipo. De esta manera, el Product Owner puede observar el valor que se está generando.

Priorización

La priorización consiste en determinar qué es lo más importante para el equipo e interesados del valor. Existen diferentes técnicas, aunque las más populares en los marcos de referencia ágil son las que aparecen en la figura 1.

Figura 1. Técnicas de priorización Agile más populares.

Fuente: Simplilearn. (2022). PMI-ACP Training: Agile Prioritization Techniques. Recuperado https://www.simplilearn.com/agile-prioritization-techniques-article

Cada técnica de priorización ayuda a determinar el orden del desarrollo de los elementos como parte del Sprint, esto con base en el nivel de importancia de los distintos interesados en el producto y en el valor que les proveerá; sin embargo, cada técnica lo hace de forma diferente. La elección de una estrategia estribará en los involucrados y en el nivel de dificultad que puedan encontrar en ellas. En este sentido, cabe aclarar que no hay una mejor que otra, pues dependen de la utilidad que tengan para los que participan en el ejercicio, así como de los datos disponibles. Según Niveditha (2022), PremierAgile (s.f.) y Simplearn (2022), las mencionadas técnicas se enfocan en lo siguiente:

• MoSCoW. Siglas provenientes de algunos conceptos en inglés: must (requerimientos con mayor prioridad), should (requerimientos altamente deseables, pero no obligatorios), could (requerimientos que podría ser bueno tener) y won't (requerimientos no solicitados en el producto).
• Modelo de Kano. Incluye tres niveles de satisfacción del cliente: insatisfecho, no feliz inmediatamente y deslumbrado. Los factores considerados para determinar el nivel se basan en las características y el grado de implementación que se consiguen a lo largo de la ejecución completa.
• Técnica de priorización de pesos relativos. El esquema de pesos relativos es un modelo de priorización simple donde se califican las características de la siguiente manera: beneficio de tener la característica, penalización por no tener la característica, costo de producir la característica y riesgo incurrido en producir la característica. La prioridad se determina con una fórmula: (beneficios – penalizaciones) / (costo + riesgo). Esta técnica ayuda a establecer fácilmente una priorización.
• Evaluación de oportunidad. Método de priorización de beneficios utilizado a partir de datos de investigación de mercados, los cuales ayudan a determinar lo que los usuarios esperan del producto o servicio. Permite crear un calendario de acuerdo con lo que la audiencia objetivo quiere y necesita.
• Ranking en pila. Es una de las formas más populares de priorización en desarrollo de software, así como de las más sencillas. La técnica considera cada historia de usuario y las ordena con base en una prioridad: la tarea más importante se coloca en la parte superior de la pila y la menos importante en la inferior. Así, se genera una lista de prioridades enfocadas en las características más importantes.
• Prioridad póker. Se basa en reglas similares al juego, ya que al jugar con las cartas se prioriza de forma calculada, pues obtener mayores ganancias es el último objetivo. Con base en lo anterior, se reúne a todos los interesados, incluso a usuarios/clientes finales, y se les pide asignar una prioridad a cada tarea o característica programada; posteriormente, se compila la lista de prioridades basadas en el ranking de interesados.
• Costo de retraso. Su objetivo es entender cuánto dinero perdería la organización si cierta característica no estuviera disponible, es decir, se centra en las pérdidas monetarias para comprender qué rasgos son los más importantes y la lista se elabora a partir de los resultados. Este es un enfoque proactivo para asegurar que el gerente combata emergencias que puedan resultar en pérdidas, pues debe identificar la urgencia de la tarea basándose en las pérdidas.
• Prueba de los 100 dólares. También conocida como voto acumulativo. Se trata de un proceso directo, similar a la técnica del póker, en el que cada persona tiene 100 puntos o dólares para distribuir entre cada característica o tarea. Una vez asignado todo el dinero o puntos, se prioriza la actividad con la mayor cantidad y las demás se acomodan por orden de puntos.

Estatus Kanban

Una vez priorizadas las actividades o características, es importante tener visibilidad del avance en todo momento y tablero Kanban es una de las herramientas más usadas para dicho fin. A través de él se muestra el desarrollo del trabajo: ayuda a visualizar el avance, limitar el trabajo en proceso y maximizar la eficiencia o flujo (Kanban Tool, s.f.; Rehkopf, s.f.).

Figura 2. Tablero Kanban.

Fuente: Kanban Tool. (s.f.). Visual Management. An overview of your project at one glance. Recuperado de https://kanbantool.com/visual-management-board
Rehkopf, M. (s.f.). What is a Kanban Board? Recuperado de https://www.atlassian.com/agile/kanban/boards

De acuerdo con Rehkopf (s.f), el tablero Kanban cuenta con los siguientes elementos:

• Tarjetas Kanban. Representación visual de cada actividad o tarea, contiene información como fecha de entrega, persona asignada, descripción, así como su estatus.
• Columnas Kanban. Cada columna del tablero (solicitado, en proceso, hecho) representa una etapa diferente del flujo de trabajo. Se mueven las tarjetas a lo largo de las tres columnas hasta que se completan las tareas mencionadas en ellas.
• Límite del trabajo en proceso. Restringe la cantidad máxima de tareas en las diferentes etapas del flujo de trabajo; por ejemplo, en la figura 2, el límite es una. Limitar el flujo de trabajo permite terminar los elementos más rápido, ya que ayuda al equipo a enfocarse en sus asignaciones.
• Carriles Kanban. Se utilizan para separar las actividades no relacionadas o de otros equipos, clases de servicio, etcétera. En el ejemplo, se representa con una franja roja horizontal.

El dueño del tablero Kanban es el equipo de desarrollo; sin embargo, también resulta muy útil para el Product Owner, ya que le da visibilidad del valor que se ha avanzado, de la velocidad, los equipos asignados y la prioridad actual. En el tablero se pueden encontrar diferentes categorías de requerimientos, todas obtenidas del Product Backlog, tales como características nuevas, tareas, bugs, solicitudes de cambios, requerimientos técnicos, conocimiento a obtener, etcétera (Miro s.f.).

Tamaño y estimación

En Scrum, los términos tamaño y estimación se enfocan en las historias de usuario y son responsabilidad del equipo de desarrollo, pues se encarga de hacer las estimaciones para el Product Backlog y Sprint Backlog. Sin embargo, el Product Owner debe alinearse o hacerlo en conjunto con este rol (Nettleton, s.f.; Blake, 2021).

Como se revisó al inicio de esta experiencia, todos los elementos deben priorizarse para después ser estimados por el equipo. De esta manera, no sólo se obtiene la valoración crítica de las actividades, sino también la estimación de la rapidez con la que se llevará la generación de valor, la cual se mide a través de los puntos de historia. Esta es una medida adimensional utilizada por las técnicas de estimación para determinar el tamaño de las historias de usuario, es decir, emplean unidades de medida que expresan una aproximación del esfuerzo total requerido para completar un elemento del Backlog o de trabajo, asignados con base en la complejidad, cantidad de trabajo y el riesgo o incertidumbre (Blake, 2021; Radigan, s.f.).

La figura 3 muestra algunas de las técnicas más populares de estimación utilizadas por los equipos ágiles. Dichas técnicas se basan en puntos de historia y se usan durante la estimación del mapeo de historias (las historias conforman el producto); es decir, una vez que los Product Owner han definido las historias de usuario y las han explicado al equipo, se procede a establecer la estimación. Esta también ayuda a priorizar el Backlog, por lo que las técnicas que aquí aparecen también sirven para establecer una priorización. El PO debe estar presente para aclarar las dudas sobre las definiciones de las historias que puedan surgir a la hora de priorizar (Hardbridge, 2020).

Figura 3. Técnicas usuales de estimación.

Fuente: Blake, S. (2021). Agile Estimation Techniques: A Deep Dive Into T-Shirt Sizing. Recuperado de https://www.easyagile.com/blog/agile-estimation-techniques/

Las diferentes técnicas se utilizan dependiendo del nivel de facilidad o enfoque del equipo, por lo que no hay una regla para seleccionarla: cada una tiene características funcionales que permiten alcanzar el éxito. Al respecto, Azmi (2020) realiza las siguientes definiciones:

• Mapa de afinidad. Se refiere a los elementos del Backlog similares al área, esfuerzo o alguna otra característica, pues se busca agruparlos por tamaños parecidos. En general, se identifican los elementos por sus características y se agrupan a partir de su tamaño, ya sea en pequeños o grandes.
• Sistemas de cubos/baldes. Es similar al mapa de afinidad, aunque con esta técnica se obtienen resultados más específicos. Habitualmente se usan los números 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100 y 200 como tamaños relativos, los cuales se colocan en diferentes cubos/baldes para determinar el tamaño del elemento.
• Voto de puntos. Se enfoca en una votación a través de la escritura de puntos en un bloc de notas; el equipo recibe cinco puntos que deben asignarse con base en lo que se considera más crítico del backlog, pues los requerimientos se añaden a partir del número de puntos obtenidos.
• Tamaño de la playera. Se enfoca en una estimación aproximada utilizando tamaños relativos, en este caso de una playera (XS, S, M, L, XL). Normalmente se utiliza para la planeación de futuras liberaciones, donde se dividen por puntos de historia.

Capacidad de asignación

El tablero Kanban ofrece visibilidad del trabajo a desarrollar y de la capacidad del equipo, la cual se calcula con base en el factor de enfoque (definido como la capacidad para permanecer enfocados en las metas del Sprint sin distracciones) que, a su vez, se valora con la velocidad del Sprint dividida por la capacidad del equipo (Obi, 2021).

La velocidad del equipo se refiere la rapidez con la que el equipo puede completar un Sprint, es decir, el número de puntos de historia promedio. Por otro lado, la capacidad del equipo contempla número total de horas que el equipo está disponible.

Por ejemplo, si el equipo está compuesto por 5 integrantes que han trabajado a una velocidad promedio de 32 puntos de historia (en los últimos 5 Sprint), 8 horas por día, entonces, el factor de enfoque se calcula así: factor de enfoque = (32)/(5*8) = 32/40 = 0.8.

Si el equipo tiene que desarrollar en las siguientes dos semanas un Sprint, entonces estaría trabajando 10 días; por tanto, la capacidad del equipo sería: 0.8*(5*8*10) = 320 horas.

De manera general, las buenas prácticas para la planeación del equipo se encuentran resumidas en la figura 4.

Figura 4. Buenas prácticas de planeación de capacidad de equipos ágiles.

Fuente: Eiche, N. (s.f.). How to Improve your Agile Team's Capacity Planning. Recuperado de https://www.method.com/insights/how-to-improve-your-agile-teams-capacity-planning/
Janakieva, I. (s.f.). The Best Practices of Team Capacity Planning in Scrum Teams. Recuperado de https://adevait.com/blog/agile-work/how-to-do-agile-capacity-planning

Las buenas prácticas de planeación de capacidad de equipos ágiles se enfocan en estos puntos:

• Priorizar el trabajo basado en la estrategia. Recuerda que, como Product Owner, siempre debes tener en mente la visión del producto para lograr alcanzar la estrategia de entrega alineada con el valor a entregar. Así, iniciarás con la visión en la mente y puedes priorizar basándote en ella.
• Analizar la capacidad actual. Determinar cuál ha sido la capacidad del equipo en los últimos cinco Sprint, de tal forma que se tenga una meta realista de cómo trabaja el equipo.
• Evitar distractores. Monitorear el proceso para asegurarse de que no existan tareas que distraigan las actividades del equipo y, de esta manera, ayudar a la gestión de su desempeño.
• Planear la capacidad como un proceso continuo. Recordar que la planeación de la capacidad no es un proceso estático, sino dinámico; por ende, debe adaptarse al crecimiento y desempeño del equipo, así como asegurar la entrega de valor en todo momento.

Al planear la capacidad como parte de procesos ágiles, hay que recordar que se enfoca en el valor máximo promedio que, en cada trabajo, el equipo puede proveer en un Sprint específico. En este sentido, debe considerarse que la principal meta es mantener un balance entre los puntos de historia hechos en el Sprint y la capacidad del equipo, así como el balance de la demanda para evitar sobrecargar a los equipos de trabajo. Además, como parte de la medición del desempeño, la evaluación de la capacidad es algo esencial que debe soportar la visión y ser parte de los indicadores clave para el equipo.

Entre los beneficios del cálculo de dicha capacidad se encuentra la responsabilidad del equipo para planear y transformar las entregas impredecibles en predecibles, sin exceder su límite, así como un uso eficiente de recursos, enfocado en un equipo empoderado con un ancho de banda para completar el valor requerido.

La gestión del Backlog no se refiere sólo a la priorización y visibilidad adecuada del valor, sino también a la forma como se estima el tamaño de los elementos que lo conforman, pues así se establece el tamaño del Sprint con base en la capacidad del equipo. En otras palabras, debe haber una alineación entre el valor a realizar, los objetivos esperados y la capacidad del equipo, lo cual se observa a través del estatus Kanban (una forma de mostrar la creación de valor de forma visual). De esta manera, no se exceden las expectativas y el equipo tiene más claro hasta dónde puede realizar y esforzarse por cumplir con los compromisos y objetivos esperados; pero, sobre todo, garantiza que trabajará en la mejora continua para su desarrollo.

Asegúrate de:

• El Product Owner es dueño del Product Backlog, pero la priorización debe hacerla con ayuda del equipo, ya que este se encarga de desarrollar el Sprint.
• En los marcos de referencia ágiles se prioriza por medio de puntos de historia o con base en la importancia de los interesados y el equipo Scrum.
• En el estatus Kanban se debe mostrar claramente en qué se está trabajando, que está pendiente y qué es lo que se ha terminado, así como la capacidad del equipo y los trabajos asignados a los diferentes equipos.
• Para estimar la capacidad del equipo se utiliza la velocidad del Sprint, el cual es diferente a la métrica de tiempo que normalmente se usa en el desarrollo tradicional.

Los siguientes enlaces son externos a la Universidad Tecmilenio, al acceder a ellos considera que debes apegarte a sus términos y condiciones.

Videos

Para conocer más acerca de Gestión de backlog, te sugerimos revisar lo siguiente:

• Ágil Es – Por Cris Rúa. (2018, 20 de mayo). ESTIMACIÓN POR PUNTOS DE HISTORIA PARA UN EQUIPO SCRUM [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=O-D22kLYi2M
• Hernán Hurtado. (2022, 21 de mayo). SCRUM PRODUCT BACKLOG, Todo lo que debes saber [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=3EaSQjTV9JI
• Info G-Talent. (2021, 5 de octubre). Tutorial - Priorización del Product Backlog [Archivo de video]. Recuperado de https://www.youtube.com/watch?v=gxnxcg57NJI

Lecturas

Para conocer más acerca de Gestión de backlog, te sugerimos leer lo siguiente:

• Martins, J. (2021). Mucho más que sólo tallas de camisetas: descubre cómo las tallas de las camisetas pueden ayudarte con la estimación de los proyectos. Recuperado de https://asana.com/es/resources/t-shirt-sizing
• Rehkopf, D. M. (2022). ¿Qué es un tablero kanban? Recuperado de https://www.atlassian.com/es/agile/kanban/boards
• Sa, E. (s.f.). Métricas de Scrum. Recuperado de https://www.atlassian.com/es/agile/scrum/scrum-metrics

• Azmi, M. A. M. (2020). Agile Estimating: Estimation of Size & Duration using Story Points & Velocity. Recuperado de https://www.linkedin.com/pulse/agile-estimating-estimation-size-duration-using-story-mohd-azmi/
• Blake, S. (2021). Agile Estimation Techniques: A Deep Dive Into T-Shirt Sizing. Recuperado de https://www.easyagile.com/blog/agile-estimation-techniques/
• Eiche, N. (s.f.). How to Improve your Agile Team's Capacity Planning. Recuperado de https://www.method.com/insights/how-to-improve-your-agile-teams-capacity-planning/
• Hardbridge, T. (2020). Story Points: definition, how-to & why they matter. Recuperado de https://www.easyagile.com/blog/user-story-points/
• Janakieva, I. (s.f.). The Best Practices of Team Capacity Planning in Scrum Teams. Recuperado de https://adevait.com/blog/agile-work/how-to-do-agile-capacity-planning
• Kanban Tool. (s.f.). Visual Management. An overview of your project at one glance. Recuperado de https://kanbantool.com/visual-management-board
• Miro. (s.f.). Kanban vs Scrum boards: 11 major differences. Recuperado de https://miro.com/blog/scrum-kanban-boards-differences/
• Nettleton, C. (s.f.). Estimating the Size of Scrum User Stories. Recuperado de https://appliedframeworks.com/estimating-the-size-of-scrum-user-stories/
• Niveditha, P. (2022). Agile Prioritization Techniques Explained. Recuperado de https://www.sprintzeal.com/blog/agile-prioritization-techniques
• Obi, A. (2021). HOW TO PLAN CAPACITY OF YOUR SCRUM TEAMS. Recuperado de https://www.scrum-institute.org/blog/How_To_Plan_Capacity_Of_Your_Scrum_Teams
• PremierAgile. (s.f.). Top 5 Agile prioritisation techniques. Recuperado de https://premieragile.com/agile-prioritization-techniques/
• Radigan, D. (s.f.). Story points and estimation. Recuperado de https://www.atlassian.com/agile/project-management/estimation/
• Rehkopf, M. (s.f.). What is a Kanban Board? Recuperado de https://www.atlassian.com/agile/kanban/boards
• Simplilearn. (2022). PMI-ACP Training: Agile Prioritization Techniques. Recuperado https://www.simplilearn.com/agile-prioritization-techniques-article
• Wilhite, D. (2021). Questions about estimation and sizing. Recuperado de https://www.scrum.org/forum/scrum-forum/49112/questions-about-estimation-and-sizing