Secuencia didáctica con proyecto ágil guiado

1. Datos generales

2. Meta de aprendizaje

Aplicar principios y prácticas de Scrum y Kanban en un proyecto de tecnología de la información, transformando una necesidad de cliente en historias de usuario con criterios de aceptación, priorizando un product backlog, planificando y ejecutando un sprint, distribuyendo responsabilidades y entregando un incremento funcional verificable.

3. Objetivo de aprendizaje SMART

Al finalizar las 10 horas de trabajo, cada equipo será capaz de elaborar y priorizar un product backlog de al menos seis historias de usuario relacionadas con un sistema de soporte técnico, definir criterios de aceptación verificables para cada historia, planificar un sprint de dos o tres historias, organizar el trabajo mediante un tablero Kanban y entregar un incremento funcional o prototipo validable, evidenciando el uso adecuado de los roles, eventos y artefactos básicos de Scrum con un mínimo del 80% de logro en la rúbrica.

4. Producto final y evidencias

• Mapa breve de la necesidad del cliente y perfil de usuario.
• Product backlog con mínimo seis historias de usuario.
• Criterios de aceptación verificables para cada historia priorizada.
• Estimación relativa de las historias mediante puntos.
• Tablero Kanban con columnas: Por hacer, En progreso, En revisión y Terminado.
• Sprint backlog con tareas, responsables y estimación.
• Incremento funcional o prototipo validable de una funcionalidad priorizada.
• Registro de revisión del sprint y retrospectiva del equipo.
• Autoevaluación y coevaluación individual sobre participación, colaboración y cumplimiento del rol.

5. Organización de roles y conceptos de Scrum

Los roles deben rotarse al menos una vez entre las actividades para que la evaluación no dependa de una sola función.

6. Actividad 1. Del problema del cliente a las historias de usuario

Objetivo parcial

Interpretar una necesidad real de un usuario de servicios de soporte técnico y convertirla en historias de usuario claras, centradas en el valor y verificables.

Tiempo

2 horas. Semana 1.

Situación de proyecto

La institución recibe solicitudes de soporte técnico por mensajes informales, llamadas y conversaciones directas. Esto provoca pérdida de información, dificultad para conocer el estado de cada solicitud y poca claridad sobre quién debe atenderla. El cliente solicita un sistema sencillo para registrar, consultar y actualizar solicitudes de soporte.

Materiales y recursos

• Tarjetas o hojas recortadas para historias de usuario.
• Marcadores, cinta adhesiva y papelógrafo o tablero.
• Formato de entrevista o ficha de necesidad del cliente.
• Celulares para consultar una plantilla compartida, tomar fotografías de los productos o registrar acuerdos, sin que sean indispensables.
• Ficha de referencia con la estructura: “Como [tipo de usuario], quiero [acción o funcionalidad], para [beneficio o valor]”.

Pasos

1. Presentación del reto y activación de saberes previos – 15 minutos.

   Acciones del docente: Presenta la situación del sistema de soporte técnico. Pregunta: “¿Qué información se necesita para atender correctamente una solicitud?”, “¿Qué diferencia existe entre una necesidad del usuario y una solución técnica?” y “¿Cómo sabríamos que una funcionalidad realmente funciona?”. Registra las respuestas sin corregirlas inicialmente.

   Acciones del estudiante: Analiza individualmente el problema, anota necesidades posibles y comparte experiencias de proyectos anteriores o de solicitudes de soporte que haya observado.

2. Mini explicación aplicada: Scrum y la historia de usuario – 20 minutos.

   Acciones del docente: Explica brevemente el propósito del product backlog, la diferencia entre requerimiento y historia de usuario, y la relación entre historia, valor y criterios de aceptación. Modela un ejemplo:

   “Como docente, quiero registrar una solicitud de soporte indicando equipo, problema y prioridad, para recibir atención sin repetir la información por varios canales.”

   Presenta los criterios INVEST de manera práctica: independiente cuando sea posible, negociable, valiosa, estimable, pequeña y comprobable.

   Acciones del estudiante: Identifica en el ejemplo el tipo de usuario, la acción y el beneficio. Formula preguntas sobre ambigüedades o información faltante.

3. Entrevista simulada y redacción cooperativa – 35 minutos.

   Acciones del docente: Entrega a cada equipo una ficha de cliente con información incompleta. Un estudiante de otro equipo puede asumir el papel de cliente y responder únicamente preguntas relacionadas con el problema. Acompaña la escritura y evita aceptar historias redactadas como tareas técnicas, por ejemplo: “crear base de datos”.

   Acciones del estudiante: Distribuye funciones de entrevistador, secretario, cliente y analista. Formula preguntas, identifica usuarios como docente, estudiante, técnico o coordinador, y redacta entre cuatro y seis historias de usuario.

