Miles de estudiantes han aprobado

apoyándose en esta guía

JERÓNIMO PALACIOS
 

Scrum  es  el  método  ágil  de  desarrollo  de  Software  más  utilizado  del  mundo.  Se  presentó 
en  1995 y hoy en día, más del 70% de los equipos de desarrollo de Software en el mundo lo 
usan. 

Scrum  es  simple  pero  no  es  fácil.  Las  compañías  que  consiguen  implementarlo, consiguen 
mejoras  de  4  a  10  veces  en productividad, time-to-market y competitividad. Sólo es posible 
mediante  la  mejora  de  la  transparencia,  la  reducción de los ciclos de desarrollo y la mejora 
de la innovación, según el reporte CHAOS de Standish Group. 

Scrum  ha  evolucionado  significativamente  para  adaptarse  a  nuevos  retos  e  ideas  durante 
los  últimos  20  años.  A  pesar  de  todo,  muy  pocas  compañías  consiguen  vencer sus propias 
resistencias para conseguir todos los beneficios de Scrum. 

El  movimiento  ágil  surge  de  la  publicación del Agile Manifesto por líderes de la industria en 

el  2001.  La  realidad  del  mercado  entonces  era  lamentable.  Los  proyectos  de  desarrollo de 
Software se planificaban durante años antes de escribir una sola línea de código, llevando a 
catástrofes  como  la  del  proyecto  Sentinel  del  FBI,  en  el  que  después  de  invertir  más de 60 
millones  de  dólares,  hubo  que  rehacer  todo el Software de nuevo. En Andalucía, España, el 
gobierno  regional  invirtió  unos  45  millones  de  euros  en  el  desarrollo  del  Software  para 
gestión  del  sistema  sanitario  Diraya,  sólo  para  tener  que  rehacerlo  antes  de  que  estuviera 
verdaderamente en funcionamiento. 

Hasta  17  críticos  con  el  modelo  de  desarrollo  tradicional  se  reunieron  en  Febrero  de  2001 
para  crear  un  manifiesto  que  corrigiera  esta  situación,  impulsados  por  el  creador  de 
eXtreme  Programming,  Kent  Beck.  De  esta  reunión  surgieron  cuatro  valores  y  doce 
principios que rigen el desarrollo ágil de Software. 

En  algunos  sitios  de  internet  y  libros  se  pueden  encontrar  referencias  tales  como 
“Metodología  Scrum”, “Scrum Agile” o incluso “Agile SCRUM”. Estos conceptos son erróneos. 
Scrum  es  un  marco  de  trabajo​,  no  una  metodología.  Scrum  es  una  implementación  del 
manifiesto  ágil,  no  parte  del  manifiesto  ágil.  Scrum  no  es  un  acrónimo,  es  un  nombre 
propio 

Cuando  en  2011  Ken  Schwaber  y  Jeff  Sutherland  decidieron  publicar  la  guía  oficial  de 
Scrum,  lo  hicieron  atendiendo a un problema cada vez mayor: Cada profesional veía Scrum 

 
 
 
de  una  manera  distinta  y,  lo  que  en  su  momento  eran  una  serie  de  reglas,  se  convirtió  en 
algo que quedaba a la más pura interpretación del profesional que lo implantaba. 

Desde  entonces  ha  habido  dos  grandes  cambios  en  la  guía  de  Scrum,  en  2013  y  2016. 
Primero,  se  eliminaron  algunas  cosas,  como  los  diagramas  de  burndown.  Se  reforzó  el 
énfasis  en  el  ​Daily  Scrum  como  elemento  de  planificación -y no solamente sincronización- 
y  también  se  cambió  el  nombre  de  la  reunión  de  grooming  a  ​refinement​.  Todos  estos 
conceptos  los  veremos  más  adelante.  En  2016  se añadieron los valores de Scrum, aquellos 
que  hacen  que  el  marco  funcione  en  una  organización,  además  de  algunos  cambios 
menores. 

Una  de  las  cuestiones  importantes  que  trajo  la  guía  de  Scrum  es  que  dejó  de  llamarse 
SCRUM.  Hace  muchos  años,  cuando  se  publicó  el  paper  original  sobre  Scrum,  se  eligió  en 
mayúsculas  para  darle  más  énfasis.  Sin embargo, parece que muchos profesionales siguen 
tratándolo como si de un acrónimo se tratara. 

Para  entender  los  orígenes  de  Scrum,  merece  la  pena  leer  el  paper  ​The  New  New  Product 
Development  Game​,  en  el  que  se  describen  las  reglas  que  dieron  lugar  al  que  hoy  es  el 
framework de desarrollo de Software ágil más usado en el mundo. 

Uno  de  los  énfasis  que  hacemos  en  ​Scrum.org es en el uso del lenguaje en lo que a Scrum 

se  refiere.  El  ​Sprint  Review  es  una  reunión  de  negocio,  no  una  demo.  El  ​Sprint  Planning 
es  para  el  equipo  Scrum,  no  para  los  Stakeholders.  Estas  cosas  marcan  la  diferencia  en  el 
entendimiento  sobre  las  responsabilidades  que  cada  una  de  las  personas  que  están 
afectadas por Scrum, tienen. Mejoran la comunicación y reducen la fricción. 

Scrum  es  un nombre propio, y por eso se escribe capitalizado, tanto en Castellano como en 

Inglés.  Cuando  veo  un  profesional  con  años  de  experiencia  escribiendo  SCRUM,  me 
pregunto: ¿Qué otros conocimientos no habrá actualizado? 

