CURSO GRATIS DE INTRODUCCIÓN A SCRUM

Hola! Soy Juan Luis, y seré tu guía personal en este micro-curso sobre Scrum desarrollado por Nader [Link],
de [Link]. Antes que nada, me gustaría darte la bienvenida. Sinceramente espero que lo disfrutes y te sea de
alguna utilidad.

Se trata de un sencillo curso de sensibilización, cuyo objetivo es que alcances, sin demasiado esfuerzo por tu parte,
una comprensión general del marco de trabajo Scrum. Quién sabe, tal vez te des cuenta de que SCRUM no es lo
tuyo, o por el contrario te gustaría seguir aprendiendo más sobre Scrum y sus posibles certificaciones

A partir de ahora publicaré periódicamente un post con una lección muy simple sobre Scrum. Serán posts cortos que
se pueden leerse en un par de minutos, ideales para llenar esos tiempos muertos en el camino al trabajo y de vuelta
a casa. ¡A todos nos gusta sacar el máximo provecho a nuestro tiempo! Si lo prefieres, puedes suscribirte por email,
y te enviaremos un mail cada día con una nueva lección.

¿Qué es Scrum?

Scrum es seguramente el marco Agile más conocido y empelado; alrededor del 70% de las empresas ágiles emplean
Scrum, o una combinación de Scrum con otro sistema Agile como XP (eXtreme Programming).

Es importante que entiendas que Scrum y Agile no son la misma cosa. Agile es un concepto sobre el que se han
creado muchos marcos y metodologías, y Scrum es uno de ellos. En otras palabras, Scrum es una manera de practicar
o llevar la “agilidad” al mundo real.
Los sistemas Agile más conocidos son:

Scrum – existe desde finales de los 90. Es un marco muy simple y ligero, por que se refiere a su estructura y requisitos.

DSDM – tiene la misma edad que Scrum, y sobre todo es conocido por su sofisticación y por el hecho de haber sido
diseñado para ser compatible con PRINCE2.

XP – existe desde 1999, y es conocido sobre todo para sus prácticas ágiles (programación por pares, desarrollo
basado en pruebas, propiedad de código compartido, etc.)

Kanban (ScrumBan) – Kanban es una técnica utilizada principalmente en la manufactura. Puede combinación con
sistemas Agile, o convertirse en un sistema Agile integrando algunos elementos adicionales.

Para aquellos de vosotros que estéis interesados en comparar la edad de los diferentes sistemas, a continuación, os
dejo una sencilla lista: PRINCE (1989), PRINCE2 (1996), PMBOK (1996), Agile Manifestó (2001).

ENTONCES… ¿QUÉ SON LOS SISTEMAS PREDICTIVOS Y ADAPTATIVOS?

Este post es la continuación del anterior sobre el curso gratis de Introducción a scrum.

Muchas personas tienen dificultades para definir “Agile”, y para ser honesto, muchas personas no lo comprenden
correctamente. A mí me parce que es muy simple: ser Agile implica utilizar un sistema de desarrollo adaptativo, en
lugar de uno predictivo.

Bueno… tal vez ahora tengamos dos problemas: 1) ¿qué son los sistemas adaptativos?, y 2) ¿Qué son los predictivos?

Vayamos paso a paso.

Desarrollo predictivo

Se emplea cuando sabes exactamente el tipo de producto que deseas crear, y es posible definirlo plenamente por
adelantado. Por lo tanto, lo que hacemos es predecir toda por la planificación y el diseño del producto por
adelantado. Luego nuestro es objetivo es seguir el plan y producir el producto previamente diseñado.

Comúnmente se conoce como el método “tradicional”. En la industria de TI, se le denomina como “cascada”.

Bien, la cuestión es, ¿por qué no podemos ser “predictivos” en algunos proyectos?, y en tales casos, ¿qué podemos
hacer?
Adaptativos

Cuando no podemos usar un sistema predictivo, los adaptativos son una muy buena opción. Los sistemas adaptativos
se conocen comúnmente como “Agiles” (Agilecuando se emplea el término en inglés).

Este sistema se utiliza cuando tenemos un resultado en mente, pero no podemos estar seguros de qué tipo de
producto puede crearlo, y por lo tanto la “predicción” no es posible. Es el caso, por ejemplo, de los mercados que
cambian rápidamente, o cuando no es posible entender realmente las necesidades del mercado o del cliente.

En este caso trabajaremos por ciclos. En cada ciclo se diseña, planifica, construye, y prueba un subconjunto del
producto final que debe quedar listo para su implementación. Es decir, que al final de cada ciclo proporcionaremos
al cliente final o usuario, un subconjunto del producto final sobre el que recibiremos un feedback. En base a dicho
feedback, comprenderemos mucho mejor cual deberá ser el resultado del próximo ciclo.

Los ciclos se ejecutan uno tras otro hasta que se genera el valor suficiente, y estamos lo suficientemente cerca del
resultado esperado. Estos son los sistemas adaptativos, y es la idea que subyace en la gestión de proyectos Agile.

Pero un ciclo de ciclo de vida adaptable no consiste simplemente en dividir y desarrollar las diferentes características
de la solución en distintas etapas, realizando todas y cada una de los procesos en cada etapa. Principalmente consiste
en el limitar la planificación a las iteraciones que se desarrollarán en el futuro más próximo, y aprovechar el output
de cada iteración para volver a planificar un paso más allá.

