Es el día de la revisión del sprint. El gráfico de capacidad del día de planificación está todo en verde y nadie supera el 100%. Sin embargo, el tablero sigue mostrando cuatro elementos de trabajo en "En revisión" y el sprint termina hoy. Si eres Scrum Master o gestor de proyectos, probablemente ya hayas pasado por esto.
La planificación de la capacidad del sprint en Jira muestra quién tiene tiempo, pero no cuánto tiempo espera el trabajo entre personas. Esa espera es, por lo general, donde se pierden los días. Este artículo muestra a dónde van esos días y cómo planificar en torno a ellos, utilizando Activity Timeline y Timepiece - Time in Status for Jira.
Puntos clave: La planificación de la capacidad te dice quién tiene tiempo. No te dice cuánto tiempo espera el trabajo. Una tarea de 4 horas puede tardar 6 días en cerrarse y aun así verse bien en el gráfico de capacidad. Para cumplir con la fecha límite de tu sprint, realiza un seguimiento de ambos: la capacidad en Activity Timeline y el tiempo de espera en Timepiece.
¿Qué mide realmente la planificación de la capacidad del sprint en Jira?
La mayoría de los planes de sprint salen mal antes de que comience el sprint. Alguien se compromete a más de lo que tiene tiempo, unas vacaciones que nadie contó restan dos días y el equipo se entera a mitad de camino. La planificación de la capacidad es la forma de detectar esto durante el día de planificación.
La planificación de la capacidad compara dos números. La carga de trabajo es el trabajo estimado asignado a un miembro del equipo. La capacidad es el tiempo que tiene esa persona: sus horas de trabajo menos vacaciones, bajas por enfermedad y días festivos. Súmalo todo en un equipo y obtendrás la capacidad del equipo, el límite máximo de lo que puede contener un sprint.
ActivityTimeline construye esto a partir de tus datos de Jira:
- La carga de trabajo proviene de la estimación restante en los elementos de trabajo asignados, distribuidos a lo largo de las fechas en las que están programados.
- Los elementos de trabajo pueden tomar esas fechas del sprint, por lo que aparecen en la línea de tiempo de cada persona para el período del sprint.
- Debajo de cada persona, un indicador de carga de trabajo muestra si están sobrecargados, subcargados o equilibrados.
Puedes ver quién está sobrecargado y mover el trabajo antes de que comience el sprint, no después de que alguien se quede atrás. Para la configuración, consulta las guías de ActivityTimeline sobre planificación de la capacidad en Jira y planificación de sprints en Jira.
El gráfico de capacidad del equipo suma al equipo: capacidad total, capacidad utilizada, capacidad restante y tasa de utilización para el período que elijas. La capacidad restante te indica cuánto espacio queda cuando llega trabajo no planificado, para que puedas decir sí o no basándote en los números.
El desarrollador reservado al 130% y el sprint que coincide con un día festivo del equipo son dos ejemplos de cómo la planificación de la capacidad del sprint en Jira detecta problemas a tiempo. Cada uno que detectas en el día de planificación es una fecha límite que no tendrás que explicar más tarde.
Carga de trabajo verde, sprint rojo: ¿dónde falla el plan?
Aquí hay un ejemplo de una historia de un sprint. Tenía una estimación de 4 horas y estaba programada en el cronograma del desarrollador en ActivityTimeline. El equipo registró 4 horas en ella. Sin embargo, tardó 6 días laborables en cerrarse. (Las cifras son ilustrativas).
La estimación fue correcta: 4 horas planificadas, 4 horas registradas. Pero los estados "Por hacer", "En revisión" y "Esperando QA" consumieron 4,5 de los 6 días, y la mayor parte de ese tiempo fue de espera.
El plan de capacidad no tuvo errores. Activity Timeline calcula la carga de trabajo a partir de la estimación restante y las fechas programadas de cada elemento de trabajo. Un cambio de estado por sí solo no altera ninguno de los dos, por lo que la historia sumó las mismas horas planificadas mientras esperaba en revisión que mientras alguien trabajaba en ella. El indicador de carga de trabajo de nadie se puso en rojo.
Esa es la diferencia entre esfuerzo y tiempo transcurrido. El esfuerzo son las horas de trabajo: 4. El tiempo transcurrido es el tiempo de calendario desde el inicio hasta la finalización, incluyendo las esperas: 6 días. La planificación de capacidad mide el esfuerzo. El plazo de tu sprint se rige por el tiempo transcurrido.
¿A dónde va el tiempo entre estados?
Respuesta corta: a la espera. El tiempo de cada elemento de trabajo se divide en dos partes:
Tiempo de ejecución: alguien está trabajando en ello.
Tiempo de espera: está en un estado y nadie está trabajando en ello.
Un plan de capacidad cuenta las horas estimadas de trabajo, que es aproximadamente el tiempo de ejecución. El tiempo de espera no consume las horas de nadie, por lo que nunca aparece en el plan. Pero aun así, resta días al calendario.
La eficiencia de flujo muestra cuánto del tiempo total fue tiempo de ejecución: tiempo de ejecución dividido por el tiempo total. En la historia anterior, el equipo registró 4 horas durante 6 días laborables (seis días de 8 horas, 48 horas laborables). Si consideras el tiempo registrado como tiempo de ejecución, eso es una eficiencia de flujo de aproximadamente el 8%. Durante el otro 92% del tiempo, la historia estuvo esperando. En un caso como este, reducir la espera ahorra más días de lo que cualquier mejora en la velocidad de trabajo podría lograr.
La espera tiende a acumularse en algunos puntos:
- Revisión de código: El código está escrito, pero el revisor está ocupado con otras tareas.
- Entrega a QA: El elemento de trabajo está listo para probarse, pero permanece en "Listo para QA" hasta que un evaluador esté libre.
- Aprobaciones: El elemento de trabajo no puede avanzar hasta que un gerente, el equipo de seguridad o el cliente den su visto bueno.
- Otro equipo: El elemento de trabajo depende de algo que otro equipo debe entregar primero.
- Retrabajo: El equipo de control de calidad encuentra un problema y devuelve la tarea, por lo que vuelve a pasar por las mismas colas.
Cada uno de estos puntos es un cuello de botella en el flujo de trabajo. Atlassian describe un cuello de botella como cualquier punto en un flujo de trabajo donde la capacidad es limitada, lo que provoca que el trabajo se acumule. Para identificar los suyos, necesita saber cuánto tiempo pasó el trabajo en cada estado.
¿Cómo encontrar cuellos de botella en el flujo de trabajo con Timepiece?
La mayoría de los equipos ya tienen una idea de dónde se estanca el trabajo. "Las revisiones son lentas". "El control de calidad siempre va con retraso". Lo difícil es demostrarlo y saber cuántos días de trabajo cuesta.
La buena noticia es que Jira registra cada cambio de estado con una marca de tiempo. Pero muestra ese historial tarea por tarea. En los espacios gestionados por la empresa, el gráfico de control representa el tiempo que las tareas pasaron en los estados seleccionados, con un promedio y una desviación estándar. Eso indica que el trabajo es lento. Sin embargo, no muestra todos los estados uno al lado del otro, ni quién tenía el trabajo. Por lo tanto, la retrospectiva se basa en la memoria y la solución depende de quién argumente mejor.
Timepiece - Tiempo en estado para Jira de OBSS convierte ese historial en informes. Lee los cambios de estado que Jira ya almacena, por lo que cubre los sprints anteriores tan pronto como lo instalas, sin que nadie tenga que registrar nada manualmente. Esto es lo que responde:
¿Qué estado consume el sprint?
El informe de duración de estado muestra el tiempo que cada tarea pasó en cada estado. Utilice columnas consolidadas para agrupar los estados en "espera" y "en proceso" (cuáles cuentan como espera depende de su flujo de trabajo) y luego ordene por la columna de espera. Su retrospectiva puede comenzar con datos, no con sensaciones.
¿Es un patrón o una mala semana?
El informe de promedio agrupa los resultados por sprint, mes u otro campo, como el tipo de incidencia. Si "En revisión" es lento en cada sprint, vale la pena solucionarlo. Si hubo un pico una sola vez, probablemente no sea necesario.
¿Con quién se acumuló el trabajo?
La duración por responsable según el estado muestra el tiempo por persona en cada estado, y la duración por grupo hace lo mismo para grupos de usuarios, como desarrolladores o evaluadores. Si la mayor parte del tiempo "En revisión" recae en un solo revisor, eso apunta a la carga de trabajo, no a una persona lenta. Los datos mantienen la conversación centrada en el proceso, no en buscar culpables.
¿Son justas las cifras?
Un calendario personalizado excluye fines de semana, días festivos y horas no laborables. Sin él, el trabajo entregado el viernes por la noche parece un retraso de todo el fin de semana, y el equipo deja de confiar en el informe. La guía de OBSS sobre excluyendo las horas no laborables muestra la configuración.
¿Con qué frecuencia se devuelve el trabajo?
El informe de recuento de estados muestra cuántas veces cada elemento de trabajo entró en cada estado, por lo que los bucles, como el paso de QA a En curso, resaltan claramente.
Y no tienes que esperar a la retrospectiva. Las reglas de resaltado colorean los elementos de trabajo cuyo tiempo de ciclo supera un umbral que tú estableces, y las alarmas envían un correo electrónico o un mensaje por Slack o Microsoft Teams cuando se supera dicho umbral. Puedes desbloquear el trabajo mientras aún queda tiempo en el sprint.
¿Qué obtienes al usar ambas aplicaciones?
Timepiece muestra dónde se acumula el trabajo. No indica si las personas en esa etapa tienen tiempo disponible, pero Activity Timeline sí. Al leer ambos, puedes determinar qué solución necesitas:
- El revisor aparece sobrecargado en Activity Timeline: Es un problema de capacidad. Asigna el trabajo a alguien con disponibilidad o planifica el tiempo de revisión para el próximo sprint.
- El revisor tiene disponibilidad y el trabajo sigue esperando: Es un problema de proceso. Analiza la transferencia: cómo se solicitan las revisiones, quién las toma y cuándo.
Ese es el valor de consultar ambos: inviertes esfuerzo en la solución que corresponde a la causa real, no en la que suena bien durante la retrospectiva.
Planificación de capacidad de sprint más flujo: un flujo de trabajo que funciona
Utiliza ambas vistas como un ciclo:
- Planifica la capacidad del sprint en Activity Timeline como de costumbre. Revisa los indicadores de carga de trabajo y el gráfico de capacidad del equipo, y ten en cuenta los días libres.
- Durante el sprint, observa el tiempo en estado en Timepiece. Desbloquea el trabajo que espera más tiempo de lo habitual.
- Después del sprint, compara las horas planificadas con las reales en el gráfico de Planificado frente a Real de Activity Timeline. Compara el tiempo programado con el tiempo registrado, por lo que le indica si sus estimaciones fueron correctas, no si el trabajo avanzó rápido.
- Aplique lo aprendido en el siguiente plan. Por ejemplo, reserve tiempo de revisión para las personas que más revisan.
Un inconveniente: para un equipo pequeño con un tablero compartido, echar un vistazo diario al tablero puede decirle lo mismo. La configuración de dos herramientas resulta rentable cuando varios proyectos comparten las mismas personas, ya que las colas son más difíciles de ver a simple vista.
¿Qué métricas debería analizar juntas?
Un número por sí solo rara vez le dice qué salió mal. Coloque una vista de cada aplicación una al lado de la otra y la razón por la que un sprint se retrasó suele quedar mucho más clara.
Los números le muestran dónde mirar. Su equipo puede decirle por qué sucedió.
Descubra a dónde se fueron los días de su sprint
Un gráfico de capacidad en verde significa que su equipo tenía tiempo. No significa que el trabajo avanzara. Cuando un sprint se retrasa y nadie estaba sobrecargado, los días perdidos suelen estar en una cola: esperando revisión, control de calidad o aprobación.
La capacidad muestra el esfuerzo, el flujo muestra el tiempo y su fecha límite vive en el calendario.
¿Quiere ver a dónde se fueron los días de su propio sprint? Ambas aplicaciones tienen una prueba gratuita en el Atlassian Marketplace:
- Pruebe ActivityTimeline para planificar la capacidad del sprint en función de la disponibilidad real.
- Pruebe Timepiece - Time in Status for Jira para ver cuánto tiempo espera el trabajo en cada estado.
¿No está seguro de si su cola es un problema de personal o de proceso? Lea el artículo complementario en el blog de OBSS.
