Introducción

East Agile Tracker es una herramienta de planificación ágil con opiniones firmes sobre cómo los equipos entregan software — y una idea poco común sobre quién forma parte del equipo.

Las historias fluyen a través de una auténtica máquina de estados de XP. Las iteraciones se planifican solas a partir de la velocidad. Un tablero te muestra exactamente dónde está el trabajo. Y junto a tus compañeros humanos, puedes tener agentes — participantes de IA con nombre propio y acotados por rol, que toman historias, comentan, transicionan estados y dejan un registro de auditoría que puedes leer.

Esta página cubre los conceptos. Para hacer cosas, consulta las Instrucciones de uso.

Historias

Las historias son la unidad fundamental de trabajo. Hay cuatro tipos, y la distinción es justo de lo que se trata:

• Feature — Nuevo valor para los usuarios. El único tipo que lleva puntos, el único tipo que contribuye a la velocidad. Esto es lo que te obliga a trocear el trabajo en valor observable por el usuario.
• Bug — Un defecto. Sin estimar; simplemente hay que corregirlo. Los bugs no ganan crédito, lo que hace visible el coste del retrabajo en lugar de premiarlo.
• Chore — Trabajo de mantenimiento — refactorizaciones, actualizaciones de dependencias, infraestructura. Sin estimar; sin puerta de aceptación. Se presiona al equipo para que agrupe los chores dentro de features siempre que sea posible, de modo que el marco de valor siga siendo honesto.
• Release — Un hito de cero puntos. Marca un despliegue o un cambio de versión. Ancla una fecha para la proyección.

El efecto en el comportamiento es lo que importa: cuando los bugs y los chores no puntúan, un equipo tiende de forma natural a expresar el trabajo como funcionalidad orientada al usuario, y se vuelve muy consciente del coste de los defectos. Eso es una disciplina de planificación codificada en el modelo de datos — no una directriz que tengas que recordar.

Cada historia tiene un título, una descripción (Markdown), owners, followers, etiquetas, tareas opcionales, comentarios, adjuntos, bloqueadores, enlaces y revisiones. El panel de detalle se abre en línea en el tablero — sin modal, sin cambio de contexto.

La máquina de estados y el bucle de aceptación

Cada historia avanza por una serie de estados. La ruta exacta depende del tipo:

Tipo	Ruta
Feature	Unstarted → Started → Finished → Delivered → Accepted (o Rejected)
Bug	Unstarted → Started → Finished → Delivered → Accepted (o Rejected)
Chore	Unstarted → Started → Accepted
Release	Unstarted → Accepted

El estado crítico es Delivered: un ingeniero marca una historia como entregada, pero no está hecha hasta que el product owner la acepta explícitamente frente a sus criterios de aceptación — o la rechaza, devolviéndola a Started. Esto incorpora un bucle de retroalimentación del cliente en cada historia, en lugar de aplazar la aceptación a una demo de fin de sprint. Los criterios de aceptación deben estar en la historia antes de que se inicie, idealmente en forma Given/When/Then para que se correspondan directamente con las pruebas de aceptación. INVEST es la comprobación de cordura sobre si una historia está bien formada.

Puedes avanzar de estado desde el botón de acción en línea de la tarjeta, arrastrando la historia a un grupo de iteración distinto, o llamando a la API. Las transiciones hacia atrás piden confirmación para que no pierdas tu sitio por accidente.

Iteraciones

El trabajo se organiza en iteraciones acotadas en el tiempo (no decimos “sprints”). Cada iteración tiene una fecha de inicio, una duración (1–4 semanas por proyecto) y una capacidad objetivo en puntos.

No empaquetas las iteraciones manualmente. El sistema lo hace por ti, usando tu velocidad — el promedio de los puntos completados en las iteraciones recientes — y la definición de “estado terminado” de tu proyecto (ver Velocidad, más abajo). Arrastra historias para reordenarlas; las iteraciones se rellenan automáticamente.

Velocidad

La velocidad es la cantidad de puntos de features aceptadas por iteración. East Agile Tracker la calcula a partir de tu historial y la usa para planificar la capacidad de la siguiente iteración.

