Proyecto Scrum para tu portafolio: cómo demostrar trabajo ágil sin experiencia formal
Documenta un proyecto académico o personal con Scrum: objetivo, responsabilidades, incrementos, aprendizaje y límites, sin fingir experiencia.
Puedes aprender Scrum sin haber trabajado todavía en una empresa, pero no puedes transformar una simulación en experiencia formal solo por usar un tablero. La forma correcta de demostrar lo aprendido es crear un producto pequeño, trabajar en incrementos, conservar evidencia de inspección y adaptación, y declarar el contexto académico o personal en cada pieza del portafolio.
El objetivo de este proyecto no es “actuar como una startup”. Es mostrar que entiendes para qué sirve cada elemento de Scrum y qué cambió gracias a la retroalimentación.
Verifica primero qué significa Scrum hoy
La fuente principal es la Guía Scrum escrita por Ken Schwaber y Jeff Sutherland. El sitio oficial confirma que la versión vigente fue publicada en noviembre de 2020, con una traducción para español latinoamericano disponible.
La guía define un Scrum Team con tres accountabilities: Product Owner, Scrum Master y Developers. El término se refiere a responsabilidades explícitas por resultados, no necesariamente a cargos laborales. Scrum.org explica que el cambio de “roles” a accountabilities evita confundir el marco con una descripción de puesto.
Scrum también define cinco eventos: Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective. Sus tres artefactos son Product Backlog, Sprint Backlog e Increment. Cada artefacto tiene un compromiso: Product Goal, Sprint Goal y Definition of Done, respectivamente. Puedes revisar la relación exacta en la guía oficial sobre artefactos y compromisos.
Si tu proyecto elimina varios de esos elementos o cambia su propósito, no lo presentes como una aplicación completa de Scrum. Puedes llamarlo “proyecto iterativo inspirado en Scrum” y explicar la adaptación. Ser preciso vale más que usar la etiqueta de moda.
Escoge un producto pequeño que admita retroalimentación
Scrum está orientado a crear valor mediante soluciones para problemas complejos. Para un ejercicio de aprendizaje, elige un producto que pueda evolucionar y ser inspeccionado. Algunas opciones seguras:
- una guía digital para estudiantes que buscan prácticas;
- un prototipo navegable de agenda universitaria;
- un repositorio de recursos con búsqueda básica;
- un sistema sencillo de reservas para una asociación estudiantil;
- un tablero de seguimiento de hábitos con datos ficticios;
- una experiencia interactiva para explicar un tema de clase.
Evita un “proyecto” que solo consista en repartir tareas para escribir un informe. Necesitas producir al menos dos incrementos útiles y recibir retroalimentación sobre ellos.
Define el contexto desde el inicio:
Simulación académica de cuatro semanas, realizada por cinco estudiantes. No hubo relación laboral ni cliente comercial. Dos compañeros de otra sección participaron como usuarios de prueba.
Ese rótulo debe aparecer en la portada y en la descripción del CV.
Crea un Product Goal verificable
El Product Goal expresa un estado futuro del producto y da una dirección de largo plazo al Scrum Team. Para el ejercicio, evita metas vagas como “hacer una buena aplicación”.
Ejemplo:
Permitir que estudiantes de últimos ciclos encuentren en menos de tres minutos una ruta de preparación para su primera entrevista, según el tipo de puesto.
Luego define cómo observarás el progreso. El tiempo de tres minutos es una hipótesis que puedes probar; no prometas que se cumplirá antes de medirlo. El Product Goal no es una lista de funcionalidades ni una fecha de entrega disfrazada.
Construye un Product Backlog inicial con problemas o capacidades ordenadas. Evita llenarlo con 100 ítems para aparentar complejidad. Diez a quince elementos entendibles son suficientes para un proyecto corto.
Asigna accountabilities reales, no títulos decorativos
Una persona actúa como Product Owner y es accountable de maximizar el valor y gestionar efectivamente el Product Backlog. Otra persona actúa como Scrum Master y es accountable de la efectividad del Scrum Team. Quienes crean cualquier aspecto de un Increment usable actúan como Developers.
En un equipo pequeño, los Developers pueden tener habilidades distintas, pero Scrum no crea subequipos internos ni jerarquías entre ellos. Documenta quién asumió cada accountability durante el ejercicio y qué decisiones tomó.
Si estás trabajando solo, no simules conversaciones contigo mismo para afirmar que operaste como un Scrum Team. Puedes estudiar los artefactos y realizar ciclos de construcción y feedback, pero describe el caso como proyecto individual inspirado en Scrum. Esa limitación es importante porque la colaboración es parte central del marco.
Diseña Sprints que produzcan incrementos observables
Un Sprint dura un mes o menos y contiene los demás eventos. Para un ejercicio de cuatro semanas, podrías realizar dos Sprints de dos semanas. Mantén la duración estable.
Sprint Planning
Registra tres respuestas:
- ¿Por qué este Sprint es valioso?
- ¿Qué puede quedar listo?
- ¿Cómo se realizará el trabajo?
El Sprint Goal debe unir el trabajo. Por ejemplo: “Validar si los usuarios comprenden la ruta de preparación y pueden llegar al primer recurso sin ayuda”. No es “terminar cinco pantallas”.
Daily Scrum
La Daily Scrum es un evento de 15 minutos para que Developers inspeccionen el progreso hacia el Sprint Goal y adapten el Sprint Backlog. No la conviertas en un reporte al docente ni en una reunión para demostrar ocupación. En el portafolio basta un registro breve de decisiones: fecha, obstáculo observado y adaptación acordada.
Sprint Review
Presenta el Increment a personas que puedan dar retroalimentación relevante. Registra qué observaron y qué cambió en el Product Backlog. Una lista de felicitaciones no sirve como inspección; busca comportamientos, dificultades y preguntas.
Sprint Retrospective
Analiza cómo trabajó el equipo y selecciona una mejora concreta para el siguiente Sprint. Por ejemplo: “Limitar el trabajo en curso a dos elementos” o “validar el criterio de aceptación antes de empezar”. No publiques comentarios personales ni culpes a un compañero.
Define “terminado” antes de construir
La Definition of Done describe formalmente el estado del Increment cuando cumple las medidas de calidad requeridas para el producto. En un prototipo educativo podría incluir:
- navegación completa de la ruta priorizada;
- revisión de ortografía;
- ausencia de datos personales reales;
- prueba en dos tamaños de pantalla;
- enlaces funcionales;
- archivo versionado y accesible al equipo;
- cumplimiento de criterios de accesibilidad básicos definidos por el proyecto.
No cambies la Definition of Done a mitad de la demostración para declarar terminado algo incompleto. Si descubres que era insuficiente, fortalécela para el trabajo posterior y registra el aprendizaje.
Cada Sprint debe producir al menos un Increment usable que cumpla esa definición. Un boceto, una presentación de avances o piezas que no funcionan juntas pueden ser trabajo útil, pero no necesariamente un Increment.
Conserva evidencia de inspección y adaptación
El portafolio debe permitir que alguien reconstruya la evolución sin leer cada tarjeta. Usa esta matriz:
| Momento | Evidencia | Qué debe mostrar |
|---|---|---|
| Inicio | Product Goal y Product Backlog v1 | Dirección y prioridades iniciales |
| Sprint Planning | Sprint Goal y Sprint Backlog | Decisión sobre valor y plan |
| Durante el Sprint | Registro de adaptaciones | Cambios por nueva información |
| Sprint Review | Demo, observaciones y backlog v2 | Feedback aplicado al producto |
| Retrospective | Una mejora seleccionada | Aprendizaje del equipo |
| Cierre | Incremento y Definition of Done | Calidad y resultado alcanzado |
Guarda capturas con fecha, historial de versiones o enlaces a prototipos. No publiques correos, rostros ni nombres de usuarios sin autorización. Si usas datos ficticios, identifícalos.
Ejemplo de evolución en dos Sprints
En el Sprint 1, el equipo crea una ruta básica para preparar una entrevista y prueba el prototipo con cuatro estudiantes. Tres no entienden la diferencia entre “investigar la empresa” y “preparar ejemplos”. El equipo incorpora esa observación al Product Backlog.
En la Sprint Review, el Product Owner reordena el trabajo: antes de agregar más tipos de entrevista, prioriza separar las dos acciones y mostrar un ejemplo. En la Retrospective, el equipo detecta que los criterios de aceptación se escribían demasiado tarde y acuerda revisarlos durante la planificación.
En el Sprint 2, el Increment incluye la nueva separación, un ejemplo y navegación revisada. Cinco de seis participantes completan la ruta sin ayuda. El resultado no prueba que el producto funcionará para toda la población ni que “aumentó la empleabilidad”. Solo muestra un aprendizaje dentro de una prueba pequeña, con condiciones definidas.
Ese cambio entre versiones es el corazón del caso. Un tablero lleno de tarjetas cerradas no demuestra adaptación por sí solo.
Arma una página de caso que se lea rápido
Usa esta secuencia:
- Contexto y etiqueta: académico, voluntario o personal.
- Producto y Product Goal: problema, usuario y estado futuro.
- Equipo: accountabilities y contribución individual.
- Dos Sprints: objetivos, incrementos y decisiones.
- Feedback: evidencia y cambios al Product Backlog.
- Calidad: Definition of Done y limitaciones.
- Resultado: qué aprendió el equipo y qué no fue validado.
Para integrar esta pieza con otros trabajos, revisa la guía de portafolio profesional por carrera y cómo presentar proyectos universitarios en tu CV.
Cómo escribirlo en el CV y LinkedIn
Ejemplo:
Prototipo de preparación para entrevistas — simulación académica con Scrum, 2026
Actué como Developer en un equipo de cinco estudiantes durante dos Sprints. Construí el flujo de navegación, participé en dos Sprint Reviews y adapté el Increment a partir de pruebas con usuarios; el proyecto no fue un empleo ni una implementación comercial.
Si fuiste Product Owner o Scrum Master en el ejercicio, escribe “asumí la accountability de…” o “actué como… en una simulación”. No pongas “Scrum Master certificado” sin credencial vigente y verificable. Participar en un proyecto tampoco certifica competencia integral en Scrum.
En una entrevista, conecta una decisión con la vacante: priorización, feedback, calidad o coordinación. Para ordenar la respuesta con contexto, acción y aprendizaje, consulta cómo demostrar competencias profesionales en una entrevista. Luego adapta la evidencia a tu perfil de LinkedIn sin duplicar todo el caso.
Señales de que el caso todavía no está listo
- Llama “Scrum” a cualquier tablero de tareas.
- Confunde Product Goal con lista de funcionalidades.
- Describe la Daily Scrum como reporte al jefe.
- No muestra un Increment usable.
- No existe Definition of Done.
- La Sprint Review es solo una exposición del equipo.
- No se ve ningún cambio después del feedback.
- Convierte accountabilities del ejercicio en cargos laborales.
- Presenta participación como certificación.
Checklist final
- La versión de referencia es la Guía Scrum vigente.
- El contexto académico o personal está visible.
- El producto tiene un Product Goal entendible.
- Las accountabilities reflejan decisiones reales.
- Cada Sprint produjo un Increment conforme a la Definition of Done.
- Hay evidencia de feedback y adaptación.
- Los resultados conservan tamaño de muestra y límites.
- El CV describe tu contribución individual.
Inicia tu caso con un Product Goal, una Definition of Done y un incremento; luego crea o actualiza tu perfil en Laborum, adjunta esa evidencia pertinente y postula a vacantes verificadas acordes con tu nivel profesional actual, sin presentar la simulación como experiencia formal ni certificación.
Fuentes consultadas
- Scrum Guides: versión oficial vigente y traducciones
- Guía Scrum 2020 en español latinoamericano
- Scrum.org: accountabilities en la Guía Scrum 2020
- Scrum.org: artefactos y compromisos
Somete el primer incremento a feedback y registra qué cambió en el segundo Sprint; esa diferencia entre versiones debe poder entenderse sin depender del tablero completo.