Generalmente se conocen como modernos o Agile, en comparación con los métodos de predicción que se conocen
como “tradicional” o en cascada. Bien, ahora que ya conoces la diferencia entre un sistema adaptativo y unió
predictivo, ¿cuál es tu opinión al respecto?

¿Es Agile “algo “nuevo?

¿Puedes imaginar que nadie en los últimos 2.000 o 3.000 años hubiera concebido la idea de la Agilidad? Yo no
puedo. Simplemente no me creo que haya sido inventado en los últimos 20 o 30 años.
Por supuesto que antes no teníamos nombres tan modernos como “Agile”, o marcos de trabajo como Scrum, pero
los conceptos estaban allí. Al menos, eso es lo que creo yo.

La clave está en que en que los métodos de trabajo predictivos han sido considerados como la manera correcta de
desarrollar los proyectos durante los últimos 100 años. Ahora sin embargo, estamos empezado a aceptar la
“adaptación” como la manera correcta de hacerlo. Ese es realmente el cambio que hemos tenido en los tiempos
modernos, pero no hemos inventado nada nuevo.

Me encanta la agilidad, pero a diferencia de algunas personas, no considero que los métodos predictivos estén
“equivocados”. Ambos son válidos y debemos ser capaces de entenderse cual se adapta mejor a nuestro proyecto.

OK, suficiente. Es hora de empezar a hablar sobre el marco de trabajo Scrum, ¿de acuerdo? Empezaremos en el
próximo post, y lo haremos hablando sobre cómo se inicia un proyecto Scrum.

EL BACKLOG DE PRODUCTO

Cuando trabajamos con Scrum, lo primero que debemos hacer es crear el “Product Backlog” o Backlog de
Producto en castellano. Este no es más que la lista de características que hemos pensado para el proyecto. Es lo
mismo que si estuviéramos hablando de la definición del alcance.

Recuerda que Scrum no es predictivo, por lo que no planea por adelantado; en lugar de crear un completo y detallado
Backlog del Producto, simplemente añadimos los suficientes elementos para los próximos ciclos (también conocidos
como iteraciones o Sprints). A continuación, empezamos inmediatamente con el primer ciclo y mantendremos el
Backlog del Producto continuamente actualizado (“adaptativa”). Esto significa que iremos añadiendo elementos
conforme surjan.

La simplicidad es uno de los principios ágiles. Por ello, preferiremos crear el Backlog de Producto en un tablero físico,
en lugar de utilizar software. Para capturar los elementos del Backlog de Producto, emplearemos tarjetas o notas
adhesivas. En una ocasión empleamos tantas notas adhesivas que alguien me preguntó, muy en serio, ¡si 3M había
sido el inventor de Scrum!

Backlog del Producto en Scrum

Bien, entonces en tu opinión ¿Cómo deberían ser los elementos del Backlog Producto? Por ejemplo, ¿estaría bien
que su contenido fuera algo como “crear el diseño de la solución”?… No, no estaría bien, porque eso es
predictivo. Tenemos que diseñar el producto de forma iterativa.

El Backlog de Producto debe estar compuesto únicamente por funciones; cosas que el cliente pueda entender, y
cuando se han desarrollado, pueda probar y darnos su opinión. Es por eso que los elementos del Backlog de Producto
deben tener dos características:

 Deben ser no técnicos, porque los usamos para comunicarse con el cliente y la comprensión mutua es la
clave de nuestro. Normalmente el cliente no es o tiene un carácter técnico. Así pues, no utilizamos una
documentación sofisticada para hablar con el cliente sobre la definición del producto; necesitamos que se
sienta cómodo y colabore.
 Deben ser independientes entre sí, porque queremos ser capaces de ordenarlo libremente en función de su
valor de negocio (importancia) y centrarnos primero en los elementos más importantes.

Una muy buena opción para redactar los elementos del Backlog de Producto es utilizar “historias de usuario”. Pero,
¿qué es una historia de usuario?

Historias de usuario

Como te comentaba una buena manera de redactar elementos del Backlog de Producto es utilizando “historias de
usuario”. Este es un ejemplo de una historia de usuario:

“Como usuario final, quiero obtener un informe sobre la actividad de mi cuenta, para comprobar si todo está bien”.

Sí, es muy breve. ¡Pero es que esa a es la clave! En Agile preferimos tener objetos pequeños, ya que hace más fácil
el control del proyecto. Además, durante una iteración también podemos producir o completar al 100% varios
artículos pequeños, mientras que, si los artículos son grandes, es difícil decir saber cuándo se completan realmente.

La plantilla genérica para una historia de usuario es la siguiente:

Como (rol)… , quiero (función)… , para (propósito)…

El tercer elemento de la plantilla es opcional y no lo mencionaremos cuando sea obvio. Fíjate en el siguiente ejemplo:

Como administrador del sistema (rol), quiero poder restablecer las contraseñas (función), para… (no es necesario
mostrar el propósito).

¡Es tu turno! ¿qué piensas acerca de la siguiente historia de usuario: Como administrador del sistema, quiero tener
una base de datos SQL para el sistema.

¿Te parece que es una historia de usuario correctamente formulada?

No. La segunda parte de la historia de usuario debe ser de una acción; se trata de hacer las cosas, en lugar de tener
las cosas.

EL SCRUM TEAM: EL DUEÑO DEL PRODUCTO

En todo Scrum Team (Equipo Scrum) hay un total de tres roles: el Product Owner(PO), el Development Team (DT) y el
Scrum Master (SM). Es posible, pero no recomendable, asignar a una persona más de un rol, pero no está permitido
crear ningún otro rol, ya que podría perjudicar al equipo poniendo en peligro su unidad.

