Documentos de Académico
Documentos de Profesional
Documentos de Cultura
04 El Equipo Scrum
04 El Equipo Scrum
© Ediciones Roble, S. L.
Indice
El equipo Scrum 3
I. Introducción 3
II. Objetivos 4
III. Equipo Scrum (Scrum team) 4
IV. Propietario del producto (product owner) 6
4.1. ¿Qué hace un buen product owner? 8
V. El equipo de desarrollo (Development team) 11
5.1. Tamaño del equipo de desarrollo 13
VI. El Scrum master 14
6.1. El Scrum master al servicio del propietario del producto (product owner) 17
6.2. El Scrum master al servicio del equipo de desarrollo (development team) 19
6.3. El Scrum master al servicio de la organización 20
VII. Resumen 22
Ejercicios 24
Caso práctico 24
Datos 24
Se pide 24
Solución 24
Recursos 26
Enlaces de Interés 26
Glosario. 26
2/27
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.
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.
3/27
El equipo Scrum
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
El Scrum master.
4/27
El equipo Scrum
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.
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.
5/27
El equipo Scrum
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).
Ordenar los elementos en la pila del producto para alcanzar los objetivos y las misiones de la mejor manera
posible.
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.
6/27
El equipo Scrum
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.
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/27
El equipo Scrum
8/27
El equipo Scrum
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.
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.
9/27
El equipo Scrum
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.
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).
10/27
El equipo Scrum
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.
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.
11/27
El equipo Scrum
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…
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.
12/27
El equipo Scrum
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.
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.
13/27
El equipo Scrum
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.
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.
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.
14/27
El equipo 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.
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.
15/27
El equipo Scrum
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:
► Terminar el proyecto.
16/27
El equipo Scrum
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.
17/27
El equipo Scrum
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:
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.
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.
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.
18/27
El equipo Scrum
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.
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.
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:
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…
19/27
El equipo Scrum
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.
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.
20/27
El equipo 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.
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.
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.
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?
21/27
El equipo 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:
VII. Resumen
22/27
El equipo Scrum
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.
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…
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.
Roles:
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.
23/27
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.
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:
¿Qué roles habría? ¿Qué cualidades tendrían los profesionales para ejercer esos roles?
Solución
1
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.
24/27
El equipo Scrum
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.
L o s 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.
25/27
El equipo Scrum
Recursos
Enlaces de Interés
Scrum Guide
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf
Schwaber, Ken; Sutherland, Jeff. 2017.
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.
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.
26/27
El equipo Scrum
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.
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.
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.
27/27