Guía de gestión ágil de proyectos digitales

Orientaciones prácticas para planificar, ejecutar y dar seguimiento a proyectos digitales del Estado utilizando enfoques ágiles, desde el descubrimiento hasta el cierre.

Qué resuelve y a quién está dirigido

Esta guía entrega orientaciones prácticas para planificar, ejecutar y dar seguimiento a proyectos digitales utilizando enfoques ágiles. Cubre el ciclo completo del proyecto, desde el descubrimiento hasta el cierre, incluyendo las fases técnicas de aseguramiento de calidad y publicación que suelen quedar fuera de las metodologías de gestión de proyectos más generales.

Está dirigida a:

• Líderes/as y patrocinadores/as de proyectos digitales.
• Product Owners y responsables de priorización de producto.
• Scrum Masters o facilitadores/as de equipos ágiles.
• Equipos de desarrollo, diseño y QA que ejecutan el proyecto.
• Equipo de gestión de proyectos (PMO), como referencia de coherencia metodológica.

Cuándo utilizarlo y cuándo no

Esta guía no reemplaza la Metodología para la gestión de proyectos vigente de la SGD, sino que la complementa. Ambas se usan en conjunto y resuelven necesidades distintas dentro de un mismo proyecto.

Utiliza la Metodología para la gestión de proyectos SGD si necesitas:

• Definir las fases formales del proyecto, sus hitos y su gobernanza.
• Autorizar el proyecto, asignar presupuesto o reportarlo a nivel de portafolio institucional.
• Resolver compromisos contractuales, de licitación o de ciclo presupuestario.
• Definir los roles institucionales que autorizan y supervisan el proyecto.

Utiliza esta guía si necesitas:

• Decidir cómo el equipo organiza su trabajo día a día dentro de las fases ya definidas.
• Elegir entre sprints, flujo continuo o una combinación de ambos.
• Establecer ceremonias, tableros de trabajo y métricas de avance a nivel de equipo.
• Definir cómo operan roles de ejecución ágil (Product Owner, Scrum Master, equipo de desarrollo) dentro de la gobernanza que ya define la Metodología SGD.

Cuando ambos documentos se refieren a gobernanza, hitos de portafolio o reporte institucional, prevalece lo explicado en la Metodología para la gestión de proyectos SGD.

Reglas o criterios principales

Adoptar gestión ágil no consiste solo en incorporar ciertas reuniones o rituales, sino que implica un cambio en cómo se planifica el trabajo, se comunica el avance y se toman decisiones sobre el alcance de un proyecto. Los siguientes principios orientan ese cambio:

• Valor por sobre alcance fijo. El éxito no se mide únicamente por cumplir exactamente el alcance definido al inicio, sino por el valor que se entrega en cada ciclo de trabajo. Las prioridades pueden, y deben, reordenarse cuando aparece evidencia de que otra funcionalidad genera más beneficio.
• Transparencia del avance. El estado del trabajo, las métricas de progreso y los riesgos identificados deben estar visibles en todo momento para el equipo, quien encarga el proyecto y cualquier otra parte interesada, reemplazando a los informes de avance extensos y esporádicos.
• Entrega incremental. El proyecto habilita funcionalidad en incrementos pequeños y frecuentes (idealmente cada una o dos semanas) en lugar de un único lanzamiento al final, para detectar y corregir errores temprano.
• Mejora continua. Cada ciclo de trabajo cierra con una instancia de reflexión que revisa tanto el producto construido como la forma de trabajo del equipo, alimentando ajustes concretos para el ciclo siguiente.
• Colaboración continua con quien encarga el proyecto. Quien encarga el proyecto o representa a los usuarios finales participa de forma recurrente —revisa incrementos, valida prioridades y ajusta expectativas— en vez de concentrar la validación en una aprobación formal al inicio y otra al final.
• Adaptación continua al cambio. La gestión ágil asume que el cambio es normal y prioriza responder a él por sobre seguir rígidamente un plan que ya no refleja la realidad del proyecto.
• Gestión adaptativa de riesgos. Los riesgos se revisan en cada ciclo de planificación y de seguimiento, incorporando lo que el equipo va aprendiendo a medida que ejecuta, para anticipar y mitigar problemas antes de que se vuelvan críticos.

Cómo aplicarlo

Enfoques ágiles y criterios para elegirlos

Existen distintas formas de organizar el trabajo ágil de un proyecto. La elección no tiene por qué ser única ni definitiva para todo el proyecto: un mismo proyecto puede combinar enfoques a lo largo de su ciclo de vida, e incluso tener más de un equipo trabajando en paralelo con enfoques distintos.

