El equipo Scrum © IMF Smart Education

Índice
El equipo Scrum 3
I. Introducción 3
II. Objetivos 4
III. Equipo Scrum (Scrum team) 5
IV. Propietario del producto (product owner) 6
4.1. ¿Qué hace un buen product owner? 8
V. El equipo de desarrollo (Development team) 10
5.1. Tamaño del equipo de desarrollo 12
VI. El Scrum master 13
6.1. El Scrum master al servicio del propietario del producto (product owner) 15
6.2. El Scrum master al servicio del equipo de desarrollo (development team) 17
6.3. El Scrum master al servicio de la organización 18
VII. Resumen 20
Ejercicios 22
Caso práctico 22
Datos 22
Se pide 22
Solución 22
Recursos 24
Enlaces de Interés 24
Glosario. 24

2/26
 El equipo Scrum

El equipo Scrum
I. Introducción
En la unidad sobre el equipo Scrum se van a aprender y comprender los distintos roles de Scrum, qué
diferencia hay entre un project manager o gestor de proyectos tradicional y los roles que hay en el marco
de trabajo de Scrum.

Se descubrirá algo que a priori puede sonar un poco utópico: que los equipos Scrum (Scrum teams )
son autoorganizados y multifuncionales. Los equipos autoorganizados eligen la mejor opción de llevar a
cabo su trabajo y no son dirigidos por personas externas al equipo. Y se verán las ventajas de que esto
sea así.

Se aprenderá que el propietario del producto (product owner) es el responsable de maximizar el valor
del producto del trabajo del equipo de desarrollo (Development team), pero que no es el responsable o
mánager de los miembros del equipo, que se dedica a priorizar, principalmente.

Se verán los comportamientos de un buen product owner y, por tanto, se entenderá qué no es un buen
product owner. Ser un buen propietario del producto no es nada fácil.

Se comprenderá qué es el equipo de desarrollo, y que se refiere a equipo que ejecuta o desarrolla tareas
relacionadas con un producto o servicio. Y no necesariamente se refiere a un equipo de desarrollo de
software.

También se aprenderá cómo de grande y de pequeño puede ser un equipo Scrum, y cómo dividir los
equipos para que cumplan los requisitos de tamaño y conocimiento.

3/26
 El equipo Scrum

El último rol que se verá es el de Scrum master (término que no se puede traducir al español), cuáles son
sus funciones y cuáles no, así como que está al servicio del product owner, del Development team y de
la organización.

Además, se aprenderá hacia dónde tiene que empujar un Scrum master a la organización para que sea lo
más partidaria posible para el uso de Scrum.

II. Objetivos
1

Equipo Scrum (Scrum team).

Propietario del producto (product owner).

¿Qué hace un buen product owner?

El equipo de desarrollo (Development team).

Tamaño del equipo de desarrollo.

El Scrum master.

El Scrum master al servicio del propietario del producto.

El Scrum master al servicio del equipo de desarrollo.
El Scrum master al servicio de la organización.
¿Hacia dónde tendrán que impulsar los Scrum Master a la organización para tener una cultura
partidaria de Scrum?

4/26
 El equipo Scrum

Diferencias entre project manager y product owner y Scrum master.

III. Equipo Scrum (Scrum team)

Vocabulario: Equipo Scrum
Un equipo Scrum (Scrum team) es un equipo completo en el que sus miembros siguen el marco de Scrum.
Está formado por un propietario del producto (product owner), el equipo de desarrollo (Development
team) y un Scrum master.
Figura 1. Roles de Scrum

Figura 1. Roles de Scrum.

Fuente: Elaboración propia basado en scrum.org

Los equipos Scrum presentan las siguientes características:

Son autoorganizados. Los equipos autoorganizados eligen la mejor opción de llevar a cabo su trabajo y
no son dirigidos por personas externas al equipo.

5/26
 El equipo Scrum

Son multifuncionales tienen todas las competencias y habilidades necesarias para llevar a cabo el trabajo
sin depender de otras personas que no formen parte del equipo.

El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la

productividad. El equipo Scrum ha demostrado ser incrementalmente efectivo para todos los usos
anteriores y para cualquier trabajo complejo.

Los equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades
para poder obtener retroalimentación.

Las entregas incrementales de producto “terminado” aseguran que siempre estará disponible una versión
potencialmente útil y funcional del producto a la finalización de cada iteración (sprint).

IV. Propietario del producto (product owner)

El propietario del producto (product owner) es el responsable de maximizar el valor del producto del
trabajo del equipo de desarrollo. Es también la única persona responsable de gestionar la pila del producto
(product backlog). Las funciones del producto owner para la gestión de la pila del producto incluyen:

Ordenar los elementos en la pila del producto para alcanzar los objetivos y las misiones de la mejor
manera posible.

Expresar claramente los elementos de la pila del producto.

6/26
 El equipo Scrum

Optimizar el valor del trabajo que realiza el equipo de desarrollo; que la pila del producto sea visible,
transparente y clara para todos, y que muestre lo que el equipo trabajará a continuación.