Esta  guía  se  divide  en  dos  partes.  En  la  primera  parte  se  describe  Scrum  y  sus  elementos 
más  importantes  de  forma  exhaustiva.  Es  importante  su  lectura  porque incluye los puntos 
más  importantes  para entender como funciona Scrum, ​lo que luego servirá para el examen 
PSM. 

 
2 
 
 

La  segunda  parte  contiene  consejos  sobre  como  prepararte  para  el  examen  y  maximizar 
tus posibilidades de aprobar. Mucha suerte. 

Jerónimo Palacios. 

 
3 
 
 

Roles en Scrum 
Product Owner 
Scrum Master 
Development Team 

Artefactos en Scrum 
Product Backlog 
Sprint Backlog 
Incremento 
Otros artefactos 
Definition of Done 

Eventos y reuniones en Scrum 

Sprint 
Sprint Planning 
Daily Scrum 
Sprint Review 
Retrospectiva del Sprint 

¿Qué es Scrum? 
Scrum es agilidad 
La guía oficial de Scrum 
Preparate usando los assessment abiertos de Scrum.org 

¿Quién soy? 

 
 

 
4 
 
 

Descargar Póster de Scrum en formato A3 

Roles en Scrum 
Scrum prescribe tres roles: 

● Product Owner 
● Equipo de desarrollo 
● Scrum Master 

Un  equipo  Scrum  está  compuesto  de  3  a  9  miembros  en  el  equipo  de  desarrollo  más  el 
Scrum  Master  y  el  Product  Owner.  Cada  uno  de  estos  roles  en  Scrum  tiene  sus 
responsabilidades  y  tiene  que  rendir  cuentas de distinta manera, entre ellos y para el resto 
de  la  organización.  La  suma  de  todos  los  roles  de  Scrum  es  el  ​Equipo  Scrum  (Scrum 
Team)​. Los tres roles tienen que estar presentes para poder usar Scrum. 

 
5 
 
 

 
Product Owner 
La  labor  del  Product  Owner  es  optimizar  el  valor  del  producto  dentro  de  los  roles 
Scrum​.  El  Product  Owner  gestiona  el  todo  el  flujo  de  valor  del  producto,  a  través  del 
Product  Backlog,  así  como  todo  lo  relacionado  con  informes,  presupuestos  y  relación  con 
las partes interesadas en el producto (Stakeholders). 

En  Scrum existe sólamente un Product Owner por cada producto, así cómo un sólo Product 
Backlog. La regla es ​1 producto, 1 Product Backlog, 1 Product Owner​. 

El  Product  Owner  es ​responsable de maximizar el valor del producto o proyecto del que 

es  responsable.  Esto,  que  se  expresa  fácilmente,  es  una  tarea  complicada,  tal  y  como 
veremos a continuación. 
 
 
Gestiona prioridades 
El  Product  Owner  se  ha  entendido  tradicionalmente  como  un  gestor  de  requisitos,  o  un 
cliente que se encarga de gestionar el Product Backlog, pero es mucho más que eso. 

 
6 
 
 

El  Product  Owner  tiene  la  responsabilidad  de  gestionar  los  presupuestos,  de  contratar  al 
equipo  de  desarrollo  y  de  explicar  a  los  stakeholders  cual  es  el  valor  que  produce  el 
producto  en  el que está invirtiendo. Al fin y al cabo, cada Sprint que pasa, el Product Owner 
hace una inversión en desarrollo que tiene que producir valor. 

 
 
Representante del negocio 
Cuando  el  Product  Owner  es  alguien  de  negocio,  aporta  valor  a  su  trabajo  al  producto 
dependendiendo de al menos dos variables. 

La  primera  es  la  capacidad  de  decisión  que  tiene​.  En  ocasiones,  es  normal  que  el 
Product  Owner  no  pueda  realmente  tomar  decisiones  sin  consultar  con  otra  persona.  En 
ese  caso,  no  es  un  Product  Owner  real y debe, o de ser sustituido por la persona que toma 
las  decisiones,  o  ser  investido  para tomarlas el mismo. Hay que recordar que esto no es un 
capricho  de  los  fanáticos  de  Scrum,  sino  una  manera  de  maximizar  la  inversión  realizada 
en el desarrollo de producto y reducir los riesgos inherentes. 

La  segunda  es  su  conocimiento  del  usuario  del  producto​.  Sorprendentemente,  hay 
muchas  organizaciones  que  toman  decisiones  que  suponen  cientos,  miles  o  millones  de 
dólares  sin  tener  en  cuenta  lo  que  el  usuario  quiere.  Un  buen  Product  Owner  gestiona 
requisitos,  mientras  que  un  gran  Product  Owner  es  capaz  de  conocer  al  usuario  y 
stakeholders para optimizar el valor de la inversión que realiza en cada Sprint. 
 
 

Intraemprendedor 
Es  en  esta  faceta  donde  realmente  el  Product  Owner  puede  aportar  valor  al  negocio.  Un 
Product  Owner  en  esta  faceta  es  un  Product  Manager  ágil,  capaz  de  medir  el  valor 
generado y utilizar la flexibilidad de entregar cada Sprint para incrementar ese valor. 

 
7 
 
 

Scrum Master 
El  Scrum  Master  se  encarga  de  gestionar  y  asegurar  el  proceso  Scrum,  que  éste  se  lleva  a 
cabo  correctamente  y  de  facilitar  la  ejecución  del  proceso  y  sus  mecánicas,  siempre 
atendiendo  a  los  tres  pilares  del  control  empírico  de  procesos.  Además,  se  encarga  de 
eliminar  impedimentos  que  puedan  afectar  a  la  entrega  de  producto.  También  se encarga 
de  hacer  coaching  al  resto  del  equipo  Scrum  cuando  lo  necesitan,  además  de  facilitar 
reuniones  y  eventos  si  es  necesario.  El  Scrum  Master  puede  ser  compartido  entre  varios 
equipos, aunque su disponibilidad afectará al resultado final del proceso Scrum. 

