La planificación de Sprints siempre se ha apoyado en una suposición silenciosa: la capacidad es el número de personas que tienes multiplicado por el timebox. Estimas el trabajo, lo comparas con lo que el equipo terminó en el ciclo anterior y te comprometes con un alcance que encaje.
Pero incorpora Agentes de codificación con IA al equipo y la ecuación deja de describir la realidad. Un Agente puede tomar una Tarea en el momento en que está lista, trabajar en paralelo con todos los demás Agentes y volver con un diff y resultados de pruebas antes del standup en el que pensabas hablar del tema. La capacidad de ejecución se dispara. La respuesta tentadora es comprometer más alcance, y los equipos que lo hacen suelen descubrir el modo de fallo al final del primer ciclo: el Sprint cierra con mucho código terminado y un muro de cambios sin revisar que nadie tuvo tiempo de aceptar.
Ese es el argumento de este artículo: con Agentes en el equipo, la ejecución deja de ser la restricción del Sprint y la revisión humana pasa a serlo. Planifica en función del rendimiento de aceptación, no de cuánto código se puede producir. Usaremos los Sprints de Sharkly como mecanismo concreto, y mantendremos el argumento de planificación claramente separado de los hechos del producto.
TL;DR
Un Sprint en Sharkly es un conjunto de Tareas acotado en el tiempo y propiedad de un único Espacio; las Tareas siguen siendo la fuente de ejecución y de conversación, mientras que el Sprint añade calendario, alcance e informes. Los Sprints son opcionales y funcionan en uno de dos modos: cadencia automática, en la que Sharkly mantiene el calendario y traslada el trabajo sin terminar al siguiente Sprint, o modo manual, en el que las personas crean, inician y completan los Sprints de forma explícita. Los informes abarcan el alcance, el trabajo iniciado y completado, la tasa de finalización, la capacidad y el historial de burnup. Para los equipos híbridos de personas y agentes, el cambio en la planificación es este: los Agentes inflan la capacidad de ejecución, pero la aceptación sigue en manos de las personas, así que el compromiso honesto de un Sprint está acotado por cuánto trabajo terminado pueden aceptar tus revisores, no por cuánto pueden producir tus Agentes.
Qué es un Sprint en Sharkly
Un Sprint es un conjunto de Tareas acotado en el tiempo y propiedad de un único Espacio. Ayuda a un equipo a planificar un alcance concreto, seguir el progreso y decidir qué ocurre con el trabajo sin terminar cuando acaba el timebox. Las Tareas siguen siendo la fuente de ejecución y de conversación; el Sprint añade calendario, alcance e informes por encima.
La documentación usa el término Sprint y le da el mismo significado que le da el sector. La Guía de Scrum describe los Sprints como contenedores de duración fija en los que las ideas se convierten en valor, y la versión de Sharkly mantiene ese linaje. Lo que cambia Sharkly es quién ejecuta dentro de esa ventana.
Tres límites mantienen limpio el concepto:
- Un Sprint pertenece a un único Espacio. Colocar una Tarea en un Sprint no cambia su propiedad.
- Los Sprints son opcionales y se activan por Espacio. Un Espacio que piensa en flujo continuo puede no activarlos nunca.
- Un Sprint no es un Proyecto ni una Vista. Usa un Sprint cuando la pregunta sea qué debería completarse en un timebox concreto. Usa un Proyecto para un resultado que puede abarcar varios Sprints o Espacios. Usa una Vista para una forma guardada de inspeccionar Tareas.
Esa última distinción tiene un peso real en un equipo híbrido: el Proyecto sostiene el resultado, el Sprint sostiene el compromiso a corto plazo y las Vistas sostienen las porciones que cada persona necesita en el día a día.
Cadencia automática o modo manual
Cuando activas los Sprints en un Espacio, eliges uno de dos modos de ciclo de vida. La elección cambia el comportamiento del ciclo de vida, no la propiedad de las Tareas.
La cadencia automática le entrega el calendario a Sharkly. Tú configuras la duración del Sprint, un cooldown opcional, el día de la semana de inicio, cuántos Sprints futuros mantener, la zona horaria y las reglas que añaden Tareas automáticamente cuando entran en determinadas categorías de estado. Sharkly entonces crea los Sprints futuros, los inicia y los completa según lo previsto, y traslada el trabajo sin terminar al siguiente. Si inicias antes de tiempo un Sprint próximo, primero se completa el actual y su trabajo sin terminar se traslada al Sprint que estás iniciando.
El modo manual deja el control del ciclo de vida en manos del equipo. Las personas crean Sprints planificados cuando hace falta, los inician sin cambiar sus fechas configuradas, pueden tener más de un Sprint activo en paralelo y eligen a dónde van las Tareas sin terminar al completarlo. La creación automática, el rollover, el cooldown y las reglas de adición basadas en estados permanecen inactivos en el modo manual.
| Cadencia automática | Modo manual | |
|---|---|---|
| Calendario | Sharkly crea, inicia y completa los Sprints según un ritmo configurado | Las personas crean, inician y completan los Sprints de forma explícita |
| Trabajo sin terminar | Se traslada automáticamente al siguiente Sprint | Se redirige al completar: sin Sprint, a otro Sprint o a uno nuevo |
| Sprints activos en paralelo | Un Sprint actual por cadencia | Se permite más de un Sprint activo |
| Entrada de Tareas | Las reglas por categoría de estado pueden añadir Tareas durante la ventana | Las personas añaden Tareas mediante la planificación, las listas o el campo Sprint |
| Ideal para | Una cadencia estable que el equipo quiere mantener sin ceremonias | Ciclos irregulares, ventanas marcadas por releases o esfuerzos solapados |
El par de decisiones honesto: usa la cadencia automática cuando tu equipo lleva un ritmo estable y quiere que le mantengan la mecánica. Usa el modo manual cuando tus ciclos son irregulares, cuando son los releases y no el calendario los que definen tus ventanas, o cuando necesitas dos Sprints activos a la vez. Cambiar a manual conserva los Sprints existentes pero detiene la programación automática. Desactivar los Sprints por completo completa los activos, elimina los futuros y conserva los datos de los completados para los informes.
Cómo entran las Tareas en un Sprint, cómo salen y cuándo se quedan fuera
Los Sprints se muestran en cinco estados: Actual, Próximo, Planificado, Completado y Cancelado. Los Sprints completados y cancelados pasan al archivo del Espacio en lugar de llenar la lista de planificación activa.
Puedes añadir o mover una Tarea a través de su campo Sprint, desde una lista de Tareas o durante la planificación del Sprint. Hay dos reglas que importan más de lo que parecen.
La primera: una Tarea puede no tener ningún Sprint. Ese es el hogar normal del trabajo del Backlog y de las Tareas que no están comprometidas con ningún timebox.
La segunda: añadir una Tarea a un Sprint no cambia su estado. Esta es la regla que los equipos híbridos deben interiorizar, porque en Sharkly la categoría de estado Backlog es un estado de estacionamiento: crear una Tarea o asignar un Agente mientras la Tarea está en Backlog no inicia la ejecución. Sacar la Tarea de Backlog y llevarla a un estado listo es lo que puede poner en marcha al Agente asignado. Así que la planificación del Sprint y la liberación de la ejecución son dos palancas distintas. Puedes planificar todo el Sprint el lunes, con los Agentes ya asignados, y no se ejecutará nada hasta que cada Tarea se mueva deliberadamente a un estado listo. Las Automatizaciones de cambio de estado pueden encargarse después de las transiciones que quieras estandarizar.
Una regla más protege tu historial: solo se pueden añadir Tareas completadas a un Sprint anterior. Eso permite corregir el histórico sin colocar nunca trabajo sin terminar en un periodo cerrado.
En cuanto a las fechas, el inicio y el fin de un Sprint planificado son editables, mientras que el inicio de un Sprint activo es fijo pero su fin se puede cambiar.
Qué te dicen los informes del Sprint
Los informes del Sprint incluyen recuentos de Tareas y, cuando el Espacio tiene las estimaciones activadas, totales de puntos de estimación en seis métricas: alcance, trabajo iniciado, trabajo completado, tasa de finalización, capacidad e historial de burnup.
La capacidad merece un examen más detenido porque es la cifra en la que se anclan las conversaciones de planificación. Sharkly la deriva de la velocidad de los Sprints completados recientemente cuando hay suficiente historial y, si no, recurre a una estimación basada en el tamaño del Espacio. La documentación dice que hay que tratarla como un insumo de planificación y no como una garantía, y en un equipo híbrido esa advertencia no es relleno: la velocidad medida sobre una cohorte solo de personas deja de predecir nada la semana en que añades tres Agentes. El historial de burnup suele ser más revelador. Si el alcance se completa en un estallido inicial y luego la línea se aplana, tus Agentes terminaron de ejecutar y tus revisores pasaron el resto del Sprint poniéndose al día.
La restricción del equipo híbrido: planifica para revisar, no para ejecutar
Todo lo que hay en esta sección es un argumento de planificación, no una funcionalidad del producto. Sharkly te da la mecánica de Sprint descrita arriba; cómo cargas el Sprint es una decisión de criterio.
Empieza por la división del trabajo. Los Agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, otorgan autoridad y aceptan el resultado. En la programación agéntica, todo lo que hay entre la dirección y la aceptación se puede delegar, pero la aceptación sigue siendo humana. Un Agente que termina una Tarea no la ha terminado en ningún sentido que tu Sprint deba contar: el diff, los resultados de verificación y los límites conocidos vuelven a la Tarea, y una persona todavía tiene que leerlos y aceptar, pedir cambios o decidir el merge.
Ahora haz las cuentas. Supongamos que un equipo de cinco personas añade Agentes y el rendimiento de ejecución se triplica. El rendimiento de revisión no se ha triplicado; lo sostienen las mismas cinco personas, y cada cambio aceptado cuesta atención real. Si planificas el Sprint en función de la capacidad de ejecución, el excedente no se convierte en valor entregado. Se convierte en una cola de trabajo sin revisar, y un cambio sin revisar es inventario, no progreso. Peor aún: un Sprint que se acerca a su cierre empuja a los revisores justo hacia el atajo que hace peligroso el desarrollo con muchos agentes: aceptar resultados sin leerlos.
Así que invierte la pregunta de planificación. En lugar de preguntar cuánto trabajo puede ejecutar el equipo en dos semanas, pregunta cuánto trabajo terminado de los Agentes pueden aceptar tus personas en dos semanas. En la práctica, esto cambia cuatro hábitos:
- Estima el coste de la revisión, no solo el de la construcción. Una Tarea que es trivial de ejecutar para un Agente puede seguir siendo cara de aceptar.
- Pon un tope al trabajo completado pero no aceptado de forma simultánea. Decide cuántas Tareas puede aceptar de verdad cada revisor por Sprint y deja de planificar más allá de esa suma. Es un acuerdo de trabajo, no una configuración de Sharkly, pero las métricas de finalización te dirán cuándo te has pasado.
- Libera la ejecución de forma deliberada. Como el Backlog aparca la ejecución, puedes escalonar los inicios para que el trabajo terminado llegue a un ritmo que los revisores puedan absorber, en lugar de todo de golpe el segundo día.
- Lee la tasa de finalización como una cifra de revisión. Cuando el burnup se aplana mientras los Agentes están parados, la restricción se ha anunciado sola. Eso es una señal para añadir revisores o comprometer menos, no para añadir Agentes.
Nada de esto frena a los Agentes. Los apunta en la dirección correcta. Un Sprint planificado en torno al rendimiento de aceptación entrega todo lo que compromete y nunca pide a una persona que apruebe código que no tuvo tiempo de leer.
Planificar un Sprint híbrido, paso a paso
- Activa los Sprints en el Espacio y elige un modo. Un ritmo de equipo estable apunta a la cadencia automática; el trabajo guiado por releases apunta al modo manual.
- Define el alcance. Lleva las Tareas candidatas al próximo Sprint mediante la planificación del Sprint o el campo Sprint. Deja el trabajo no comprometido sin Sprint.
- Asigna las dos mitades de cada Tarea. Sharkly separa la responsabilidad humana de la ejecución del Agente: las personas van en el conjunto de asignados y un Agente o un Crew va en la única ranura de ejecución. Cambiar una nunca cambia la otra.
- Escribe Tareas sobre las que un Agente pueda actuar. La descripción debe incluir el objetivo, las restricciones y los criterios de aceptación que necesitaría una persona nueva o un Agente para seguir adelante.
- Libera el trabajo al ritmo de la revisión. Saca Tareas de Backlog a medida que se libera capacidad de revisión.
- Cierra con intención. En el modo manual, elige a dónde va cada Tarea sin terminar. En la cadencia automática, revisa qué se trasladó al siguiente Sprint y pregúntate si se dimensionó demasiado grande o se revisó demasiado despacio.
La disciplina más amplia de trabajar así se cubre en nuestro artículo pilar sobre gestión de proyectos con agentes de IA; el Sprint es la porción con timebox de ese sistema.
Si hoy tus Sprints viven en Jira
No tienes que rehacer tu proceso para probar nada de esto. La integración de Sharkly con Jira puede importar los datos de Sprints de Jira y, cuando se activa la importación de Sprints, el Espacio de destino se puede cambiar al modo Jira Sprint, de modo que la cadencia que tu equipo ya sigue se traslada en lugar de empezar de cero. El tutorial sobre asignar un ticket de Jira a un Agente de IA muestra la misma idea a nivel de un solo ticket, y la documentación de Sharkly cubre en profundidad la configuración de Sprints y la integración con Jira.
Empieza con algo más pequeño que una migración: activa los Sprints en un Espacio, planifica una ventana de dos semanas según la capacidad de aceptación real de tus revisores y compara el burnup con tu último ciclo solo con personas.
Preguntas frecuentes
¿Tengo que usar Sprints en Sharkly?
No. Los Sprints son opcionales y se activan por Espacio. Un Espacio que prefiera el flujo continuo puede dejarlos desactivados por completo y, aun con los Sprints activados, una Tarea puede no tener ningún Sprint, que es el estado normal del trabajo del Backlog.
¿Qué ocurre con las Tareas sin terminar cuando acaba un Sprint?
En la cadencia automática, Sharkly completa el Sprint según lo previsto y traslada el trabajo sin terminar al siguiente. En el modo manual, el flujo de finalización te pregunta a dónde deben ir las Tareas sin terminar: a ningún Sprint, a otro Sprint activo o próximo, o a un Sprint recién creado.
¿Pueden los Agentes trabajar automáticamente en las Tareas del Sprint?
Un Agente o un Crew configurado como asignado de ejecución de una Tarea puede realizar el trabajo, pero la pertenencia al Sprint por sí sola nunca inicia nada. Backlog es un estado de estacionamiento, así que asignar un Agente a una Tarea en Backlog no inicia la ejecución; mover la Tarea a un estado listo es lo que puede arrancar la ejecución. Esa separación te permite planificar primero un Sprint completo y liberar la ejecución al ritmo que puedan absorber tus revisores.
¿Cómo calcula Sharkly la capacidad de un Sprint?
La capacidad usa la velocidad de los Sprints completados recientemente cuando hay suficiente historial y, si no, recurre a una estimación basada en el tamaño del Espacio. La documentación recomienda tratarla como un insumo de planificación y no como una garantía, algo que importa el doble en equipos híbridos, donde la velocidad mide todo el sistema y no el cuello de botella de revisión que hay dentro.
¿Puedo añadir una Tarea a un Sprint que ya ha terminado?
Solo se pueden añadir Tareas completadas a un Sprint anterior. Eso permite correcciones históricas, como acreditar trabajo terminado dentro de la ventana pero nunca registrado, sin colocar jamás trabajo sin terminar en un periodo cerrado.