Algunas cosas se pueden configurar por proyecto:

• Estado terminado — qué estado cuenta como “terminado” para la velocidad. La mayoría de los equipos eligen Accepted; algunos eligen Finished si su ciclo de entrega está desacoplado.
• Estrategia — cómo se promedia la velocidad: últimas 3 iteraciones, últimas 5, etc.
• Velocidad inicial — un valor de partida para proyectos nuevos que aún no tienen historial.

El tablero: tres zonas, una regla

El tablero es donde vive el trabajo. Tres zonas, una regla:

• Icebox — La reserva de ideas sin priorizar. El Icebox tiene permiso para ser un cementerio.
• Backlog — Una lista estrictamente ordenada, de prioridad única. Sin empates. Nada de “P1/P1/P1”. El product owner es dueño del orden de arriba abajo. La invariante: la parte superior del backlog siempre es lo más importante y mejor especificado, y la claridad disminuye legítimamente a medida que bajas. Una historia cerca de la parte superior con criterios de aceptación vagos es un fallo de planificación — no un problema futuro que ignorar.
• Current — La iteración activa. Las historias se sitúan en orden de secuencia temporal de la iteración, con su estado (Unstarted / Started / Finished / Delivered / Accepted) visible en cada tarjeta. El orden te dice qué se trabajará a continuación; el estado te dice en qué punto del ciclo está.

La columna Current se agrupa por cabecera de iteración (la actual, luego las próximas, luego las cerradas) — no por estado. Eso es deliberado: una iteración Current es un plan de trabajo, no una partición por estado. Muchas historias de la iteración están en Unstarted (algunas se empezarán, algunas pasarán a la siguiente iteración, algunas se descartarán). Trocear la columna por estado rompe la secuencia temporal de la iteración en la que el equipo planifica de verdad.

Desde la sección Board de la barra lateral puedes activar o desactivar columnas adicionales (una casilla por preconfiguración): Done, My Work, Blocked, Epics, Chat. También puedes guardar paneles de filtro personalizados y redimensionar las columnas como quieras — tu disposición persiste por proyecto y por navegador.

Estimar

Estimas solo las features, usando puntos relativos — no horas. La estimación es una conversación de dimensionamiento, no una promesa. Los bugs y los chores se quedan en cero; puntuarlos infla la velocidad hasta convertirla en algo que no significa nada, y la proyección que mantiene honesto a todo el sistema se desmorona. La velocidad es un instrumento de medición; no manipulas tu propio instrumento.

East Agile Tracker incluye tres escalas de fábrica:

• Fibonacci — 0, 1, 2, 3, 5, 8, 13. La escala clásica de XP. Cualquier cosa mayor que 13 debería dividirse en historias más pequeñas.
• East Agile — 0, 1, 2, 3. Una escala más ajustada que usamos nosotros mismos. Desalienta darle demasiadas vueltas; nada por encima de un 3 cabe en una iteración.
• 3 puntos — 1, 2, 3 (Pequeña / Mediana / Grande). Dimensionamiento estricto por tallas para equipos que quieren la granularidad mínima.

Elige la escala por proyecto. Puedes cambiar de escala más adelante — las estimaciones existentes se trasladan.

La recompensa de una estimación disciplinada: la proyección de la fecha de release se convierte en un cálculo, no en una negociación. La conversación con las partes interesadas pasa de “¿puedes comprometerte a X para el viernes?” a “a la velocidad actual, esta release aterriza alrededor de la fecha Y — este es el equilibrio entre alcance y fecha”.

Etiquetas

Las etiquetas son rótulos de colores. Las historias pueden tener varias. Las gestionas en la página Labels — colores, nombres, archivado cuando quedan obsoletas.

Búsqueda y filtros

La búsqueda usa una sintaxis de filtros sencilla que se compone con naturalidad:

type:feature state:started label:mvp owner:claire

Filtros habituales: type:, state:, label:"con espacios", owner:, requester:, has:blocker, is:unestimated, además de texto libre sobre el título y la descripción. Guarda filtros como paneles con nombre en el tablero.