Scrum

Organiza el trabajo en bloques de tiempo fijo llamados sprints, durante los cuales el equipo se compromete a alcanzar un objetivo de sprint (Sprint Goal), seleccionando el trabajo que estima necesario para lograrlo. El compromiso real de Scrum es con ese objetivo, no con completar una cantidad fija de historias: si durante un sprint se descubre que algunas historias ya no son necesarias, o se requieren ajustes, el sprint backlog puede renegociarse con el Product Owner sin que eso signifique incumplir el sprint.

Conviene usar Scrum cuando el alcance del proyecto es cambiante, se necesita una cadencia predecible de entrega, y el equipo puede mantenerse relativamente estable para comprometerse a un ritmo fijo de trabajo.

Términos propios de Scrum: backlog de producto (lista priorizada de todo el trabajo pendiente), sprint (bloque de tiempo fijo, normalmente de una a cuatro semanas, comúnmente dos), Sprint Goal (propósito único que el equipo se compromete a alcanzar durante el sprint), historia de usuario (unidad de trabajo descrita desde la perspectiva de quien la usará) y Definición de Terminado (DoD) (lista acordada que define cuándo un incremento se considera realmente completo). Para profundizar en otros conceptos de Scrum (Sprint Planning, Daily, Revisión de sprint, Retrospectiva, estimación de esfuerzo y velocidad), consulta la Scrum Guide oficial.

Kanban

Organiza el trabajo como un flujo continuo, visualizado en un tablero, sin bloques de tiempo fijo. En vez de comprometerse a un conjunto cerrado de trabajo por adelantado, el equipo limita cuánto trabajo puede tener en curso simultáneamente y va incorporando nuevas tareas a medida que se libera capacidad.

Conviene usar Kanban cuando el trabajo llega como un flujo continuo de solicitudes (por ejemplo, soporte o mejoras menores), las prioridades cambian con frecuencia, o el proyecto corresponde a la mantención continua de un servicio ya en producción, sin una fecha de término definida.

Términos propios de Kanban: tablero Kanban (representación visual del flujo de trabajo en columnas por estado), flujo de trabajo (secuencia de estados por los que pasa una tarea; gestionarlo significa identificar dónde se acumula o se atasca el trabajo y actuar sobre esas causas) y límite de trabajo en curso (WIP limit) (número máximo de tareas permitidas simultáneamente en una columna). Para profundizar en otros conceptos (política explícita, reposición, lead time, cycle time y throughput), consulta la guía oficial de Kanban.

Enfoque híbrido

Combina hitos y fases formales asociados a compromisos externos (un contrato, una licitación o un hito regulatorio) con una ejecución iterativa dentro de cada fase, ya sea con lógica de Scrum, de Kanban, o de ambos según el momento del proyecto.

Conviene usarlo cuando existen compromisos externos con fecha y alcance fijos, combinados con la necesidad de ejecutar el trabajo técnico de forma iterativa. Es también el enfoque más común cuando un mismo proyecto pasa por más de una etapa con necesidades distintas.

Términos propios: hito (punto de control formal asociado a un compromiso externo), fase (bloque más amplio de trabajo delimitado por hitos) e iteración (ciclo corto de trabajo, equivalente a un sprint o a un periodo de flujo Kanban, que ocurre dentro de una fase).

Cómo elegir entre los tres

Un mismo proyecto puede usar una lógica más cercana a Kanban durante el descubrimiento, cuando el flujo de hallazgos y validaciones es irregular, y pasar a Scrum durante la construcción, cuando el equipo ya tiene mayor certeza sobre el alcance que puede comprometer en cada iteración. También puede haber más de un equipo trabajando en paralelo con enfoques distintos, como cuando un equipo construye una nueva funcionalidad en Scrum mientras otro sostiene el soporte del servicio actual en Kanban.

El ciclo del proyecto

Las cuatro etapas siguientes —priorización, entrega, validación y aprendizaje— cubren desde la gestión (planificación, seguimiento, cierre) hasta la ejecución técnica (QA, publicación). No ocurren una sola vez a lo largo del proyecto, sino que se repiten dentro de cada iteración: cada sprint, o cada ciclo de flujo en Kanban, pasa por su propia priorización, entrega y validación. Solo el aprendizaje de cierre final del proyecto ocurre típicamente una vez.

1. Priorización