El Scrum Team

El Scrum Team tiene que ser:

Auto-organizado: no hay un líder de equipo que decide qué persona va a hacer qué tarea o cómo se resuelve un
problema. Es el equipo en su conjunto quien decide estas y otras cuestiones.

Multidisciplinar: el ST tiene todos los conocimientos y las competencias necesarias para realizar el trabajo,
dependiendo lo mínimo de personas externas al equipo.

El Dueño del Producto.

Él es el responsable de redactar los elementos que componen el Backlog de Producto.

Sólo hay un Dueño del Producto por proyecto, independientemente que sea a tiempo completo o tiempo parcial. La
persona que ocupa este rol debe estar orientada a los negocios; por ejemplo, un analista de negocios es un muy
buen candidato para desempeñar este rol.

El Propietario o Dueño del Producto está constantemente en contacto con el cliente, entiende sus necesidades, y
los transforma en elementos del Backlog de Producto. Después, asigna un “valor de negocio” a cada artículo, y
ordena el Backlog de Producto en función de este valor. De esta manera los elementos más importantes estarán
siempre en la parte de arriba de la lista. Esos elementos de la parte superior son lo que haremos en la siguiente

iteración.

Cuando iniciamos un proyecto con Scrum, tras dedicar unos días a redactar elementos del Backlog de Producto
deberíamos tener suficientes para comenzar con la primera iteración. Recuerda que no necesitamos generar un
Backlog completo al 100%, tan solo las suficientes para iniciar el primer Sprint. Estamos trabajando con un modelo
adaptativo, no predictivo.

LOS SPRINTS Y SU PLANIFICACIÓN

Hola, tras la lección sobre el Dueño del Producto, hoy seguimos con la lección 5 de nuestro curso de Introducción a
scrum. Al final del post tienes un índice con el enlace al resto de lecciones.

Los Sprints

Sprint es el término que empleamos en Scrum para referirnos a las iteraciones. Las iteraciones son ciclos en los que
nos centramos en un subconjunto de características del producto final y creamos un producto utilizable.
Un proyecto gestionado con Scrum se desarrolla a partir de un número de sprints consecutivos, tal y como muestra
el diagrama. El número de sprints que integran cada proyecto dependerá del propio proyecto.

Durante cada Sprint tienen lugar otros cuatro eventos, que sirven para gestionar el proyecto:

 La Planificación del Sprint; durante la que se planifica el trabajo del sprint

 El Scrum Diario; para que el equipo de trabajo puedo ponerse al día sobre el estado del trabajo en proceso
 La Revisión del Sprint; para mostrar al cliente los avances y recibir su fedback
 La Retrospectiva del Sprint; evento formalmente reservado para poner en marcha mejoras

La duración de un sprin t nunca pude ser superior a un mes. Normalmente

yo prefiero los sprints cortos; lo sprints de dos o tres semanas son las opciones más comunes, pero como siempre
dependerá del proyecto.

La duración de los sprints se fija al inicio del proyecto; todos los sprints deben tener la misma duración. Además, los
sprints son “timeboxed“, lo que significa que tienen una duración máxima y NUNCA se extienden más allá de esta.
Al finalizar el sprint entregaremos tantos elementos del Backlog de Producto como podamos acabar, pero nunca
extenderemos la duración el Sprint para completar un elemento, por muy poco que falta para acabarlo.

Llegado este punto, ya tendríamos un Backlog de Producto con suficientes elementos como para empezar el primer
Sprint. ¿Cuál piensas que debería ser la primera cosa a hacer?
Planificar el sprint

Bien, lo primero que hacemos en el Sprint es planificar. Sí, aunque algunos piensan lo contrario cuando empleamos
marcos de trabajo Agile también planificamos.

La Reunión de Planificación de Sprint tiene una duración de 8 horas para un Sprint de un mes, y es proporcionalmente
más corta en función de la duración de los Sprints. Recuerda que en scrum todos los eventos cumplen con la regla
de ser “timeboxed“.

Durante esta reunión movemos los artículos de la parte superior del Backlog de Producto al Backlog del Sprint. Ese
será nuestro plan para el Sprint. Los elementos de la parte superior del Backlog de Producto son los más importantes;
centrándonos primero en estos queremos ofrecer el máximo valor posible en cada Sprint. Es lo que se conoce como
priorizar.

Pero, ¿cuántos elementos debemos escoger? Depende del tamaño de los elementos del Backlog de Producto. La
cuestión es ahora ¿quién debe estimar el tamaño de los artículos? A ti ¿qué te parece? Lo veremos en la próxima
lección.

COMO ESTIMAR EL BACKLOG DE PRODUCTO

En nuestra última lección sobre el sprint y su planificación, concluimos preguntándonos quién debía estimar el
tamaño de los artículos del Backlog de Producto. Bien, ¿a ti quien o quienes te parece que deben ser los responsables
de hacerlo?

Estimación

La estimación debe realizarse por aquellos que se supone que harán el trabajo, y en Scrum son el equipo de
desarrollo.
El equipo de desarrollo es el segundo rol en el marco de trabajo Scrum, el primero fue el Dueño del Producto, sobre
el que ya hemos hablado. En un equipo de trabajo que utilice Scrum debe haber entre 3 y 9
desarrolladores. “Desarrolladores” es un término que se refiere a los analistas, diseñadores, programadores, testers,
diseñadores de interfaz de usuario, y cualquier otra persona que tiene un papel en la producción de la solución.

