Los 3 roles, en una tabla
La pregunta que ordena todo no es «qué hace cada uno» sino «quién decide qué cuando hay que elegir». Ahí es donde los roles se distinguen de verdad.
Product Owner
- Responde por
- El valor del producto
- Decide
- Qué se construye y en qué orden va el Backlog
- No decide
- Cómo se construye ni cuánto entra en el Sprint
Scrum Master
- Responde por
- La efectividad del equipo y del marco
- Decide
- Cómo se facilita el proceso y qué impedimento se ataca
- No decide
- El contenido del Backlog ni la asignación de tareas
Developers
- Responde por
- Un Increment usable cada Sprint
- Decide
- Cómo se construye y cuánto se compromete en el Sprint
- No decide
- La prioridad de negocio del Backlog
Product Owner: el único dueño del Backlog
El Product Owner es una persona, no un comité. Puede recoger input de stakeholders, de ventas o de gerencia, pero la decisión de orden es suya y nadie debería poder saltarse esa decisión metiendo trabajo por un canal lateral.
El síntoma más común de un PO sin poder real es que el Backlog se reordena en una reunión donde el PO no estaba. Cuando eso pasa, el rol existe en el organigrama pero no en la práctica: alguien más está haciendo el trabajo de priorizar, y normalmente lo hace sin contexto de lo que el equipo ya se comprometió.
- Formula el objetivo de producto y lo mantiene visible
- Ordena el Product Backlog y explica por qué ese orden
- Se asegura de que el Backlog sea transparente y entendible
- Está disponible para resolver dudas durante el Sprint, no solo en el Planning
Scrum Master: autoridad sobre el proceso, no sobre las personas
El Scrum Master no tiene gente a cargo. Su influencia viene de la facilitación, no de la jerarquía, y esa es exactamente la parte que más cuesta sostener: pedirle a un gerente que deje de meter trabajo a mitad de sprint sin poder invocar ningún cargo.
En muchas empresas peruanas el Scrum Master termina siendo el que arma el reporte de avance para gerencia. Es entendible —alguien tiene que dar visibilidad— pero cuando esa se vuelve su función principal, el equipo deja de tener a quien le cuide el proceso y pasa a tener un coordinador de status.
- Facilita las ceremonias para que sirvan, no para que ocurran
- Remueve impedimentos que el equipo no puede resolver solo
- Protege al equipo del trabajo que entra sin negociación
- Forma a la organización, no solo al equipo, en cómo funciona Scrum
Developers: se autogestionan o no son Developers
En Scrum, «Developers» incluye a todos los que construyen el Increment: programadores, QA, diseño, datos. No es sinónimo de programador.
Lo que define al rol es la autogestión: el equipo decide cómo hacer el trabajo y cuánto puede comprometer en un Sprint. Si las tareas llegan asignadas desde afuera y el compromiso lo fija otro, tienes un equipo ejecutando tickets con vocabulario de Scrum encima.
Señales de que los roles están mal implementados
Ninguna de estas señales aparece en la Scrum Guide, pero todas aparecen en equipos reales. Si reconoces dos o más, el problema no es que falte capacitación: es que el sistema alrededor del equipo no cambió.
- El Scrum Master asigna tareas en la Daily
- El Product Owner necesita aprobación de un comité para reordenar el Backlog
- Los Developers reciben el alcance del Sprint ya cerrado
- Una misma persona es Scrum Master y Product Owner del mismo equipo
- El Scrum Master reporta el avance individual de cada persona a gerencia
¿Y el jefe de proyecto? Lo que pasa en Perú
Scrum no tiene rol de jefe de proyecto, y esa ausencia es la que más fricción genera en organizaciones peruanas donde el PMO sigue existiendo. Las responsabilidades del jefe de proyecto no desaparecen: se reparten. El alcance y la prioridad se van al Product Owner, la forma de trabajar y los impedimentos al Scrum Master, y la estimación y el cómo a los Developers.
El error caro es renombrar al jefe de proyecto como Scrum Master y dejarle las mismas atribuciones. El equipo aprende rápido que el cambio fue de vocabulario, y a partir de ahí cualquier intento de agilidad se lee como discurso.
Preguntas frecuentes
Product Owner, Scrum Master y Developers. Desde la Scrum Guide de 2020 se llaman «responsabilidades» (accountabilities) y no roles, para dejar claro que son compromisos dentro del equipo y no cargos del organigrama.