Evaluar primero el tamaño y granularidad de los elementos, independientemente de la velocidad para estimar el tamaño probable.
El texto «Evaluar primero el tamaño y granularidad de los elementos, independientemente de la velocidad para estimar el tamaño probable» se refiere a un enfoque en la estimación ágil que separa el proceso de estimación del tamaño de las tareas de la velocidad del equipo.
Evaluar primero el tamaño y granularidad de los elementos:
- Tamaño: Se refiere a la complejidad o cantidad de trabajo involucrado en una tarea o historia de usuario. En lugar de centrarse inicialmente en cuántas tareas se pueden completar en un tiempo determinado (velocidad), el equipo debe enfocarse en cuánto trabajo implica cada tarea o historia.
- Granularidad: Significa que las historias de usuario o tareas deben estar lo suficientemente detalladas para poder estimarse adecuadamente. Esto implica dividir grandes elementos en piezas más pequeñas y manejables, con un nivel adecuado de detalle, antes de realizar una estimación.
Independientemente de la velocidad:
- Velocidad es una medida de cuánto trabajo un equipo puede completar en un sprint o ciclo de trabajo. Este texto sugiere que, en las primeras etapas, la estimación no debe verse influenciada por la velocidad del equipo. En lugar de pensar en cuántas tareas pueden hacerse en un sprint, el foco debe estar en cuantificar el tamaño de cada tarea de forma independiente.
Estimar el tamaño probable:
- Una vez que se ha evaluado el tamaño y granularidad de las tareas, se puede hacer una estimación del tamaño probable de los elementos en función de su complejidad. Esto generalmente se hace con técnicas como puntos de historia o tamaño relativo, donde se comparan las tareas entre sí para determinar cuáles son más grandes o más pequeñas.
Ejemplo
Imaginemos que un equipo de desarrollo está trabajando en una nueva aplicación de gestión de tareas para equipos. Como parte de su planificación ágil, deben estimar el trabajo necesario para implementar diferentes funcionalidades, como la creación de tareas, asignación de prioridades y notificaciones. Para hacer esto, siguen el enfoque de evaluar primero el tamaño y granularidad de los elementos, independientemente de la velocidad del equipo.
Escenario:
Identificación de las historias de usuario:
- El Product Owner presenta varias historias de usuario, como:
- «Como usuario, quiero poder crear nuevas tareas en la aplicación.»
- «Como usuario, quiero asignar prioridades a las tareas.»
- «Como administrador, quiero recibir notificaciones cuando una tarea esté retrasada.»
- El Product Owner presenta varias historias de usuario, como:
Evaluación del tamaño y granularidad:
- Antes de empezar a estimar el esfuerzo en términos de tiempo o velocidad, el equipo evalúa primero el tamaño y la granularidad de cada historia de usuario:
- La funcionalidad de crear nuevas tareas parece ser una tarea simple y pequeña, ya que implica una interfaz básica y lógica de back-end sencilla.
- La funcionalidad de asignar prioridades a las tareas es algo más compleja, ya que implica integrar un sistema de prioridad y filtros en la interfaz.
- La funcionalidad de notificaciones de tareas retrasadas es la más grande y compleja, ya que requiere integración con un sistema de notificaciones y cálculos basados en fechas y tiempos.
- El equipo se da cuenta de que la historia de notificaciones es demasiado granular y necesita ser dividida en partes más manejables, como la implementación de las notificaciones y la creación de la lógica que define cuándo una tarea está retrasada.
- Antes de empezar a estimar el esfuerzo en términos de tiempo o velocidad, el equipo evalúa primero el tamaño y la granularidad de cada historia de usuario:
Estimación independiente de la velocidad:
- Una vez que las historias tienen un nivel de granularidad adecuado, el equipo utiliza técnicas como Planning Poker o puntos de historia para estimar el tamaño relativo de cada tarea, sin considerar aún cuántas de estas tareas podrán completar en un sprint.
- La historia de crear tareas podría estimarse en 3 puntos de historia, dado que es pequeña.
- La historia de asignar prioridades podría estimarse en 5 puntos de historia, ya que es más compleja.
- Las historias divididas de notificaciones podrían tener estimaciones de 8 y 5 puntos de historia, respectivamente, según su dificultad relativa.
- Una vez que las historias tienen un nivel de granularidad adecuado, el equipo utiliza técnicas como Planning Poker o puntos de historia para estimar el tamaño relativo de cada tarea, sin considerar aún cuántas de estas tareas podrán completar en un sprint.
Utilización de las estimaciones:
- Ahora que el equipo ha evaluado el tamaño probable de cada historia de usuario, tienen una base sólida para planificar los futuros sprints.
- En sprints posteriores, se podrá usar la velocidad del equipo (es decir, cuántos puntos de historia completan por sprint) para calcular cuánto trabajo pueden asumir en cada ciclo.
Comentario
Este contenido refiere al Dominio 5 – Planificación Adaptativa (PMI ACP)