Asegurar que el equipo de desarrollo entiende los elementos de la pila del producto a nivel necesario. El
propietario del producto podría hacer el trabajo anterior o delegarlo en el equipo de desarrollo. Sin
embargo, en ambos casos el propietario del producto sigue siendo el responsable (tiene la
accountability) de dicho trabajo.

El propietario del producto es una única persona, no un comité. Este podría representar los deseos de
un comité en la pila del producto, pero aquellos que quieran cambiar la prioridad de un elemento de la
pila deben hacerlo a través del propietario del producto.

Figura 2. Funciones principales del Product Owner.

Fuente: Elaboracion propia basada en scrum.org

Para que el propietario del producto pueda hacer bien su trabajo, toda la organización debe respetar sus
decisiones. Las decisiones del propietario del producto se reflejan en el contenido y en la priorización de la
pila del producto. Nadie puede pedir al equipo de desarrollo que trabaje en un conjunto diferente de
requisitos.

El propietario del producto tiene que actuar como guardián del castillo, protegiendo al equipo de desarrollo
de peticiones del resto de la organización sin haber pasado por su filtro. En concreto, evitará que mánager
de otras áreas les pidan realizar trabajos a los miembros del equipo de desarrollo sin haber pasado por él
primero. Esto no se hace para restar autonomía a los miembros del equipo, es para ofrecerles protección.

Por otro lado, el product owner no puede asignar las tareas los miembros del equipo. Las prioriza, las
detalla, las explica…, pero es el equipo el que de forma autoorganizada se reparte y asigna las tareas según
su criterio.

7/26
 El equipo Scrum

Resumen: Product Owner

Responsable de maximizar el valor del producto.

Gestiona presupuestos, consigue miembros para el equipo de desarrollo, se asegura de que se
explique el valor a los stakeholders.
Tiene poder de decisión.
Tiene gran conocimiento de los usuarios y clientes.
Intraemprendedor: mide el valor generado y aprovecha la flexibilidad de las entregas por sprint.
1 Producto -> 1 Product Backlog -> 1 PO.
El product owner es solamente una persona.
El product owner o propietario del producto no puede actuar como un mánager. Es decir, podrá tener
la categoría profesional de mánager, pero no podrá actuar como tal, y, en concreto:
No será el responsable de la evolución profesional de los miembros del equipo de desarrollo o
del equipo Scrum.
No será responsable de potenciales subidas de sueldo.
No será el responsable de solicitar formaciones.
No será el responsable de aprobar vacaciones, permisos, reducciones de jornada…
No será el responsable de asignar trabajo o tareas a los miembros del equipo.
Que actuara como un mánager le inhabilitaría para poder realizar sus funciones como product owner.
Si fuera imprescindible que recayeran en una misma persona las funciones de responsable de la pila
de producto y mánager del equipo, entonces habría que hacer explícito que no se está realizando
Scrum y al puesto de esa persona se le denominaría mánager, responsable de equipo ágil…, pero
nunca product owner, para distinguirlo de aquellos que Sí son realmente product owners y no
mánager.

4.1. ¿Qué hace un buen product owner?

El product owner es un emprendedor: un maximizador y optimizador de valor.

Un buen product owner se hará responsable de los problemas e incidencias del producto o servicio, del
que es el último responsable.

También dará todos los méritos a los miembros del equipo por los éxitos y el buen trabajo realizado en el
producto o servicio.

Siempre que sea posible, permitirá que los miembros del equipo expongan los trabajos realizados ante los
interesados (stakeholders ) en las reviews .

El Product Owner establece una visión sólida para ayudar al equipo Scrum a mantener el foco y la
dirección, lo que ayuda al progreso incremental al final de cada sprint.

8/26
 El equipo Scrum

1 producto = 1 product backlog = 1 propietario del producto.

Tener un product owner por cada producto ayuda con la claridad y el enfoque, asegura una rápida toma de
decisiones y la responsabilidad de una sola persona para el éxito del producto.
1

Para validar el valor o ideas, el product owner pone a disposición de los clientes frecuentemente el
incremento del producto. Así se obtiene información real del cliente.

El product owner tiene la última palabra en el orden del product backlog. Este ordena los elementos del
producto backlog teniendo en cuenta el valor de los elementos (tareas), las dependencias entre ellos y
las dependencias con los otros productos (y equipos).

El product owner garantiza que el equipo de desarrollo genere en todo momento la funcionalidad más
valiosa, pero con algunos matices.

Si siempre deja con prioridad baja las peticiones de un grupo de interesados y, por tanto, nunca se
abordan, ese grupo acabará desconectando de ese equipo. Entre los distintos grupos de interesados están
las mejoras que propone el propio equipo de desarrollo, si no se abordan nunca, generará una gran
desafección dentro del equipo y problemas a futuro (se estará construyendo todo sobre un castillo de
naipes).

Más que valiosa, la que tenga la mejor relación valor/esfuerzo-complejidad, y teniendo en cuenta que
tendrá que encontrar un equilibrio entre las peticiones de distintos interesados.

El product owner es el responsable del retorno de la inversión (ROI) y el coste total de propiedad (total
cost of ownership) antes de que se cree/desarrolle una característica.

