Teambook para Equipos de TI y Software

Los sprints suelen fallar no porque el código sea difícil, sino porque las "100 horas de capacidad" que creías tener en realidad son 60 debido a un día festivo, una baja por enfermedad o un desarrollador que es reasignado a corregir un bug de alta prioridad en otro proyecto.

Teambook cierra la brecha entre el backlog de Jira/DevOps y las personas reales que hacen el trabajo.

Paso 1: Establecer una capacidad base realista

Antes de asignar tickets a un sprint, necesitas saber cuánto tiempo tiene realmente disponible tu equipo.

En Teambook:

• Configura el horario de trabajo de cada desarrollador en su perfil de usuario.
• Permite que Teambook tenga en cuenta automáticamente:
• • Días festivos
  • Contratos a tiempo parcial
  • Tiempo libre planificado
• Establece una tasa de utilización realista, por ejemplo:
• • 85 % es un objetivo generalmente aceptado
  • Esto significa que el 15 % se dedica a tareas no productivas Esto te da una capacidad base real, no teórica.

Paso 2: Detectar el sobrecompromiso antes de que comience el sprint

Usa la Vista de Usuario en el módulo de planificación para identificar inmediatamente las disponibilidades (celdas en blanco) y las sobrecargas (números en rojo).

Cuando alguien aparece en rojo, puedes inmediatamente:

• Reasignar el trabajo a un desarrollador con capacidad disponible, simplemente arrastrando y soltando las reservas correspondientes a otro usuario (puedes filtrar la lista por habilidades/etiquetas).
• Reducir el alcance o la duración de una tarea.
• Posponer el trabajo al siguiente sprint, simplemente arrastrando y soltando las reservas correspondientes a una fecha posterior. Esto reemplaza el hábito de las hojas de cálculo, donde solo notas la sobrecarga después de que el sprint ya haya fallado.

Paso 3: Proteger el tiempo para el trabajo "business as usual"

Los equipos de TI y software siempre tienen trabajo invisible como reuniones diarias, revisiones de código, reuniones internas o correcciones urgentes no planificadas.

Si ignoras esto, tu velocidad siempre estará sobreestimada.

Buenas prácticas en Teambook:

• Crea proyectos internos (marca como no facturables).
• Reserva una cantidad fija de tiempo por desarrollador, por ejemplo, 1 hora al día, asignada a los proyectos internos correspondientes. Usa reservas recurrentes para este propósito. Esto garantiza que la capacidad del sprint refleje el tiempo real de codificación, no las horas totales de trabajo.

Paso 4: Realizar una verificación de realidad post-sprint 
Al final del sprint, pide a tus colegas que completen sus hojas de tiempo. Una vez hecho, compara el tiempo planificado y el tiempo real en los informes.

Qué buscar:

• 40 horas planificadas, 30 horas registradas = brecha de capacidad o estimación.
• Brechas repetidas en varios sprints = problema estructural, no un caso aislado.

Cómo usar estos datos:

• Incorpóralos a las retrospectivas del sprint.
• Ajusta las estimaciones de puntos de historia o las suposiciones de carga de trabajo.
• Refina las asignaciones de BAU (Business As Usual) si es necesario. Con el tiempo, esto convierte la planificación de sprints de una suposición en un ciclo de retroalimentación.

¿Cómo se ve el éxito?
Los equipos que usan Teambook para la planificación de sprints suelen ver:

• Menos compromisos de sprint incumplidos.
• Velocidad más predecible.
• Detección más temprana de sobrecarga.
• Mayor confianza entre los equipos de producto, ingeniería y las partes interesadas. Los planes de sprint se convierten en algo que el equipo puede entregar realmente, no en algo que esperan que funcione.

Próximos pasos

Para hacer que la planificación de sprints sea más confiable:

• Revisa el horario de trabajo y las asignaciones de cada miembro del equipo para asegurarte de que reflejen la realidad, no suposiciones.
• Crea proyectos internos para reservar horas no productivas y aplica estas reservas de manera consistente en todos los sprints.
• Usa la Vista de Usuario durante la planificación del sprint para resolver el sobrecompromiso antes de que comience el sprint.
• Compara el tiempo planificado y el tiempo real al final de cada sprint y ajusta regularmente las suposiciones de capacidad. Usado de manera consistente, este enfoque ayuda a los equipos a planificar en función de la disponibilidad real, no de estimaciones optimistas.

Si necesitas ayuda para configurar proyectos, horarios personales o informes, contacta al soporte y podemos ayudarte a configurar los flujos de trabajo de planificación de sprints en Teambook.