Roles y Responsabilidades del Equipo Scrum

Conoce los 3 'roles' de Scrum: Product Owner, Scrum Master y Developers para lograr proyectos exitosos.

Equipo Scrum

Antes de avanzar con los roles de Scrum, recordemos que Scrum no es una metodología sino un marco de trabajo deliberadamente incompleto para ser efectivo en contextos complejos (con variables no predictivas). Para que Scrum funcione, una de las condiciones fundamentales es la forma de trabajar que tiene el Equipo Scrum en estos contextos.

Veamos cómo se compone el Equipo y el sentido que tiene cada integrante tiene dentro de este marco ágil de trabajo.

El Equipo Scrum

"La unidad fundamental de Scrum es un pequeño equipo de personas, un equipo Scrum. El equipo Scrum consta de un Scrum Master, un propietario de producto (Product Owner) y desarrolladores. Dentro de un equipo de Scrum, no hay sub-equipos ni jerarquías. Es una unidad cohesionada de profesionales enfocada en un objetivo a la vez, el objetivo del Producto." - Guía Oficial de Scrum

Cuando hablamos de roles en Scrum, no nos referimos a la función tradicional de rol entendido dentro de un organigrama, sino a la naturaleza de las responsabilidades de las personas que ocupan cada espacio dentro del Equipo Scrum. Es por ello que la Guía oficial de Scrum no habla de funciones ni roles Scrum. Su foco está puesto en las responsabilidades dentro del Scrum Team.

Aclarado esto, la Guía describe al Equipo Scrum como un pequeño número de profesionales que trabaja centrado en el Objetivo de Producto, sin jerarquías ni subequipos. El pequeño número de integrantes (usualmente menor a 10) garantiza la agilidad y la productividad. Dado que Scrum está diseñado para responder a bajo costo a los cambios, tanto la estructura como el tamaño del equipo deben estar orientados a este fin.

No debe ser muy pequeño tampoco, sino del tamaño necesario para que el Incremento producido en cada Sprint sea de un valor considerable. Los equipos muy grandes se dividen en Equipos Scrum de no más de 10 personas, todos trabajando en un mismo producto, compartiendo no solo un único Product Owner, sino enfocados en un único objetivo de producto y Product Backlog. En el caso que desees profundizar en el uso de Scrum a gran escala, puedes profundizar en un marco derivado de Scrum que se llama LeSS (Large Scale Scrum).

Otro aspecto relevante en cuanto a los roles Scrum es que los equipos que adoptan este marco ágil de trabajo son multifuncionales y autogestionados en su trabajo. En otras palabras, estos equipos contienen en sí mismos todas las habilidades necesarias para construir el producto sin necesitar recurrir a habilidades externas al Equipo (multifuncionalidad) y deciden cuál es la mejor forma de conducir el trabajo durante cada Sprint sin órdenes externas al Equipo.

A diferencia de la organización piramidal, todos los roles de Scrum son responsables por igual en entregar un Incremento de Producto que sea valioso en cada Sprint.

Este grupo pequeño de profesionales se distribuye entre los siguientes tres roles: Developers o desarrolladores, Scrum Product Owner y Scrum Master.

Scrum Master

Podríamos decir que dentro de los roles Scrum, el Scrum Master es quien se ocupa de que el equipo tenga un conocimiento acabado del funcionamiento del marco de trabajo y de remover los impedimentos al progreso para que el equipo pueda enfocarse en entregar Incrementos de valor al final de cada Sprint de trabajo.

>Liderazgo servicial

Una de las características más destacadas del Scrum Master es la de ser un líder servicial. Muchas veces será nombrado no como Scrum Master, sino como Facilitador o incluso Coach. Ser líder servicial en este contexto significa apoyar al Equipo, al Scrum Product Owner y a la organización en el correcto uso de Scrum. Pensemos en algunos ejemplos:

  • Asegurar que se practique un Scrum saludable
  • Que los miembros del equipo alcancen niveles de autogestión y multifuncionalidad
  • Que el Equipo pueda concentrarse en crear un incremento de alto valor
  • Eliminar impedimentos al progreso del Equipo
  • Que todos los eventos de Scrum ocurran y sean productivos
  • Facilitar la colaboración con los stakeholders
  • Liderar y capacitar a la organización en la adopción de Scrum


>Conocimiento profundo de Scrum

Quien escoge el camino de Scrum Master está iniciando un camino en el que debe lograr comprender Scrum en profundidad. Su foco está puesto en el proceso de trabajo y en la mejora continua. Su objetivo es que el Equipo Scrum se desarrolle y logre ser un equipo:

  • Competente: No solo en el conocimiento de Scrum, sino en la puesta en práctica.
  • Autogestionado: poder decidir quién trabaja en qué, cómo lo hace y cuándo lo hace.
  • Multifuncional: no depender de terceros para construir un Incremento en cada Sprint.


Para apoyarse en el logro de estos tres objetivos, es recomendable desarrollar y dominar cuatro disciplinas claves: el training, la consultoría, la facilitación y el coaching.