Cuando el Dueño del Producto crea un nuevo elemento del Backlog de Producto, se dirige al equipo de desarrollo,
explica su significado y pide a al equipo de desarrolladores que realicen una estimación. Los desarrolladores, tras
discutirlo, acordaran una estimación. El propietario del producto agrega la estimación al elemento del Backlog de
Producto. Esto se conoce como el “aseo” o “refinamiento” del Backlog de Producto.

Ahora ya sabes algo más a cerca de la estimación de los elementos del Backlog de Producto, pero aún hay algunas
otras cuestiones al respecto que resolver. ¿Cuál piensas que debería ser la unidad para estimar el tamaño de los
elementos del Backlog de Producto, tiempo, esfuerzo…?

Unidades de estimación en Scrum

En Scrum preferimos estimar en base a unidades de esfuerzo relativo, en lugar de en unidades basadas en tiempo,
tales como horas-hombre. Si empleáramos horas-hombre siempre podría haber alguien que dijera: “durante este
Sprint habéis creado 10 elementos del Backlog de Producto por un valor estimado de 381 horas-hombre. Sois 6
personas trabajando en Sprints de dos semanas, lo que hacen un total de 528 horas-hombre. ¿Por qué vuestra
producción ha sido tan baja? ¿Qué va mal?”

Queremos evitar la anterior situación, pues tan pronto como se empiece a culpar a los desarrolladores estos
empezaran a añadir márgenes de seguridad es sus estimaciones; en lugar de decir que algo requiere 20 horas-
hombre, dirán que necesitan 35 horas-hombre para evitar ser cuestionados, lo que creará un montón de problemas.
Para empezar, el “sindroma del estudiante”, que consiste en extender el tiempo necesario para realizar un trabajo
durante tanto tiempo como del que se disponga. Cuando se suman los márgenes, automáticamente se produce
menos.

Por esto no nos gustan las unidades basadas en tiempo. A cambio preferimos utilizar unidades basadas en el esfuerzo
relativo que se conocen como puntos de historia. ¿Sabes lo que son? Te lo contaré en nuestra próxima lección que
dedicaremos a los Puntos de Historia, y al concepto de velocidad.

PUNTOS DE HISTORIA Y VELOCIDAD EN SCRUM

En nuestra última lección hablamos sobre cómo estimar el Backlog de Producto y te conté que en Scrum utilizamos
puntos historia en lugar de horas-hombre o cualquier otra unidad basadas en tiempo. A continuación, te cuento
brevemente a cerca de los puntos de historia y la velocidad, un concepto clave para estimar la duración de los
proyectos gestionados con scrum.

Scrum y lo puntos de historia

Vemos cómo funcionan los puntos de historia en dos sencillos pasos:

1. Definición de la referencia

Escogemos una historia de usuario sencilla, una que todo el mundo entiende, para emplearla como referencia. Esta
sería la definición de 1 punto de la historia en nuestro proyecto.

2. Estimación

Establecida la referencia, cada vez que queremos estimar algo tan solo tenemos que compararlo con la historia de
referencia. Si creemos que nos llevará el doble de trabajo que la historia de referencia, entonces el valor será de 2
puntos de historia; si creemos que tarda la mitad del esfuerzo, sería 0.5 puntos; etcétera.

Sé lo que estás pensando; los puntos de historia son convertibles en tiempo. ¡Correcto! Lo hacemos empleando el
concepto de “velocidad”. ¿Adivinas a que me refiero al hablar de la “velocidad”?.
Velocidad

Bien, déjame explicarte este concepto en base a al ejemplo siguiente:

Digamos que el resultado, o los puntos de historia que hemos podido concluir transcurridos 5 sprints ha sido el
siguiente:

 Sprint 1: 73 puntos
 Sprint 2: 110 puntos
 Sprint 3: 98 puntos
 Sprint 4: 131 puntos
 Sprint 5: 122 puntos

En este caso, podemos decir que, en promedio, hemos entregado 107sp por Sprint. Esto es lo que llamamos “la
velocidad”. Nuestra velocidad al final del quinto Sprint es 107puntos de historia por Sprint.

Por lo tanto, en base a estos datos podemos calcular la siguiente información:

1. La cantidad de trabajo que podríamos realizar en el siguiente Sprint: alrededor 107 puntos.
2. Si actualmente tenemos un Backlog de Producto con un valor estimado de 1000 puntos, y no pensamos
añadir nuevos artículos para evitar cualquier retraso. ¿Cuándo estimamos que podríamos terminar el
proyecto? 1000 puntos / 107 puntos por Sprint = unos 10 sprints

Por supuesto, la velocidad es algo que cambia constantemente. Por ejemplo, si nuestra producción es de 140 putos
durante el 6º Sprint, la velocidad se modificaría a 112 puntos. Así pues, cada Sprint concluido es una oportunidad
para ajustar todos los cálculos y realizar previsiones más realistas.
Al inicio del proyecto es normal que se produzcan grandes cambios de velocidad. Digamos que esta se estabiliza
entre el quinto y el octavo sprint.

Bien, ahora conocemos la unidad de medida (puntos de historia) y quiénes son los responsables de realizar las
estimaciones. Imaginemos un equipo de 6 desarrolladores: el Dueño del Producto les ha presentado un nuevo
elemento del Backlog de Producto, ya han discutido y aclarado el contenido, así que solo queda realizar la estimación.
¿Cómo lo hacen? ¿Deben votar uno por uno? En el próximo post te contaré como estimar los elementos del Backlog
de Producto mediante la técnica del Planning Poker (Póker de Planificación).

