Guía de Recomendaciones para la gestión ágil de proyectos digitales

1. Propósito y alcance

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.

Esta guía no reemplaza la Metodología para la gestión de proyectos (enlace: https://wikiguias.digital.gob.cl/guias/Gestion_de_proyectos ) vigente de la SGD, sino que la complementa al ser específica para proyectos con componente digital y necesidad de iteración rápida. Cuando ambos documentos se refieren a gobernanza, hitos de portafolio o reporte institucional, prevalece la explicado en Metodología para la gestión de proyectos (enlace: https://wikiguias.digital.gob.cl/guias/Gestion_de_proyectos ). La presente guía detalla cómo ejecutar esos mismos compromisos con prácticas ágiles a nivel de equipo.

2. Público objetivo

Esta guía 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.

3. Principios de la gestión ágil de proyectos

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. Esto significa que las prioridades pueden, y deben, reordenarse cuando aparece evidencia de que otra funcionalidad genera más beneficio, incluso si eso implica dejar fuera algo planeado originalmente.

Transparencia del avance

El estado del trabajo, las métricas de progreso y los riesgos identificados deben estar visibles en todo momento, considerando al equipo, a quien encarga el proyecto y cualquier otra parte interesada. Esta transparencia reemplaza a los informes de avance extensos y esporádicos: el estado real del proyecto puede revisarse en cualquier momento.

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. Esto reduce el riesgo: si algo no funciona como se esperaba, se detecta y corrige temprano, con un costo mucho menor que si se descubre recién al cierre del proyecto.

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, y que alimenta ajustes concretos para el ciclo siguiente. La mejora no es un evento aislado al final del proyecto, sino una práctica incorporada en el propio ritmo de trabajo.

Colaboración continua con quien encarga el proyecto

En vez de concentrar la validación en una aprobación formal al inicio y otra al final, quien encarga el proyecto o representa a los usuarios finales participa de forma recurrente: revisa incrementos, valida prioridades y ajusta expectativas junto al equipo durante todo el proyecto. Esto reduce el riesgo de construir, durante semanas o meses, algo que finalmente no responde a la necesidad real.

Adaptación continua al cambio

Un plan detallado y cerrado desde el inicio suele perder validez apenas el proyecto avanza y aparece nueva información. 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 del proyecto no se identifican una sola vez en un documento inicial que luego nadie vuelve a mirar. Se revisan en cada ciclo de planificación y de seguimiento, incorporando lo que el equipo va aprendiendo a medida que ejecuta, lo que permite anticipar y mitigar problemas antes de que se vuelvan críticos.

4. Enfoques ágiles y criterios para elegirlos

Existen distintas formas de organizar el trabajo ágil de un proyecto. Esta sección explica los tres enfoques que se usan a lo largo de esta guía: Scrum, Kanban y un enfoque híbrido. Además define los términos propios de cada uno, que se utilizarán sin volver a definirse en las secciones siguientes.

4.1 Scrum

Organiza el trabajo en bloques de tiempo fijo llamados sprints, durante los cuales el equipo se compromete a completar un conjunto acotado de trabajo. Es un enfoque basado en cadencia: cada sprint se planifica, se ejecuta y se cierra siguiendo el mismo ritmo.

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 del proyecto.
• Sprint: bloque de tiempo fijo, normalmente entre una y cuatro semanas, y comúnmente dos semanas, en el que el equipo se compromete a completar un conjunto acotado de trabajo.
• Sprint backlog: subconjunto del backlog de producto que el equipo se compromete a completar durante el sprint.
• Historia de usuario: unidad de trabajo que describe una funcionalidad desde la perspectiva de quien la usará.
• Estimación de esfuerzo: ejercicio en que el equipo dimensiona cuánto trabajo implica cada historia, habitualmente en unidades relativas (puntos) más que en horas.
• Definición de Terminado (DoD): lista acordada que define cuándo un incremento de trabajo se considera realmente completo.
• Sprint Planning: reunión al inicio del sprint donde se define su objetivo y se arma el sprint backlog.
• Daily: reunión breve diaria de coordinación del equipo.
• Revisión de sprint (Sprint Review): instancia al cierre del sprint donde se muestra el incremento construido a quien encargó el proyecto.
• Retrospectiva: instancia de reflexión del equipo sobre cómo trabajó, no sobre qué construyó.
• Velocidad (velocity): cantidad de trabajo que el equipo completa, en promedio, por sprint. Sirve para estimar cuánto podrá comprometer en los siguientes.

4.2 Kanban

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. Estas son situaciones donde forzar compromisos por sprint no aporta valor.

Términos propios de Kanban:

• Tablero Kanban: representación visual del flujo de trabajo, dividido en columnas que representan estados (por ejemplo: por hacer, en curso, en revisión, terminado).
• Límite de trabajo en curso (WIP limit): número máximo de tareas permitidas simultáneamente en una columna, para evitar sobrecarga y detectar cuellos de botella.
• Política explícita: reglas visibles y acordadas sobre cómo se mueve el trabajo entre columnas.
• Reposición: instancia periódica, sin una cadencia necesariamente fija, en la que se decide qué nuevas tareas entran al tablero.
• Lead time: tiempo total desde que una tarea se solicita hasta que se entrega.
• Cycle time: tiempo que una tarea pasa efectivamente en ejecución activa, desde que se empieza a trabajar hasta que termina.
• Throughput: cantidad de tareas completadas en un periodo de tiempo determinado.

4.3 Enfoque híbrido

Un enfoque híbrido combina hitos y fases formales asociados a compromisos externos como un contrato, una licitación o un hito regulatorio. Se desarrolla 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 usar un enfoque híbrido 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 del enfoque híbrido:

• Hito: punto de control formal del proyecto asociado a un compromiso externo.
• Fase: bloque más amplio de trabajo delimitado por hitos, dentro del cual se ejecuta de forma iterativa.
• Iteración: ciclo corto de trabajo, equivalente a un sprint o a un periodo de flujo Kanban, que ocurre dentro de una fase.

4.4 Cómo elegir entre los tres

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, por ejemplo: 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 dentro del mismo proyecto, como ocurre cuando un equipo construye una nueva funcionalidad en Scrum mientras otro sostiene el soporte del servicio actual en Kanban.

5. El ciclo del proyecto

Las siete fases que se describen a continuación cubren desde la gestión (planificación, seguimiento, cierre) hasta la ejecución técnica (QA, publicación), para que ningún momento del proyecto quede sin orientación aplicable. Los términos de Scrum y Kanban usados a continuación se definieron en la sección 4.

5.1 Descubrimiento y priorización

Esta fase busca entender el problema real antes de empezar a construir una solución, usando evidencia y no solo supuestos internos del equipo o de quien encarga el proyecto.

Actividades clave:

• Entrevistas o levantamiento con usuarios finales.
• Análisis de datos de uso existentes.
• Talleres de priorización conjunta con quien encarga el proyecto.
• Construcción del backlog inicial y de un mapa de valor.

5.2 Planificación

El equipo define qué abordará en el siguiente incremento de trabajo. En Scrum esto ocurre en el Sprint Planning, donde se arma el sprint backlog y se acuerda la Definición de Terminado. En Kanban ocurre de forma más continua, mediante instancias de reposición que van incorporando tareas al tablero según su prioridad y los límites de trabajo en curso disponibles.

Actividades clave:

• Sesión de planificación (Sprint Planning o reposición).
• Estimación de esfuerzo de cada historia o tarea.
• Acuerdo explícito de la Definición de Terminado.
• Identificación temprana de dependencias externas.

5.3 Ejecución

Es el desarrollo propiamente tal del incremento de trabajo, con coordinación diaria y visibilidad constante del avance en el tablero.

Actividades clave:

• Desarrollo iterativo del incremento comprometido.
• Reuniones diarias breves de coordinación (daily).
• Actualización constante del tablero visual.
• Revisiones de diseño y de código entre pares.

5.4 Aseguramiento de calidad (QA)

El QA se integra dentro de cada iteración, no se deja como una etapa final aislada e incluye pruebas funcionales, de accesibilidad y de usabilidad.

Actividades clave:

• Pruebas funcionales de cada incremento antes de darlo por terminado.
• Pruebas de accesibilidad y de usabilidad.
• Registro y seguimiento de hallazgos hasta su resolución.

5.5 Publicación / despliegue

El paso a producción se habilita de forma incremental, con capacidad de revertir rápidamente si algo falla, en vez de un único lanzamiento masivo.

Actividades clave:

• Elaboración del plan de despliegue.
• Pruebas en ambiente de pre-producción (staging).
• Despliegue gradual cuando la herramienta lo permite.
• Monitoreo activo inmediatamente después de cada publicación.

5.6 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; lead time, cycle time y throughput en Kanban.

Actividades clave:

• Actualización periódica del tablero de métricas.
• Reporte de avance a quien corresponda dar seguimiento al proyecto.
• Gestión activa de riesgos e impedimentos identificados durante la ejecución.

5.7 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.

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.

6. 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. Para cada rol se explica primero qué significa y por qué es importante para el proyecto, y luego se detalla qué hace concretamente durante el ciclo descrito en la sección 5.

Patrocinador/a

Es quien autoriza el proyecto y respalda su alcance estratégico. Su importancia radica en dar legitimidad y respaldo institucional al proyecto, y en estar disponible para resolver bloqueos que superan las atribuciones del equipo. No participa en el trabajo diario, y su rol es de respaldo y decisión en los momentos clave.

Product Owner

Es quien representa a los usuarios finales y a quien encarga el proyecto, y su importancia está en tomar diariamente las decisiones sobre qué se construye primero y qué se deja para más adelante según el valor esperado. Es el rol con mayor dedicación y presencia continua durante todo el proyecto.

Scrum Master (facilitador/a ágil)

Es quien facilita las ceremonias del equipo y vela por que la forma de trabajo acordada se sostenga en el tiempo. Su importancia está en proteger al equipo de interrupciones y en ayudar a resolver impedimentos, no en 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. Su importancia está en autogestionar cómo distribuye el trabajo dentro de cada iteración para cumplir el compromiso acordado en la planificación.

Equipo de gestión de proyectos (PMO)

Da seguimiento transversal a los proyectos del portafolio. Su importancia está en asegurar 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 del equipo.

7. Herramientas y plantillas de apoyo

Esta sección detalla las herramientas y plantillas mencionadas en las secciones anteriores describiendo para qué sirve cada una, cómo usarla en términos generales, y un ejemplo concreto de aplicación. Pueden implementarse en cualquier plataforma disponible (por ejemplo, Jira, Trello, Azure DevOps entre otras) o si el equipo no cuenta con una herramienta digital habilitada lo puede hacer en una planilla compartida simple. Lo relevante no es la herramienta específica, sino que estén siempre visibles y actualizadas para todo el equipo.

7.1 Tablero de trabajo visual

Para qué sirve: Visualizar en todo momento en qué estado está cada tarea del proyecto, sea el enfoque Scrum o Kanban.

Cómo usarlo:

1. Definir las columnas que representan el flujo de trabajo del equipo (mínimo: Por hacer, En curso, Terminado).

2. Registrar cada tarea o historia como una tarjeta con un título breve y quién la tiene asignada.

3. Mover la tarjeta de columna a medida que cambia su estado real, ni antes ni después.

4. Revisar el tablero en cada instancia de coordinación del equipo (daily o equivalente).

Ejemplo: Un equipo divide su tablero en las siguientes 4 columnas: Por hacer, En desarrollo, En revisión, Terminado. Cada mañana revisan juntos las tarjetas que llevan más de dos días sin moverse para detectar bloqueos a tiempo.

7.2 Plantilla de Sprint Planning

Para qué sirve: Estructurar la reunión de planificación de un sprint para que termine con un compromiso claro y realista.

Cómo usarla:

1. Antes de la reunión el Product Owner ordena el backlog según prioridad.

2. Durante la reunión el equipo revisa las primeras historias del backlog y estima su esfuerzo.

3. El equipo va sumando historias al sprint backlog hasta llegar a su capacidad estimada para ese sprint.

4. Se documenta el objetivo del sprint en una frase breve y se deja registro de los riesgos identificados.

Ejemplo: En un sprint de dos semanas con una capacidad estimada de 20 puntos, el equipo selecciona historias del backlog hasta sumar entre 18 y 20 puntos, dejando como objetivo del sprint "habilitar el ingreso de datos básicos del formulario".

7.3 Plantilla de Definición de Terminado (DoD)

Para qué sirve: Evitar ambigüedad sobre cuándo un incremento de trabajo está realmente completo.

Cómo usarla:

1. Antes de empezar a construir el equipo acuerda una lista de condiciones mínimas que debe cumplir cualquier incremento.

2. La lista se deja visible para todo el equipo.

3. Antes de mover una tarjeta a "Terminado" se revisa contra ese checklist.

4. La lista se ajusta cuando el equipo detecta, en una retrospectiva, que algo relevante quedó fuera.

Ejemplo: Una Definición de Terminado simple puede incluir "código revisado por otra persona del equipo", "pruebas funcionales ejecutadas sin errores críticos", "documentación de usuario actualizada" y "aprobación del Product Owner".

7.4 Plantilla de Retrospectiva

Para qué sirve: Capturar aprendizajes sobre cómo trabajó el equipo (no sobre qué construyó) para convertirlos en mejoras concretas.

Cómo usarla:

1. Cada integrante del equipo anota, de forma individual, qué funcionó bien, qué no funcionó y qué propone mejorar.

2. Se agrupan las respuestas por tema en una sesión conjunta.

3. El equipo prioriza dos o tres mejoras concretas para el siguiente ciclo.

4. Al inicio de la siguiente retrospectiva se revisa si esas mejoras se aplicaron.

Ejemplo: En una retrospectiva el equipo identifica que las revisiones de código estaban demorando la entrega. Como mejora concreta acuerdan un plazo máximo de 24 horas para revisar cualquier código pendiente.

7.5 Tablero de métricas

Para qué sirve: Comunicar con datos simples cómo avanza el proyecto.

Cómo usarlo:

1. Definir una o dos métricas según el enfoque: velocidad y burndown en Scrum; y lead time, cycle time y throughput en Kanban.

2. Actualizar los datos al cierre de cada sprint (Scrum) o de forma continua (Kanban).

3. Compartir el tablero con quien encarga el proyecto en cada instancia de reporte.

Ejemplo: Un equipo Scrum lleva un gráfico de burndown que muestra, día a día dentro del sprint, cuánto trabajo queda pendiente frente a lo planificado. Si la línea real se aleja mucho de la ideal el equipo lo conversa en el siguiente daily.

7.6 Política de límites de trabajo en curso (WIP)

Para qué sirve: Evitar que el equipo tenga demasiadas tareas abiertas a la vez, lo que suele alargar el tiempo real de entrega de todas ellas.

Cómo usarla:

1. Definir para cada columna del tablero Kanban un número máximo de tarjetas permitidas simultáneamente.

2. Si una columna llega a su límite el equipo prioriza terminar tareas existentes antes de iniciar una nueva.

3. Revisar periódicamente si los límites definidos siguen siendo razonables para la capacidad real del equipo.

Ejemplo: Un equipo define un límite de tres tarjetas en la columna "En desarrollo", al llegar a ese límite el equipo se organiza para terminar una tarea en curso antes de que cualquier persona tome una nueva.

8. Caso de aplicación

El siguiente caso ilustra cómo se aplican los enfoques según el ciclo de fases, los roles y las herramientas descritos en esta guía, incluyendo la mezcla de enfoques ágiles dentro de un mismo proyecto.

Contexto

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.

8.1 Descubrimiento (semanas 1 a 3, enfoque Kanban)

El equipo trabaja en flujo, no en sprints, porque el ritmo de los hallazgos es irregular (algunas entrevistas y análisis de datos toman más tiempo que otros). Usa un tablero Kanban con un límite de trabajo en curso de tres tareas en la columna "En análisis", y realiza instancias breves de reposición a medida que se cierran hallazgos y se necesitan nuevas líneas de investigación. Al término de las tres semanas, el equipo cuenta con un backlog priorizado de 24 historias y un mapa de valor del formulario.

8.2 Planificación y ejecución (semanas 4 a 9, enfoque Scrum, tres sprints de dos semanas)

Con el alcance ya más estable, el equipo cambia a Scrum para la construcción. En el Sprint Planning del primer sprint estima una capacidad de 18 puntos y se compromete con nueve historias, definiendo como objetivo del sprint "habilitar el ingreso de datos básicos del formulario". El equipo se coordina con un daily cada mañana y actualiza su tablero durante el día. El QA (pruebas funcionales y de accesibilidad) se ejecuta dentro de cada sprint como parte de la Definición de Terminado, no al final del proyecto. El segundo y tercer sprint repiten el ciclo, incorporando validación de campos, mensajes de error y el flujo de confirmación del formulario.

8.3 Publicación incremental (durante los sprints 2 y 3)

Al cierre del segundo sprint el incremento se despliega primero a un ambiente de pre-producción y luego a un 10% de los usuarios, con un plan de reversa definido por si aparecen errores críticos. Los resultados de ese despliegue parcial se revisan al inicio del tercer sprint, y al cierre de este se completa la liberación al 100% de los usuarios.

8.4 Seguimiento y mezcla de enfoques en paralelo

Mientras el equipo principal ejecuta los tres sprints de construcción, dos integrantes se mantienen atendiendo el soporte de la versión actual del formulario en un tablero Kanban aparte, con su propio límite de trabajo en curso, porque ese flujo de solicitudes no encaja en compromisos de sprint. Ambos tableros son visibles para el equipo de gestión de proyectos, que consolida el reporte de avance combinando la velocidad y el burndown del equipo Scrum con el lead time y el throughput del equipo de soporte en Kanban. Este es el ejemplo concreto de mezclar enfoques dentro de un mismo proyecto: no solo de forma secuencial (Kanban en el descubrimiento y Scrum en la construcción), sino también en paralelo, con dos equipos usando enfoques distintos al mismo tiempo.

8.5 Cierre (semana 10)

El equipo realiza la retrospectiva del tercer sprint, documentando aprendizajes sobre la coordinación entre ambos tableros y sobre el proceso de despliegue incremental. El formulario rediseñado se traspasa a mantención, integrándose al mismo tablero Kanban que ya usa el equipo de soporte, y el proyecto se cierra formalmente ante quien lo encargó.

9. 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. Esta sección reúne las consideraciones específicas para aplicarlos dentro de una institución pública.

Vincular la ejecución ágil con la gobernanza de portafolio

Los compromisos institucionales (presupuesto asignado, plazos regulatorios, hitos de un convenio o licitación) se resguardan a nivel de portafolio y se reportan en los formatos que exige la gobernanza institucional. Lo que la gestión ágil cambia es cómo se ejecuta el trabajo para cumplir esos compromisos: el equipo trabaja de forma iterativa dentro de los márgenes que ellos permiten, y es la PMO quien articula ambos niveles (ver sección 6).

Compatibilizar la entrega ágil con la Ley de Compras Públicas y los ciclos presupuestarios

Cuando el proyecto involucra contratación de terceros o presupuesto sujeto a ciclos anuales, conviene fijar los hitos contractuales y presupuestarios como los "hitos" del enfoque híbrido descrito en la sección 4.3, dejando la ejecución técnica dentro de cada fase a cargo de sprints o de flujo Kanban según corresponda.

Generar evidencia útil también para la rendición de cuentas

Los mismos artefactos ágiles -backlog priorizado, actas de retrospectiva, tableros de métricas- pueden servir como evidencia de avance y de uso responsable de recursos frente a control interno o Contraloría, siempre que se mantengan actualizados y accesibles, y no solo como documentación interna del equipo.

Incorporar los estándares de accesibilidad digital vigentes dentro de la Definición de Terminado

El cumplimiento de la normativa de accesibilidad digital aplicable a los servicios del Estado no debería quedar como una revisión aparte al final del proyecto. Conviene incorporarlo explícitamente en la Definición de Terminado de cada incremento, dentro de la fase de aseguramiento de calidad (sección 5.4).

Mantener 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. De esa manera se cumple en la práctica el rol de Product Owner o trabajando en conjunto con quien lo ejerza.

Reservar un rol acotado y puntual para el patrocinador institucional

La participación del patrocinador institucional 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, lo que suele ralentizar la cadencia ágil del equipo.