Metodología Scrum para el desarrollo de software ágil

La metodología Scrum es una metodología de desarrollo ágil de software que ayuda a los equipos a desarrollar productos en periodos cortos, permitiendo obtener de forma rápida feedback por parte del cliente, adaptaciones y una mejora continuada.

Para comprender a fondo qué es la metodología Scrum vamos a ver primero las características del desarrollo ágil de software y sus diferencias con respecto a la metodología tradicional.

1. Desarrollo ágil de software 

El desarrollo ágil de software o metodología ágil (Agile Methodology en inglés) es una metodología de desarrollo de software basada en el desarrollo iterativo e incremental, donde los requisitos y soluciones van evolucionando según las necesidades del proyecto. En las metodologías ágiles la adaptación al cambio forma parte del proceso natural del proyecto.

💡Si aún no conoces las bases de las metodologías ágiles, puedes leer este artículo introductorio: Qué son las metodologías ágiles y cómo ayudan a gestionar proyectos

1.1. Diferencias entre desarrollo ágil de software con el enfoque tradicional

En el modelo tradicional, el proyecto se planifica de forma detallada desde el inicio y se ejecuta en fases lineales. El objetivo es entregar el producto completo al final. Los cambios durante el proceso suelen generar problemas, ya que todo está sujeto a un plan inicial cerrado.

En cambio, con metodologías ágiles como Scrum se priorizan las funcionalidades más importantes y se entrega software funcional desde las primeras etapas. Las reuniones periódicas con el cliente permiten adaptar el proyecto sobre la marcha, asegurando que lo que se construye tenga valor real.

A continuación, puedes ver un esquema visual que resume cómo se organizan los proyectos en cada uno de los enfoques:

Además del esquema visual, esta tabla resume de forma clara las principales diferencias entre ambas metodologías:

Metodología Tradicional	Metodología Ágil
Planificación detallada al inicio	Planificación adaptativa y continua
Entregas al final del proyecto	Entregas frecuentes e incrementales
Resistencia al cambio	Adaptación constante a los cambios
Comunicación formal	Comunicación directa y continua

1.2. Principios de la metodología ágil aplicados a Scrum

Si ya has leído nuestro artículo introductorio sobre metodologías ágiles, recordarás que el Manifiesto Ágil no solo plantea 12 principios que promueven la colaboración, la adaptabilidad y la entrega continua de valor. En Scrum, todo esto se traduce en prácticas concretas que refuerzan esa filosofía de trabajo. Por ejemplo:

• Entrega continua de valor: en Scrum, el trabajo se organiza en sprints de duración fija (normalmente de 2 a 4 semanas). Al final de cada sprint, el objetivo es entregar una versión funcional del producto que pueda recibir feedback real.
• Adaptación al cambio: el backlog se revisa de forma constante y se ajusta según las prioridades del cliente y la evolución del proyecto. Esto permite responder rápidamente a cambios sin que eso suponga un problema.
• Comunicación directa: el equipo se reúne cada día en una daily de pocos minutos para sincronizarse y resolver bloqueos. Además, tras cada sprint hay una revisión con las personas interesadas y una retrospectiva interna para mejorar el proceso.
• Equipos motivados y autoorganizados: en Scrum, el equipo tiene autonomía para decidir cómo abordar el trabajo. No hay una figura que imponga tareas, sino un equipo que se coordina para cumplir con los objetivos del sprint.
• Mejora continua: la retrospectiva es una reunión clave que se celebra al final de cada sprint. Sirve para identificar qué ha funcionado y qué se puede mejorar, y para aplicar esos aprendizajes en el siguiente ciclo.

2. Metodología Scrum

Como has visto, Scrum no añade nuevos principios al Manifiesto Ágil, pero sí los traduce en prácticas concretas, repetibles y fáciles de implementar. Esta metodología parte de los valores y principios del desarrollo ágil y los convierte en una forma de trabajar estructurada, que permite entregar valor de manera continua y adaptarse con rapidez a los cambios.

Scrum organiza el trabajo en ciclos cortos llamados sprints, que suelen durar entre 2 y 4 semanas. En cada sprint, el equipo se enfoca en entregar una versión funcional del producto, recoger feedback y aplicar mejoras. Esto permite evolucionar el proyecto de forma iterativa y centrada en lo que realmente necesita el cliente.