Busca entender el problema real antes de construir una solución, y luego decidir qué se abordará en el siguiente incremento de trabajo. Comienza con evidencia, no solo con supuestos internos, y culmina cuando el equipo se compromete con un conjunto de trabajo para el siguiente ciclo. En Scrum ocurre en el Sprint Planning; en Kanban, de forma más continua mediante instancias de reposición. Suele tomar entre 2 y 4 semanas la primera vez (descubrimiento), y cada ciclo de planificación posterior es una reunión breve de 2 a 4 horas (Scrum) o instancias recurrentes (Kanban); estas duraciones son orientativas.

Actividades clave: entrevistas o levantamiento con usuarios finales; análisis de datos de uso existentes; talleres de priorización conjunta; construcción del backlog y de un mapa de valor; sesión de planificación (Sprint Planning o reposición); estimación de esfuerzo; acuerdo explícito de la Definición de Terminado; identificación temprana de dependencias externas.

Entregable esperado: backlog inicial priorizado; mapa de valor; sprint backlog o tablero repuesto; Definición de Terminado documentada.

2. Entrega

Es el desarrollo del incremento comprometido, con coordinación diaria y visibilidad constante del avance en el tablero. El aseguramiento de calidad se integra dentro de cada iteración, no se deja como una etapa final aislada, e incluye pruebas funcionales, de accesibilidad y de usabilidad. El paso a producción se habilita de forma incremental, con capacidad de revertir rápidamente si algo falla. La etapa dura lo mismo que el sprint definido (Scrum) o es continua respetando los límites de trabajo en curso (Kanban); la duración del despliegue varía según la criticidad del servicio.

Actividades clave: desarrollo iterativo; daily; actualización del tablero visual; revisiones de diseño y código entre pares; pruebas funcionales, de accesibilidad y de usabilidad; registro y seguimiento de hallazgos; elaboración del plan de despliegue; pruebas en pre-producción (staging); despliegue gradual; monitoreo activo tras cada publicación.

Entregable esperado: incrementos de producto funcionales y probados; tablero actualizado; checklist de QA por incremento; plan de despliegue; registro de la versión publicada.

3. Validación (seguimiento y control)

El avance se reporta a quien corresponde y se mide con métricas propias del enfoque elegido: velocidad y burndown/burnup en Scrum; y en Kanban, lead time (tiempo total desde que una tarea se solicita hasta que se entrega), cycle time (tiempo que la tarea pasa en ejecución activa) y throughput (cantidad de tareas completadas por periodo).

Estas métricas de flujo describen cómo avanza el trabajo del equipo, pero no dicen por sí solas si ese trabajo generó el resultado esperado en el servicio o trámite digital. Por eso el seguimiento debe combinar dos tipos de métricas: las de flujo ya mencionadas, con métricas de resultado —por ejemplo, tasa de cumplimiento de tareas por parte de las personas usuarias, errores reportados, abandono, satisfacción y cumplimiento de accesibilidad— que habitualmente provienen de la analítica del servicio o de investigación con usuarios.

Actividades clave: actualización periódica del tablero de métricas; reporte de avance; gestión activa de riesgos e impedimentos; incorporación de indicadores de resultado del servicio junto a las métricas de flujo del equipo.

Entregable esperado: tablero de métricas de ejecución; indicadores de resultado del servicio cuando estén disponibles; informe de avance periódico.

4. Aprendizaje (cierre y retrospectiva)

El ciclo, de un sprint o del proyecto completo, cierra con una revisión conjunta del equipo que documenta aprendizajes y define compromisos concretos de mejora, además del cierre administrativo cuando corresponda. La instancia toma entre 1 y 2 horas al cierre de cada ciclo o del proyecto.

Actividades clave: sesión de retrospectiva con todo el equipo; cierre administrativo o contractual cuando el proyecto lo requiera; traspaso formal a operación y mantención del servicio.

Entregable esperado: acta de retrospectiva; backlog de mejoras para el próximo ciclo; documento de traspaso a mantención.

Roles y responsabilidades

La gestión ágil no elimina los roles tradicionales de la gestión de proyectos, pero sí redistribuye cómo se toman las decisiones día a día.