EL PÓKER DE PLANIFICACIÓN EN SCRUM

Tras nuestra última lección sobre los puntos de historia y la velocidad, es momento de estudiar cómo deben proceder
los desarrolladores para establecer el valor de los artículos del Backlog de Producto. La clave está en reconocer que,
si los desarrolladores comienzan a votar uno por uno, los primeros votos se influirán en el resto, y reducirá la calidad
de las estimaciones. Entonces, ¿cómo hacerlo?

Póker de Planificación en Scrum

Es responsabilidad del Equipo de Desarrollo estimar el esfuerzo necesario de cada historia de usuario, y una manera
de hacerlo es mediante el póker de planificación. En esta técnica, el Equipo de Desarrollo se reúne y el Dueño del
Producto explica la historia de usuario para asegurarse de que todo el mundo la entiende.

Como te decía la clave está en reconocer que, si los desarrolladores comienzan a votar uno por uno, los primeros
votos se influirán en el resto, y reducirá la calidad de las estimaciones. Para evitar este sesgo cognitivo suele utilizarse
el póker de planificación. Cada miembro del equipo tiene una serie de cartas con unos valores, y cada uno debe
elegir una carta que representa su estimación personal, basada en su opinión, y que mantiene boca abajo.

Cuando todos han elegido, se muestran todas las cartas a la vez y entonces se comprueban los valores. Si, por
ejemplo, alguien cree que el valor del artículo es de 2 puntos, y otra cree que es de 20 puntos, podremos estar
seguros de que al menos uno de ellos no ha entendido bien el artículo. Así pues, deberá discutirse de nuevo y volver

a votar.

Cuando todos los votos están en la misma línea, calculamos un promedio y eso sería el valor estimado del artículo
del Backlog de Producto.

Bien, tras estos días te habrás dado cuenta que hay un montón de cosas a tener en cuenta al implementar Scrum.
¿No te parece? ¿Crees que el Dueño de Producto y el Equipo de Desarrollo pueden con todo? ¿Y si pasara cualquier
cosa…? Veremos más en la próxima lección sobre el Rol del Scrum Máster.

EL SCRUM TEAM: EL SCRUM MASTER

Tal y como comentábamos en nuestra última lección hay muchos detalles a considerar cuando aplicamos Scrum.
Parece que el Dueño de Producto y el Equipo de Desarrollo necesitarán algo de ayuda para mantener el proceso
bajo control, e implementar correctamente el marco Scrum. Bien, esta persona es el Scrum Máster.

El scrum máster

El Scrum Máster es un especialista que conoce y comprende Scrum completamente; ayuda al equipo entrenándolo
y asegurándose de que todos los procesos de Scrum se ponen en práctica correctamente.
Un Scrum Máster se asegura de que todos tengan una correcta comprensión del marco de trabajo. Si no, el/la Scrum
Máster los entrenará y los convencerá para hacer lo correcto.

El Scrum Máster se centra en el proceso más que en el contenido (solución, alcance, etc.)

Además, el Scrum Máster es también responsable de la eliminar de los impedimentos; cuando los miembros del
equipo tienen un problema, se lo cuentan al Scrum Máster y este es el encargado de intentar resolverlo. Por supuesto
no si se trata de problemas técnicos, sino de problemas que tienen que ver con la implementación de Scrum.

OK, a lo largo de este curso ya hemos hablado de los tres roles de Scrum. Antes de seguir avanzando, me gustaría
hacer un resumen rápido.

El Equipo scrum

Recapitulemos cuáles son los tres roles de que integran un Equipo Scrum, que es cómo se conoce al equipo que
trabajo bajo el marco de trabajo Scrum:

El Dueño del Producto; es la persona del equipo orientada a los negocios, responsable del Backlog de Producto, y
encargado de ordenar los elementos del Backlog del Producto en función de su valor para maximizar el valor del
negocio.

El Scrum Máster; es el experto en el marco de trabajo Scrum, entrena al equipo y elimina los impedimentos.

El Equipo de Desarrollo; son todos los expertos necesarios para desarrollar el proyecto.

El equipo de desarrollo debe tener dos características fundamentales:

 Ser multifuncional: significa que deben tener todos los conocimientos necesarios para crear el producto sin
depender de las personas externas.
 Ser auto-organizado: significa que debe encontrar su propio camino en lugar de recibir órdenes. Por supuesto
debido a esto tienen más responsabilidades.

Scrum no permite definir ninguna otra función, títulos o roles. Por ejemplo,
no hay en el equipo un “tester” o probador. Hay uno (o más) desarrolladores
en el equipo de expertos en pruebas, pero aun así se llaman
desarrolladores. Es así porque queremos que todos se ayuden mutuamente
y que se centren en el resultado o producto, en lugar de en sus actividades
de experto.
Tampoco tenemos jefes de equipo, pues en ese caso los desarrolladores se sentirán menos responsable. Al respecto
ten en cuenta que el Scrum Máster tampoco debe actuar como un líder de equipo; sólo ayuda y apoya.

¿QUIEN ES EL PROJECT MANAGER EN SCRUM?

En nuestra última lección tratamos acabamos de ver los roles que intervienen en un proyecto gestionado con scrum.
Sin embargo, todavía no hemos hablado del rol del Project Manager, así que ¿quién es el Project Manager en scrum?

Es importante que recuerdes que scrum no permite crear otros roles diferentes al de Scrum Máster, Dueño del
Producto y Equipo de Desarrollo. Dicho esto, y aunque algunos sistemas Ágiles incluyen el rol del Project Manager,
no es el caso de Scrum donde ni siquiera existe un rol similar al Project Manager.