Este garantiza que todo el trabajo realizado por el equipo de desarrollo provenga de un único product
backlog, para evitar que se cuelen cosas de menor prioridad y protegiendo al equipo.

9/26
 El equipo Scrum

Para determinar el valor del producto que se entrega, el product owner puede usar métricas, como el
tiempo de comercialización (tiempo de ciclo/tiempo de entrega —cycle time/lead time—), el porcentaje
de funcionalidades lanzadas que son utilizadas por los clientes y la satisfacción general del cliente.

El product owner es responsable de interactuar y relacionarse con los interesados (stakeholders ).

Conseguirá que asistan y participen en la revisión del sprint (sprint review).

Además, llega a la planificación de sprint con un claro objetivo de negocio en mente y trabaja con el
equipo de desarrollo para elaborar un objetivo de sprint basado en la previsión que realiza el equipo de
desarrollo.

Durante el sprint en curso, el product owner es responsable (accountable) del refinamiento del product
backlog, pero puede delegar el trabajo al equipo de desarrollo.

El product owner es el único que puede terminar anormalmente el sprint en caso de que el objetivo de
este se vuelva obsoleto.

Asimismo, genera confianza al trabajar estrechamente con los equipos de desarrollo. No duda en delegar
el trabajo de detallar elementos del product backlog (tareas) al equipo de desarrollo. Como en el resto
de cosas, al delegar, se sigue manteniendo la responsabilidad (accountability, si permite delegación).

El product owner no es un project manager.

El product owner no es un product manager.

Son roles distintos, mapearlos y encontrar diferencias sería largo, lo importante es reforzar que si se hace
Scrum (de verdad) hay un product owner por producto y que un product owner no es ni un project
manager ni un product manager.

V. El equipo de desarrollo (Development team)

10/26
 El equipo Scrum

Cuando se dice equipo de desarrollo se hace referencia al equipo que ejecuta o desarrolla tareas
relacionadas con un producto o servicio. No se refiere a un equipo de desarrollo software (cuando se
escribió la primera versión de la guía de Scrum sí se referían a un equipo de desarrollo software, pero hoy
Scrum se aplica a muchos más usos y, por tanto, el ámbito del equipo de desarrollo es mucho más
genérico).

Vocabulario: Equipo de desarrollo

El equipo de desarrollo se compone de profesionales que realizan el trabajo de entregar un incremento de
producto “terminado” (done) que potencialmente se pueda poner en producción el final de cada iteracción.
Es obligatorio en la revisión del sprint el equipo tenga un incremento de producto “terminado”. Solo los
miembros del equipo de desarrollo participan en la creación del incremento.
La organización tiene que estructurar y empoderar a los equipos de desarrollo para que estos organicen y
gestionen su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del equipo de
desarrollo.

Figura 3. Rol de Development Team

Fuente: Elaboracion propia basada en scrum.org

Los equipos de desarrollo tienen las siguientes características:

Son autoorganizados. Nadie (ni siquiera el Scrum master) indica al equipo de desarrollo cómo convertir
elementos de la pila del producto (por elementos de product backlog se puede pensar en tareas) en
incrementos de funcionalidad potencialmente desplegables.

Sucede que Scrum masters con poca experiencia indican al equipo cómo dividir las tareas en subtareas,
asignan las tareas, estiman por el equipo… Esto es un gran error. Si se ven esos comportamientos, de
forma muy educada se tiene que indicar al Scrum master que se ciña a su rol y permita la
autoorganización del equipo de desarrollo.

Los equipos de desarrollo son multifuncionales, con todas las habilidades necesarias para crear un
incremento de producto.

Esto no quiere decir que todos sepan hacer de absolutamente de todo, simplemente que entre todos
cubren todas las habilidades necesarias. Igual solamente se requiere una habilidad y todos la tienen, o se
requieren dos habilidades y el 80 % del equipo de desarrollo tiene la primera y el 20 % tiene la segunda
habilidad, lo importante es que entre todos tengan todas las habilidades.
Por supuesto, lo ideal sería que todos supieran hacer de todo o que todos fueran muy buenos en una
cosa y razonablemente buenos en casi todas las cosas. Esto ayuda mucho en vacaciones,
enfermedades, picos de trabajo de una actividad determinada…

11/26
 El equipo Scrum

Scrum no reconoce títulos para los miembros de un equipo de desarrollo, independientemente del
trabajo que realice cada persona.

Esto quiere decir que para Scrum no existen los roles o títulos de QA (experto en calidad), business
analyst (analista de negocio), ni ningún otro. Scrum no reconoce subequipos en los equipos de
desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas,
arquitectura, operaciones, o análisis de negocio.

Los miembros individuales del equipo de desarrollo pueden tener habilidades especializadas y áreas en
las que estén más enfocados, pero la responsabilidad recae en el equipo de desarrollo como un todo.

Esto quiere decir que no sirve de nada que unos miembros del equipo de desarrollo realicen muy bien
sus tareas si el resto del equipo no ha realizado correctamente las suyas. Son un único equipo y todos
son absolutamente responsables de todo el trabajo que realizan. Se podrá asignar temporalmente quién
hace qué tarea, pero la responsabilidad de esa y de todas las tareas sigue siendo del conjunto del
equipo.