Además, se basa en roles bien definidos, artefactos que ayudan a gestionar el trabajo y eventos o ceremonias que estructuran la comunicación y la mejora continua.

A lo largo de los próximos puntos estudiaremos cada uno de estos elementos de Scrum: los roles del equipo, los artefactos que estructuran el trabajo y las ceremonias que marcan el ritmo del desarrollo ágil.

3. Roles en la metodología Scrum

Scrum define tres roles, que permiten una buena comunicación entre las personas interesadas y una ejecución efectiva del trabajo:

3.1. Product Owner

• Representa al cliente o al negocio.
• Decide qué se desarrolla y qué no.
• Define buenas historias de usuario, que describen de forma sencilla lo que el producto debe hacer desde el punto de vista del usuario final.
• Gestiona el Product Backlog, que es una lista priorizada y en constante evolución con todas las funcionalidades, mejoras o correcciones que necesita el producto.
• Es responsable de maximizar el valor del producto.
• Define el producto mínimo viable (MVP), es decir, la versión más simple del producto que ya puede usarse y aportar valor real.
• Valida las entregas al final de cada sprint (Sprint Review), comprobando que el resultado se ajusta a lo esperado.

3.2. Scrum Master

• Planifica la implantación de Scrum y se asegura de que todo el equipo lo entienda y lo aplique correctamente.
• Ayuda a resolver los impedimentos que surjan durante el sprint, eliminando obstáculos que impiden el progreso del equipo.
• Crea un buen ambiente en el equipo y favorece la auto-organización, fomentando la colaboración y el compromiso de todos los miembros.
• Protege al equipo de interferencias externas, asegurándose de que el trabajo no se vea interrumpido por demandas ajenas al sprint en curso.
• Ayuda al Product Owner a comprender y aplicar la metodología ágil, apoyando en la gestión del Product Backlog.
• Se asegura de que se celebren las reuniones y de que se cumpla el objetivo en el tiempo establecido, facilitando la organización de eventos Scrum como las reuniones diarias o las revisiones de sprint.

3.3. Development team

• Compuesto de 5 a 9 miembros, con las habilidades necesarias para desarrollar el producto.
• Auto-organizado y auto-gestionado, lo que significa que el equipo decide cómo abordar el trabajo y cómo organizarse.
• Decide la cantidad de trabajo a realizar en un sprint durante el Sprint Planning (planificación del sprint), comprometiéndose a entregar un conjunto de funcionalidades al final del ciclo.
• Estable, motivado y dedicado, trabajando con un enfoque en la calidad y el valor de lo entregado.
• Se obtienen mejores resultados cuando trabajan en la misma localización física, aunque en la práctica, los equipos distribuidos también pueden ser efectivos si tienen las herramientas de colaboración adecuadas.

4. Artefactos en Scrum

Scrum utiliza una serie de artefactos que permiten visualizar el trabajo, organizarlo y hacer seguimiento del avance de forma transparente. Estos artefactos ayudan al equipo a mantener el foco, fomentar la colaboración y facilitar la entrega de valor continuo.

4.1. Product Backlog 

El Product Backlog (o pila del producto) es una lista ordenada y priorizada de todo lo que podría necesitar el producto, definida y gestionada por el Product Owner.
Incluye nuevas funcionalidades, correcciones, mejoras técnicas y cualquier otro elemento que aporte valor al producto final.
Esta lista es dinámica: evoluciona a medida que cambian las necesidades del negocio o se descubren nuevas oportunidades de mejora.

4.2. Product backlog items 

Dentro del Product Backlog, cada entrada se conoce como Product Backlog Item o PBI.
Un PBI puede ser una funcionalidad, una corrección de error, una tarea técnica o cualquier otro trabajo necesario.
Suele contener:

• Una descripción clara del ítem.
• Su orden o prioridad dentro del backlog.
• Una estimación de esfuerzo.
• El valor que aporta al usuario o al negocio.

También puede ir acompañado de materiales como diagramas de uso, prototipos o datos de investigación. Sin embargo, la forma más habitual de expresar un PBI es mediante Historias de Usuario.

4.3. Historia de Usuario

Una Historia de Usuario (elemento de la lista del product backlog) es una forma de representar funcionalidades desde la perspectiva del usuario final. Se redacta de forma breve y sencilla para que cualquier persona del equipo pueda comprender su finalidad. El formato estándar es el siguiente:

• Como <tipo de usuario>
• Quiero <necesidad a implementar>
• Para <funcionalidad>

Un ejemplo aplicado podría ser: Como persona usuaria registrada, quiero poder recuperar mi contraseña, para acceder de nuevo a mi cuenta sin ayuda externa.

Otro ejemplo aplicado podría ser:

4.4. Estimación 

Cada Historia de Usuario del Product Backlog debe ser estimada para valorar el esfuerzo que implicará su desarrollo.
Pero más allá del número, lo verdaderamente útil de la estimación es que abre la conversación sobre posibles dificultades, riesgos e incertidumbres.

Durante la reunión de estimación se suelen tener en cuenta tres factores clave:

• Esfuerzo: cuánto tiempo o trabajo puede llevar su desarrollo.
• Complejidad: qué tan difícil es la tarea o si requiere conocimientos específicos.
• Incertidumbre: cuánto sabemos sobre lo que se necesita hacer, o qué grado de definición tiene.

Esta evaluación permite al equipo anticiparse a los retos y decidir si es necesario dividir la tarea, investigar más o priorizar de otra forma.

4.5. Planning Poker o Scrum Poker

Para facilitar este proceso de estimación, se suele usar una técnica colaborativa llamada Planning Poker (también conocida como Scrum Poker).
Ayuda al equipo a estimar de forma rápida y consensuada, evitando discusiones largas o dominadas por una sola persona. El funcionamiento es simple:

• Cada componente del equipo tiene un mazo de cartas con valores predefinidos.
• Cuando se presenta una historia de usuario a estimar, cada integrante elige en secreto una carta que representa su estimación del esfuerzo.
• Luego, todas las cartas se revelan al mismo tiempo.
• Si hay grandes diferencias entre los valores elegidos, se abre una breve discusión para comprender las distintas percepciones antes de hacer una nueva votación.

Las barajas más utilizadas se basan en:

• La serie de Fibonacci (1, 2, 3, 5, 8, 13…), que permite marcar diferencias claras entre niveles de esfuerzo.
• Tallas de ropa (XS, S, M, L, XL…), una alternativa más visual o intuitiva para algunos equipos.

Si una historia excede el tamaño máximo aceptable, se recomienda dividirla en tareas más pequeñas y manejables.

4.5.1. Cartas basadas en la serie de Fibonacci

A continuación se propone la operativa que se llevaría durante una reunión de estimación mediante cartas basadas en la serie de Fibonacci:

1. Cada miembro dispone de un mazo de cartas. Cada componente dispone de un mazo de cartas con puntuación basada en la serie Fibonacci: 0, ½, 1, 2, 3, 5, 8, 13, 21, infinito.
2. Cliente o Product Owner lee la historia. Las historias de usuario son explicadas por el cliente o por el Product Owner. El equipo de desarrollo debe realizar todas las preguntas necesarias para la estimación.
3. El Development Team selecciona las cartas. Cada miembro del equipo de desarrollo selecciona una carta, sin mostrársela al resto.
4. Se muestran las cartas. Todas las cartas se levantan a la vez.
5. Argumentación de las diferencias. Se argumentan las diferencias entre las estimaciones más extremas.
6. Nueva estimación. Se vuelve a realizar una nueva estimación hasta que se consiga un consenso

4.5.2. Cartas con talla de ropa

El mecanismo es el mismo que mediante cartas con serie de Fibonacci. La diferencia es que en vez de utilizar números, se utilizan tallas de camiseta o de ropa. De esta forma se pueden definir otros valores diferentes que se pueden asociar a cada una de las cartas durante en la estimación.

Las cartas Scrum, especialmente las de Planning Poker, se usan tanto en formato físico como digital para estimar tareas de forma colaborativa. Existen varias aplicaciones online de Planning Poker que permiten replicar esta dinámica de estimación de manera remota: plataformas gratuitas como Scrumpoker Online o incluso extensiones integradas en herramientas como Jira o Trello.

4.6. Orden de los PBIs

Los elementos del Product Backlog, conocidos como PBIs (Product Backlog Items), deben estar ordenados por prioridad.
Los que se sitúan en la parte superior son los más importantes y serán los primeros en ser desarrollados. Esto permite que, si no se completan todos los elementos durante un sprint, lo que quede pendiente sean funcionalidades menos críticas.