El  Scrum  Master  tiene  dos  funciones  dentro  del  marco  de  trabajo. La primera es gestionar 
el  proceso  Scrum  y  la  segunda  es  ​ayudar a eliminar impedimentos. Vamos a echarles un 
vistazo en profundidad: 

 
Gestionar el Proceso Scrum 
El  Scrum  Master  es  el  encargado  de  mantener  Scrum  al  dia,  de  proporcionar  coaching, 
mentoring  y  formación  a  la  organización  en  caso  de  que  lo  necesita  y  de  velar  porque 
Scrum favorezca la entrega de valor en lugar de ser una herramienta de microgestión. 

 
Ayudar a eliminar impedimentos 
Esta  función  del  Scrum  Master  indica  la  necesidad  de  ayudar  a  eliminar  progresiva  y 
constantemente  impedimentos  que  van surgiendo en la organización y que afectan tanto a 
la integridad de Scrum como impiden a la organización entregar valor. 

Hay  que  remarcar  que  estos  impedimentos  no  son  del  equipo,  sino  de  la  organización,  y 
donde  el  Scrum  Master  aporta  es  a  nivel  organizativo,  no  reparando  teclados  para  los 
miembros  del  Development  Team.  En  ocasiones  me  encuentro  Scrum  Masters  que  se 
quejan  de  la  imposibilidad  de  hacer  Scrum  debido  a  que  la  organización  no  facilita  su 
introducción  adecuada  a  lo  largo  y  ancho  de  la  misma.  Es  precisamente  al  contrario,  es  el 

 
8 
 
 
Scrum  Master el responsable de velar porque Scrum se lleve adelante y se pueda facilitar la 
implementación. 
 

Development Team 
El  Equipo  de  desarrollo  está  formado  por  ​3  a  9  profesionales  que  se  encargan  de 
desarrollar  el  producto,  se  autoorganizan  y  deciden  cuál  es  la  mejor  manera  de  conseguir 
entregar un incremento de software al final del ciclo de desarrollo. 

Nótese  que  en  Scrum  no  importa  el  número  de  individuos  sino  el  rol,  y  este  solo  hay uno, 
independientemente  de  cuántos  miembros tenga el equipo de desarrollo y cuales sean sus 
roles  internos.  Cómo  el  equipo de desarrollo decida gestionarse internamente es su propia 
responsabilidad  y  tiene  que  rendir  cuentas  por  ello;  hay  que  evitar  intervenir  en  sus 
dinámicas. 

El  equipo  de  desarrollo  se  encarga  de  crear  un  incremento  terminado  a  partir  de  los 
Product  Backlog  items  seleccionados  durante  el  Sprint  Planning.  El  Equipo  de  desarrollo 
tiene un tamaño recomendado de 3 a 9 personas, que rinden cuentas como uno solo. 

También  es  un  equipo  cross-funcional,  capaz  de  generar  un  incremento  terminado  de 
principio  a  fin,  sin  otras  dependencias  externas.  El  aspecto  más  importante  del  equipo  de 
desarrollo es que se auto-organiza y se auto-gestiona. 

En  el  caso  de  los  equipos  de  desarrollo  en  Scrum,  cross-functional  significa  que  todas  las 
personas  necesarias  para  producir  un  incremento  terminado  forman  parte  del  equipo.  El 
equipo de desarrollo, sin embargo, no es un equipo de desarrolladores únicamente. 

El equipo de desarrollo es responsable de contratar al Scrum Master 

 
9 
 
 

Artefactos en Scrum 

En  ​Scrum  existen  tres  artefactos.  En  este  caso,  artefacto  se  refiere  a elementos físicos que 
se  producen  como  resultado  de  la  aplicación  de  Scrum.  Los  artefactos  en  Scrum  son:  El 
Product Backlog, el Sprint Backlog y el Incremento. 

Product Backlog 
El  Product  Backlog  es  un  inventario. Contiene cualquier tipo de trabajo que haya que hacer 
en  el  producto.  Requerimientos,  casos  de  uso,  tareas,  dependencias.  Todas  ellas  están 
representadas  en  el  Product  Backlog  y  este  es  ​la  fuente  principal  de  información  sobre 
el producto en Scrum. 

El  Product Backlog es una lista en cualquier formato que contiene todos los requerimientos 
que  necesitamos  implementar  en  el  producto.  Esta  lista  es  el  resultado  del  trabajo  del 
Product  Owner  con  los  distintos Stakeholders de la organización, y refleja el estado real del 
trabajo pendiente de implementar en un producto. 

El Product Backlog está gestionado por el Product Owner. Puede contener cualquier tipo de 
tarea  en  cualquier  formato  y  su  única  condición  es  que  esté  priorizado  con aquellos ítems 
que tienen más valor en ese momento. 

Al  comenzar  a  utilizar  Scrum,  no  es  necesario  una  lista  completa  y  exhaustiva  de 
todos  los  requerimientos​.  Es  posible  (¡Y  recomendable!)  empezar  con  los  dos  o  tres 
requerimientos  más  urgentes  arriba  e  ir  añadiendo  conforme  vamos  descubriendo  más 
necesidades de nuestro producto. 

Sprint Backlog 
Una  vez  que  se  hace  el  Sprint  Planning,  ​todo  el  trabajo  que  el Development Team haya 
seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog​. 

 
10 
 
 