• Patrocinador/a. Autoriza el proyecto y respalda su alcance estratégico. Da legitimidad y respaldo institucional, y está disponible para resolver bloqueos que superan las atribuciones del equipo. No participa en el trabajo diario.
• Product Owner. Representa a los usuarios finales y a quien encarga el proyecto. Su responsabilidad central es maximizar el valor del producto: gestiona el backlog priorizando, decide qué se construye primero, y se asegura de que el backlog sea visible y comprendido por el equipo. Es el rol con mayor dedicación continua durante todo el proyecto.
• Scrum Master (facilitador/a ágil). Facilita las ceremonias del equipo y vela por que la forma de trabajo acordada se sostenga en el tiempo. Protege al equipo de interrupciones y ayuda a resolver impedimentos, sin dirigir el trabajo técnico ni priorizar el alcance.
• Equipo de desarrollo. Incluye a quienes diseñan, desarrollan, prueban y documentan el incremento de producto. Autogestiona cómo distribuye el trabajo dentro de cada iteración para cumplir el compromiso acordado.
• Equipo de gestión de proyectos (PMO). Da seguimiento transversal a los proyectos del portafolio, asegurando que la ejecución ágil de cada equipo sea coherente con los compromisos institucionales de más alto nivel, sin intervenir en el detalle operativo diario.

La siguiente matriz resume qué hace cada rol en cada etapa del ciclo:

Herramientas y plantillas de apoyo

Pueden adaptarse a cualquier plataforma disponible (Jira, Trello, Azure DevOps, entre otras) o usarse directamente como planilla o documento simple si el equipo no cuenta con una herramienta digital habilitada. Lo relevante no es la herramienta específica, sino que estén siempre visibles y actualizadas para todo el equipo.

Plantilla de objetivo y Definición de Terminado. Deja explícito, antes de empezar a construir, cuál es el objetivo del ciclo (Sprint Goal) y qué condiciones mínimas debe cumplir cualquier incremento para considerarse terminado. Se acuerda al iniciar la planificación, se deja visible para todo el equipo, se revisa antes de mover una tarjeta a "Terminado", y se ajusta cuando una retrospectiva detecta que algo relevante quedó fuera.

Plantilla de backlog priorizado. Mantiene visible y ordenado todo el trabajo pendiente del proyecto. Cada historia se registra con una descripción breve y el valor esperado que justifica su prioridad; el Product Owner es responsable de mantenerlo actualizado y de reordenarlo en cada instancia de planificación.

Plantilla de planificación de entrega. Estructura cómo el equipo organiza y visualiza el trabajo durante la entrega, con sprints o con flujo continuo: columnas del tablero, límites de trabajo en curso (WIP) cuando aplica, e historias seleccionadas para el ciclo con su responsable y estado.

Plantilla de retrospectiva y registro de decisiones. Captura aprendizajes sobre cómo trabajó el equipo y deja trazabilidad de las decisiones y ajustes acordados: qué funcionó bien, qué no funcionó, mejoras acordadas, y un registro de decisiones con fecha, responsable y motivo.

Las cuatro plantillas están disponibles como archivos descargables en la carpeta de recursos de gestión ágil y se detallan en la sección Recursos y contenidos relacionados.

Recomendaciones para aplicar esta guía en el sector público

Los principios, enfoques y prácticas descritos en esta guía son aplicables a cualquier organización. Estas son las consideraciones específicas para aplicarlos dentro de una institución pública:

• Vincula la ejecución ágil con la gobernanza de portafolio. Los compromisos institucionales (presupuesto, plazos regulatorios, hitos de un convenio o licitación) se resguardan a nivel de portafolio y se reportan según la gobernanza institucional. La gestión ágil cambia cómo se ejecuta el trabajo para cumplir esos compromisos; es la PMO quien articula ambos niveles.
• Compatibiliza la entrega ágil con los ciclos de contratación y presupuesto. Cuando el proyecto involucra contratación de terceros o presupuesto sujeto a ciclos anuales, fija los hitos contractuales y presupuestarios como los "hitos" del enfoque híbrido, dejando la ejecución técnica dentro de cada fase a cargo de sprints o de flujo Kanban. Valida esta compatibilización con la unidad jurídica y financiera de tu institución.
• Genera evidencia útil también para la rendición de cuentas. Los mismos artefactos ágiles —backlog priorizado, actas de retrospectiva, tableros de métricas— pueden aportar como evidencia de avance y de uso responsable de recursos, siempre que se mantengan actualizados y accesibles. Valida con las áreas de auditoría o control de tu institución qué evidencia se requiere formalmente.
• Incorpora los estándares de accesibilidad digital vigentes dentro de la Definición de Terminado. No debería quedar como una revisión aparte al final del proyecto (ver Consideraciones de contenido y accesibilidad).
• Mantén una contraparte institucional con participación continua. La unidad dueña del servicio o trámite debe participar de forma recurrente durante todo el proyecto, y no solo en una aprobación inicial y otra final.
• Reserva un rol acotado y puntual para el patrocinador institucional. Su participación debe concentrarse en los hitos de revisión de portafolio y en la remoción de bloqueos que exceden al equipo, evitando convertirse en un punto de aprobación operativa del día a día.