La respuesta es pues muy simple: no existe tal rol en scrum y ninguno de los tres roles actúa como un Project
Manager “tradicional”. Entonces, ¿qué ocurre con la gestión del proyecto? Ocurre que la responsabilidad de la
gestión se distribuye entre los distintos roles de scrum, por lo que no hay una gestión centralizada:

 El Scrum Máster únicamente es responsable de algunas de las actividades de gestión de proyectos (por
ejemplo, la gestión de procesos, y la resolución de problemas);
 El Dueño del producto (por ejemplo, es el responsable de priorizar y definir el alcance);
 El Equipo de Desarrollo es responsable de algunas de las actividades de gestión de proyectos (por ejemplo,
la estimación).

Así pues, la clave está en saber que en Scrum las actividades de gestión del proyecto se distribuyen entre todos los
miembros del equipo Scrum.

¡Estupendo! Espero que haya quedado claro, aunque es cierto que puedes resultar algo difícil de asimilar.

Cuando empezamos a hablar de los diferentes roles del equipo Scrum estábamos tratando el tema de la Planificación
del Sprint. Recuerda, la planificación del Sprint es el primer evento en cada Sprint; cuando seleccionamos una serie
de elementos del Backlog de Producto y los ponemos en el Backlog del Sprint. Ha llegado el momento de estudiar
los diferentes eventos de scrum. Hablaremos de ello en el próximo post.

¿COMO SE DESARROLLA UN PROYECTO CON SCRUM?

En nuestra última lección sobre la planificación de los sprints aprendimos que un proyecto gestionado con Scrum se
desarrolla a partir de un número de sprints consecutivos. Recuerda que sprint es el término que empleamos en
Scrum para referirnos a las iteraciones, y que estas son ciclos de trabajo en los que nos centramos en un subconjunto
de características del producto final y creamos un producto utilizable. Además, el número de sprints que integran
cada proyecto dependerá del propio proyecto.

Los elementos del sprint

Un proyecto que sigue Scrum se gestiona siguiendo cinco eventos:

1.- El Sprint: cada proyecto Scrum es un conjunto de Sprints. Un Sprint contiene, tal y como muestra el diagrama de
arriba, los otros cuatro eventos o rituales, el esfuerzo de desarrollo, y el mantenimiento del Backlog de Producto

2.- La Planificación del Sprint: es el primer evento dentro de un Sprint. El Equipo Scrum planea los artículos que se
van a entregar en el Sprint y cómo se hará.

3.- El Scrum Diario: durante el Sprint, el equipo de desarrollo tiene una reunión diaria de 15 minutos, durante la cual
se coordinar el trabajo de las próximas 24 horas. Esta reunión se llama Scrum Diario.

4.- Revisión del Sprint: antes del final del Sprint el equipo de Desarrollo demuestra el resultado del Sprint al cliente y
recibe retroalimentación (feedback). Esta reunión se llama Revisión del Sprint, también se conoce como
Demostración del Sprint.

5.- Retrospectiva del Sprint: después de la revisión de Sprint y justo antes de que finalice el Sprint, el equipo de
desarrollo tiene una reunión interna para revisar el Sprint y mejorar el proceso (lecciones aprendidas) en el próximo
Sprint. Esta reunión se conoce como Retrospectiva del Sprint.

Desarrollar un proyecto con scrum

Tan pronto como la reunión de Planificación del Sprint se ha celebrado, no podremos añadir, eliminar o modificar
ningún elemento del Backlog del Sprint. De esta manera, evitando modificaciones en el Backlog del Sprint,
queremos mantener la concentración del Equipo de Desarrollo para completen los artículos planificados.
Los desarrolladores empiezan a trabajar en los artículos de la parte superior del Backlog de Producto, y los completan
al 100% antes de pasar a los siguientes artículos. Así mismo, diseñan, programan, integran y prueban todos y cada
uno de los artículos.

La “prueba” incluye todos los tipos de prueba. La razón es que al finalizar el sprint debemos estar completamente
seguros de que el artículo se ha desarrollado completamente, al 100%. Solo de esa manera podremos obtener un
feedback efectivo al presentárselo al cliente.

Por lo tanto, las pruebas de aceptación del usuario son también parte del concepto de prueba. Tan pronto como
todo está preparado los desarrolladores solicitan una prueba de aceptación de los nuevos artículos desarrollados
durante el sprint. Las pruebas se realizan a lo largo de todo el sprint; no es necesario esperar y realizarlas al final del
sprint.

La colaboración entre todos los desarrolladores es fundamental: todos deben estar en “la misma página”, pero
¿cómo lograrlo? Lo veremos en nuestro siguiente post.

EL DESARROLLO DEL SPRINT: MEDICIÓN Y CANCELACIÓN

En nuestra última lección estuvimos aprendiendo sobre el desarrollo de un proyecto en scrum. Recuerda: un
proyecto scrum se desarrolla en basa a sprints, y durante los sprints tienen lugar una serie de eventos que guían el
desarrollo del proyecto. Antes de profundizar en los eventos hay dos cuestiones sobre los sprints que debemos
considerar: ¿cómo se mide su desempeño?, ¿pueden cancelarse? En este post trataremos estas dos cuestiones.

Medir el desempeño del sprint