Este  artefacto  es  un  elemento para visualizar el trabajo del Sprint y ​está gestionado por el 

Development  Team​.  Su  propósito  es  mantener  la  transparencia  durante  todo el Sprint. El 
Equipo  de  Desarrollo  es  el  encargado de mantenerlo. Nadie más -ni el Product Owner, ni el 
Scrum Master- pueden modificarlo. 

El  Sprint  Backlog  nos  proporciona  una  visión  del  trabajo  a realizar durante el Sprint actual. 
Está  gestionado  por  el  equipo  de  desarrollo,  que  se  encarga  de  mantenerlo  actualizado  y 
transparente durante toda la iteración, especialmente a través de los daily Scrums. 

Después  del  Sprint  Planning,  el  equipo  de  desarrollo  obtiene  una lista de elementos en los 
que  van  a trabajar durante un Sprint. Estos elementos normalmente se deshacen en tareas 
técnicas  más  pequeñas.  Facilitan  la  implementación  de  los  mismos  en  un  Incremento  de 
software terminado. 

El  Sprint  Backlog  permite  visualizar  todo  el  trabajo  pendiente  durante  un  Sprint.  Así,  se 
pueden  ver  aquellos  elementos  que  aún  no  han empezado a desarrollarse, aquellos que sí 
y  quienes  están  trabajando  en  los mismos y aquellos que están esperando a desplegarse o 
están completamente terminados. 

Este  artefacto  permite  entender  cuál  es  la  evolución  del  trabajo durante el Sprint así como 
hacer  una  análisis  de  riesgos.  Dado  que  cada  Sprint tiene una meta específica (​p.e. permitir 
que  los  usuarios  se  registren  en  la  app  móvil​)  y  hay  elementos  seleccionados  del  Product 
Backlog  que  tienen  más  o  menos  valor,  el  Sprint  Backlog  permite  analizar  hasta  dónde  se 
ha  cumplido  el  objetivo  y  que  se  podría  eliminar.  Así  maximizamos  el  retorno  de  la 
inversión en desarrollo. 

Incremento 
Si  Scrum  tuviera  que  ser  reducido  a  una  sola  cosa,  sería  a  entregar  una  pieza  de 
software  terminado  cada  Sprint​.  El  Incremento  es  la  suma  de  todas  las  tareas,  casos  de 
uso,  user  stories  y  cualquier  elemento  que  se  haya  desarrollado  durante  el  Sprint  y  que 
será puesto a disposición del usuario final en forma de software al final del mismo. 

 
11 
 
 

Un  incremento  es  el  resultado  del  Sprint.  Es  una  pieza  de  Software,  acorde  con  los 
elementos  seleccionados  durante  el  Sprint  Planning  del Sprint Backlog que aporta un valor 
de negocio al producto que se está desarrollando. 

Construir  software  de  manera  ágil  se  basa  en  hacerlo  de  manera  iterativa  e 
incremental​.  Mediante  las  iteraciones,  nos  aseguramos  que  todo  el  ciclo  de  vida  del 
software:  Planificación,  diseño,  desarrollo,  testeo  y  entrega  ocurre en 30 días o menos. Por 
supuesto,  no  podemos  construir  toda  la  funcionalidad  que  queremos  en  sólo  30  días  y 
tenemos  que  buscar  la  manera  de  ir  entregando  los  componentes  necesarios  justo  a 
tiempo. 

A  través  de  un  desarrollo  incremental,  primero  nos  centramos  en  las  características  o 
features  principales  y  luego  vamos  añadiendo  más, refactorizando y permitiendo tanto una 
arquitectura como un diseño emergentes. 

Otros artefactos 
Aunque  existen  otros  artefactos  que  se  pueden  utilizar  en  Scrum,  el marco de trabajo sólo 
necesita  los  tres  expuestos  anteriormente.  Sin  embargo,  hay  otro  que,  a  pesar  de  no 
formar parte del core, es necesario para asegurar la calidad cuando se sigue Scrum. 

Definition of Done 
La  DoD  es  un  documento,  checklist  o  cualquier  otra  cosa  que  define  qué  se  considera 
hecho  en  un  equipo  Scrum.  La  idea  es  establecer  una  serie  de  criterios  comunes  para 
especificar  cuándo  un  ítem  está  completamente  terminado y que aplique a todos los ítems 
que forman parte del incremento. 

Aunque  la  Definition  of  Done  no  es  un  artefacto  que  forme  parte  del  núcleo  de  Scrum,  es 
un  elemento  fundamental  para  que  el  equipo  de  desarrollo  pueda  gestionar  la  calidad 
técnica del producto. 

 
12 
 
 

Eventos y reuniones en Scrum 

Scrum  prescribe  cinco  eventos  para  cumplir  con  el  control  empírico  de  procesos.  Todos 
tienen  un  sentido  y sirven a distintas razones. Todos son necesarios para hacer Scrum y las 
adaptaciones  suelen  terminar  en  desastre. Algunas organizaciones piensan que tienen que 
adaptar  Scrum  a  sus  necesidades  y  terminan  haciendo  lo  mismo  que  solían  hacer  con 
nuevos nombres. 

La  razón  por  la  que  Scrum tiene estos cinco eventos es porque son los mínimos necesarios 

para  facilitar  que  el  control  empírico  de  procesos  funcione.  El  gran  problema  de  adaptar 
estos  eventos  o  convertirlos en otra cosa es que el control empírico de procesos, el pilar de 
Scrum deja de funcionar. Analicemolos uno a uno:  