Las habilidades de training son de utilidad para poder transmitir los conocimientos necesarios para comprender Scrum. Las habilidades de consultoría le serán útiles para aconsejar al Equipo Scrum y a los stakeholders en cómo hacer uso de Scrum de una forma eficiente y evitando anti-patrones. La facilitación ágil, por su parte, será una habilidad clave a la hora de los diferentes eventos de Scrum y que sean encuentros significativos para todos los involucrados con resultados de valor. Por último, el coaching ágil es una competencia esencial para acompañar al Equipo Scrum a superarse Sprint tras Sprint, derribar creencias auto limitantes, expandir su abanico de posibilidades con vistas a la entrega de valor y mejorar sus prácticas particulares dentro del framework de Scrum.

>Background técnico

Una pregunta frecuente es si el Scrum Master debe tener conocimiento y habilidades de desarrollo del producto. La respuesta corta es que se recomienda que sí. Aunque el Scrum Master no está a cargo del desarrollo, difícilmente un buen Scrum Master podrá generar una cultura de trabajo agradable y remover dificultades en los procesos de trabajo sin el conocimiento de la industria en que se encuentra. Es más, si el Scrum Master no conoce los aspectos técnicos del desarrollo del producto, esto dificultará su labor de planificación, estimación y comunicación, y el resto del Equipo podría considerarlo insuficiente en su rol.

Certified Scrum Master (CSM)
Certified Scrum Master (CSM)
  • Filosofía y funcionamiento:Valores y principios, Equipo, desarrollo iterativo e incremental con Sprints, Sprint Backlog, Product Backlog y PBIs, refinamiento, criterios de aceptación, y más.
  • El campo de acción del Scrum Master y las cuatro disciplinas de su trabajo cotidiano.
  • Las diferencias entre el liderazgo Ágil y el tradicional para adaptarse mejor a los cambios y liderar desde el servicio.
  • Estimación Relativa de PBIs o Historias de Usuario, planificación evolutiva de desarrollo ágil de productos digitales y métricas basadas en outcomes.

Scrum Product Owner

Entre los otros roles Scrum, y siguiendo la Guía oficial, el Product Owner es quien vela por que los Incrementos construidos por el equipo sean del mayor valor posible en cada Sprint. Una característica del Product Owner es asumirse como único responsable de tomar decisiones acerca del producto.

El producto puede ser un producto digital, físico, un servicio o, inclusive, algo más abstracto como una experiencia. Aunque puede recibir ayuda de otros, no es un trabajo que realiza un comité, lo realiza solo el PO. También recuerda que, si bien podría tomar acciones como desarrollador, las responsabilidades de Product Owner son incompatibles con las del Scrum Master. Esta es una pregunta frecuente y un concepto que es necesario reforzar.

>Establecer los objetivos del producto

Una de las responsabilidades del Product Owner es desarrollar y comunicar explícitamente los objetivos del producto.

Dada la naturaleza colaborativa de Scrum, lo ideal sería que estos objetivos no sean algo impuesto a los demás, sino el resultado de una creación conjunta alrededor de una visión de producto.

La visión de producto establece el escenario futuro a lograr con el producto. Esta visión es típicamente utópica e inspiradora y determina la dirección, pero difícilmente ayude a medir el progreso. La visión de producto no es parte del framework de Scrum.

A partir de la visión, el PO debe establecer la estrategia de creación del producto. En esa estrategia trazará los diferentes objetivos del producto a ir alcanzando. Los objetivos de producto sí son parte del framework de Scrum.

Podríamos deducir entonces que cuando hablemos de Objetivos de Producto estaremos hablando de diferentes hitos de negocio, medibles, que al encadenarse determinan la estrategia de producto hacia una visión.

Tanto la visión, como la estrategia, como los objetivos emergen del trabajo colaborativo que involucra a stakeholders y miembros del Equipo Scrum.

>Determinar el orden en el que se hace el trabajo

Todo lo que forma parte del Product Backlog está ordenado. El orden es muy preciso para aquellas cosas prioritarias que se transformarán en un Incremento en el corto plazo.

No tiene mucho sentido dotar de mucha precisión al orden de aquellas cosas que tienen menor prioridad, en las que se trabajará en el mediano plazo, ya que cualquier esfuerzo dedicado a ordenar con precisión estos ítems es muy probable que se deba volver a invertir cuando se descubra que las prioridades deben cambiar a partir del feedback o el aprendizaje.

Definitivamente, los ítems del Product Backlog a largo plazo no tiene ningún sentido que estén ordenados. A medida que te acerques a ellos en el tiempo, en los Refinamientos, los irás ordenando con mayor precisión.

>Garantizar el entendimiento del Product Backlog

El Product Owner es parte del Equipo Scrum, está en contacto constante con el resto del equipo. Si trabajan de forma remota, está accesible todo el tiempo. Si trabajan de manera presencial, se sienta juntos a los desarrolladores. En cualquier caso, trabaja codo a codo con el resto del Equipo Scrum durante todo el Sprint.