Bien, entonces ¿Quién debe medir el desempeño de los Sprints? ¿El Dueño del Producto? ¿El Scrum Máster? O ¿el
Equipo de Desarrollo? ¿Recuerdas las características del Equipo de Desarrollo? La primera consistía en que el Equipo
de Desarrollo debe organizarse por cuenta propia (auto-organizado). Así pues, debe ser responsable de medir su
propio desempeño.

La medición del sprint debe hacerse de manera efectiva dado que sencillamente monitorear los recursos planeados
vs los recursos reales no es algo realmente útil. Simplemente comprobaremos el número de elementos que hemos
completado, y comprobaremos si podemos entregar el resto antes de que concluya el Sprint.

Si nos diéramos cuenta de que no podemos acabarlo todo, entonces deberemos llamar al Dueño del Producto para
que compruebe el orden de los elementos del Backlog del Sprint. Eso es todo. No debemos ni agregar, ni quitar o
cambiar ningún artículo del Backlog del Sprint.
Bien, ahora supongamos que hay algún cambio en el mercado y que el cliente ya no necesite la mitad de los
elementos del Backlog del Sprint. ¿Qué deberíamos hacer? Después de todo, no se nos permite eliminar elementos
del Backlog del Sprint.

Cancelar un sprint

Si el cliente ya no necesita más elementos de Backlog del Sprint, o aún más el Backlog
del Sprint en general ya no tiene sentido, el Dueño del Producto tiene la autoridad para
cancelar el Sprint.

En este caso empezaríamos inmediatamente un nuevo Sprint, con una nueva

planificación. Por supuesto, cualquier cambio se aplicará al Backlog de Producto antes
de comenzar el nuevo Sprint.

Lo cierto que las cancelaciones del sprint no son habituales; es una opción extrema. Si
tenemos Sprints los suficientemente cortos no será necesario llevar a cabo cambios tan
dramáticos. En general, los Sprints cortos reducen los riesgos.

Estupendo, como ves vamos avanzando y tus conocimientos sobre Scrum van en aumento. ¡Espero que estés
disfrutando! Si quieres saber más, no te pierdas nuestro próximo webinario.

En la próxima lección seguiremos con los eventos. Te sugiero que te tomes unos minutos para revisar las cosas que
hemos discutido hasta ahora. No es necesario que repases todos los posts, solo trata de hacer un poco de memoria:
¿recuerdas los roles de Scrum? ¿Qué es un Sprint? ¿Cómo y cuándo se planifica?… Al final del post encontrarás un
resumen con todas las lecciones.

EVENTOS SCRUM: EL SCRUM DIARIO

Tal y como te dije en la última lección, hoy empezaremos a ver los eventos, también conocidos como rituales, a
través de los que se desarrolla scrum. En total son cinco eventos, sobre algunos ya hemos hablado a lo largo de este
curso, el resto los veremos en las siguientes lecciones:

1.- El sprint

2.- La Planificación del sprint

3.- El Scrum Diario

4.- La Revisión del sprint

5.- La Retrospectiva del sprint

Todos y cada uno de estos rituales ocurren durante el sprint, que como recordaras en como denominamos a las
iteraciones en scrum.
Cada uno de estos rituales está diseñado para permitir la transparencia, la inspección, la regularidad y la adaptación.
En scrum somos partidarios de utilizar estas reuniones predefinidas con objetivos fijos y duraciones máximas (time
box), en lugar de reuniones ad-hoc, que muy probablemente nos harán perder tiempo.

El Scrum Diaro

Durante el desarrollo del Sprint los miembros el Equipo de Desarrollo mantienen una serie de reuniones diarias que

se conocen como Scrum Diario. Estás reuniones tienen una duración máxima de 15 minutos, y son solo para los
desarrolladores; nadie más puede participar. Bueno, cualquiera puede “asistir” a la reunión, pero en “modo de
silencio”.

Durante el Scrum Diario los desarrolladores responde a tres preguntas:

1. ¿Qué hice desde ayer?

2. ¿Qué voy a hacer hasta mañana?
3. ¿Qué obstáculos he encontrado o podría encontrar?

Recuerde que la reunión debe hacerse en 15 minutos. Así que, ¡NO hablamos de los problemas! Discutiremos los
problemas después de la reunión, y si el problema no es técnico y no podemos resolverlo, entonces pediremos ayuda
al Scrum Máster.
EVENTOS SCRUM (II): LA RETROSPECTIVA DEL SPRINT

Con el post de hoy finalizaremos la sección dedicada a los eventos de scrum: la Retrospectiva del Scrum. ¿Recuerdas
el nombre de los otros cuatro eventos?:

1.- El sprint

2.- La Planificación del sprint

3.- El Scrum Diario

4.- La Revisión del sprint

5.- La Retrospectiva del sprint

Todos y cada uno de estos rituales ocurren durante el sprint, que como recordaras en como denominamos a las
iteraciones en scrum. Cada uno de estos rituales está diseñado para permitir la transparencia, la inspección, la
regularidad y la adaptación. Además, ¿recuerdas el concepto de time box?

La Retrospectiva del Sprint

Después de la Revisión de Sprint y justo antes del final del Sprint, se lleva a cabo una reunión cuyo objetivo es la
mejora de procesos (lecciones aprendidas), que se conoce como Retrospectiva del Sprint.

La última cosa que necesitamos hacer antes de proceder con el siguiente Sprint es invertir en nuestra propia mejora.
Siempre hay margen para mejorar, y en Scrum queremos hacerlo poco a poco en cada Sprint.

Esta última reunión se conoce cómo Retrospectiva del Sprint, y tiene una duración de 3 horas para Sprints de un
mes. Es proporcionalmente más corta para Sprints más cortos.