Sprint 
El  sprint  es  un  contenedor  para  el  resto  de  los  eventos  de  Scrum.  El  Sprint  es continuo, es 
decir,  su  duración  no  cambia  y  se  puede  interpretar  como  una  medida  de  ritmo  que  no 
cambia  a  lo  largo  del  tiempo  y  nos permite reducir complejidad y comparar resultados a lo 
largo  de  diferentes  Sprints.  El  Sprint  sirve  a  la  transparencia  y  permite  inspeccionar  y 
adaptar todos los otros eventos de Scrum. 

Scrum  prescribe  que  un  Sprint  debe  durar  30  días  o  menos.  La  duración  de un Sprint está 
determinada  por  el  periodo  mínimo  en  que un equipo de desarrollo puede generar valor a 
través  de  un  Incremento  terminado.  El  Sprint  es  una  iteración  definida  (​time  boxed​)  que 
sirve  al  desarrollo  iterativo  e  incremental.  Todo  el  desarrollo  se  realiza  durante  el  mismo 
Sprint  y  este  contiene  al  resto  de  los  eventos  en  Scrum, teniendo una duración de 1 mes o 
menos.  La  duración  del  Sprint  se  determina  por  un  horizonte  de  planificación  aceptable. 
No  hay  fases  en  Scrum,  sólo  Sprints.  No  existen los Sprints de testing, hardening, release o 
análisis. 

El  Sprint  es  un  evento  que  contiene  a  todos  los  demás  eventos  en  Scrum,  y  su  cometido 
principal  es  facilitar  la  transparencia  del  proceso  Scrum.  Un  Sprint debe de durar 30 días o 

 
13 
 
 
menos,  y  es  bastante  habitual  que  los  equipos  Scrum  elijan  tener  Sprints  de  una  duración 
de  dos  semanas.  Sin  embargo,  cada  caso  es  diferente,  y  es  el  equipo  Scrum  el  que  debe 
descubrir  cuál  es  su  periodo  mínimo  necesario  para  generar  valor  a  través  de  un 
Incremento terminado. 

El  Sprint  también  se  puede  definir  como  un  meta-evento  que  contiene  todos  los  demás 
eventos. Un Sprint normal tendría: 

● El Sprint Planning al comienzo del Sprint 

● Daily Scrums para actualizar el Sprint Backlog e identificar impedimentos 
● Una Sprint Review al final del Sprint para inspeccionar el incremento 
● Justo  después,  la  retrospectiva  para  hacer  transparentes  e  inspeccionar  posibles 
problemas en la forma de trabajar o de hacer Scrum. 
 
 
 
Todo ocurre en un sólo Sprint 
La  mentalidad  de  un  proyecto  por  Sprint  es  uno  de  los  cambios  más difíciles de asumir en 
la  mentalidad  de  organizaciones  que  están haciendo una transición ágilScrum. A diferencia 
de  la  gestión  tradicional  de  proyectos,  donde  un  proyecto  puede  durar  meses  o  años,  en 
Scrum  un  proyecto  dura  un  sólo  Sprint.  Todas  las  tareas  necesarias para llevar el proyecto 
a  cabo  se  realizan  durante  el  mismo  Sprint.  Así,  el  diseño,  la  planificación  o  el  testing  son 
actividades  que  se  realizan  dentro  de  un  sólo  Sprint,  siempre  orientado  a  generar  el 
máximo  valor.  En  Scrum,  los  proyectos  se  financian  cada  Sprint  y  es  el  Product  Owner 
quien  decide  dónde  y  a  qué  dedicar  los  recursos.  Entender  esto  es  crítico para asegurarse 
el éxito en la utilización de Scrum en una organización. 

 
14 
 
 
Claves 
● La duración del Sprint se mantiene fija.  
● No hay espacios entre Sprints, cuando acaba uno, empieza el siguiente.  
● Permite mantener el ritmo.  
● Sirve a la transparencia 

Sprint Planning 
El  Sprint  Planning es una reunión que se realiza al comienzo de cada Sprint donde participa 
el  equipo  Scrum  al  completo;  ​sirve  para  inspeccionar  el  producto  backlog  y  que  el 
equipo  de  desarrollo  seleccione  los  Product  Backlog  Items  en  los  que  va  a  trabajar 
durante  el  siguiente  sprint​.  Durante  esta  reunión  el  Product  Owner  presenta  el  Product 
Backlog actualizado, que el equipo de desarrollo se encarga de estimar, además de intentar 
clarificar aquellos ítems que crean necesarios. 

En  el  Sprint  Planning  participa  el  equipo  Scrum  al  completo,  pero  no  Stakeholders.  En  el 
Sprint  Planning  se  inspeccionan  el  Product  Backlog,  los  acuerdos  de  la  Retrospectiva,  la 
capacidad  y  la  Definition  of Done y se adaptan el Sprint Backlog, el Forecast y el Sprint Goal 
El  Sprint  Planning  se  divide  en  dos  partes.  En  la  primera  parte  de  la  reunión  se  trata  el 
¿Qué?  ​se  va  a  hacer  el  siguiente  Sprint  y  en  la  segunda  parte,  se  discute  el  ¿Cómo?​.  La 
primera  parte  está  organizada  y  liderada  por  el  Product  Owner  y  la  segunda  parte  por  el 
Development  Team.  La  única  labor  del  Scrum  Master  es  asegurarse  de  que  la  reunión 
existe como parte de Scrum. 

El  Sprint  Planning  es  una reunión de planificación y puede durar hasta 8 horas para Sprints 

de  30  días.  La  razón  del  Sprint  Planning  es  conseguir  alineamiento  entre  negocio  y 
desarrollo de producto en cuanto a cuáles son las prioridades. 

 
15 
 
 