Resumen: Equipo de desarrollo

De tres a nueve profesionales.

Deciden cómo y lo ejecutan.
Ejecutan tareas (según el sector podrán desarrollar software, pero no siempre).
Cross-functional: capaces de hacer todo lo necesario, sin dependencias externas.
No todos tienen que saber hacer de todo, pero al menos debe haber uno especializado en cada tarea.
No hay roles en el equipo de desarrollo del tipo: tester, business analyst, front, back, etc.

5.1. Tamaño del equipo de desarrollo

El tamaño óptimo del equipo de desarrollo es lo suficientemente pequeño como para permanecer ágil y lo
suficientemente grande como para poder completar una cantidad de trabajo significativa.
Tener menos de tres miembros en el equipo de desarrollo reduce la interacción y resulta en ganancias de
productividad más pequeñas.

Los equipos de desarrollo más pequeños podrían encontrar limitaciones en cuanto a las habilidades
necesarias durante un sprint, haciendo que el equipo de desarrollo no pudiese entregar un incremento que
potencialmente se pueda poner en producción.

Esto quiere decir que un equipo pequeño (dos-tres personas) va a tardar mucho en realizar unas tareas de
una cierta envergadura y, además, va a tener problemas para contar con todas las habilidades necesarias.

12/26
 El equipo Scrum

Tener más de nueve miembros en el equipo requiere demasiada coordinación. Los equipos de desarrollo
grandes generan demasiada complejidad como para que un proceso empírico pueda ser de utilidad. Los
roles de propietario del producto y Scrum master no se contabilizan en el cálculo del tamaño del equipo a
menos que también estén contribuyendo a trabajar en la pila del sprint.

El tamaño del equipo de desarrollo será de un mínimo de tres profesionales y máximo de nueve.
En general, no se tienen en cuenta al product owner ni al Scrum master.
Si un equipo va a crecer a un número superior a nueve, hay que dividirlo en varios equipos.
La mejor forma de crear equipos es pedir a los profesionales que se dividan como equipos (dejar a
los que van a estar en el día a día trabajando en sacar resultados que sean los que elijan cómo dividir
los equipos, con la premisa de que estén equilibrados entre sí).

VI. El Scrum master

Figura 4. Funciones principales del Scrum master

Fuente: Elaboracion propia basada en scrum.org

El Scrum master tiene las siguientes características:

Los Scrum masters hacen esto ayudando a todos con la teoría de Scrum, prácticas, reglas y valores.

Esto quiere decir que el Scrum master tiene que velar por que se aplique correctamente Scrum en el
equipo. Sin embargo, hay que tener en cuenta que tiene que hacerlo con inteligencia o habilidad. No
puede actuar como un “policía del Scrum”, tiene que saber cuál es su objetivo y ha de encontrar las
formas para conseguir que los miembros del equipo y la organización vayan convergiendo hacia allí. Por
tanto, no deberían obligar, sí debería sugerir y fomentar las mejores prácticas de Scrum.

El Scrum master es un líder servicial (servant leader) que está al servicio del equipo Scrum. El Scrum
master ayuda a las personas externas al equipo a entender qué interacciones con el equipo Scrum
pueden ser útiles y cuáles no. El Scrum master asiste a todos para modificar estas interacciones y, así,
maximizar el valor creado por el equipo Scrum.

Un líder servicial no es el que reserva las salas de reuniones ni el que trae los cafés a los asistentes, lo
que trata es de que se empoderen los equipos y los anima y guía para que ellos tomen las riendas,
reserven las salas, lancen convocatorias de reuniones, etc. Para que sea un líder deberá tener seguidores
(followers ), y eso lo conseguirá resultando útil al equipo y a la organización al ayudarles a conseguir los
mejores objetivos de negocio posibles de forma continuada, mediante la mejora continua y las mejores
prácticas de Scrum.

13/26
 El equipo Scrum

Es importante que ayude a mánager y directores a relacionarse con el equipo Scrum.

Por ejemplo, pidiéndoles que acudan al product owner en vez de realizar peticiones a los miembros del
equipo de desarrollo. También informándoles de que, si quieren un informe de la situación del
proyecto/producto, lo podrán ver en todo momento en el tablero del equipo, y que si quieren una
explicación más detallada el momento es la sprint review.

Importante: El Scrum master no es un project manager

Las funciones de un project manager en un proyecto predictivo difieren de aquellas que asume el Scrum
master en Scrum. A continuación, se enumeran las responsabilidades de cada uno de ellos:

Project manager vs. Scrum master

Project manager Scrum master
► Fijar objetivos definidos: A/T/C.
► Asegurar el entrenamiento del equipo.
► Definir el alcance.
► Planificar los sprints.
► Preparar el horario de trabajo para los
miembros del equipo.
► Programar la reunión diaria de Scrum.
► Reunir los requisitos.
► Gestionar el proceso Scrum de forma
responsable.
► Definir los requerimientos de recursos para
el proyecto.
► Ayudar a los equipos de Scrum a seguir las
prácticas de Scrum.
► Preparar el presupuesto para un proyecto.
► Eliminar barreras para que el equipo pueda
► Asegurar la calidad.
centrarse en su trabajo.
► Mitigar los riesgos.
► Ayudar con la cartera de productos.
► Mantener un seguimiento de los planes.
► Cooperar con el propietario del producto
en el diseño de los elementos del product
► Obtener comentarios de los usuarios. backlog para el próximo sprint.
► Gestionar las relaciones con el cliente y las ► Proteger al equipo de las distracciones
partes interesadas.
externas.
► Terminar el proyecto.