Para decidir este orden, se pueden aplicar diferentes técnicas de priorización. Una de las más conocidas es el método MoSCoW:

M Must have: elementos esenciales que deben incluirse sí o sí.

S Should have: importantes, pero pueden esperar a otra iteración si fuera necesario.

C Could have: elementos deseables, pero no imprescindibles. Se desarrollan solo si hay tiempo.

W Won’t have: no se abordarán por ahora, aunque podrían retomarse en el futuro.

Este enfoque ayuda a tener una visión clara del valor de cada funcionalidad y facilita la toma de decisiones sobre qué construir primero.

4.7. Tablero Scrum

El tablero Scrum es una herramienta visual para hacer seguimiento del trabajo y ayudar a la coordinación del equipo.
Muestra de forma clara qué tareas están por hacer, cuáles están en marcha y cuáles se han completado.

El tablero puede ser físico (pizarra, corcho, pared con post-its…) o digital, utilizando herramientas online como Trello, Jira o Asana. Lo habitual es organizarlo en columnas del tipo:

• To Do (por hacer)
• In Progress (en proceso)
• Done (terminado)

💡 Usar un tablero bien actualizado favorece la transparencia, el compromiso del equipo y agiliza las reuniones diarias de seguimiento (daily meetings).

Además, es posible añadir más columnas al flujo de trabajo según las necesidades del equipo. Por ejemplo, muchas veces se incluye una columna «In Review (en revisión)» para reflejar las tareas que están esperando validación antes de considerarse terminadas. Esta práctica ayuda a visualizar mejor el estado real del trabajo y es una forma de acercarse a métodos como Kanban, que permiten un control más detallado del flujo.

👉 En un próximo artículo hablaremos en profundidad sobre Kanban y cómo se relaciona con Scrum.

5. Eventos, ceremonias o reuniones

Scrum se organiza en torno a una serie de eventos que estructuran el trabajo del equipo. Estas ceremonias permiten planificar, inspeccionar y adaptar el desarrollo de forma continua. Son repetitivas, breves y tienen objetivos muy concretos.

5.1. Daily stand-up (también llamada daily meeting o reunión diaria)

Es una reunión breve de unos 15 minutos, que se realiza cada día a la misma hora.
El objetivo es coordinar el trabajo diario y detectar posibles bloqueos.

Cada persona del equipo responde a tres preguntas:

• ¿Qué hiciste ayer?
• ¿Qué harás hoy?
• ¿Tienes algún impedimento?

👥 Quién acude: Principalmente los miembros del equipo de desarrollo (team members). El Scrum Master y el Product Owner pueden asistir como oyentes, pero no son imprescindibles.

5.2. Sprint Planning (planificación del sprint)

Se celebra al inicio del sprint.
Su objetivo es decidir qué se va a hacer y cómo se va a hacer durante los próximos días.

En esta reunión:

• El Product Owner presenta las historias de usuario priorizadas.
• El equipo selecciona las que puede abordar.
• Se estima el esfuerzo necesario (con herramientas como planning poker).

El resultado es el Sprint Backlog, el plan de trabajo acordado.

👥 Quién acude: Product Owner, Scrum Master y equipo de desarrollo.

5.3. Sprint Review (revisión del sprint)

Se hace al finalizar el sprint.
Sirve para mostrar lo desarrollado al Product Owner y a otras personas interesadas, y recoger su feedback.

En esta reunión se revisan:

• Las funcionalidades completadas.
• Las que no se han finalizado.
• El estado general del producto.

Este intercambio de opiniones permite ajustar el Product Backlog y mejorar el resultado final.

👥 Quién acude: Al Sprint Review asisten el equipo de desarrollo, el Scrum Master, el Product Owner y los stakeholders (personas interesadas o involucradas en el proyecto) para revisar el trabajo realizado y recibir feedback.

5.4. Sprint Retrospective (retrospectiva del sprint)

Es una reunión interna del equipo para reflexionar sobre el trabajo realizado.

Se analizan aspectos como:

• ¿Qué ha funcionado bien?
• ¿Qué deberíamos mejorar?
• ¿Qué podemos probar a partir de ahora?

Su objetivo es fomentar la mejora continua en la forma de trabajar.

👥 Quién acude: A la Sprint Retrospective asiste todo el equipo Scrum: el equipo de desarrollo, el Scrum Master y el Product Owner.