Flujo del Sprint Planning 

El  ​Product  Owner  presenta  un  Product  Backlog  priorizado  y  actualizado,  además  de 
proponer  un  Sprint  Goal  que  dé  coherencia  a  todos  los  ítems  seleccionados  durante  la 
reunión. 

Durante  la  primera  parte​,  el  Equipo  de  Desarrollo  pronostica  cuantos  elementos  del 
Product  Backlog  cree  que  será  capaz  de  terminar  en  el  Sprint,  teniendo en mente el Sprint 
Goal propuesto por el Product Owner. 

Una  vez  que  existe  un  acuerdo  entre  el Product Owner y el Equipo de Desarrollo, entonces 

el  equipo  de  desarrollo  pasa  a  la  segunda  parte​,  donde  se  encargan  de  desmenuzar  el 
trabajo  que  hayan  seleccionado  en  tareas  más  pequeñas,  siempre  cumpliendo  la  regla  de 
analizar solamente el mínimo para empezar a trabajar. 

● El  Sprint  Planning  se  compone  de  dos  partes:  Una  donde  se  pronostica  el trabajo a 
realizar  y  otra  donde  el  Development  Team  se  encarga  de analizar y desmenuzar el 
trabajo en tareas, hasta donde crean necesario. 

 
16 
 
 
● La  primer  parte  del  Sprint  Planning está liderada por el Product Owner y la segunda 
parte por el Development Team. 
● Es  responsabilidad  del  Scrum  Master  que  el  meeting  ocurra,  pero  no  tiene  que 
facilitarlo ni organizarlo él mismo. 
● El  Development  Team  tiene  la  última  palabra  sobre  cuánto  trabajo  creen  que 
pueden completar en un sólo Sprint. 

¿Que necesitamos? 

● Definition of Done   
● Acuerdos de la retrospectiva   
● Product Backlog   
● Disponibilidad del Development Team 

¿Que obtenemos? 

● Product Backlog actualizado  

● Sprint Backlog   
● Sprint Goal  

Duración 

8 horas para Sprints de 30 días. Menos para Sprints más cortos. 

Quien es el responsable 

Primera parte:​ Product Owner,  

Segunda parte:​ Development Team 

 
17 
 
 

Daily Scrum 
El  Daily  Scrum  es  una  reunión  diaria  de  planificación  de  15  minutos  en  la  que  participa  el 
Development  Team.  Durante  el  Daily  Scrum,  se  inspecciona  el  Sprint  Backlog  y  se 
adaptan  las  tareas.  Se  hacen  transparentes  los  impedimentos  y  el  progreso  hacia  el 
Sprint Goal. 

El  Daily  Scrum  es  una  reunión  de  inspección  y  adaptación  en  Scrum  de  una  duración  de 
unos  15  minutos.  Durante  esta  reunión,  el  equipo  de  desarrollo se reúne y analizan cuáles 
son  los  elementos  en  los  que  están  trabajando  y  qué  impedimentos  encuentran.  También 
comunican  si  existe  riesgo  de  no  alcanzar  la  meta  marcada  durante  el  Sprint  -el  Sprint 
goal-. 

En  Scrum  existen  varios  ​feedback  loops​,  pequeñas  interacciones  que  nos  dan  la 
oportunidad de inspeccionar y adaptar nuestro trabajo. Eso nos permite planificar riesgos y 
tener  transparencia  y  visibilidad  sobre  el  proceso.  El  Daily  Scrum  es  de  frecuencia  diaria  y 
es  exclusivo  para  el  equipo  de  desarrollo.  Durante  el  mismo,  el  equipo  discute  cuál  es  la 
situación del incremento y cómo mitigar los riesgos asociados al mismo. 

Sprint Review 
El  Sprint  Review  es  una  reunión  que  ocurre  al  final  del  Sprint,  donde  ​el  Product  Owner 
presenta  a  los  Stakeholders  el  Incremento  terminado  para  su  inspección  y 
adaptación​.  Esta  reunión,  organizada  por  el  Product  Owner,  es el momento de medir cual 
es  la  situación  y  actualizar  el  Product  Backlog  con  nuevas  condiciones  que  puedan  afectar 
al negocio. 

El  Sprint  Review  marca  la  finalización  de  un  ​Sprint​.  El  ​equipo  ha  pasado  hasta  cuatro 
semanas  desarrollando  un  ​incremento  terminado  de  ​software  que  ahora  mostrará  a  los 
Stakeholders.  Para  ello,  el  ​Product  Owner  se  encarga  de  convocar  una  reunión  donde  se 
revisaran varias cosas. 

No  se  trata  de  una  demostración,  sino  de  una  reunión  de  trabajo​.  El  software  ya  ha 
sido mostrado y validado junto con el Product Owner. 

 
18 
 
 

Por  un  lado,  se  revisará  el  incremento  terminado.  Se  mostrará el software funcionando en 
producción  y  los  stakeholders  tendrán  la oportunidad de hacer cuantas preguntas estimen 
oportunas  sobre  el  mismo.  El  Software  funcionando  ha  sido  validado  previamente  por  el 
Product  Owner,  que  se  ha  encargado  de  trabajar  con  el  equipo  durante  el  Sprint  para 
asegurarse  que  cumple  con  la  ​Definition  of  Done  y  efectivamente hace que el Sprint Goal 
sea válido.  

Posteriormente,  el  equipo  de  desarrollo  comenta  qué  ha  ocurrido  durante  el  ​Sprint​. 
Problemas  que  se  han  encontrado,  así  como  soluciones  tomadas,  y  actualizan  a  los 
stakeholders  con  la  situación  del  equipo.  Por  último  el  Product  Owner  y  los  stakeholders 
actualizan, con las condiciones de negocio, el​ Product Backlog​ para el siguiente Sprint. 