Ejemplos recomendados y no recomendados

Recomendado — caso de aplicación: un equipo de cinco personas debe rediseñar el formulario de solicitudes de una plataforma digital, en un plazo de diez semanas, sin dejar de atender el soporte de la versión actualmente en producción.

• Semanas 1 a 3, descubrimiento (Kanban): el equipo trabaja en flujo, no en sprints, porque el ritmo de los hallazgos es irregular. Usa un tablero con un límite de trabajo en curso de tres tareas en "En análisis" y hace reposiciones breves a medida que se cierran hallazgos. Al término, cuenta con un backlog priorizado de 24 historias y un mapa de valor.
• Semanas 4 a 9, planificación y ejecución (Scrum, tres sprints de dos semanas): con el alcance más estable, el equipo cambia a Scrum. En el primer Sprint Planning estima una capacidad de 18 puntos y se compromete con nueve historias, definiendo como objetivo "habilitar el ingreso de datos básicos del formulario". Se coordina con un daily diario y el QA se ejecuta dentro de cada sprint como parte de la Definición de Terminado, no al final del proyecto.
• Sprints 2 y 3, publicación incremental: al cierre del segundo sprint, el incremento se despliega primero a pre-producción y luego a un 10% de los usuarios, con un plan de reversa definido. Al cierre del tercer sprint se completa la liberación al 100%.
• Seguimiento y mezcla de enfoques en paralelo: mientras el equipo principal ejecuta los sprints de construcción, dos integrantes atienden el soporte de la versión actual en un tablero Kanban aparte, con su propio límite de trabajo en curso. La PMO consolida el reporte combinando la velocidad y el burndown del equipo Scrum con el lead time y el throughput del equipo de soporte en Kanban.
• Semana 10, cierre: el equipo hace la retrospectiva del tercer sprint, documentando aprendizajes sobre la coordinación entre ambos tableros y el despliegue incremental. El formulario se traspasa a mantención, integrándose al tablero Kanban del equipo de soporte, y el proyecto se cierra formalmente ante quien lo encargó.

No recomendado — riesgos comunes a evitar en cada etapa:

• Priorización: saltarse el descubrimiento por presión de plazos, lo que suele derivar en retrabajo costoso; o comprometer más trabajo del que el equipo puede sostener de forma realista, afectando la confianza del equipo y de quien encarga el proyecto.
• Entrega: acumular trabajo en curso sin cerrarlo, lo que oculta el verdadero avance; dejar el QA solo para el final, generando un cuello de botella antes del lanzamiento; o lanzar el cien por ciento del alcance de una sola vez, sin un plan de reversa definido.
• Validación: reportar únicamente métricas de flujo del equipo (velocidad, throughput) sin visibilizar el resultado que el trabajo generó para las personas usuarias en cada ciclo.
• Aprendizaje: omitir la retrospectiva por falta de tiempo, la práctica que más rápido se sacrifica bajo presión, lo que hace que el equipo repita los mismos errores en el ciclo siguiente.

Consideraciones de contenido y accesibilidad

• Incorpora los estándares de accesibilidad digital vigentes explícitamente en la Definición de Terminado de cada incremento, dentro de la etapa de entrega, en lugar de dejarlos como una revisión aparte al final del proyecto.
• Redacta las historias de usuario y los criterios de aceptación en lenguaje claro, comprensible tanto para el equipo técnico como para quien encarga el proyecto (ver Material de apoyo: lenguaje claro).
• Los tableros e informes de avance deben comunicar el valor entregado en cada ciclo, no solo el cumplimiento de plazos, siguiendo el principio de transparencia del avance.
• Mantén visibles las métricas de resultado orientadas a las personas usuarias (abandono, satisfacción, cumplimiento de accesibilidad) junto a las métricas de flujo del equipo, para que el seguimiento del proyecto no se limite a la productividad interna.

Checklist de implementación o revisión

Recursos y contenidos relacionados

Plantillas de apoyo:

• Plantilla de objetivo y Definición de Terminado.
• Plantilla de backlog priorizado.
• Plantilla de planificación de entrega.
• Plantilla de retrospectiva y registro de decisiones.

Guías relacionadas del sistema de diseño:

• Metodología para la gestión de proyectos (SGD).
• Investigación usuaria.
• Prototipado y testeo.
• Adopción del Sistema de Diseño.
• Diseño de servicios digitales.

Evidencia o fuentes

• Scrum Guide oficial.
• Kanban Guide oficial.
• Guía Recomendaciones para la gestión ágil de proyectos digitales, versión 2.0, Secretaría de Gobierno Digital (SGD).