14/26
 El equipo Scrum

Resumen: Scrum master

Mantiene Scrum en el día a día: formación, mentoring, etc.

Elimina impedimentos en la organización, afecten a Scrum o a la entrega de valor.
Propicia que la organización sea amable con el framework Scrum.
Ejerce influencia en aquellos que tienen puestos de responsabilidad.
Cambia procesos internos para favorecer adopción Scrum.
Podrá estar en varios equipos, pero el resultado se verá afectado.

La única excepción en la que puede haber un project manager en un equipo Scrum sería cuando tambien
ejerce de project manager en otro proyecto que no es el trabajo diario de ese equipo Scrum, es decir,
cuando está gestionando un proyecto que están realizando en otra área o está subcontratado.

6.1. El Scrum master al servicio del propietario del

producto (product owner)

Un Scrum master ayudará al product owner de varias formas, sobre todo enseñándole, formándole,
mentorizándole… Si el Scrum master se convierte en el asistente del product owner que realiza de forma
regular las tareas que tiene como responsabilidad el product owner, le está haciendo un flaco favor a este
(al no dejarle mejorar esas habilidades), al equipo (al tener abandonadas por falta de tiempo otras funciones
que solamente el Scrum master puede realizar) y a la organización.

Esto sucede especialmente en Scrum masters noveles que se quieren hacer imprescindibles con un enfoque
cortoplacista y equivocado.

Es importante que las figuras del product owner y del Scrum master estén equilibradas para el correcto
funcionamiento de Scrum, del equipo y de la entrega de valor.

Lo más habitual es que los product owners sean internos, con categoría de mánager o con un seniority
muy alto, y en muchos casos, el Scrum master es de una consultora y tiene un par de años de experiencia.

Si ese Scrum master no contrapesa el poder del product owner y se empodera desde el inicio, hay muchas
posibilidades de que el product owner continúe ejerciendo de mánager, acabe asignando tareas,
presionando en exceso al equipo con los tiempos… Es fundamental que tengan mucha colaboración entre
ellos y que el Scrum master haga que el product owner evite tener comportamientos que no están alineados
con Scrum o el agilismo, y que los corrija, ya que a medio plazo traerían muchos problemas al equipo.

El Scrum master sirve al propietario del producto de varias formas, incluyendo las siguientes:

15/26
 El equipo Scrum

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el
equipo Scrum de la mejor manera posible.

Es fundamental que los miembros del equipo entiendan correctamente qué hay que realizar (el cómo lo
fijarán ellos mismos), pero si no entienden el qué, difícilmente alcanzará las expectativas del product
owner.

Encontrar técnicas para gestionar la pila del producto de manera efectiva.

Asegurar que el propietario del producto conozca cómo ordenar la pila del producto para maximizar el
valor, enseñando al product owner las mejores prácticas para mantener el product backlog priorizado,
ordenado…, así como que estén estimados el valor y el esfuerzo-complejidad, y ordenando los
elementos por ese valor, teniendo, además, en cuenta las dependencias internas y externas.

Ayudar al equipo Scrum a entender la necesidad de contar con elementos de pila del producto
claros y concisos.

Cuanto más grandes sean los elementos del product backlog, mayor es la probabilidad de que no lo
entiendan correctamente, que surjan problemas y que requieran más de un sprint para finalizarlo. El
Scrum master tiene que sugerir al product owner y miembros del equipo que los elementos del product
backlog (tareas…) tengan un tamaño abordable.

Entender la planificación del producto en un entorno empírico.

Hacer entender que Scrum no se basa en suposiciones a largo plazo, sino que hay que tomar decisiones
según se van obteniendo resultados iterativos e incrementales. Esos resultados serán tangibles y no
suposiciones hipotéticas.

Entender y practicar la agilidad.

El Scrum master tiene que conseguir con sutiliza que el product owner sea un promotor de un correcto
Scrum, que entienda y lo practique tan cerca como sea posible de la guía de Scrum.

Facilitar los eventos de Scrum según se requiera o necesite.

El Scrum master no facilita por defecto los eventos de Scrum. El equipo de desarrollo o el product
owner se lo tienen que solicitar o tiene que ser necesaria su facilitación. Por otro lado, les hará ver, con
inteligencia emocional, la importancia de que realicen correctamente los eventos de Scrum. Y cuando
facilite los eventos, lo hará de forma que evite “ser juez y parte”, tendrá que hacer de espejo de las
situaciones, pero evitando dar sus opiniones.

16/26
 El equipo Scrum

Resumen: Scrum master

Asegura que Scrum se entiende y se sigue.