A pesar de lo que muchos creen, el Sprint Review no se trata de una demo para un cliente o 
para  los  stakeholders,  o  incluso  para  el  Product  Owner.  No  es  tampoco  una  reunión  para 
felicitar  al  Equipo  de  Desarrollo  o  congratularse. Es una reunión de trabajo, una de las más 
importantes ya que sirve para marcar la estrategia de negocio. 

Ficha del Sprint Review 

Asistentes​:  Equipo  Scrum  (Product  Owner,  Scrum  Master  y  Equipo  de  Desarrollo)  y 
Stakeholders 

Facilitador​: Product Owner 

Duración​: 4 horas para un Sprint de 4 semanas, menos para sprints más cortos 

¿Que se inspecciona durante el Sprint Review? 

● El Incremento  
● El Sprint  
● El Product Backlog 

¿Qué se adapta durante el Sprint Review? 

El Product Backlog con las condiciones actualizadas de negocio 

 
19 
 
 

Retrospectiva del Sprint 

La  Sprint Retrospective ocurre al final del Sprint, justo después del Sprint Review. ​En ella se 
hacen  transparentes  los  problemas  del  equipo  y  se  llegan  a  acuerdos  para 
solucionarlos. También se inspecciona y adapta la definition of Done 

Justo  después  del  Sprint  Review,  ocurre  la  Sprint  Retrospective, que marca el fin del Sprint. 

El  objetivo  de  la  retrospectiva  es  hacer  de  reflexión  sobre  el  último  Sprint  e  identificar 
posibles  mejoras  para  el  próximo  Sprint.  Aunque  lo  habitual es que el Scrum Master sea el 
facilitador,  es  normal  que  distintos  miembros  del  equipo  Scrum  vayan  rotando  el  rol  de 
facilitador durante la retrospectiva.

Ficha de la retrospectiva 
Asistentes​:  El  equipo  Scrum  (Product  Owner,  Scrum  Master  y  Development  Team)  Dueño 
de la reunión: Scrum Master  

Duración​: 3 horas  

¿Qué se inspecciona durante la retrospectiva?  

● El último Sprint  
● Herramientas y procesos técnicos  
● Definition of Done  
● Relaciones entre los miembros del equipo  
● Procesos  

¿Que se adapta durante la retrospectiva?  

Una serie de acciones para mejorar la forma en la que el equipo trabaja 

  

 
20 
 
 

¿Qué es Scrum? 

Definición de Agilidad 

-nombre 

1.  La  agilidad  es  la  capacidad  de  responder  rápida  y  deliberadamente  a  las  demandas  de 
cambio mientras se controla el riesgo.  

2. Flexibilidad, la capacidad y cualidad de adaptar rápida y eficientemente  

3. La habilidad de innovar 

La  agilidad  es  una  necesidad  que  surge  del  hecho  de  que  desarrollar  software  es  algo 
complejo  y  no  se  puede  planificar  de  manera  perfecta  dada  la  velocidad  y  los  distintos 
cambios.  Aunque  admitir  esto  requiere  ​coraje,  requiere  de  más  coraje  admitirlo  y  vivir  de 
acuerdo a sus consecuencias. 

Definición de Scrum 

–Marco de trabajo 

1. Ayuda a personas a gestionar problemas complejos 

2. Entrega productos del más alto valor de forma productiva y creativa  

Scrum  es  un  marco  de  trabajo,  esto  es,  un  grupo  de  reglas  que  ayuda  a  facilitar  y 
hacer  más  sencillo  el  desarrollo  de  software.  Scrum  es  fácil de entender y muy difícil 
de dominar. 

Entender  Scrum  requiere  tanto  de  aprender  una  serie  de  mecánicas,  necesarias  para 
ponerlo  en  marcha,  que  son  las  que  se  describen  en la guía, así como entender los valores 
y  principios  que  soportan  esas  mecánicas.  Cuando  se  implanta  en  una  organización  sin 

 
21 
 
 
seguir  los  valores  y  principios,  se  consigue  un  resultado  bastante  problemático,  que 
conocemos como ​amateur Scrum​, en contraste con ​professional​ ​Scrum. 

 
 

Scrum es agilidad 
Scrum  ayuda  a  limitar  el  riesgo  cuando  ejecutamos  proyectos  de  desarrollo  de 
software  mediante  iteraciones  cortas  y  de  alto  valor​,  para  entregar  trozos  de 
funcionalidad  de  altor  valor  y  justo  a  tiempo,  mediante  el uso de equipos autoorganizados 
y crosfuncionales. 

Por  sí mismo, el framework no aporta mucho. Ese es el caso de las implantaciones amateur 
de  las  que hablaba anteriormente. El objetivo debe ser la agilidad, y el framework es solo el 
camino  para  conseguirlo.  A  pesar  de  su  comparación con proyectos industriales, Scrum no 
es  sino  un  reflejo  del  empirismo  y  un  marco  de  trabajo  listo  para  funcionar  en  entornos 
complejos. 

La guía oficial de Scrum

La  guía  de  Scrum  es  el  documento  que  explica  en  detalle  cuales  son  las  mecánicas,  sus 
eventos  (Sprint,  Sprint  Planning,  Daily  Scrum,  Sprint  Review  y  Sprint  Retrospective),  roles 
(​Scrum  Master​,  Product  Owner  y  Development  Team​)  y  artefactos  (Product  Backlog, Sprint 
Backlog  e  Incremento).  La  guía  se  puede  descargar  aquí  en  Castellano​.  En  las  próximas 
páginas  desgranamos  cuales  son  los  detalles  de  cuales son cada una de las mecánicas que 
subyacen a Scrum. 

