Cuando trabajas en un enfoque ágil de actividades necesitas un mecanismo subjetivo que te permita determinar el valor que aportas con tus actividades. La unidad más común para determinar la relación de valor/esfuerzo son los Story Points, entre más puntos le asignes a una actividad significa que es más costosa, aporta más valor o ambas. No existe un estándar o convención que te ayude a determinar cuantos puntos debe tener una actividad, cuál es el valor mínimo o cuál es el valor máximo. Puedes llegar a la conclusión que una actividad pequeña puede valer un punto, por ejemplo. La cosa es más complicada al momento de cuantificar actividades grandes, complejas o no documentadas. En principio las actividades con altos puntos no son malas, tienen implicaciones que te explico:
Muchos puntos significan actividades grandes o incluso proyectos enteros.
Cuando redactas las actividades o tareas puedes anotar items que representan un gran esfuerzo, no necesariamente los vas a tomar en este momento, sirven como recordatorios o items crudos que requieren cocinarse un poco más. Está bien dejarlos así en tu backlog o icebox, en espera de poder refinar más la tarea o borrarla para sustituirla por un desglose de actividades más granulares. Ningún item del tablero está escrito en piedra, tampoco sus estimaciones todo es ajustable a menos que ya este entregado.
Un item con muchos puntos puede ser señal de advertencia.
Van a existir items que no quieres trabajar en este momento, tampoco vas a querer que alguien más los tome. Un buen método de ser claros y específicos de que los items están prohibidos es subir su puntuación a una cantidad que los haga inviables o irreales de trabajar en el Sprint o cadencia que manejes. Por ejemplo: si tu equipo de trabajo entrega en promedio 25 puntos por cadencia, realizar una actividad de 100 puntos hace que se prendan todas las alarmas. ¿Por qué se subió el puntaje de items de entrega en un 400 %?, ¿cómo es posible que una tarea que vale 100 puntos se entregue solo en un ciclo?, ¿por qué se estimo en 100 puntos esta tarea en particular?. Obvio, el propósito es no tomar la tarea en este momento, es no trabajarla. Las tareas con muchos puntos son tareas a medias, no son items listos para trabajar.
Un item épico siempre es una agrupación de más actividades.
Es un suicidio tomar items exageradamente pesado, y no por el item. Si no porque hay que partirlo en pedazos masticables para que sean de fácil asimilación. Tienes un item grande, ya necesitas tomarlo, entonces debes ir restándole peso. Puedes crear actividades que le resten peso y sean complementarias sin borrar el item original, o puedes borrar el item original y crear una serie de actividades que te permiten completar tu tarea enorme. Esto depende de ti, y de tu flujo de trabajo, no hay respuestas correctas o incorrectas.
Conclusiones.
Hay posiciones en el ecosistema ágil en contra de asignar muchos puntos a las actividades, algunos consideran que el número máximo debería ser hasta 3 puntos. Es entendible, es un desastre trabajar con items de gran peso, son difíciles de reportar, muy opacos y generan desperdicio. El problema de asignar muchos puntos a una actividad, en mi opinión, no es el tamaño, es el tratamiento que le da el equipo. Está bien estimar números altos, una estimación es eso, asignar un valor que puede tener un rango de error muy alto, y es preferible en las actividades de desarrollo estimar con recursos sobrantes a estimar con recursos faltantes. Entre más tiempo pasa, las estimaciones de tus items épicos deben reflejar la realidad. Si de verdad son muy difíciles, su valor se queda, pero si son tareas menos complejas, entonces debes de ajustar esos valores para reflejar la realidad. Asignar puntos es un proceso que cambia según las necesidades de tu proyecto.
Autor imagen: Jason Witwicker
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
1 comments On User Stories: Historias con muchos story points.
Pingback: User Stories: Las historias épicas no son malas. – Happy Devops ()
Comments are closed.