Facilita los eventos de Scrum cuando se le solicite (o sea realmente necesario).
Ayuda a que todos se adieran a la teoría, practicas y reglas de Scrum
Ayuda a que las personas abracen y vivan los valores de Scrum.
Hace de líder servicial para el PO, el equipo Scrum y la organización.
Fomenta cambios que mejoran la calidad o la productividad.
Permea la agilidad en la organización.

6.2. El Scrum master al servicio del equipo de desarrollo

(development team )
El Scrum master ayudará al equipo fomentando su correcta evolución y no entrando dentro de las
responsabilidades del equipo de desarrollo (lo mismo que con el product owner).

En concreto, no asignará tareas a los miembros del equipo de desarrollo y no buscará ayuda fuera del
equipo en caso de dificultades, cuando con un poquito de tiempo podrá resolverse desde dentro del
equipo. Tampoco gestionará sus vacaciones, permisos…

El Scrum master sirve al equipo de desarrollo varias formas, incluyendo las siguientes:

1
Guiar al equipo de desarrollo para ser autoorganizado y multifuncional, que el equipo elija cómo
organizarse a todos los niveles. Cómo abordar tareas, vacaciones… Y que entre todos tengan las
habilidades que se requieran al equipo, y, en la medida de lo posible, sugerirles que lo unos se enseñen a
los otros.

Ayudar al equipo de desarrollo a crear productos de alto valor, recordándoles que se trabajará por los
elementos del product backlog que han sido priorizados y planificados previamente, sugiriéndoles que,
si se quedan atascados con una tarea, informen al resto y pidan ayuda…

3
Eliminar impedimentos para el progreso del equipo de desarrollo.

Un ejemplo puede ser hacer ver al equipo si tienen dependencias de terceros y ayudar a que las
gestionen debidamente, consiguiendo con ello fechas de compromiso de cuándo estará realizado aquello
que necesitan de otro equipo.

Otro ejemplo de impedimento a eliminar puede ser respecto del responsable que proceda para que
consiga una formación o una herramienta para el equipo de desarrollo.

17/26
 El equipo Scrum

Facilitar los eventos de Scrum según se requiera o necesite.

El Scrum master no facilita por defecto los eventos de Scrum. El equipo de desarrollo o el product
owner se lo tienen que solicitar o tiene que ser necesaria su facilitación. Por otro lado, les hará ver, con
inteligencia emocional, la importancia de que realicen correctamente los eventos de Scrum. Y cuando
facilite los eventos, lo hará de forma que evite “ser juez y parte”, tendrá que hacer de espejo de las
situaciones, pero evitando dar sus opiniones.

Guiar al equipo de desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado
y entendido por completo.

Ha de ayudar al equipo a relacionarse con áreas de la organización que no utilizan Scrum o agilidad o
que están en un Scrum todavía muy incipiente (con una madurez agile muy bajita).

6.3. El Scrum master al servicio de la organización

El Scrum master ayudará a la organización para que la mancha de aceite de Scrum se vaya extendiendo a lo
largo de esta y para alcanzar un Scrum con una madurez mayor progresivamente.

El Scrum master sirve a la organización de varias formas, incluyendo las siguientes:

Liderar y guiar a la organización en la adopción de Scrum

Debe hacer ver con inteligencia las ventajas de Scrum, gestionando correctamente las expectativas de la
organización. Y, en concreto, no prometer más beneficios de Scrum de los que puede producir, así
como hacer entender que los resultados de negocio dependen de muchísimos factores y no únicamente
de que se emplee o no Scrum.

Planificar las implementaciones de Scrum en la organización

La implementación de Scrum en una organización es un proyecto en sí mismo. Suele iniciarse con el

análisis y con conseguir el visto bueno de los tomadores de decisiones; requiere planificación, dotar de
profesionales que apoyen la adopción del Scrum (Scrum master, principalmente), que se genere la
asignación de profesionales a los distintos equipos (staffing) (preferentemente que sean los miembros
implicados los que se repartan en equipos de forma equilibrada), las formaciones iniciales y la
realización de los primeros sprints (iteraciones). El proyecto se puede dar por finalizado y entraría en
modo business as usual (BAU) cuando finalice el segundo sprint, por ejemplo.

18/26
 El equipo Scrum

Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico
de producto

Hacer entender a los interesados (stakeholders ) y resto de empleados que Scrum no se basa en
suposiciones a largo plazo, sino en tomar decisiones según se vayan obteniendo resultados iterativos e
incrementales. Esos resultados serán tangibles y no suposiciones hipotéticas.

También debe hacer ver que a la finalización de los primeros sprints quedarán muchas funcionalidades o
tareas por realizar en el conjunto del producto o servicio, pero las finalizadas estarán totalmente listas
para que se pongan a disposición del cliente y con ello medir su aceptación en el mercado.

Motivar cambios que incrementen la productividad del equipo Scrum

Fomenta cambios en la organización para que sea más amigable hacia Scrum y con ello que la
productividad del equipo sea mayor.

Trabajar con otros Scrum masters para incrementar la efectividad de la aplicación de Scrum
en la organización

Trabaja con Scrum masters de otros equipos para mejorar la interacción entre los distintos equipos,
cómo se sincronizan estos entre sí, la gestión de las dependencias, posibles planificaciones conjuntas…