La  guía  de  Scrum  ha  tenido  su  última  actualización  en  2017,  matizando  el  uso  de  Scrum 
fuera  del  software,  el  papel  del  Scrum  Master  o  el  objetivo  del  Daily  Scrum.  Esta 
actualización,  después  de  las  de  2016,  incluyendo  los  valores,  2011  y  2013,  indican  la 

 
22 
 
 
excelente  relación  de  los  creadores  de  Scrum  y  su  compromiso  hacia  este  marco  de 
trabajo. 

Algunos puntos clave 

● El desarrollo de software se emplaza en el dominio de la complejidad 
● El mejor enfoque para la complejidad es un proceso empírico 
● Los 3 pilares del empirismo son la transparencia, la inspección y la adaptación   
● La transparencia requiere confianza y coraje   
● Existen tres roles en Scrum:​ Product Owner​,​ Scrum Master​ y​ Development Team 
● Hay tres artefactos en Scrum: Product Backlog, Sprint Backlog e Incremento  
● Cinco  eventos:  Sprint,  Sprint  Planning,  Daily  Scrum,  Sprint  Review  y  Sprint 
Retrospective. 

Tanto  si  has  asistido  a  uno  de  nuestros  cursos  ​presenciales de Scrum​, si estás enrolado en 

unos  de  nuestros  cursos  online​,  si  estás  preparándote  por  tu  cuenta  o  has  asistido  a  un 
curso  de  otro  proveedor,  en  este  artículo  tienes  desgranadas  las  claves  fundamentales 
para pasar el examen PSM y convertirte en Scrum Master. 

El  examen  PSM  I  es  el  más  riguroso  de  la  industria.  Realmente  te  prepara  para  ser  un 
Scrum  Master  evaluando  tu  conocimiento  de  Scrum.  Aquí  te  dejo  algunos  consejos  para 
afrontar esta certificación: 

 
Estudia la guía de Scrum 
Descargar  la  guía  oficial  de  Scrum​.  De  ella  salen  la  mayoría  de  las  preguntas  del  examen 
PSM y tiene todos los conocimientos clave para entender cómo funciona Scrum. 

No  sólo  hay que dedicarle una lectura rápida. Necesita una lectura comprensiva. Tómate tu 

tiempo  para  marcar  aquello  que  no  comprendas  e  intenta  buscar  la  solución  en  la  propia 
guía. Merece la pena dedicar ese tiempo. 

Asegúrate de entender conceptos clave como el valor de la autoorganización. 

 
23 
 
 

Revisa el glosario de términos de Scrum.org 

Scrum.org  tiene  un  glosario  de  términos  bastante  extenso  en  el  cual  se  hacen 
descripciones de cada una de las palabras claves de Scrum, sus eventos, artefactos y roles. 

Este  glosario  es  imprescindible  para  preparar  el  examen.  También  en  la  realización  del 
mismo.  Asegurate  de  añadirlo  a  tus  marcadores  para  tenerlo  a  mano  y  consultarlo 
primero, en lugar de ir a Google. 

Preparate usando los assessment abiertos de Scrum.org

En  los  Open  Assessment  de Scrum.org encontraras grupos de 30 preguntas con soluciones 
que  incluyen  algunas  preguntas  reales  del  PSM  I.  Tomate  tu  tiempo  y  hazlo  cuantas  veces 
veas necesario. Tienes 30 minutos para terminar el assessment. 

Idealmente,  antes  de  lanzarte  a  por  el  test  real,  deberías  de  pasar  al  menos  3  veces 
seguidas  sin  ningún  error  el  examen  abierto,  dejándote  tiempo  de  sobra  para  acabarlo.  Si 
no es así, sigue practicando y estudiando. 

Al final lo conseguirás. 
 
 
 
Durante el examen sigue estos consejos: 
● Asegurate de pasar cómodamente el Open Assessment antes de intentarlo  
● El  examen  dura  60  minutos  y  consta  de  80 preguntas, así que tienes algo menos de 
un minuto por pregunta   
● Ten  abierta  la  guía  de  Scrum  y  el  glosario  de  términos  para  consultar  dudas,  te 
serán útiles.   
● Si te atascas en alguna pregunta, apunta el número y vuelve a ella más tarde. 
● Cuando  llegues  a  la  última  pregunta,  ten  cuidado  de  no  pulsar  en  finalizar  examen 
hasta que hayas tenido tiempo de revisar las preguntas.  

Si  no  consigues  pasar  el  examen,  puedes  hacerlo  de  nuevo. Tendrás que pagar otros 150$ 
a  Scrum.org.  Si  has  asistido  a  ​mi  curso  oficial​,  recuerda  que  tienes  dos  intentos  siempre 

 
24 
 
 
que  el  primero  lo  acometas  dentro  de  los  14  días  siguientes  a  recibir  el  correo  de 
Scrum.org con tu clave para el examen. 

Si  tienes  alguna  pregunta,  no  dudes  en  escribirme,  me  encanta  tener  relación  con  futuros 
Scrum Masters. 

¿Quién soy? 

Mi  misión  es  ayudar  a  mejorar  la  profesión  del  desarrollo  de  software.  Soy  Professional 
Scrum  Trainer  de  Scrum.org,  Accredited  Kanban  Trainer  de  Lean  Kanban  y  facilitador  de 
LEGO® Serious Play. Vivo entre Berlín y Granada. Me encantan la vela y el Rugby 

 
25