Su responsabilidad es garantizar que todos entiendan lo mismo del Product Backlog. Esto no significa documentar detalladamente los requerimientos, sino conversar y verificar durante el Sprint que el Incremento que se vaya creando cumple con las expectativas.

Al mismo tiempo, coordina y facilita actividades que llamaremos Refinamiento donde los stakeholders, los desarrolladores y el PO se involucran activamente en la definición del producto a mediano plazo y el entendimiento en detalle a corto plazo.

>Visibilizar el Product Backlog

El Product Owner es responsable de que el Product Backlog sea accesible y conocido por todos los involucrados, ya sean miembros del Equipo Scrum, stakeholders o cualquier persona en la organización.

Esto no significa que cualquiera pueda alterarlo, recuerda que solo el PO tiene la potestad de alterar el Product Backlog, pero sí debe facilitar el acceso a verlo, con el fin de informarse. Por ejemplo, sin importar la herramienta que se utilice para almacenar el Product Backlog, la cual podría ser desde Excel, Google spreadsheets, Trello, Monday, Jira, etc; no haya restricción de acceso y en cada comunicación/e-mail es útil incluir en el pie un link a la visualización del Product Backlog.

En el ejercicio de su función dentro de Scrum, se espera que el PO gestione eficientemente las variables de negocio involucradas y conozca profundamente los problemas que el producto pretende resolver a los usuarios. En resumen, el Product Owner es responsable del éxito del producto.

Para que sepas: 3 similitudes y 3 diferencias entre Product Owner Interno y Product Owner Externo

Certified Scrum Product Owner (CSPO)
Certified Scrum Product Owner (CSPO)
  • Comunicarás el progreso a los Stakeholders para calmar ansiedades y despertar su involucramiento.
  • Diferenciarás Product Discovery de Product Delivery y comprende el valor de cada una de esas disciplinas.
  • Segmentarás tu universo de consumidores o usuarios para empatizar e identificar necesidades profundas de cada uno.
  • Conocerás los criterios para ordenar el Product Backlog según la estrategia de producto y la fase del ciclo de vida en la que se encuentra.


Scrum Developers

Por último, entre los roles de Scrum, también nos encontramos con quienes tienen la responsabilidad de Developers dentro del Equipo Scrum. Los Developers o Desarrolladores son los integrantes del equipo que crean el Incremento del Sprint.

Un dato interesante es que anteriormente a los Developers se los conocía como el Equipo de Desarrollo, pero esta terminología se ha actualizado a Developers porque en verdad el Equipo Scrum es uno solo.

Dentro de los tres roles Scrum, así como el Scrum Master es experto en Scrum y el Product Owner es experto en visión y estrategia de producto, para los Developers no existe un set predeterminado de habilidades específicas ya que esto dependerá del tipo de industria y producto que estén creando.

Al margen de las habilidades técnicas que deban tener, las cuales varían según la industria en la cual te desempeñas, hay ciertas responsabilidades que son inalienables.

>Crear el Plan del Sprint

En principio, los Devs son los responsables de crear el plan de cada Sprint. Para poder crear este plan, antes deberían haber estimado el trabajo a realizar, identificado cuánto de ese trabajo pueden realizar en el Sprint en cuestión, desglosar ese trabajo en diferentes tareas y darle cierta coherencia a todo ese trabajo.

Este plan se verá reflejado en el Sprint Backlog, no está escrito en piedra e irá mutando durante el Sprint en función del aprendizaje que vaya emergiendo.

>Entregar solo aquello que esté “terminado”

En segunda instancia, los desarrolladores deberán mostrarse comprometidos con los estándares de calidad asumidos por todos y registrados en la Definición de Terminado. Nadie podrá solicitarles la alteración de esos criterios con el fin de terminar más rápido o entregar más cantidad de producto. Deberán defender la calidad de tu trabajo como algo no negociable. El Incremento de cada Sprint debe estar alineado con este Definición de Terminado.

Por respeto a su propio trabajo, a los compañeros de equipo y a los stakeholders, no entregarán nada que no esté terminado.

>Adaptar el plan frecuentemente

En tercer lugar, los Developers del Equipo Scrum son responsables de revisar día a día, junto a los demás desarrolladores, el avance hacia el objetivo del Sprint. Es su responsabilidad compartida detectar desvíos y tomar las decisiones necesarias para adaptar el plan de las próximas 24 horas con el objetivo de corregir cualquier eventualidad.

Los Desarrolladores tienen la responsabilidad de decidir ellos mismos cuál es la mejor forma de trabajar, es decir la manera en que alcanzarán el Objetivo del Sprint y participan de todas las reuniones que ocurren dentro del Sprint de trabajo de Scrum.

Una pregunta frecuente: Desarrolladores en Scrum: ¿Cuál es la diferencia entre un programador y un desarrollador?