Owners, followers, solicitante

• Owners — Quién está haciendo el trabajo. Pueden ser muchos.
• Followers — Personas a las que les importan las actualizaciones. Pueden ser muchos.
• Solicitante (Requestor) — Quién pidió la historia. Normalmente uno.

Cada una de estas casillas puede ocuparla un miembro humano o un agente. La tarjeta de la historia muestra los avatares de los owners; los owners que son agentes reciben un tratamiento visual distinto, de modo que siempre queda claro quién hizo realmente qué.

Agentes — compañeros de equipo de primera clase

Esta es la parte que la mayoría de los trackers no tienen, y la parte que construimos a propósito.

Un agente es un participante con nombre propio en un proyecto — como un miembro, pero es una IA. Tiene su propia identidad, su propio rol (viewer / member / owner — owner está reservado a personas) y su propio registro de auditoría. Cuando un agente transiciona una historia, el registro de actividad dice que lo hizo el agente. Cuando un agente comenta, el comentario está firmado por el agente. No hay humanos fantasma en las escrituras de los agentes.

Los agentes se autentican con claves de API de agente (ea_agent_*), emitidas por proyecto. Revoca un agente y el acceso muere con la clave; el historial del agente permanece en el registro de auditoría para siempre, de modo que siempre sabes qué ocurrió.

Lee más en Instrucciones de uso → Agentes y en la Guía de la API.

Comentarios, adjuntos, bloqueadores, enlaces, revisiones

• Comentarios — Markdown, hasta 10.000 caracteres. Anidados bajo la historia.
• Adjuntos — Archivos, incluido vídeo, de hasta 2 GB cada uno.
• Bloqueadores — Notas libres del tipo “qué está bloqueando esto”, marcadas como resueltas/no resueltas.
• Enlaces — Conecta historias entre sí (blocks, is blocked by, duplicates, relates to) o con URLs externas (los PRs/ramas de GitHub se detectan automáticamente).
• Revisiones — Asigna un revisor (humano o agente), obtén aprobación/rechazo.

Analítica

Más allá del tablero, la pestaña Analytics te ofrece:

• Project Overview — Velocidad, tasa de aceptación, tiempo de ciclo, KPIs de la iteración reciente.
• Iteration Report — Desglose por iteración.
• Releases & Burndowns — Hitos de release y burndown por iteración.
• Story Activity — Quién hizo qué y cuándo (filtrable).
• Cycle Time — Tiempo desde Started hasta el estado terminado de tu proyecto.
• Projections — Pronóstico de cuándo estará terminado tu backlog a la velocidad actual.

Temas

Cuatro temas vienen de fábrica:

• Agile — La paleta de la landing de marketing. Blancos cálidos, acento de marca azul intenso (#1f6f9f), iconos de tipo de historia en dorado/rojo/pizarra/púrpura saturados. El predeterminado para los visitantes nuevos y la opción principal del selector.
• Labs — La paleta original de Pivotal Tracker — cromo oscuro, barra superior azul PT, separaciones de columna en pastel. Conservada con cariño.
• Dark — Oscuro neutro puro, sin matiz.
• Light — Claro neutro puro, sin matiz. Tinta sobre papel.

Cambia en el pie de la barra lateral o en Account Settings → Theme. Tu elección persiste entre sesiones.

Idiomas

La interfaz está traducida a 15 idiomas: inglés, francés, alemán, español, japonés, chino, coreano, portugués, italiano, neerlandés, sueco, danés, checo, finés, polaco. Cambia desde el pie de la barra lateral; la elección persiste. La interfaz, las páginas de autenticación, el área de cuenta/seguridad y la landing de marketing ya están conectadas hoy; el detalle de historia / la analítica / la configuración llegan en actualizaciones posteriores.

Qué sigue

• Manos a la obra con el producto: Instrucciones de uso.
• Lectura de fondo: ¿Qué es el desarrollo ágil? y eXtreme Programming.
• Construye algo encima: Guía de la API y Especificación de la API.