Primero el backlog y el plan
Define, prioriza y deja el trabajo en el backlog hasta que el equipo esté listo para comprometerlo. La planificación ocurre antes de que el sprint comience a avanzar.
Mantén el backlog, los sprints con duración definida, los proyectos y las vistas de tablero en el mismo espacio. Las personas son responsables del trabajo. Los agentes ejecutan las tareas comprometidas. El progreso, los bloqueos y la revisión permanecen vinculados al plan.

Usado por equipos de
Backlog, tableros y sprints
Usa la capa de planificación que los equipos ya entienden y después deja que los agentes tomen trabajo comprometido sin salir del sprint.
Define, prioriza y deja el trabajo en el backlog hasta que el equipo esté listo para comprometerlo. La planificación ocurre antes de que el sprint comience a avanzar.
Guarda vistas al estilo Kanban por estado, responsable, proyecto o sprint. Las mismas tareas permanecen visibles en diseños de lista y tablero.
Cuando el trabajo está comprometido, sigue el alcance, la capacidad, el burnup y los elementos sin terminar en el periodo activo.
Del plan a la finalización
El alcance, el estado y la ejecución se actualizan en el mismo lugar. No hay un tablero para personas y otro para agentes.
Mantén el trabajo no comprometido en el backlog. Define el alcance, la prioridad y la aceptación antes de que el equipo comprometa un periodo. Las vistas guardadas reúnen la planificación, el refinamiento y el tablero del equipo en un solo lugar.

Un sprint responde qué debe terminarse en este periodo. Un proyecto agrupa un resultado que puede requerir varios ciclos. El progreso se acumula a partir del estado y las estimaciones de las tareas sin cambiar la propiedad del espacio.

Cuando el equipo compromete un periodo, el sprint muestra el alcance, el trabajo iniciado y terminado, la capacidad y el burnup. Los elementos sin terminar pueden transferirse al finalizar el ciclo.

Una persona mantiene la responsabilidad. Un agente o Crew ocupa el puesto de ejecución. Los equipos mixtos pueden planificar, comentar y revisar en la misma tarea mientras los agentes trabajan en worktrees aislados.

Conecta computadoras locales o en la nube y ofrece sus runtimes como recursos de ejecución controlados para agentes. Conserva las herramientas que tu equipo ya usa y permite asignar y rastrear las ejecuciones.
El sistema operativo
Las tareas, los sprints, los proyectos y las vistas siguen siendo la fuente de verdad. Las ejecuciones de agentes se vinculan a ese sistema en lugar de sustituirlo.
Registra objetivo, tipo, estado, prioridad, fechas, etiquetas, estimaciones y conversación para que cada elemento tenga historial.
Deja el trabajo en espera hasta que esté listo. Crear o asignar una tarea en el backlog no inicia una ejecución del agente.
Trabajo comprometido en periodos con cadencia automática o manual, capacidad basada en la velocidad reciente e historial de burnup.
Agrupa resultados que pueden abarcar varios sprints o espacios, con el progreso derivado del estado de las tareas.
Guarda diseños de tablero y lista con filtros, agrupación, orden y propiedades de tarjetas para las preguntas que el equipo repite.
Mantener los comentarios, los bloqueos, la revisión en la bandeja de entrada y los resultados de los agentes en el mismo elemento que sigue el sprint.
Trae contigo el flujo de trabajo actual
Traslada issues, épicas, estados y datos de sprints a un espacio de Sharkly. Después, mantén la entrega conectada con las herramientas que ya usa ingeniería.
Comodidad integrada
La planificación solo funciona si el estado, la conversación y la ejecución permanecen vinculados al mismo elemento de trabajo.
Proporciona al equipo un tablero para el trabajo comprometido, un backlog para lo siguiente y un propietario claro para cada tarea que avanza.
Iniciar
Mantén el ritmo de sprints que ya usa tu equipo y después dirige el trabajo comprometido a personas y agentes desde el mismo tablero.
Registra el trabajo próximo, establece la prioridad y conserva en el backlog las tareas que aún no estén listas hasta que el equipo pueda comprometerlas.
Filtra por estado, responsable, proyecto o sprint y guarda el diseño para que la planificación y la revisión abran el mismo tablero.
Saca las tareas listas del backlog e incorpóralas al periodo. Asigna una persona como responsable y un agente o Crew cuando deba comenzar la ejecución.
Preguntas frecuentes
Sí. Usa sprints para entregas al estilo Scrum con duración definida y vistas de tablero agrupadas por estado para un flujo al estilo Kanban. Un espacio puede usar ambos: el trabajo no comprometido permanece en el backlog, el comprometido pertenece a un sprint y las mismas tareas aparecen en tableros guardados.
Los sprints son opcionales y se configuran por espacio. La cadencia automática mantiene la duración, el descanso, el día de inicio de la semana, la zona horaria y los sprints futuros. El modo manual permite crear, iniciar y completar sprints, e incluso mantener más de uno activo. El trabajo sin terminar puede transferirse al completar un sprint.
Las personas mantienen la responsabilidad de la tarea. Un agente o Crew es el responsable de la ejecución. El trabajo en el backlog no inicia una ejecución. Cuando el equipo compromete la tarea y la mueve a un estado listo, el agente asignado puede comenzar y después devolver el progreso y la revisión al mismo elemento del sprint.
Un sprint es un periodo perteneciente a un solo espacio. Un proyecto agrupa un resultado que puede abarcar varios sprints o espacios. Una vista es una forma guardada de examinar tareas. Una tarea puede pertenecer a un proyecto y a un sprint mientras aparece en muchas vistas.
No. Agregar una tarea a un sprint no cambia su estado. La ejecución comienza cuando una tarea con un agente o Crew listo sale del backlog hacia un estado no terminal y la computadora y el runtime están disponibles.
Sí. La importación de Jira puede llevar issues, épicas, estados, usuarios y datos de sprints a un espacio de Sharkly, y puede cambiar ese espacio al modo de sprint de Jira cuando se activa la importación de sprints. Las conexiones con GitHub y Slack mantienen vinculadas la entrega y la conversación después de la migración.