¿Hacia dónde tendrán que impulsar los Scrum masters a la organización para tener una cultura
partidaria de Scrum?

Un Scrum master con poca experiencia se quejará de la cultura de la organización o empresa o de la

propia empresa, un buen Scrum master luchará con inteligencia para cambiar y mejorar la cultura de la
empresa. Y para ello, de las primeras cosas que realizará es asegurarse con su responsable de que tiene
las espaldas cubiertas por él o ella y bajo la premisa de que su puesto de trabajo no está en peligro por
“tensionar” con inteligencia a distintos niveles de la organización para que se apueste por la mejora
continua a través de la correcta adopción del Scrum (Scrum no es un fin en sí mismo, es un catalizador
para conseguir los mejores objetivos de negocio posibles).

Los Scrum masters tendrán que impulsar lo siguiente por parte de la organización:

Valorar el éxito del equipo sobre el éxito individual.

Estimular a los miembros del equipo a responsabilizarse a sí mismos.
Promover la mejora continua y la experimentación.
Apreciar a todos por sus talentos y habilidades únicos.
Valorar el comportamiento por encima de los logros (en Scrum son tan importantes los medios
como el fin).
Poner al cliente en el centro de sus operaciones.
Considerar que el acto de planificar es más útil que el plan en sí mismo.

19/26
 El equipo Scrum

Apoyar la composición estable del equipo durante un periodo largo de tiempo para que aumente
el rendimiento de los equipos.
Invitar e inspirar a los empleados a sacar el máximo provecho de sí mismos.
Prosperar la autodisciplina al darse la confianza y responsabilidad a los empleados.
Ayudar a los empleados a tener éxito al brindarles apoyo, confianza y orientación.
Reemplazar la documentación temporal y exhaustiva por la comunicación cara a cara (la
documentación necesaria es importante, pero la mejor forma de comunicarse es la
comunicación cara a cara).
Valora una orientación basada en productos y servicios en lugar de proyectos.
Entrega valor de negocio a través de equipos pequeños, coubicados, multifuncionales y
autoorganizados.

VII. Resumen
Un equipo Scrum está formado por un product owner, varios miembros del development team, que tendrá
entre tres y nueve integrantes, y un Scrum master.

Las funciones principales del product owner son las siguientes:

Maximizar el valor del producto del trabajo del equipo de desarrollo, o, dicho de forma más breve,
optimizar el valor del producto.
Gestionar el product backlog teniéndolo siempre priorizado, ordenado…

Respecto de los miembros del equipo de desarrollo:

Son los responsables de realizar los trabajos correctamente y, con ello, crear incrementos finalizados,
y, por tanto, listos para poner a disposición de los clientes.
Se gestionan a sí mismos. Así, gestionan el trabajo de sus compañeros del equipo de desarrollo,
además del suyo propio.

El Scrum master (SM) tendrá dos responsabilidades principales:

Gestionar el marco de trabajo Scrum, induciendo a los equipos y la organización a las mejores
prácticas de Scrum.
Eliminar impedimentos que afectan a la productividad del equipo.

20/26
 El equipo Scrum

Figura 5. Resumen de roles

Figura 5. Resumen de roles.

Fuente: elaboración Propia basada en Scrum.org

Roles:

PO: no participa de las dailies . Puede asistir, pero de forma reactiva.

SM: no gestiona el trabajo del equipo. No facilita las dailies, ni hace el burn-down chart, por ejemplo.
Ningún rol se parece al project manager.
Pueden tener distintas localizaciones, colaboradores externos, etc.

Los roles de Scrum master y product owner no se corresponden con el project manager y tampoco podrán
ejercer como manager de los miembros del equipo.

21/26
 El equipo Scrum

Ejercicios
Caso práctico

Datos

Se propone el siguiente caso práctico de unidad no evaluativo.

Los casos prácticos no evaluativos son ejercicios que se proponen al alumno para fijar conceptos y con
solución en la plataforma. Se darán indicaciones del trabajo para realizar y de los resultados esperados, sin
embargo, las entregas no se evalúan, es decir, los alumnos no tienen que realizar entregas de estos.

Enunciado del caso

Se pide

Partiendo del área o dirección del caso práctico de la unidad "Introducción al Scrum" en el cual se pedía
que se explicara y razonara un área o dirección donde SÍ aplicaba Scrum, y limitándolo a un máximo de 80
profesionales:

¿Cómo se haría para organizar los distintos equipos Scrum?

¿Qué roles habría? ¿Qué cualidades tendrían los profesionales para ejercer esos roles?

¿Qué tamaño tendrían los equipos? ¿Habría managers o responsables?

Solución

22/26
 El equipo Scrum

La idea sería dejar que se organizaran los equipos por ellos mismos, evitando que un director o mánager
los imponga. Los equipos tendrían que ser equilibrados, no vale que unos equipos sean muy potentes y
otros estén muy faltos de profesionales cualificados. Los equipos tienen que tener las habilidades
necesarias para hacer el trabajo que se les solicite.

Los equipos tendrían como equipo de desarrollo entre tres y nueve miembros, preferentemente seis-
siete.

