Entender los tres roles y sus responsabilidades.
El Equipo Scrum es una unidad cohesiva de profesionales enfocados en un producto.
No hay sub-equipos ni jerarquías—solo tres responsabilidades distintas:
Nota: La Guía de Scrum 2020 usa "Developers" para todos los que crean el Incremento, sin importar el título del puesto. Testers, diseñadores y otros son todos "Developers" en términos de Scrum.
Tamaño del Equipo
Los Equipos Scrum típicamente tienen 10 personas o menos. Los equipos más pequeños se comunican mejor. Si necesitas más personas, considera múltiples Equipos Scrum.
El Product Owner es una persona, no un comité. Es responsable de:
Desarrollar y comunicar el Objetivo del Producto La visión de hacia dónde se dirige el producto. Esto guía todas las decisiones.
Crear y ordenar el Product Backlog Decidir qué construir y en qué secuencia. Esto requiere entender el valor, el riesgo y las dependencias.
Asegurar que el backlog sea transparente y comprendido El equipo debe entender los elementos del backlog lo suficientemente bien para discutirlos.
Principio clave: El Product Owner puede delegar estas actividades, pero permanece responsable de ellas. La organización debe respetar las decisiones del PO—el backlog refleja sus decisiones, no un voto de comité.
Sarah dice 'no' a una solicitud de un interesado que no se alinea con el Objetivo del Producto. Explica el trade-off y sugiere una alternativa para el próximo trimestre.
El 'Product Owner' es en realidad tres personas que votan sobre prioridades. Las decisiones toman días y nadie asume la responsabilidad de los resultados.
Los Developers son profesionales que crean cualquier aspecto de un Incremento utilizable en cada sprint. Son responsables de:
Crear un plan para el sprint (Sprint Backlog) Los Developers deciden CÓMO convertir los elementos del backlog en un Incremento.
Infundir calidad adhiriéndose a una Definición de Terminado La calidad no es negociable. Terminado significa terminado—no "terminado pendiente de pruebas".
Adaptar su plan cada día hacia el Objetivo del Sprint El Sprint Backlog es un plan vivo, actualizado a medida que el equipo aprende.
Responsabilizarse mutuamente como profesionales La autogestión significa que el equipo maneja sus propios problemas.
Principio clave: Nadie le dice a los Developers cómo hacer su trabajo. El Product Owner dice QUÉ construir; los Developers deciden CÓMO.
Malentendido Común
"Developers" no significa "solo programadores". Ingenieros de QA, diseñadores de UX, DBAs—cualquiera que cree el Incremento es un Developer en términos de Scrum.
El Scrum Master es responsable de la efectividad del Equipo Scrum. Sirve al equipo y a la organización mediante:
Ayudar al equipo a mejorar sus prácticas Coaching, facilitación, enseñanza. No hacer el trabajo por ellos.
Eliminar impedimentos al progreso del equipo Cuando algo bloquea al equipo que no pueden resolver por sí mismos, el Scrum Master ayuda a eliminarlo.
Asegurar que los eventos de Scrum sean productivos y con tiempo limitado Facilitación, no toma de asistencia.
Ayudar a la organización a adoptar Scrum A veces los mayores impedimentos son organizacionales. El Scrum Master también los aborda.
Principio clave: El Scrum Master es un líder-servidor—lidera sirviendo, no comandando. No tiene autoridad sobre el equipo excepto la autoridad de la experiencia y la confianza.
Durante la retrospectiva, el SM nota que un desarrollador duda. Crea espacio para que esa persona hable haciendo una pregunta directa, luego la protege de interrupciones.
El 'Scrum Master' asigna tareas, reporta el estado a la gerencia y toma decisiones técnicas por el equipo.
Las tres responsabilidades crean un equilibrio de poder:
Product Owner ↔ Developers El PO decide QUÉ y POR QUÉ. Los Developers deciden CÓMO y se comprometen con CUÁNDO (basándose en su capacidad, no en presión externa).
Scrum Master ↔ Product Owner El SM ayuda al PO con técnicas de gestión del backlog y comunicación con interesados. Entrena sobre propiedad efectiva del producto.
Scrum Master ↔ Developers El SM ayuda a los Developers a auto-organizarse, mejorar prácticas técnicas y eliminar bloqueos. Nunca asigna trabajo ni microgestiona.
La tensión clave: Los POs quieren más alcance; los Developers quieren un ritmo sostenible; el SM asegura que el proceso respete ambos.