5.5. Refinement (refinamiento del Product Backlog)

Aunque no es una ceremonia oficial de Scrum, es esencial para mantener un backlog saludable y facilitar la planificación. Es un proceso que puede desarrollarse de forma continua o en sesiones puntuales.
Permite preparar las historias de usuario que se desarrollarán en futuros sprints.

Durante el refinamiento se:

• Detallan funcionalidades.
• Estiman esfuerzos.
• Reorganizan prioridades.
• Dividen tareas grandes en unidades más manejables.

👥 Quién acude: Al Refinement (refinamiento del Product Backlog) asisten principalmente el Product Owner y el equipo de desarrollo. El Scrum Master puede participar para facilitar la sesión, pero no es obligatorio.

💡 ¿Sabías que…? Empresas como Spotify, Netflix, Amazon y Airbnb aplican variantes de marcos ágiles a escala para gestionar proyectos enormes sin perder la agilidad que los impulsó a crecer. Utilizan enfoques como Scrum@Scale o el famoso Spotify Model, que permiten coordinar a cientos de equipos trabajando en paralelo, garantizando la innovación continua, entregas rápidas y una capacidad de adaptación constante. Este es un claro ejemplo de cómo Scrum puede evolucionar para enfrentar los retos de grandes organizaciones manteniendo su esencia ágil.

6. Definition of Done (DoD) y Definition of Ready (DoR)

En Scrum, para evitar confusiones sobre cuándo una tarea está lista para comenzar o se puede considerar realmente terminada, se utilizan dos conceptos:

6.1. Definition of Done (Definición de hecho)

La Definition of Done es una lista de criterios que deben cumplirse para que una tarea se considere finalizada. Puede incluir aspectos como:

• Código desarrollado, revisado y probado.
• Documentación técnica actualizada.
• Tests exitosos.
• Aprobación del Product Owner.

6.2. Definition of Ready (Definición de preparado)

La Definition of Ready define cuándo una historia de usuario está suficientemente clara y detallada como para poder empezar a desarrollarse. Por ejemplo:

• La historia está bien escrita (formato “Como… quiero… para…”).
• Se entiende qué debe hacerse.
• Está priorizada.
• Tiene estimación de esfuerzo.

Esto evita interrupciones innecesarias y mejora la productividad durante el sprint.

Criterio	Descripción	Estado
Historia bien escrita	Usa el formato “Como… quiero… para…”	✔️ / ❌
Claridad	Se entiende claramente qué debe hacerse	✔️ / ❌
Prioridad definida	La historia está ordenada según su importancia	✔️ / ❌
Estimación de esfuerzo	El equipo ha estimado el esfuerzo requerido	✔️ / ❌

💡¿Te interesa profundizar más sobre Scrum y metodologías ágiles? Echa un vistazo a esta selección de los mejores libros sobre metodologías ágiles y Scrum: Ver colección de los mejores libros

7. Ventajas y limitaciones de la metodología Scrum

7.1. Ventajas

• Entrega continua de valor: Scrum permite entregar funcionalidades útiles desde las primeras etapas del proyecto, facilitando la retroalimentación temprana y la adaptación a los cambios.
• Mejora continua: Las reuniones periódicas, como la retrospectiva, fomentan la reflexión y la mejora constante del proceso y del equipo.
• Transparencia y visibilidad: El uso de artefactos como el tablero Scrum y las reuniones diarias proporcionan una visión clara del progreso y los obstáculos.
• Fomento de la colaboración: Scrum promueve la comunicación constante entre los miembros del equipo y con las partes interesadas, mejorando la cohesión y la toma de decisiones.

7.2. Limitaciones

• Requiere compromiso total: La implementación efectiva de Scrum necesita que todo el equipo y la organización estén comprometidos con sus principios y prácticas.
• No es adecuado para todos los proyectos: En proyectos con requisitos muy definidos y poco propensos al cambio, metodologías más tradicionales pueden ser más eficaces.
• Puede generar reuniones excesivas: Si no se gestionan adecuadamente, las ceremonias de Scrum pueden convertirse en una carga en lugar de una ayuda.
• Dependencia de la autoorganización: Scrum confía en equipos autoorganizados; si los miembros no están preparados para asumir esta responsabilidad, el proceso puede fallar.

8. Recomendaciones de lectura