Además, tendrán un product owner por equipo que se encargará de maximizar el valor a obtener y de
priorizar el product backlog, y un Scrum master por equipo. Los Scrum masters se encargarán de
ayudar a que se siga el proceso Scrum.

Los product owners tendrán que tener habilidades para priorizar y ser organizados, visión de negocio, y
deberían ser capaces de refrenarse y no mandar tareas a personas concretas del equipo y sí hacer
peticiones al sistema del equipo. Tendrán que vender los éxitos del equipo.

El Scrum master tendrá que ser capaz de explicar el proceso Scrum. Le gustará ayudar a las personas y
mirará por el bien común del equipo. Sabrá escuchar, tendrá empatía. Tendrá que ser capaz de hacer
sugerencias al equipo, product owner, managers …

Los managers o responsables del crecimiento profesional y económico estarán fuera de los equipos
Scrum y, en particular, no podrán ejercer de managers ni los product owners ni los Scrum masters .

Resolución del caso

23/26
 El equipo Scrum

Recursos
Enlaces de Interés
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pd
f: Schwaber, Ken; Sutherland, Jeff. 2017.
https://www.scrum.org/resources/blog/scrum-master-change-agent: Overeem, Barry. Scrum; 2016.
https://www.scrum.org/resources/blog/15-things-professional-scrum-product-owner-pspo-actually-do
es: Doshi, Hiren. Scrum; 2016.

Glosario.

Agile: También agilismo; es un mindset, una forma de pensar y de actuar que está muy relacionada
con los valores y principios del Agile Manifesto.

Artefactos de Scrum: Los artefactos en Scrum son objetos hechos con unas técnicas asociadas al
Scrum y que cumplen un determinado propósito. Y simplificándolo muchísimo, son los objetos
tangibles de Scrum.

Daily Scrum (Scrum diario): El equipo de desarrollo usa la daily para evaluar en menos de quince
minutos, todos los días, el progreso hacia el objetivo del sprint (sprint goal) y para valorar que?
tendencia sigue este progreso hacia la finalización del trabajo contenido en la pila del sprint (sprint
backlog).

Equipo de desarrollo (development team): Equipo capaz de crear incrementos finalizados. Se

gestiona a sí mismo.

Eventos: Reuniones o eventos predefinidos con el fin de crear regularidad y minimizar la necesidad
de reuniones no definidas en Scrum.

Incremento: El incremento es la suma de todos los elementos de la pila del producto completados
durante un sprint y el valor de los incrementos de todos los sprints anteriores.

Marco de trabajo: Los marcos de trabajo son algo más ligeros que las metodologías, marcan unas
líneas maestras, pero dejan más libertad. Un framework, entorno de trabajo o marco de trabajo, es un
conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática
particular que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.

24/26
 El equipo Scrum

Metodología: Las metodologías son algo más rígido y acotado que los frameworks. La metodología
es el análisis teórico sistemático de los métodos aplicados a un campo de estudio. Comprende el
análisis teórico del conjunto de métodos y principios asociados con una rama del conocimiento.
Típicamente, abarca conceptos como paradigma, modelo teórico, fases y técnicas cuantitativas o
cualitativas.

Planificación del sprint (sprint planning): El evento en el que todo el equipo Scrum planifica en
qué y cómo va a trabajar el equipo se llama sprint planning. Es el primer evento de un sprint.

Product backlog: La pila del producto es una lista ordenada de todo lo conocido que podría ser
necesario en el producto, y es la única fuente de requisitos para cualquier cambio a realizarse en el
producto.

Propietario del producto (product owner): Responsable de optimizar el valor del producto y
gestionar el product backlog.

Retrospectiva del sprint (sprint retrospective): La retrospectiva del sprint es una oportunidad para
el equipo Scrum de inspeccionarse a sí mismo y crear un plan de mejoras que sean abordadas
durante el siguiente sprint.

Revisión del sprint (sprint review): Al final del sprint se lleva a cabo una revisión de sprint para
inspeccionar el incremento y, si fuese necesario, adaptar la pila del producto.

Roles - equipo Scrum: El equipo Scrum está formado por un propietario del producto, el equipo de
desarrollo y un Scrum master.

Scrum: Scrum es un marco de trabajo compuesto de procesos que se ha utilizado para gestionar el
trabajo de productos complejos desde principios de los años noventa.

Scrum master: Responsable de gestionar el marco de trabajo Scrum y de eliminar impedimentos.

Sprint (sprint): El corazón de Scrum es el sprint, un compartimiento o periodo de tiempo (time-box)

de un mes o menos durante el cual se crea un incremento de producto ?terminado? utilizable y
potencialmente puesto a disposición de los clientes finales.

Sprint backlog: La pila del sprint es el conjunto de los elementos de la pila del producto
seleccionados para el sprint, más un plan para entregar el incremento de producto y conseguir el
objetivo del sprint.

25/26
 El equipo Scrum

Valores de Scrum: Cuando los valores coraje, foco, compromiso, respeto y apertura son
incorporados y vividos por el equipo Scrum, los pilares Scrum, como son la transparencia,
inspección y adaptación, se materializan y fomentan la confianza en todo el mundo.

26/26