Durante esta reunión planeamos una pequeña mejora que llevaremos a cabo durante el próximo Sprint. Nos
limitamos a una pequeña mejora para ser realistas. Es una buena idea definirla de manera clara y medible, para
comprobar si logramos aplicarla.

En Scrum la regla es que debemos buscar constantemente formas de mejorar, no importa lo pequeña que sea la
mejora, pero debe haber una mejora. Esta reunión es una oportunidad formal para generar mejoras, aunque no
debemos limitarnos ni esperar a los resultados de esta reunión; debemos buscar y aplicar mejoras
constantemente.
Ten en cuenta que la Retrospectiva del Sprint gira únicamente en torno a la mejora del proceso, y la forma en que
estamos trabajando; no trata sobre la solución o el producto que estamos desarrollando. Evidentemente en Scrum
también hay lugar para mejorar la solución que estamos desarrollando, pero este no es el adecuado.

Con este post hemos terminado de explorar los eventos scrum. A partir de ahora exploraremos los artefactos; ¿sabes
a que me refiero por artefacto?

ARTEFACTOS SCRUM (I)

En scrum nos referimos a los Artefactos como a los resultados, o productos, de las actividades de gestión. Estos
productos están diseñados para aumentar la transparencia de la información relativa a la entrega del proyecto, y
propiciar oportunidades para la inspección y adaptación del mismo.

Según la guía Oficial de [Link] hay seis artefactos:

1. El Backlog de Producto

2. El Backlog del Sprint

3. Incremento

4. La definición de “Completo”

5. El monitoreo del progreso hacia la meta

6. El monitoreo del progreso hacia el Sprint

¿Cómo funcionan los artefactos?

El funcionamiento general de Scrum consiste en desarrollar por sprints los elementos que seleccionados del Backlog
de Producto. El Backlog de Producto es cómo una lista de las características (elementos) del producto, escogemos
un número de “artículos”, empezando siempre por la parte de arriba, para completar en cada Sprint. Finalmente
realizamos tantos sprints como sea necesario hasta que el proyecto termina.

De manera muy general el proceso de Scrum a través de sus artefactos puede describirse de la siguiente manera:

1.- El Backlog de Producto se emplea para determinar el alcance del Producto, o solución a desarrollar.

2.- En cada Sprint se seleccionan una serie de elementos (características) del Backlog del Producto a desarrollar,
dando lugar al Backlog del Sprint.
3.- Es fundamental monitorear el avance del Sprint y del Proyecto, en general. Para ello, podemos empelar gráficas
de avance o de “quemado”.

4.- La solución final va construyéndose de forma iterativa (en cada sprint) e incremental (añadiéndose
funcionalidades potencialmente entregables sucesivamente en cada sprint).

5.- Las sucesivas iteraciones permite una interactuación con el cliente que genera un feedback fundamente para
continuar desarrollando la solución

ARTEFACTOS SCRUM (II)

En nuestro última lección empezamos a estudiar los Artefactos de scrum, y vimos cómo se desarrolló scrum a través
de estos. Por cierto, ¿recuerda a que nos referimos en scrum por artefacto? En esta lección repasaremos a grandes
rasgos cada uno de los seis artefactos. ¡Comencemos!

Los Artefactos de scrum

Los artefactos a los que se refiere La Guia de Scrum de [Link] son seis:

1. El Backlog de Producto: una lista ordenada de todos los elementos que podría necesitar el producto final,
conocidos como historias o historias de usuario. Todos los elementos que componen el Backlog de Producto
se escriben en un lenguaje sencillo y no técnico, que permite que sean comprensibles por todos los
interesados. El Backlog de Producto es dinámico, cambia y mejora continuamente: nunca está completo.

2. El Backlog del Sprint: se compone de los artículos seleccionados (historias) del Backlog del Producto que se
entregarán a través de un Sprint, junto con el objetivo del Sprint y los planes para la entrega de los artículos
y la realización del objetivo del Sprint. El Backlog del Sprint se crea durante el evento de Planificación del
Sprint, y una vez comienza el sprint se “congelan”. ¿Qué quiere decir esto? Que no pueden añadirse ni
eliminarse artículos (historias de usuario) del Backlog del Sprint durante el Sprint.
 3. Incremento: un incremento es la suma de todos los elementos del Backlog de producto completados al
finalizar un Sprint. Recuerda que cada incremento debe esta “completo” (al 100%) y ser entregable. El Dueño
del Producto puede o no puede entregar un cierto incremento, pero este debe ser potencialmente
entregable

4. La definición de “Completo”: es la comprensión compartida entre todos los miembros del Equipo de
Desarrollo de lo que significa que un elemento de trabajo se considere “completo”, 100% realizado.

5. Monitoreo del progreso hacia la meta: se refiere a la medición de los resultados y las previsiones para todo el
proyecto

6. Monitoreo del progreso hacia el Sprint: es la medición de los resultados y las previsiones para un solo Sprint

Los puntos 5 y 6 pueden parecer más actividades que artefactos, pero La Guía de Scrum los considera como tales, y
nosotros haremos lo mismo. Tal vez es más fácil entenderlos como artefactos si consideramos como los auténticos
artefactos los productos generados por estas actividades (información de seguimiento, graficas de seguimiento, etc.)

Con este post deberíamos haber terminado de explorar los artefactos, pero por su importancia “la definición de
completo” es lo merece que le dediquemos una lección. La próxima lección profundizaremos en la definición de
hecho, o “Definition of Done”, como se conoce en inglés.