Para profundizar en Scrum y las metodologías ágiles, te recomendamos los siguientes recursos:

• Guía de Scrum: Documento que describe el marco de trabajo Scrum y sus componentes esenciales. scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-European.pdf
• Manifiesto Ágil: Documento fundacional que establece los valores y principios del desarrollo ágil de software. agilemanifesto.org/iso/es/principles.html
• Selección de libros sobre metodologías ágiles: Una recopilación de libros recomendados para profundizar en las metodologías ágiles y Scrum. eniun.com/mejores-libros-metodologias-agiles-espanol/

Scrum no es solo una metodología, es una forma de trabajar que fomenta la colaboración, la transparencia y la mejora continua. Su éxito radica en que, sin añadir complejidad innecesaria, ofrece una estructura clara y adaptable que permite a los equipos entregar valor real de forma iterativa y eficaz.

Como has leído, su aplicación va mucho más allá del desarrollo de software: hoy se utiliza en diseño, marketing, educación y en cualquier entorno donde se valore la adaptación rápida al cambio. Si estás empezando o quieres mejorar tus procesos, adoptar Scrum puede ser un buen primer paso hacia una forma más ágil y efectiva de trabajar.

En la próxima sección veremos Kanban, otra metodología ágil con un enfoque visual y flexible.

9. Ejercicios metodología Scrum

Para ayudarte a afianzar los conceptos de la metodología Scrum, hemos preparado algunos ejercicios interactivos que puedes realizar. ¡Pónte a prueba!

9.1. Ejercicio de arrastrar palabras

Relaciona cada término con su definición correcta.

9.2. Ejercicio de verdadero y falso

Lee las afirmaciones y marca si son verdaderas o falsas.

9.3. Investiga y responde estas preguntas sobre Scrum

Pon a prueba tus conocimientos sobre la metodología Scrum. Lee cada pregunta y trata de responderla antes de comprobar la respuesta.

FAQ Scrum

---

9.4. Ejercicio de investigación vocabulario inglés / español

A continuación verás una lista de conceptos clave en inglés relacionados con metodologías ágiles que aún no hemos estudiado. Tu tarea es investigar qué significa cada uno y luego arrastrarlo hasta su definición correspondiente (en español). Este ejercicio te ayudará a ampliar tu vocabulario y comprensión sobre agilidad en entornos reales de trabajo.

💡Te puede interesar: Si quieres seguir ampliando tu vocabulario técnico en inglés, especialmente enfocado al desarrollo y la programación, no te pierdas este completo curso completo de vocabulario técnico

9.3. Ejercicio práctico de Scrum en Jira

Aprende a gestionar un proyecto ágil básico utilizando Jira como herramienta de planificación y seguimiento.

1. Crea una cuenta gratuita en Jira
   Accede a Atlassian Jira y regístrate. Selecciona el plan gratuito para comenzar.
2. Configura tu primer proyecto Scrum
   • Elige la opción «Crear proyecto».
   • Selecciona la plantilla Scrum.
   • Nombra tu proyecto como: «Proyecto de prueba Scrum TunombreApellido».
3. Define el Backlog
   • Crea al menos 5 historias de usuario sencillas para el proyecto.
     Ejemplo:
     • «Como usuario, quiero registrarme en la plataforma para acceder a contenido exclusivo.»
     • «Como administrador, quiero aprobar publicaciones de usuarios para asegurar la calidad del contenido.»
   • Estima el esfuerzo de cada historia usando Story Points (por ejemplo: 2, 3, 5 puntos).
4. Crea un Sprint 1.
   • Añade al Sprint 3 historias de usuario.
5. Planifica tu primer Sprint
   • Inicia el Sprint
     • Da clic en «Iniciar Sprint».
     • Define una duración de 7 días para este primer Sprint.
   • Gestiona el Sprint
     • Mueve las tareas en el tablero:
       • De To Do (Por hacer) a In progress (En curso).
       • Y de In progress (En curso) a Done (Terminado).

Entrega: La entrega del ejercicio consiste en enviar una captura de pantalla del Backlog de tu proyecto con las historias de usuario creadas y organizadas. A continuación tienes un ejemplo de captura a entregar:

Ampliación: Sigue descubriendo las funcionalidades de Jira para Scrum, incluyendo reportes y gestión avanzada del backlog. Para profundizar, consulta el curso oficial gratuito de Atlassian: Jira Getting started