4. Definición de criterios de aceptación – 35 minutos.

   Acciones del docente: Modela la transformación de una condición vaga en una condición comprobable. Por ejemplo, reemplaza “el sistema debe ser fácil de usar” por “dado que el usuario ha completado los campos obligatorios, cuando selecciona ‘Registrar solicitud’, entonces el sistema muestra un número de ticket y el estado ‘Recibida’”.

   Acciones del estudiante: Define para cada historia prioritaria entre dos y cuatro criterios observables utilizando, cuando sea posible, la estructura “Dado que…, cuando…, entonces…”. Revisa que los criterios permitan decidir si la historia está terminada.

5. Socialización y retroalimentación – 15 minutos.

   Acciones del docente: Selecciona dos historias de distintos equipos, solicita que el grupo detecte ambigüedades y proporciona retroalimentación con las preguntas: “¿Quién obtiene valor?”, “¿Qué resultado se puede comprobar?” y “¿La historia es demasiado grande para un sprint corto?”.

   Acciones del estudiante: Expone una historia, recibe observaciones y mejora su redacción.

Formato de historia de usuario

Antes de pasar a la siguiente actividad, verifica que:

• Cada equipo tenga al menos seis historias de usuario relacionadas con el sistema de soporte técnico.
• Las historias estén redactadas desde la perspectiva de un usuario y no como una lista de tareas de programación.
• Las historias priorizadas tengan criterios de aceptación observables.
• El cliente o usuario representado pueda explicar qué valor espera recibir.

7. Actividad 2. Construcción y priorización del product backlog con Scrum y Kanban

Objetivo parcial

Organizar, estimar y priorizar el product backlog tomando decisiones justificadas según valor para el cliente, urgencia, riesgo, dependencias y esfuerzo relativo.

Tiempo

3 horas. Semana 1.

Materiales y recursos

• Historias de usuario elaboradas en la actividad anterior.
• Tarjetas, notas adhesivas o recortes de papel.
• Tablero físico dividido en Product Backlog, Por hacer, En progreso, En revisión y Terminado.
• Celulares con una hoja de cálculo, tablero Kanban o formulario, como alternativa al tablero físico.
• Cartas o tarjetas con valores de estimación: 1, 2, 3, 5, 8 y 13 puntos.
• Matriz sencilla de valor, urgencia, riesgo y esfuerzo.

Pasos

1. Revisión de calidad del backlog – 25 minutos.

   Acciones del docente: Presenta una lista de comprobación: claridad, valor, tamaño, criterios de aceptación y dependencias. Explica que el product backlog es ordenado y evoluciona; no es una lista definitiva de tareas.

   Acciones del estudiante: Revisa sus historias, divide las que sean demasiado amplias y registra dependencias. Por ejemplo, “consultar estado de una solicitud” puede depender de que exista previamente una solicitud registrada.

2. Estimación relativa mediante Planning Poker – 40 minutos.

   Acciones del docente: Explica que los puntos representan tamaño relativo, considerando complejidad, esfuerzo, incertidumbre y dependencias; no son horas exactas. Facilita rondas de estimación y solicita justificaciones cuando existan diferencias importantes.

   Acciones del estudiante: Cada integrante selecciona en secreto una tarjeta de estimación. Todos revelan al mismo tiempo, explican sus razones y acuerdan un valor para cada historia. Registran los puntos en el backlog.

3. Priorización del product backlog – 45 minutos.

   Acciones del docente: Entrega una matriz con cuatro criterios: valor para el usuario, urgencia operativa, reducción de riesgo y esfuerzo. Sugiere utilizar una escala de 1 a 5 para los tres primeros criterios y considerar el esfuerzo como factor de análisis, no como único criterio.

   Acciones del estudiante: Ordena las historias, argumentando decisiones como: “Registrar solicitud” tiene prioridad sobre “Generar estadísticas” porque habilita el flujo principal del sistema. Identifica el conjunto mínimo que permite obtener un resultado útil.

4. Diseño del tablero Kanban – 35 minutos.

   Acciones del docente: Modela el flujo de una historia desde “Por hacer” hasta “Terminado”. Explica el límite de trabajo en proceso: cada equipo podrá tener como máximo dos historias en “En progreso” y dos en “En revisión”.

   Acciones del estudiante: Organiza visualmente el backlog, agrega responsables temporales y aplica etiquetas para prioridad, dependencia o bloqueo. Decide qué información debe estar visible para detectar cuellos de botella.

5. Reto cooperativo de priorización – 30 minutos.

   Acciones del docente: Entrega a cada equipo una tarjeta de cambio del cliente, por ejemplo: “Durante esta semana aumentaron las solicitudes críticas de acceso a plataformas”. Solicita que revisen el orden del backlog sin eliminar automáticamente las historias anteriores.

   Acciones del estudiante: Reprioriza el backlog, explica qué cambia y qué riesgo se asume. El Product Owner del equipo presenta la decisión; el resto del equipo puede cuestionarla con argumentos técnicos o de negocio.

6. Registro de acuerdos – 5 minutos.

   Acciones del docente: Verifica que el backlog tenga orden, puntos, criterios y justificación.

   Acciones del estudiante: Conserva una versión final del backlog en papel o mediante fotografía/hoja de cálculo compartida.

Formato de product backlog

Antes de pasar a la siguiente actividad, verifica que:

• El backlog tenga un orden explícito y una justificación basada en valor.
• Las estimaciones hayan sido discutidas por todo el equipo.
• Las historias seleccionables para el sprint sean pequeñas y tengan criterios de aceptación.
• El tablero Kanban permita identificar rápidamente qué está bloqueado y dónde se acumula el trabajo.

8. Actividad 3. Planificación y ejecución de un sprint

Objetivo parcial

Planificar y ejecutar un sprint corto, distribuyendo el trabajo de forma colaborativa, realizando seguimiento mediante reuniones diarias y aplicando límites de trabajo en proceso.

Tiempo

3 horas. Semana 2.

Materiales y recursos

• Product backlog priorizado.
• Formato de objetivo del sprint y sprint backlog.
• Tablero Kanban físico o digital mediante celular.
• Papel, marcadores y hojas para prototipar pantallas o flujos.
• Computadores disponibles, si existen, para implementar una funcionalidad sencilla.
• Alternativas sin conectividad: prototipo en papel, diagrama de flujo, formulario local, maqueta navegable en un celular o simulación manual del flujo del sistema.

Pasos

1. Sprint Planning: objetivo y selección de historias – 30 minutos.

   Acciones del docente: Explica que el equipo no debe comprometer más trabajo del que puede terminar y verificar. Solicita formular un objetivo concreto, por ejemplo: “Permitir que un usuario registre una solicitud de soporte y reciba un número de ticket”.

   Acciones del estudiante: El Product Owner propone el objetivo; el equipo selecciona dos o tres historias prioritarias según su capacidad y puntos estimados. El Scrum Master registra acuerdos y dependencias.

2. Descomposición y distribución del trabajo – 30 minutos.

   Acciones del docente: Orienta la conversión de historias en tareas técnicas y de validación: diseñar formulario, definir campos obligatorios, construir flujo, preparar datos de prueba y verificar criterios de aceptación. Aclara que asignar tareas no significa que cada persona trabaje de manera aislada.

   Acciones del estudiante: Descompone las historias en tareas de análisis, diseño, construcción y prueba. Estima cada tarea en horas o bloques de trabajo y acuerda responsables principales y colaboradores.

3. Construcción del incremento funcional – 75 minutos.

   Acciones del docente: Observa el tablero y formula preguntas de acompañamiento: “¿Qué impide terminar esta historia?”, “¿Por qué hay varias tareas abiertas?”, “¿Qué evidencia demuestra que el criterio se cumple?”. Interviene solo cuando haya bloqueo, conflicto de roles o desviación del objetivo.

   Acciones del estudiante: Construye el incremento mediante código, herramienta disponible, prototipo de pantallas o simulación funcional. Mueve las tarjetas en el tablero, respeta el límite de dos historias en progreso y prueba el resultado contra los criterios de aceptación.

4. Daily Scrum simulada – 15 minutos.

   Acciones del docente: Controla que la reunión sea breve y centrada en la coordinación, no en informes extensos al docente.

   Acciones del estudiante: Cada integrante responde: “¿Qué terminé?”, “¿Qué haré ahora?” y “¿Qué impedimento tengo?”. El Scrum Master actualiza bloqueos y acuerdos en el tablero.

5. Ajuste técnico y verificación – 30 minutos.

   Acciones del docente: Solicita que los equipos realicen una prueba con un escenario concreto: una docente registra una solicitud de proyector que no enciende y selecciona prioridad alta.

   Acciones del estudiante: Ejecuta pruebas, registra resultados, corrige defectos y mueve las historias a “En revisión” o “Terminado” solo cuando cumplan la definición de terminado.

Formato de sprint backlog

Definición de terminado

• La funcionalidad responde al flujo acordado.
• Los criterios de aceptación fueron verificados con al menos un caso de prueba.
• El equipo puede mostrar una evidencia: prototipo, pantalla, flujo ejecutable, registro o simulación.
• Los defectos conocidos quedaron registrados.
• El resultado puede ser comprendido y utilizado por el usuario representado.

Antes de pasar a la siguiente actividad, verifica que:

• Cada equipo tenga un objetivo de sprint escrito.
• Las historias seleccionadas estén descompuestas en tareas.
• El tablero muestre el estado real del trabajo.
• Existe un incremento demostrable, aunque no sea un producto de software completo.
• La participación individual pueda evidenciarse mediante tareas, acuerdos, pruebas y observaciones del equipo.

9. Actividad 4. Sprint Review, retrospectiva y mejora continua

Objetivo parcial

Demostrar el incremento funcional, recoger retroalimentación del cliente, evaluar el cumplimiento de los criterios de aceptación y proponer mejoras concretas para un siguiente sprint.

Tiempo

2 horas. Semana 2.

Materiales y recursos

• Incremento funcional o prototipo.
• Product backlog y sprint backlog.
• Lista de criterios de aceptación y casos de prueba.
• Formato de retroalimentación del cliente.
• Tarjetas de tres colores o papel dividido en: Mantener, Mejorar y Probar.
• Celular para registrar la demostración o tomar evidencias, si está disponible.

Pasos

1. Preparación de la demostración – 15 minutos.

   Acciones del docente: Explica que la revisión se centra en el incremento y en el valor entregado, no en una exposición teórica sobre Scrum. Entrega una lista de comprobación al público.

   Acciones del estudiante: Organiza una demostración de tres a cinco minutos: presenta el problema, muestra el flujo implementado o prototipado y evidencia el cumplimiento de los criterios.

2. Sprint Review con rol de cliente – 45 minutos.

   Acciones del docente: Asume el papel de cliente o asigna ese papel a estudiantes de otros equipos. Formula preguntas sobre utilidad, claridad, errores y necesidades no cubiertas. Registra si la historia cumple, cumple parcialmente o no cumple.

   Acciones del estudiante: El Product Owner explica el valor y recoge comentarios. El equipo demuestra el incremento, responde preguntas y actualiza el backlog con nuevas necesidades o ajustes derivados de la revisión.

3. Retrospectiva del equipo – 35 minutos.

   Acciones del docente: Facilita la conversación sin asignar culpas. Solicita evidencias de colaboración, gestión del tiempo, uso del tablero y cumplimiento de roles.

   Acciones del estudiante: Registra una situación para mantener, una para mejorar y una acción concreta para probar en el siguiente sprint. Analiza si el límite de trabajo en proceso ayudó a reducir bloqueos.

4. Evaluación individual y cierre conceptual – 25 minutos.

   Acciones del docente: Aplica una salida escrita con cuatro preguntas: “¿Qué diferencia existe entre product backlog y sprint backlog?”, “¿Qué función cumple el Product Owner?”, “¿Cuándo una historia puede considerarse terminada?” y “¿Qué información permite detectar un cuello de botella en Kanban?”. Integra la rúbrica del producto con la coevaluación.

   Acciones del estudiante: Responde individualmente, completa su autoevaluación y explica qué decisión técnica o de organización aportó al incremento.

Antes de cerrar la secuencia, verifica que:

• El cliente o grupo revisor haya proporcionado retroalimentación sobre el incremento.
• Las historias estén clasificadas según el cumplimiento de sus criterios.
• Cada equipo tenga una acción de mejora concreta para un siguiente sprint.
• La evaluación individual incluya evidencias de participación y no solo la calidad del producto colectivo.

10. Evaluación

Criterios de evaluación alineados con la meta

Escala de desempeño

• Superior: Aplica las prácticas con autonomía, justifica decisiones y entrega un incremento verificable que cumple los criterios.
• Alto: Aplica correctamente la mayoría de las prácticas, con pocas orientaciones del docente.
• Básico: Utiliza formatos y roles, pero presenta inconsistencias en la priorización, coordinación o validación.
• Bajo: Redacta historias ambiguas, no mantiene actualizado el tablero o no logra demostrar un incremento verificable.

11. Formatos de Scrum para usar en el aula

Objetivo del sprint

Durante este sprint, el equipo logrará: ____________________________________________

Registro de Daily Scrum

Registro de Sprint Review

Formato de retrospectiva

12. Adaptaciones y contingencias TIC

• Con celulares: cada equipo puede fotografiar el tablero, registrar acuerdos en una nota compartida, usar una hoja de cálculo o gestionar las tarjetas en una aplicación de tablero Kanban.
• Con conectividad limitada: el tablero físico, las tarjetas y los formatos impresos serán la fuente principal. Al recuperar conexión, un integrante puede digitalizar únicamente el estado final y las evidencias.
• Sin computadores para construir: el incremento puede ser un prototipo de baja fidelidad, un flujo navegable en papel o una simulación con tarjetas que evidencie registro de solicitud, generación de ticket y consulta de estado.
• Con pocos dispositivos: se asigna un celular por equipo para documentación y registro. La construcción y validación se realizan de forma cooperativa con materiales físicos.