Introducción A La Gestión de Proyectos Con Metodología Ágil SCRUM

1.
1 Presentación y objetivos
Presentación y objetivos
Los objetivos de este módulo son:
Conocer los valores del enfoque ágil.
Aplicar los principios del enfoque ágil.
Diferenciar entre manifiesto ágil y valores o

principios ágiles.
TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

Bienvenido y bienvenida a este nuevo módulo. Hasta ahora sabemos que los enfoques ágiles se basan en un ciclo de
desarrollo ágil o adaptativo.
Sin embargo, al hablar de gestión ágil no basta con emplear un ciclo de desarrollo ágil, la agilidad consiste en unos valores
y unos principios.
En este capítulo examinaremos en detalle dichos valores y principios ágiles, pero antes, veamos los objetivos de este
módulo:
2.1 El manifiesto ágil

El Manifiesto Ágil
Estamos descubriendo formas mejores de
desarrollar software tanto por nuestra propia INDIVIDUOS E INTERACCIONES
experiencia como ayudando a terceros. A través
de este trabajo hemos aprendido a valorar: Sobre procesos y herramientas.
SOFTWARE FUNCIONANDO
En lugar de documentación extensiva.
COLABORACIÓN EN EL CLIENTE
Sobre negociación contractual.
RESPUESTA ANTE EL CAMBIO

Sobre seguir un plan.
Importante
La idea en torno al concepto de Agilidad se formalizó en el 2001, cuando un grupo de expertos en procesos para el
desarrollo de software redacto y firmo un manifiesto conocido como el Manifiesto Ágil.
Este breve manifiesto explica de la manera más sencilla la idea de Agilidad. Debemos recordar que aunque la idea de
Agilidad esta mayoritariamente ligada al desarrollo de proyectos de software, no es ni mucho menos de exclusiva
aplicación a este sector. Los valores del Manifiesto Ágil son aplicables prácticamente a cualquier ámbito, producto o
servicio.
El significado del Manifiesto Ágil. Valor 1: Individuos e interacciones

sobre procesos y herramientas
Para facilitar la comunicación, los sistemas de
trabajo ágiles establecen ciclos frecuentes de Respetar el valor de cada persona.
inspección y adaptación, y confían en una
comunicación cara a cara. Aunque estas medidas
son necesarias, no son suficientes, y se requiere
además de otros comportamientos clave para que Veracidad en cada comunicación.
los ciclos de inspección y adaptación funcionen
correctamente. Algunos ejemplos son:
Transparencia de todos los datos, acciones y

decisiones.
Confianza en que cada persona respaldará al

equipo.
Compromiso con el equipo y los objetivos del

equipo.
Importante
En definitiva se trata de prestar la debida atención a la parte humana de las organizaciones. Es necesario que
comprendamos y seamos conscientes de la prioridad que tiene el aspecto humano sobre los procesos y las herramientas, y
de que si queremos mejorar, debemos comenzar por los individuos y sus interacciones.
El significado del Manifiesto Ágil. Valor 2: Software funcionando sobre

documentación extensiva
Respecto a este valor es necesario aclarar dos cosas: Un “producto o servicio” que funciona es
una de las grandes diferencias que
aporta el desarrollo Ágil. Todos los
sistemas Ágiles se basan en la entrega
al cliente de partes pequeñas de
“producto o servicio” que funciona, a
intervalos fijos. Se conoce como entrega
“incremental”.
Para lograrlo es fundamental que el
equipo de trabajo establezca una
1. La filosofía Ágil tiene 2. ¿Por qué es necesario definición común de lo que entienden por
“que funciona”, lo que se conoce en
aplicación más allá del ámbito elaborar tanta documentación scrum como “definición de completo” o
del software. al inicio de cualquier proyecto Definition of Done (DoD) en inglés.
Por ello, cuando leemos este valor lo antes de empezar a trabajar?
hacemos de un modo más amplio, Bien, realmente es una cuestión de
sustituyendo “software” por: producto, comunicación. Es decir, básicamente
servicio o solución. necesitamos la documentación para
comunicarnos con el cliente y crear una
base sobre la que desarrollar una
solución que satisfaga sus necesidades.
Importante
¿Significa esto que en los proyectos ágiles no existe ningún tipo de documentación? No, contrariamente a lo que muchas
personas piensan, en los enfoques Ágiles también es necesaria documentación, pero se hace de otra manera. Por ejemplo,
son necesarios los manuales de operación, que si bien pueden ser documentos, se prefieren en otro formato como vídeos o
similar. También necesitamos documentar gran cantidad de información de seguimiento para los sistemas de gestión de la
configuración, actividad administrativa y técnica relacionada con el cambio controlado de la configuración del proyecto a lo
largo de toda su vida.
El significado del Manifiesto Ágil. Valor 3: Colaboración con cliente sobre

negociación contractual
RESOLUCIÓN
El propósito de un proyecto no es entregar un producto o
servicio, sino resolver un problema o necesidad, y por ello es
tan fundamental la participación del cliente.
Los autores del Manifiesto Ágil sabían de qué estaban

hablando cuando enfatizaron que conseguir la implicación del
cliente en el proceso de desarrollo de “producto o servicio” es
esencial para el éxito del proyecto.
REPRESENTANTE
Todos los enfoques de trabajo Ágiles fomentan este valor ya
que incluyen un representante del cliente que trabaja mano a
mano con el equipo de desarrollo. Por ejemplo, en scrum es el
Propietario o Dueño del Producto quien representa los
intereses del cliente.
ADAPTACIÓN
Un entorno adaptable no tiene sentido sin adaptación, y la
base para la adaptación es la colaboración con cliente. En un
entorno Ágil no dependemos de un diseño inicial y estamos
abiertos a cualquier cambio del cliente, en cualquier momento.
Los cambios de última hora no implican una gran cantidad de
trabajo que haya que volver a hacer, porque no tenemos un
diseño inicial que modificar en cada cambio.
El significado del Manifiesto Ágil. Valor 4: Respuesta ante el cambio

sobre seguir un plan
Para evitar esto, los enfoques Ágiles Además, el enfoque Ágil está diseñado Por todo ello podemos decir que los
buscan obtener los comentarios para entregar siempre primero el mayor sistemas Ágiles están basados en la
(feedback) del cliente durante el proyecto valor comercial. Dado que el 80 por premisa de que, para tener éxito, se debe
para poder incorporar la nueva ciento del valor representa el 20 por planificar para cambiar; por eso
información a medida que se desarrolla ciento de las características, los establecen procesos, como revisiones y
el producto. Todos los sistemas de proyectos ágiles bien realizados tienden retrospectivas, diseñados
trabajo Ágiles tienen procesos a finalizar temprano, mientras que la específicamente para comprobar y variar
integrados para cambiar sus planes a mayoría de los proyectos tradicionales las prioridades con regularidad en
intervalos regulares en función de los finalizan tarde. Como resultado, los función de los comentarios del cliente y el
comentarios del cliente o su clientes están más satisfechos y los valor comercial.
representante. desarrolladores de software disfrutan
más de su trabajo. Cómo sabemos que el cliente no sabe lo
que quiere no planeamos por anticipado
el proyecto en su totalidad. En lugar de
seguir forzosamente un plan empleamos
un ciclo de vida adaptativo que se basa
en la respuesta al cambio.

Aunque pueda parecerlo, la Agilidad no es algo tan nuevo, ya que comenzó a desarrollarse en los años 50. Por aquel
entonces era considerado por la mayoría como algo extraño, incluso anárquico; el método tradicional, predictivo, era la
manera habitual de trabajar.
Progresivamente el concepto de Agilidad se fue haciendo cada vez más conocido, y su método de trabajo fue
extendiéndose.
La esencia de toda organización son los individuos que la forman. Por ello, para su óptimo funcionamiento dichas
organizaciones necesitan que estos se comuniquen de manera eficiente y eficaz.
Sin embargo, aún a día de hoy es habitual en muchas organizaciones considerar a los miembros de un equipo de trabajo
simplemente como piezas de una “máquina” que pueden ser fácilmente sustituidas, sin que el trabajo pueda resentirse por
ello.
Todo el interés generado alrededor de la idea de la Agilidad es consecuencia del aumento que se ha experimentado en la
tasa de éxito de los proyectos de software durante los últimos años.
Dicho éxito es principalmente resultado de las entregas frecuentes, que permite a los clientes proporcionar comentarios
(feedback) sobre el software que funciona parcialmente y que se entrega a intervalos regulares, para ajustar la solución en
la dirección correcta.
En el ámbito del desarrollo de software, la “Ley de Humphrey” establece que los clientes nunca saben lo que desean hasta
que ven el software funcionando.
Pero ¿qué ocurre si seguimos un ciclo de vida predictivo? Entonces, los clientes no ven el software que funciona hasta el
final del proyecto, y entonces ya es demasiado tarde para incorporar sus comentarios y realizar cualquier cambio. O
hacerlo será muy costoso dado que implicará deshacer, o rehacer un trabajo ya realizado.
2.2 Preguntas de autoevaluación

Preguntas de autoevaluación
A continuación, debes realizar las siguientes preguntas de autoevaluación:
2.3 El manifiesto ágil

Los 12 Principios Ágiles
PRINCIPIO 1
Principio 1: Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continuada de software con
valor.
El objetivo es lograr un cliente satisfecho, lo que contribuirá a

que tengamos más clientes en el futuro. ¿Pero cómo?
Proporcionando a los clientes la solución que realmente
quieren, aunque ya sabemos que esto no es posible sin ser
adaptativos, y sin entregas tempranas y continuas de software
funcionando. Esta flexibilidad necesaria, aunque es posible en
los ciclos de vida predictivos, resulta demasiado cara.
PRINCIPIO 2
Principio 2: Aceptamos que los requisitos cambien, incluso en
etapas tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al cliente.
Empleando un ciclo de vida adaptable estamos abiertos al

cambio ya que no existe ningún diseño inicial al que debamos
ceñirnos cada vez que queramos realizar un cambio. Además,
cualquier petición de cambio nos hará felices, pues será un
paso más que nos permitirá acercarnos a lo que el cliente
realmente desea.
PRINCIPIO 3
Principio 3: Entregamos software funcional frecuentemente,
entre dos semanas y un mes, con preferencia por periodos de
tiempo lo más corto posibles.
El cliente tendrá una mejor comprensión de lo que quiere

cuando vea el software en funcionamiento. Nosotros,
recibiremos información (feedback) que podremos utilizar para
adaptarlo.
Hay distintos marcos Agiles que emplean diferentes

iteraciones. Por ejemplo, en Scrum no están permitidas las
iteraciones de más de un mes, mientras que otros marcos
Ágiles aceptan iteraciones más largas. Siempre y cuando sean
suficientes para crear un incremento significativo (software en
funcionamiento) preferiremos las iteraciones más cortas.
PRINCIPIO 4
Principio 4: Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo el proyecto.
En un entorno predictivo la participación de la empresa/cliente

se limita generalmente a especificar los requisitos al inicio, y de
nuevo al final a aprobar la solución final. Sin embargo, en un
entorno adaptable necesitamos que la empresa/cliente trabaje
a diario con los desarrolladores, ya que sus inputs son la fuente
de la adaptabilidad.
PRINCIPIO 5
Principio 5: Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que necesitan,
y confiarles la ejecución del trabajo.
Un entorno ágil se basa en un equipo multifuncional y auto-

organizado que se auto-gestiona y encuentra su camino en
lugar de recibir órdenes. Esta es una gran responsabilidad para
los desarrolladores, y no todos son capaces de trabajar de esta
manera. Cuando tenemos los miembros de equipo adecuados,
debemos confiar en ellos, motivarles y darles la posibilidad de
permitir la agilidad.
PRINCIPIO 6
Principio 6: El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus miembros es la
conversación cara a cara.
En un entorno tradicional los miembros del equipo se centran

en sus actividades de especialista, incluso podrían estar
ubicados en lugares diferentes, por lo general en sus
respectivos departamentos dentro de la organización. A veces
ni siquiera podemos llamarlos “equipo”; no son más que una
serie de personas que trabajan en el mismo proyecto. Por el
contrario en un entorno Ágil necesitamos un verdadero equipo,
en el que los miembros deben estar co-localizados para poder
comunicarse continuamente. Nada puede sustituir una
conversación cara a cara.
Aunque ciertamente es una gran ventaja contar con equipos

co-localizados, esto no significa que no podamos tener un
proyecto Ágil con un equipo “distribuido”. En estos casos sin
embargo, necesitaremos aprovechar al máximo la tecnología
para reducir al mínimo la falta comunicación cara a cara, y
asumir un nivel de productividad inferior al final del día.
PRINCIPIO 7
Principio 7: El software funcionando es la principal medida
progreso.
¡Un producto acabado al 99 % es un producto que esta 0 %

“completo” o “hecho”. Pero entonces, ¿cómo conocer el
progreso de nuestro trabajo sin entrar en detalles técnicos?
Recuerda que estamos interesados en mantener al cliente
involucrado en el proyecto, y para ello debemos tratar de evitar
los detalles técnicos, y mantener un lenguaje sencillo, dado que
en muchas ocasiones se tratará de un cliente “no técnico”. La
solución pasa por diferenciar los artículos del Backlog de
Producto únicamente en dos categorías: "completo" y “no
completo”. Esta simple distinción es suficiente ya que los
elementos del Backlog son lo bastante pequeños para mostrar
nuestro progreso simplemente diferenciando entre completo/no
completo.
PRINCIPIO 8
Principio 8: Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante de
forma indefinida.
Trabajar no es el objetivo; alcanzar el producto es el objetivo.

Podría parecernos que hacer horas extras puede acelerar las
cosas, pero en realidad reduce los outputs disminuyendo la
productividad y aumentando los defectos. Es preferible
mantener un ritmo sostenido a lo largo del tiempo.
PRINCIPIO 9
Principio 9: La atención continua a la excelencia técnica y al
buen diseño mejoran la Agilidad.
No tener un diseño inicial no significa que no tengamos que

estar preocupados por el diseño. Los proyectos ágiles tienen
diseño, lo que ocurre es que este se realiza en cada iteración
para cada elemento del Backlog de Producto.
Debemos prestar atención a la excelencia técnica y el buen

diseño para evitar problemas; sin olvidar que el objetivo es
encontrar una solución lo "suficientemente buena" más que la
solución perfecta.
PRINCIPIO 10
Principio 10: La simplicidad, o el arte de maximizar la cantidad
de trabajo no realizado, es esencial.
Un proyecto Ágil se gestiona y entrega de manera simple. Por

ejemplo, la gestión del alcance se realice simplemente
detallando la información esencial en una tarjeta o nota
adhesiva (ficha); no son necesarios instrumentos sofisticados
para gestionar el producto. Además, hacerlo de manera
sencilla favorece la colaboración del cliente.
PRINCIPIO 11
Principio 11: Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.
Por lo general la gente trabaja mejor cuando se siente

respetada y están autorizados para decidir cómo funcionar.
Además, es mejor que todos los miembros del equipo sean
responsables de todo el proyecto. Por ejemplo, sí los
diseñadores no funcionan de manera aislada, entonces
estarán constantemente en contacto con los programadores, y
pueden utilizar la información que se genera para mejorar los
diseños y hacerlos más prácticos.
PRINCIPIO 12
Principio 12: A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.
¡Creemos que siempre hay margen de mejora, sin importar lo

bien que estemos haciendo las cosas! Por ello necesitamos
tiempo para investigar la iteración anterior y encontrar la
manera de implementar mejoras, por muy pequeñas que sean.
El objetivo es mejorar un poco cada iteración.
Importante
El Backlog de Producto, también conocido como Pila del Producto es una lista de objetivos/requisitos priorizada que
representa la visión y expectativas del cliente respecto a los objetivos y entregas del producto o proyecto. Se emplean en
los entornos ágiles para gestionar el alcance del proyecto. Veremos más al respecto en la sección dedicada a Scrum.

Además de los cuatro valores del Manifiesto Ágil, existen doce principios que completan el Manifiesto Ágil y que describen
la idea de Agilidad con mayor detalle:

3.1 Resumen y autoevaluación

Resumen y autoevaluación
La esencia de toda organización son los

individuos que la forman.
Un entorno adaptable no tiene sentido sin
adaptación, y la base para la adaptación es la
colaboración con cliente.
La mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continuada de
software con valor.
El equipo debe reflexionar de manera constante
sobre cómo ser más efectivo para ajustar y
perfeccionar su comportamiento en
consecuencia.

Casi hemos finalizado el estudio de este módulo, pero antes repasa el resumen del contenido que aparece en pantalla.
3.2 Cierre
¡Enhorabuena! Has finalizado esta unidad sobre Gestión Ágil con Scrum.
1.1 Presentación y objetivos
Definir qué es SCRUM en el ámbito de la gestión

de proyectos.
Comprender el funcionamiento del SCRUM en

base a sus cuatro elementos.
Aplicar el SCRUM más allá del desarrollo de

software.
Conocer qué es un marco de gestión.

¡Bienvenido a este módulo! Aquí veremos las principales características de SCRUM, pero antes veamos los objetivos de
este módulo:
2.1 Qué es SCRUM

Que es SCRUM
Es un marco de gestión que permite hacer frente a problemas complejos de
manera adaptativa, contribuyendo al desarrollo de productos/soluciones del
más alto valor para los clientes. En este sentido más amplio SCRUM es:
Un acelerador de negocios.
Un sistema de gestión del riesgo integrado.
Y una herramienta de gestión de equipos.
Marco de trabajo SCRUM

A continuación vamos a ver las reglas necesarias, y sus principales
componentes:
ROLES
Dueño del producto, SCRUM máster y equipo de desarrollo.
EVENTOS
Sprint, planificación del sprint, SCRUM diario, demostración del sprint y
retrospectiva del sprint.
ARTEFACTOS
Backlog del producto, backlog del sprint, definición de “hecho” (DoD),
incremento y seguimiento.

SCRUM es ampliamente conocido como un marco de gestión Ágil para el desarrollo productos de software, pero es mucho
más que eso.
SCRUM se basa en tres elementos: eventos, roles y artefactos, que deben ser aplicados en conjunto. Cada uno estos
elementos sirve para un propósito específico, y cada uno es esencial para el éxito de SCRUM. Además, es necesario un
conjunto de reglas para aglutinar y armonizar todos los elementos.
2.2 Cómo funciona

Cómo funciona
Una vez establecido el Equipo
SCRUM, es necesario definir el 1. PARTIMOS DEL BACKLOG DE PRODUCTO
alcance del producto, y para ello se
emplea el Backlog de Producto. Este Que es responsabilidad exclusiva del Dueño del Producto.
es el principal artefacto de cualquier
enfoque Ágil, y es como una lista de
las características o funcionalidades
que componen el producto.
2. EL EQUIPO DE DESARROLLO ESCOGE UN NÚMERO DE

“ARTÍCULOS”
En función su capacidad de trabajo prevista.
3. LOS ARTÍCULOS SELECCIONADOS DEL BACKLOG DE

PRODUCTO SE COMPLETARÁN DURANTE EL SPRINT
Al elegirlos empezaremos siempre por la parte de arriba.
4. REALIZAMOS TANTOS SPRINTS COMO SEA NECESARIO

Hasta que el proyecto termine.
Fin del Proyecto

El fin del proyecto puede deberse a:
1. Todos los “artículos” del 2. El cliente decide que con la 3. Por la razón que sea
Backlog de Producto última iteración realizada es Como por ejemplo que no hay mas fondo
Se han completado. suficiente para el proyecto
Y no es necesario invertir más tiempo ni
dinero en añadir nuevas
“funcionalidades”, que se desarrollarían
en futuras iteraciones.
SCRUM paso a paso

El primer paso es establecer el equipo SCRUM, y el último la propuesta de nuevos backlogs atendiendo a los feedbacks recibidos.
En la siguiente pantalla veremos cada uno de los apartados de manera más detallada.
SCRUM paso a paso. Desglose
EQUIPO SCRUM
1. Se establece el Equipo SCRUM. En SCRUM existen tres roles:
El Dueño del Producto; es la persona responsable de crear y

mantener el Backlog del Producto, para lo que se requiere una
comunicación y colaboración constante con el cliente.
El SCRUM Máster; es la persona encargada de asegurar que
el marco SCRUM se sigue completa y correctamente, lo qué
requiere entrenamiento, formación y solucionar los problemas
que vayan surgiendo.
El Equipo de Desarrollo; es el grupo de técnicos encargado
de desarrollar la solución. Sus principales características es que
son auto-organizados y multifuncionales.
BACKLOG DEL PRODUCTO

2.- Se crea el Backlog de Producto para determinar el alcance del Producto,
o solución a desarrollar.
BACKLOG DE SPRINT
3.- En cada Sprint se seleccionan una serie de elementos (características)
del Backlog del Producto a desarrollar, dando lugar al Backlog del Sprint.
EVENTOS
4.- El sprint, ese periodo de tiempo durante el que se desarrollan los
elementos del Backlog del Sprint, tiene lugar en base a los eventos SCRUM.
Estos eventos se repiten en cada sprint:
La Planificación del Sprint, una breve reunión en la que se

seleccionan las historias de usuario (también historias) del
Backlog de Producto y se crea el Backlog del Sprint. A partir de
este momento, comenzamos a trabajar en las historias
seleccionadas hasta el último día del sprint.
La Reunión Diaria (SCRUM Diario); durante todo el sprint se
llevan a cabo unas breves reuniones diarias para examinar
cómo nos fue el día anterior, planear el presente día y hablar de
los problemas que han surgido y dificultan el trabajo del
equipo. El tiempo máximo es de 15 minutos.
La Revisión del Sprint; para demostrar el incremento al
cliente y recibir feedback.
La Retrospectiva del Sprint, para examinar el sprint y
planear las mejoras que puedan llevarse a cabo en el próximo
sprint.
SOLUCIÓN
5.- 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).
FEEDBACK
6.- Las sucesivas iteraciones permiten una interactuación con el cliente que
genera un feedback fundamental para continuar desarrollando la solución.
NUEVOS BACKLOGS DE PRODUCTO

7.- El feedback recibido es el que determina el Backlog de Producto, que
emplearemos para diseñar el siguiente Backlog del Sprint.
Básicamente un proyecto SCRUM se compone de varias iteraciones, que en SCRUM se conocen como “sprints”. Dentro de
cada uno de los sprints tienen lugar una serie de eventos en los que participan unos roles, que tienen atribuidas unas
responsabilidades definidas, y que emplean unos artefactos (productos de gestión) para controlar el desarrollo del
producto o servicio.
A continuación, vamos a ver un esquema de los pasos a seguir en la realización de un SCRUM.
2.3 Cuando aplicar SCRUM

Cuando aplicar SCRUM
LA NOVEDAD
Es conveniente usar un enfoque Ágil, y SCRUM, cuando estamos haciendo
algo que es nuevo, o al menos nuevo para el equipo que lo está llevando a
cabo. Es decir, si el objeto del proyecto es desarrollar un proyecto o servicio
que el equipo ha hecho antes una y otra vez, entonces el equipo
probablemente no necesita trabajar con un enfoque Ágil.
Por ejemplo, si día tras día fabricamos el mismo coche, aprenderemos todos
los matices de la fabricación de dicho coche. En ese caso, no es necesario
un enfoque Ágil: la novedad de la situación es baja. Es decir, la novedad por
sí sola no determina que debamos usar un enfoque Ágil, es necesario algo
más.
LA COMPLEJIDAD
Además de la novedad para emplear SCRUM el proyecto o servicio a
desarrollar debe de implicar cierto grado de complejidad. ¿Qué significa
complejo?
Cuando nos enfrentamos a problemas complejos los resultados se vuelven

más impredecibles. En los entornos complejos no existen ni mejores ni
buenas prácticas que nos ofrezcan garantías para resolver la situación;
simplemente no sabemos con anticipación si una determinada solución va a
funcionar. La manera de actuar es elaborar una hipótesis, ponerla en
práctica, examinar los resultados y actuar en consecuencia (adaptarse).
LOS PLAZOS AGRESIVOS

El tercero de los requisitos que determinan la idoneidad para gestionar un
proyecto con SCRUM es la urgencia. Los timebox y las iteraciones que
empleamos cuándo trabajamos con un enfoque Ágil, están diseñados para
mantener el enfoque en el proyecto y la intensidad de trabajo. Lo cierto es
que si no existe la necesidad de cumplir con unos plazos, ni las iteraciones
ni los timebox son necesarios.
Importante
En conclusión, un enfoque Ágil es apropiado cuándo debemos desarrollar proyectos urgentes, con cierta complejidad, y de
novedad significativa para el equipo.

Hay tres circunstancias que indican cuando es conveniente usar SCRUM para gestionar la entrega de una solución.

2.5 Ejemplo
Ejemplo
Automatismos para el Hogar S.L. es un fabricante de La dirección de Automatizaciones S.L. está decidida a
sistemas automatizados para viviendas familiares: implementar un giro en el desarrollo de nuevos productos de
calefacción, refrigeración, electricidad, etc. Uno de los nuevos la organización para hacer frente a la competencia: necesitan
productos que están desarrollando es un sistema de hacerlo más rápido y mejor. Conocedores de las ventajas que
domótica qué permita controlar desde el teléfono móvil del reportan los enfoques Agiles, han decidió probar con la
usuario todos los aspectos de la casa: desde abrir la puerta implementación de un nuevo sistema de gestión de desarrollo
principal hasta controlar los costes de calefacción, encender productos y servicios conocido como SCRUM.
la luz, etc.
A partir de este sencillo ejemplo te voy a mostrar como
funciona SCRUM.

Uno de los objetivos de este breve curso de introducción a la gestión Ágil es mostrarte como emplear SCRUM para
gestionar la entrega de un producto. Recuerda: la Agilidad son un conjunto de principios y valores, y para llevarlos a la
práctica podemos emplear diferentes técnicas o metodologías.
En este curso nos centramos en SCRUM, y para ello exploraremos el funcionamiento de SCRUM apoyándonos en un
sencillo ejemplo que te presentamos a continuación.

Es conveniente usar SCRUM cuando estamos
haciendo algo que es nuevo, o al menos nuevo
para el equipo que lo está llevando a cabo.
En los entornos complejos no existen ni mejores ni
buenas prácticas .La manera de actuar es
elaborar una hipótesis, ponerla en práctica,
examinar los resultados y actuar en consecuencia
(adaptarse).
El primer paso es establecer el equipo SCRUM.

3.2 Cierre

¡Enhorabuena! Has finalizado esta unidad sobre Gestión Ágil con SCRUM.
Conocer los tres roles que componen el equipo

scrum.
Conocer las diferentes características de cada

uno de ellos.
Crear consciencia sobre las responsabilidades de

los distintos componentes.

¡Bienvenido! En este módulo veremos los distintos roles de un equipo scrum, pero antes, veamos los objetivos de este
módulo:
2.1 Equipo de Scrum (I)

Equipo de Scrum
El término “Equipo Scrum” se refiere a todos los miembros del
equipo del proyecto: a cada uno de los miembros internos del
proyecto. Por lo general los Miembros del Scrum llevan a cabo
solo uno de los roles: Dueño del Producto, Scrum Máster o
Miembro del Equipo de Desarrollo. Es posible asignar a una
persona más de un rol, pero no es recomendable.
El Equipo Scrum es parte de la organización que ejecuta el

proyecto, para sí o como contratista para un cliente externo.
Importante
Existen otras personas que pueden estar implicadas en el proyecto pero no se consideran “internas” al proyecto y SCRUM
no dice mucho respecto a ellos. Sin embargo, es necesario que estas personas mantengan cierto comportamiento para que
un proyecto Scrum tenga éxito (por ejemplo, deben respetar el funcionamiento de un proyecto Scrum).
Características Scrum
El Equipo Scrum tiene dos características esenciales:
Auto-gestionado Multifuncional
El Equipo Scrum gestiona sus propios esfuerzos en vez de El Equipo Scrum tiene los conocimientos y capacidades
estar gestionados o dirigidos por otros. En los métodos necesarias para completar el trabajo sin ayudas de fuera del
tradicionales, las actividades de gestión y dirección se equipo.
separan y centralizan; un subconjunto del equipo de proyecto
es responsable de la gestión de proyectos y otro de las
actividades de especialista (ejecución). Sin embargo en
Scrum, las tareas de gestión y las actividades de especialista
no se separan.
El Dueño del Producto

Este rol pertenece a una única persona. Puede
existir una Comisión que gestione las
responsabilidades de este rol, pero en tal caso
debe haber una persona que los represente, y EL DUEÑO DEL PRODUCTO NO NECESITA TENER
dicha persona será el Dueño del Producto. CONOCIMIENTO DEL ÁREA DE APLICACIÓN DEL
PROYECTO
Se concentra en los aspectos del negocio. Por ejemplo, en proyectos de
desarrollo de software no es necesario que el Dueño del Producto sea un
desarrollador, únicamente necesitaría saber un poco sobre desarrollo, pero
mucho sobre cómo opera el negocio.
EL DUEÑO DEL PRODUCTO ES RESPONSABLE DEL

BACKLOG DE PRODUCTO
El Backlog de Producto es una lista priorizada de elementos (generalmente
en la forma de historias de usuario) que el cliente espera del proyecto; es la
principal herramienta de planificación en Scrum. También es el responsable
de hacer que cada elemento (historia del usuario) sea fácilmente entendible
para el equipo Scrum y el resto de partes interesadas.
EL DUEÑO DEL PRODUCTO DEBE COMUNICARSE

CON EL CLIENTE (INDISCUTIBLE FACTOR DE ÉXITO
EN CUALQUIER MÉTODO DE GESTIÓN DE
PROYECTOS)
Y utilizar la información para mantener actualizado el Backlog del Producto.
También es responsable de monitorear el desarrollo del proyecto, estimar la
fecha de finalización y hacer esta información transparente a todas las
partes interesadas.
EL DUEÑO DEL PRODUCTO CONOCE EL NEGOCIO Y
POR ELLO PUEDE CLASIFICAR CADA ELEMENTO
DEL BACKLOG DE PRODUCTO
En función del retorno de inversión y/o cualquier otro factor que encuentre
conveniente para el negocio. Los artículos o elementos del Backlog se
ordenan mayor a menor en función de su valor de negocio (para abreviar
sólo valor); cuanto más arriba estén en el Backlog de Producto, más pronto
se desarrollarán por el Equipo de Desarrollo.
PARA QUE EL PROYECTO TENGA POSIBILIDADES DE

ÉXITO TODA LA ORGANIZACIÓN DEBE RESPETAR
LAS DECISIONES DEL DUEÑO DEL PRODUCTO.
Nadie, ni siquiera el director general, debería permitir que se invaliden
dichas decisiones, y nadie debe decirle al equipo de desarrollo que
desarrollar y entregar, salvo el Dueño del Producto, que establece y ordena
los elementos del Backlog del Producto. Las decisiones del Dueño del
Producto podrían estar influenciadas por otros, pero es él quien tendrá la
última palabra.
EL DUEÑO DEL PRODUCTO PUEDE DELEGAR PARTE

DE SUS RESPONSABILIDADES
Como la preparación de la lista de artículos del Backlog de Producto en el
equipo de desarrollo, pero continuará siendo su responsabilidad.
El Scrum Máster
Además de asegurarse de que el Equipo de Eliminar los impedimentos que el Equipo de
Desarrollo comprende y utiliza Scrum
correctamente, el Scrum Máster es el responsable
Desarrollo encuentra en la implementación de
de: Scrum.
Facilitar los eventos Scrum (reuniones).
Entrenar al equipo en el marco Scrum.

Hay tres roles en un proyecto SCRUM, ni más ni menos. No podemos establecer ningún otro rol ya que pondría en peligro
la unidad del equipo, lo que es incompatible con la filosofía de SCRUM. Un equipo Scrum consiste en las tres funciones
siguientes:
El cliente (sea interno o externo) también deberá entender y adoptar el marco Scrum, dado que tanto la manera de
relacionarse con el equipo, como la manera en que el proyecto se entrega varían en Scrum.
Cada proyecto necesita de una persona orientada al negocio, destinada a maximizar el valor comercial del producto y el
trabajo del equipo de desarrollo. En Scrum esta persona es el Dueño del Producto.
El Dueño del Producto, como el resto de roles, provienen de la organización ejecutante, en lugar de la del cliente. Pudiera
ser que el cliente asigne a una o más personas para administrar o controlar la ejecución del producto, pero no se llamarán
Dueño del Producto.
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. El Scrum Máster es un puesto de
gestión que gestiona el proceso Scrum, no el Equipo Scrum. El Scrum Máster es un “líder servicial” para el Equipo Scrum,
un líder que está al servicio del Equipo Scrum.
2.2 Equipo de Scrum (II)

Características del Scrum Máster
COLABORAR
El Scrum Máster también colabora con el Dueño del Producto, por ejemplo
ayudando y asesorando en encontrar nuevas técnicas, en la comunicación y
en la facilitación de las reuniones.
AYUDAR
Las responsabilidades de Scrum Máster no se limitan al Equipo Scrum.
También son responsables de ayudar a aquellos fuera del Equipo Scrum a
comprender la forma apropiada de relacionarse con el Equipo Scrum, con el
fin de maximizar el valor del negocio. El Scrum Máster por lo general dirige a
la organización en su esfuerzo por adoptar Scrum.
RECOMENDACIONES
Si bien una persona puede ser Scrum Máster y miembro del Equipo de
Desarrollo a la vez, no es lo recomendable. Ser el Scrum Máster de un
proyecto normal podría no ocupar 100% del tiempo de una persona; en ese
caso, la mejor solución es asignar a esa misma persona como Scrum Máster
en más de un proyecto, en lugar de hacerlo miembro del equipo de
desarrollo.
COMUNICACIONES
La mayor parte de las comunicaciones sobre el proceso Scrum, tanto
internas como externas, son responsabilidad del Scrum Máster, mientras
que la mayoría de las comunicaciones sobre el contenido del proyecto, tanto
internas como externas, son responsabilidad del Dueño del Producto. Así
pues, el Scrum Máster no se involucra en el contenido (el significado, la
estimación, el valor del negocio, etc., de las historias de usuario, o el
contenido de los incrementos).
Equipo de Desarrollo
MULTIFUNCIONAL
Un Equipo de Desarrollo debe ser multifuncional, capaz de realizar cada uno
de los elementos del Backlog de Producto de la A la Z.
AUTO-ORGANIZACIÓN
Además debe auto-organizarse, ser responsable y capaz de encontrar su
propio camino en lugar de recibir órdenes.
ALINEACIÓN
Deberá alinearse con el propósito del proyecto y no trabajar “a ciegas”.
Durante el Sprint una tarea podría asignarse a un solo miembro del equipo,
pero todo el equipo de desarrollo será responsable de esa tarea; ningún
individuo es dueño de una tarea.
INCREMENTAL
El Equipo de Desarrollo entrega el producto paso a paso, de manera
incremental: tal y como está definido en el Backlog de Producto. Siempre
trabaja enfocado en el producto.
Recomendaciones para el equipo de desarrollo

LA COMPOSICIÓN DEL EQUIPO DE DESARROLLO
No debe cambiar a menudo, y si hubiera necesidad de hacer algún cambio
en los miembros del equipo, no debería suceder durante un Sprint.
ES NECESARIO SER CONSCIENTE

De que cuando se produzca un cambio en la composición del equipo, habrá
una disminución en la productividad del equipo a corto plazo.
SCRUM ES MÁS EFICAZ

Cuando el equipo está compuesto por entre 3 y 9 miembros. En proyectos
grandes, podemos utilizar un modelo a escala con múltiples equipos de
Scrum.
Otros roles
El éxito de Scrum depende de la colaboración y del trabajo en equipo. Los
miembros del equipo de desarrollo deben estar unidos, y completamente
alineados con el objetivo del proyecto. Si les otorgamos diferentes títulos o
roles, se centrarán en su propio rol en lugar de hacerlo en el proyecto, y
podrían no prestar la suficiente atención al producto final, que es lo
necesario en los proyectos ágiles. Cada uno de los miembros del Equipo de
Desarrollo es responsable de todos y cada uno los productos que genera el
Equipo de Desarrollo, a pesar de que cada uno de ellos pudiera estar
centrado en un conjunto específico de tareas.

Los miembros del Equipo de Desarrollo, también conocido como "equipo", son especialistas de área, y responsables de
entregar los elementos del Backlog, y de la gestión de sus propios esfuerzos.
Es muy recomendable para los miembros del equipo de desarrollo trabajar a tiempo completo en un proyecto, para
mantenerse centrados y ágiles.
Podríamos caer la tentación de dar a los miembros del Equipo de Desarrollo títulos más específicos como el de diseñador,
probador, inspector de calidad y jefe de equipo; ¡Scrum NO lo permite! Todos los miembros deben tener el mismo rol y el
mismo título: Miembro del Equipo de Desarrollo.
2.3 ¿Quién es el director de proyecto?

¿Quién es el director de proyecto?
Algunas personas piensan que el Scrum Quienes piensen que el Dueño del Además, la gestión del marco que es
Máster es el equivalente a un director de Producto es el equivalente a un director también una responsabilidad de la
proyecto tradicional; pero no es verdad de proyecto tradicional, también se gestión del proyecto, la lleva a cabo el
ya que las responsabilidades de un equivocan. Aunque el Dueño del Scrum Máster.
Scrum Máster son muy diferentes a las Producto es responsable de parte de la
de un director de proyecto tradicional. planificación y el monitoreo del proyecto, Así pues, resulta mucho más conveniente
Por ejemplo, no son responsables de por ejemplo, algunas otras partes de la plantearse ¿qué ocurre con la gestión de
planificar. planificación y el monitoreo no son de proyectos?
sus responsabilidad y las lleva a cabo el
Equipo de Desarrollo.
Importante
Las responsabilidades de la gestión del proyecto se distribuyen entre los tres roles de Scrum y no hay una gestión de
proyectos centralizada.

Ahora que ya hemos examinado todos los papeles de Scrum, te preguntarás ¿quién es el director de proyecto?
La respuesta es simple: no hay tal rol en Scrum, y ninguno de los tres roles actúa como un director de proyecto tradicional.
2.4 Ejemplo
Ejemplo - Paso 1. El Equipo Scrum
MARISOL
Responsable de producto con amplia experiencia de venta al público
(B2C/B2B)
JUAN
Desarrollador de software senior.
LORENZO
Desarrollador de software.
PACO
Técnico instalador experto en automatización de vivienda. Cuenta con más
de 6 años de experiencia en la empresa.
ANA
Especialista en marketing y comunicaciones. Es además responsable de las
RRSS de la empresa.
JAVIER
Técnico instalador en automatización de viviendas recientemente graduado,
y en periodo de pruebas.
DAVID
Ingeniero Técnico - Industrial, especialidad en Electricidad. Tiene amplia
experiencia en la redacción de proyectos de instalaciones, elaboración de
estudios, ofertas y presupuestos.
MANUEL
Técnico en RRHH. Certificado como Scrum Máster (PSM I). Trabaja a tiempo
parcial en la empresa.

En primer lugar es necesario configurar el equipo scrum para que cada uno conozca su rol y responsabilidades. En este
caso, el equipo responsable de desarrollar la solución domótica está compuesto por los siguientes perfiles:



Los Miembros del Scrum llevan a cabo solo uno
de los roles: Dueño del Producto, Scrum Máster o
Miembro del Equipo de Desarrollo. Es posible
asignar a una persona más de un rol, pero no es
recomendable.
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.
La mayor parte de las comunicaciones sobre el
proceso Scrum, tanto internas como externas, son
responsabilidad del Scrum Máster, mientras que
la mayoría de las comunicaciones sobre el
contenido del proyecto, tanto internas como
externas, son responsabilidad del Dueño del
Producto.

3.2 Cierre

Conocer qué es el Backlog de Producto.
Saber para qué se utiliza el Backlog en scrum.
Conocer las características de los elementos que

componen el Backlog.

¡Bienvenido a este módulo! Aquí haremos una introducción al Backlog del Producto, pero antes veamos los objetivos de
este módulo:
2.1 ¿Qué es el Backlog de Producto?

¿Qué es el Backlog de Producto?
SENCILLO
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. Cada requisito y cada cambio en el proyecto, debe
reflejarse en el Backlog de Producto. Es por ello que el Backlog de Producto
es dinámico, cambia y mejora continuamente: nunca está completo, y está
en constante evolución (de otra manera sería predictivo).
ESTIMACIÓN
Además, cada elemento del Backlog de Producto incluye una estimación de
trabajo. Estas estimaciones las realiza exclusivamente el equipo de
desarrollo y se utilizan para determinar el número de elementos que se
llevará a cabo durante un Sprint, en comparación con la capacidad de
trabajo que el equipo pueda desarrollar en un Sprint.
REFINAMIENTO
El Equipo Scrum debe añadir detalles, estimaciones y ordenar los elementos
del Backlog de Producto durante todo el proyecto. Esta actividad se conoce
en scrum como “refinamiento” del Backlog del Producto, y según establecen
las reglas de scrum no debería consumir más de 10% del tiempo del Equipo
de Desarrollo.

El Backlog de Producto es una lista ordenada de todo lo que podría incluir el producto final del proyecto, en otras palabras:
un listado de las distintas partes (funcionalidades o características) que podría incluir el producto final esperado (cómo si
se tratase de una lista de deseos).
Los elementos del Backlog de Producto aparecen ordenados de arriba abajo en función de su importancia (valor). Es
responsabilidad del Dueño del Producto establecer dicho orden.
2.2 Elementos que componen el Backlog de Producto (I)

Características
No importa qué tipo de elementos utilicemos para
crear el Backlog de Producto; estos deben ser INDEPENDENT (I), INDEPENDIENTE
independientes y de carácter no técnico. Es
conveniente que para su composición sigamos la Si los elementos del Backlog de Producto no son independientes, será
pauta marcada por las siglas INVEST: imposible ordenarlos en función de su valor para el negocio. Para que sean
independientes podemos redefinirlos, y si aún así no lo logramos, la última
solución es combinar varios en uno solo.
NEGOTIABLE (N), NEGOCIABLE

Los elementos del Backlog del Producto son también una herramienta de
comunicación, y por lo tanto deben ser negociables.
VALUABLE (V), VALORABLE
Cada elemento debe tener un valor de negocio asignado, y este ser la base
para ordenarlos.
ESTIMATE-ABLE (E), ESTIMABLE

Small (S), pequeño
SOLO LOS ELEMENTOS EN LA PARTE SUPERIOR DEL

BACKLOG DEL PRODUCTO TIENEN QUE SER
PEQUEÑOS (DETALLADOS); NO PASA NADA SI EL
RESTO SON MÁS GRANDES (GENERALES) O
AMPLIOS.
Testable (T), verficable
LA PRUEBA ES SIEMPRE PARTE FUNDAMENTAL DE

LA DEFINICIÓN DE “COMPLETO”.
Historias de usuario
En un entorno Ágil tenemos que ser capaces de comunicarnos y

colaborar con el cliente para recibir feedback y adaptarnos en
consecuencia. Al fin y al cabo un ciclo de vida adaptable no sería útil si
no llevamos a cabo una adaptación. Por lo tanto es necesario compartir
un lenguaje común con el cliente y por ello la definición técnica de un
requisito sería poco útil; en un entorno Ágil preferimos emplear formas
“no técnicas” para definir el alcance, como lo son las “historias de
usuario”.
Ejemplos de historia de usuario son:
1. Como un usuario final

Queremos ser capaces de recibir Queremos ser capaces de
una lista de las últimas reinicializar las contraseñas.
transacciones. Partes de la historia de usuario
2. Como administradores del sistema
(1) Como...
1. " COMO… ", DEFINE EL ROL DE AQUEL QUE VA A INTERACTUAR EN LA HISTORIA;

POR EJEMPLO EL USUARIO FINAL, EL ADMINISTRADOR O EL GERENTE:
como usuario final…
como administrador…
como gerente…
como lector del blog…
(2) Quiero...
2. " QUIERO… ", DEFINE LA EXPECTATIVA DEL ROL; POR EJEMPLO BUSCAR
APARTAMENTOS, CALCULAR EL IMPUESTO, CONCEDER PERMISO A ALGUIEN Y QUE SE
REGISTRE EN LA WEB. DEBEMOS TENER EN CUENTA QUE NOS REFERIMOS A ACCIONES:
"COMO ADMINISTRADOR, QUIERO TENER MI SISTEMA PARA UTILIZAR SQL SERVER" ¡NO
ES UNA HISTORIA DE USUARIO! UNA HISTORIA DE USUARIO IMPLICA HACER ALGO, EN
LUGAR DE TENER ALGO.
como usuario final quiero acceder al carro de mi compra.
como administrador quiero…

como gerente quiero…
como lector del blog quiero responder a los comentarios de
otros lectores.
(3) De modo que…
3. " DE MODO QUE… ", ESTA PARTE OPCIONAL DE LA HISTORIA DE USUARIO
EXPLICA LA RAZÓN QUE ESTÁ DETRÁS DE LA ACCIÓN Y ES DE GRAN AYUDA EN LA
INTERPRETACIÓN DE LA HISTORIA. LA RAZÓN DE ALGUNAS HISTORIAS ES TAN
EVIDENTE QUE ES POSIBLE QUE NO TENGAMOS QUE MENCIONARLA.
3. " de modo que… ", esta parte opcional de la historia de usuario explica la
razón que está detrás de la acción y es de gran ayuda en la interpretación
de la historia. La razón de algunas historias es tan evidente que es posible
que no tengamos que mencionarla.

Un Backlog de Producto está compuesto por diferentes elementos. Lo más habitual es que los elementos del Backlog de
Producto estén redactados siguiendo el formato de historias de usuario, pero no es obligatorio, ni tampoco algo que
prescriba scrum.
Una historia de usuario es la representación de un requisito redactado en una o dos frases utilizando el lenguaje común del
usuario.
Una historia de usuario tiene tres partes (dos obligatorias y una tercera opcional):
2.3 Elementos que componen el Backlog de Producto (II)

Reglas sobre los artículos del Backlog
Reglas básicas sobre los artículos del Backlog de
Producto: 1. NO DEBEN SER DE CARÁCTER TÉCNICO.
Debemos recordar que el Backlog de Producto es nuestro medio “no
técnico” de comunicación con el cliente. Digamos que un niño de diez años
debería ser capaz de entender cada historia de usuario.
2. DEBEN SER INDEPENDIENTES ENTRE SÍ.

De manera que podamos desarrollarlas libremente en cualquier orden.
Debemos recordar emplear el acrónimo INVEST.
Tarjetas
En la parte de delante de la tarjeta escribiremos el texto de la
historia de usuario (por ejemplo, como administrador, quiero
reiniciar contraseñas), el valor del negocio, y la estimación
Reverso de la tarjeta (puntos de la historia). En el reverso de la tarjeta todo lo
demás. Por ejemplo, ¿cómo se informa al usuario de la
Sólo contraseñas seguras son aceptables. contraseña cambiada?, ¿qué tipo de contraseñas podemos
aceptar? etc. Además, tiene que ser breve, pues el espacio
Vínculo de cambio de contraseña debe ser para escribir es limitado. Recuerda que la clave es mantener la
enviada a la dirección de correo electrónico sencillez.
registrada.
El usuario debe responder a la pregunta de
seguridad correctamente antes de tener el En la siguiente lección “Ordenar el Backlog de Producto”
restablecimiento de la contraseñas. aprenderemos a priorizar y estimar los elementos del Backlog
de Producto.
Haz clic para ver más información

Si como lector del blog queremos responder a los comentarios de otros lectores de modo que podamos mantenernos en
contacto con el resto de usuarios, debemos cumplir dos reglas.
Generalmente redactamos los elementos del Backlog de Producto en tarjetas o notas adhesivas y las colocamos en un
tablón. Este enfoque “artesanal” es preferible a la utilización de una aplicación informática, a no ser que el equipo se
encuentre “distribuido”, o por razones de tamaño de la solución sea inviable trabajar con un Backlog de Producto Físico.
2.4 Ejemplo
Ejemplo - Paso 2. Componer el Backlog de Producto
De cualquier forma, antes debemos tener una visión clara de Como ya sabemos, en nuestro caso se trata de un sistema de
aquello que queremos llevar a cabo, sea una boda, un nueva domótica qué permita al usuario controlar desde el teléfono
página web o algo tan sencillo como pintar una casa. móvil todos los aspectos de la casa. Una vez hemos
Después, es necesario reflexionar sobre que se necesitará designado al equipo scrum, el siguiente paso es escribir todas
para llevarlo a cabo. las “historias” de lo que vamos a necesitar.
Lo primero que hay que hacer cuando estamos implementado scrum es crear el Backlog de Producto. Este puede estar
compuesto de cientos de elementos, o tan solo de algunos.



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.
Generalmente redactamos los elementos del
Backlog de Producto en tarjetas o notas
adhesivas y las colocamos en un tablón.
En la parte de delante de la tarjeta escribiremos
el texto de la historia de usuario, el valor del
negocio, y la estimación. En el reverso de la
tarjeta todo lo demás.
3.3 Cierre

Poder trabajar el Backlog de producto.
Ordenar los elementos del Backlog de Producto.
Usar la técnica de priorización MoSCoW.
Estimar los elementos del Backlog de Producto

utilizando el Póker de Planificación.

Una vez redactados los elementos del Backlog de producto, es necesario ordenarlos, y asignarles un valor para poder
decidir por cual empezar a trabajar. Para ello es necesario priorizar y estimar el esfuerzo necesario para llevar a cabo cada
uno de dichos elementos.
En el desarrollo de productos existe una norma estricta que se ha mostrado cierta una y otra vez: el 80% del valor radica
en el 20% de las características. La clave de scrum radica en averiguar cómo crear ese 20% para antes que el restante
80%.
2.1 Priorización del Backlog de Producto

Priorización del Backlog de Producto
La priorización de los elementos del Backlog de
Producto es responsabilidad del Dueño de
Producto.
1.- ES RESPONSABILIDAD DEL DUEÑO DEL
PRODUCTO DECIDIR CÓMO LLEVAR A CABO DICHO
Al respecto debemos saber dos cosas: CÁLCULO.
Y lo cierto es que no hay una única manera de calcularlo.
2.- EL MARCO DE TRABAJO SCRUM NO INCLUYE

NINGUNA RECOMENDACIÓN AL RESPECTO.
Así que el Dueño del Producto es completamente libre de elegir como
hacerlo.
Importante
Los elementos de la parte de arriba del Backlog de Producto por norma general aparecen más detallados, y serán más
claros que los que se encuentran en la parte media y baja del Backlog de Producto. Al respecto no debemos preocuparnos
por esto ya que los elementos de la parte de arriba serán los primeros sobre los que trabajará el equipo de desarrollo
(serán los primeros que se entreguen). Los de la parte media y baja, los iremos trabajando (refinamiento del Backlog de
producto) conforme avancemos en el desarrollo y la entrega de la solución.
Cómo priorizar el Backlog de Producto
ORDEN
Los artículos con más valor se colocan en la parte superior. Cuando se inicie
una nueva iteración comenzaremos escogiendo los productos de la parte
superior del Backlog de Producto, lo que significa que siempre
desarrollamos primero los elementos que tienen más valor de negocio. De
esta manera logramos mantenernos enfocados en el valor y en las
necesidades del negocio.
FÓRMULA
La primera opción en la que se piensa para calcular el valor de las historia
de usuario es emplear una fórmula que considere en el cálculo todos los
beneficios y todos los costes para cada una de las historias de usuario, y el
resultado será un número. Este número, sería el que utilizaríamos para
ordenar la historia de usuario en el Backlog de Producto.
PROBLEMA
El problema es que hacerlo así es realmente complicado; calcular este valor
para cada una de las historias de usuario es prácticamente una locura, ya
que en un proyecto tendremos cientos de historias de usuario, y estimar el
importe de los costes de y los beneficios es muy complicado. Es por ello, que
algunos marcos ágiles utilizan métodos como la técnica de priorización
MoSCoW en lugar, o en combinación, con la asignación de valores de
negocios para ordenar los elementos del Backlog. Más adelante
explicaremos la técnica de priorización MoSCoW.
Técnica de priorización MoSCoW
M (MUST HAVE) DEBE TENER

Requisito que tiene que estar implementado en la versión final del producto para que la misma pueda ser considerada un éxito.
S (SHOULD HAVE) DEBERÍA TENER

Requisito de alta prioridad que en la medida de lo posible debería ser incluido en la solución final, pero que llegado el momento y
si fuera necesario, podría ser prescindible si hubiera alguna causa que lo justificara.
C (COULD HAVE) PODRÍA TENER

Requisito deseable pero no necesario, se implementaría si hubiera posibilidades presupuestarias y temporales.
W (WON’T HAVE) NO TENDRÁ ESTA VEZ

Hace referencia a requisitos que están descartados de momento pero que en un futuro podrían ser tenidos en cuenta y ser
reclasificados en una de las categorías anteriores.
Importante
Si asignamos estas prioridades siendo realistas, sabremos que nuestro producto mínimo aceptable es el que contiene
todas las historias de usuario con la letra M. El producto deseable sería aquel que contiene todas las historias de usuario M
y S, y el producto ideal es la que contiene todas las historias de usuario M, S y C.
La técnica de priorización MoSCoW es una muy buena manera de enfocarse en el valor del negocio: permite centrarse en
las necesidades reales en lugar de las características “ideales” que “podría tener” (could have), pero que no son necesarias.

El Backlog de Producto debe aparecer ordenado en función del valor de negocio. ¿Y qué es el valor de negocio? El Valor de
negocio es el ratio del beneficio de la historia de usuario a desarrollar y el coste de desarrollarla. Esa es la definición
general de valor del negocio.
Priorizar el Backlog de Producto consiste en asignar un valor de negocio a cada elemento del Backlog de Producto. El
resultado es una lista ordenada en función de dicho valor, de mayor a menor.
La técnica de priorización MOSCOW es una técnica para la gestión del alcance. MoSCoW es una combinación de las
primeras letras de: debe tener (Must have), debería tener (Should Have), podría tener (Could Have), y no tendrá en esta
ocasión (Would not Have). En esta técnica, asignamos una de las letras a cada una de las características, en base a la
siguiente definición:
2.2 Estimar los elementos del Backlog de Producto

Estimar los elementos del Backlog de Producto es responsabilidad del
Equipo de Desarrollo
Por lo tanto para estimar en los entornos Ágiles
1. EL COMPROMISO DEL EQUIPO no utilizamos unidades basadas en el tiempo. En
cambio empleamos unidades de esfuerzo relativo,
Para cumplir los plazos inicialmente que muestran la cantidad de esfuerzo necesario
establecidos puede repercutir en la calidad para realizar cualquier historia de usuario en
(reducción de la calidad), y en un entorno comparación con las demás, o con una historia de
Ágil nunca debemos comprometer la referencia. Esta unidad suele denominarse puntos
calidad. de historia.
¿Cómo funcionan? Bien, empezamos por

establecer una referencia para determinar los
2. EL EQUIPO “APRENDE” puntos de cada historia; podemos partir de una
historia de usuario simple y que este clara para
A incluir márgenes de seguridad para evitar todos porque ya la hemos hecho varias veces
futuras responsabilidades respecto al antes, y sabemos exactamente cuánto esfuerzo
incumplimiento de los plazos. Estos requiere. Le asignamos 1 punto historia a esta
márgenes de seguridad, no se controlan y historia de usuario y luego comparamos el resto
generan problemas. Por ejemplo, el conocido de historias con esta; si por ejemplo creemos que
como síndrome del estudiante; el trabajo se una determinada historia requiere diez veces el
prolonga en el tiempo hasta consumir todo esfuerzo de la historia de referencia, el valor de
el tiempo disponible. dicha historia será de 10 puntos de historia.
Las características principales de los puntos de

historia son dos:
Se basan en el esfuerzo en vez de en

el tiempo.
Son relativos.
Importante
Cualquier unidad basada en un esfuerzo relativo podría convertirse en unidades de tiempo absoluto, aunque esta
conversión es meramente estadística. Por ejemplo, si consideramos que hemos realizado 100 puntos de historia en cada
uno de los Sprints anteriores, podemos esperar que realizar 1 punto requerirá una centésima parte del Sprint.
La historia de referencia no tiene que ser una historia real, sólo algo lo suficientemente pequeño, sencillo, claro, y familiar
para todo el mundo. Incluso utilizando una misma historia de referencia para todos los proyectos de la organización, la
asignación de los puntos de historia en cada proyecto sería diferente porque la composición del equipo, las capacidades
del cliente, y otros factores ambientales también lo serán.
Póker de Planificación
En esta técnica, el Equipo de Desarrollo La clave está en el mecanismo de En el “planning póker” cada miembro del
se reúne y el Dueño del Producto explica votación. Si empezamos a recibir votos quipo de desarrollo cuenta con una
la historia de usuario para asegurarse de uno por uno, cada persona escuchará la baraja, elige una carta que muestra su
que todo el mundo la entiende. A opinión de todos los anteriores y su estimación y la coloca hacia abajo.
continuación el equipo puede discutir el respuesta podría estar sesgada.Cuando todos estén listos se muestran
enfoque de desarrollo o cualquier otro Empleando la técnica del póker de las cartas al mismo tiempo. Si los valores
aspecto técnico y finalmente se planificación evitamos ese sesgo. propuestos por todos están en el mismo
establece su valor mediante votación. rango, la media o el promedio de los
valores serán la estimación de la historia.
Sin embargo, si hay una gran diferencia
El siguiente dibujo muestra una baraja entre los valores propuestos,
normal de cartas de póker de entenderemos que no todo el equipo lo
planificación: comprende de la misma manera. Por lo
tanto, se discute y se vota de nuevo
hasta que los valores están en el mismo
rango.

Estimar se refiere a “calcular” la cantidad de esfuerzo necesario para completar un elemento del Backlog de Producto, o
una historia de usuario en su caso. Tradicionalmente cuando se estima el esfuerzo requerido para completar una tarea se
hace en base a horas-hombre o días-hombre, pero estimar en base al tiempo genera dos problemas principales:
Es responsabilidad del Equipo de Desarrollo estimar el esfuerzo necesario de cada historia de usuario. Una manera de
hacerlo es mediante el póker de planificación.
2.3 El refinamiento del Backlog de producto

El refinamiento del Backlog de producto
MOMENTO
No existe un momento concreto durante el sprint reservado para esta
actividad.
PROCESO
Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo
de Desarrollo colaboran acerca de los detalles de los elementos de la Lista
de Producto.
REVISIÓN
Durante el refinamiento de la Lista de Producto, se examinan y revisan sus
elementos.
EQUIPO
El Equipo Scrum decide cómo y cuándo se hace el refinamiento.
CAPACIDAD
Este usualmente consume no más del 10% de la capacidad del Equipo de
Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden
actualizarse en cualquier momento por el Dueño de Producto o a criterio
suyo.
El refinamiento” del Backlog del Producto consiste en revisar y modificar los elementos del Backlog del Producto y
normalmente implica añadir detalles, estimaciones y ordenar los elementos.
2.4 Ejemplo
Ejemplo Paso 3 - Priorizar el Backlog de Producto
Recuerda que decidir el orden (valor) de los elementos del

Tras redactar los elementos que componen el Backlog de Backlog del Producto es una competencia exclusiva del
Producto ha llegado el momento de ordenarlo. La clave radica Dueño del Producto. No ocurre lo mismo con la estimación,
en decidir que se tiene que entregar primero. En nuestro caso que es competencia del equipo de desarrollo.
el equipo se ha reunido en torno a la lista de características y
se pregunta: ¿qué es más importante para el cliente?, ¿cómo
entregar al cliente valor más rápido que los demás?
Básicamente lo que queremos determinar son las cosas que
aportarán más valor con el menor riesgo.

3.2 Resumen
Resumen
Priorizar el Backlog de Producto consiste en
asignar un valor de negocio a cada elemento del
Backlog de Producto.
Los artículos con más valor se colocan en la parte

superior. Cuando se inicie una nueva iteración
comenzaremos escogiendo los productos de la
parte superior del Backlog de Producto, lo que
significa que siempre desarrollamos primero los
elementos que tienen más valor de negocio.
En el “planning póker” cada miembro del equipo

de desarrollo cuenta con una baraja, elige una
carta que muestra su estimación y la coloca hacia
abajo. Cuando todos estén listos se muestran las
cartas al mismo tiempo. Si los valores propuestos
por todos están en el mismo rango, la media o el
promedio de los valores serán la estimación de la
historia.

3.3 Cierre

Conocer qué es el Backlog de Sprint.
Saber para qué y cómo se utiliza en scrum.
Conocer las características y elementos que

componen el Backlog de Sprint.

El Backlog del Sprint es el artefacto que se emplea en scrum para planificar el sprint. Se crea durante el evento de
Planificación del Sprint, que es el primer evento en un Sprint, y además para su planificación, se contribuye a mantener el
sprint bajo control.
2.1 Qué es el Backlog del Sprint

Qué es el Backlog del Sprint
Tras el evento de Planificación del Sprint los
elementos del Backlog del Sprint se congelan, y el
equipo de desarrollo se centrará en entregar un
incremento "completo" siguiendo el plan
establecido. Debemos recordar que por norma
general no pueden añadirse ni eliminarse artículos
(historias de usuario) del Backlog del Sprint
durante el Sprint. Sin embargo, podría ser
necesario obtener más información, justificar o
aclarar algunos de los artículos, lo que debe
realizarse siempre en presencia del Dueño del
1. Un conjunto de 2. El objetivo del 3. Un plan Producto.
funcionalidades Sprint detallado
(historias de Que ayudará a Para la entrega de los
usuario) comprender el productos y la El plan detallado del Sprint que normalmente no
Seleccionadas de la significado real de las realización del objetivo está completo al final del evento de Planificación
parte superior del funcionalidades y a del Sprint durante el del Sprint, continuará actualizando a medida que
Backlog de Producto en dirigir los esfuerzos del Sprint. Este plan avanza el Sprint.
base a la capacidad y la equipo de desarrollo. detallado se actualizará
carga de trabajo continuamente durante
estimado del Equipo de el Sprint.
Desarrollo.
Excepcionalmente cuando todos los elementos se han completado antes de la final del
Sprint, el equipo de desarrollo puede escoger el siguiente elemento del Backlog de Producto
y empezar a trabajar en él durante el resto del Sprint.
Excepcionalmente cuando todos los elementos se han completado antes de la final del Sprint, el equipo de desarrollo
puede escoger el siguiente elemento del Backlog de Producto y empezar a trabajar en él durante el resto del Sprint.

Durante el evento de Planificación del Sprint, el Equipo Scrum colabora en la creación del Backlog del Sprint, que consta de
tres elementos:
2.2 Formato y contenido del Backlog del Sprint

Priorización del Backlog de Producto
Observa como en este sencillo tablero se
muestran los tres elementos que componen el 1. EL ALCANCE DEL SPRINT.
Backlog del Sprint:
Hace referencia a las distintas historias de usuario o funcionalidades, que
desarrollaremos durante el sprint. El Equipo de Desarrollo es el encargado
de seleccionar un número de elementos de la parte superior del Backlog del
Producto y los pone en el Backlog del Sprint, para completarlos y
entregarlos en el Sprint actual.
2. EL OBJETIVO DEL SPRINT.

Es el objetivo que debería alcanzarse durante el Sprint a través del
desarrollo de los elementos seleccionados del Backlog del Producto, y
proporciona orientación al Equipo de Desarrollo sobre por qué se está
construyendo el incremento.
3. “EL PLAN DETALLADO”.

Las historias de usuario descompuestas en tareas. No es necesario que
durante la sesión de Planificación del Sprint se desarrolle un plan detallado
para todos y cada uno de los elementos del Backlog del Sprint. Es suficiente
con tener un plan detallado de los elementos en los que se trabajará los
primeros días; el equipo de desarrollo puede ir preparando el resto de
planes detallados posteriormente durante el Sprint.

Scrum no establece ninguna regla específica sobre la documentación, almacenamiento, y la presentación del Backlog del
Sprint. Para ello, podrías emplear un tablón similar al que te mostramos en el siguiente dibujo.
2.3 Velocidad
¿Para qué emplear la velocidad?
La velocidad se calcula promediando el Obviamente la velocidad puede cambiar
número de puntos de historia después de cada Sprint. Por lo general,
completados en los sprints anteriores. se experimentan grandes cambios en la
Algunos equipos prefieren excluir del velocidad en el inicio del proyecto, pero
cálculo los primeros sprints ya que tras seis o siete Sprints, la velocidad se
pueden no ser representativos. Otros, sin En este caso el promedio es de alrededor vuelve más o menos constante, porque
embargo, prefieren calcular una media de 100 puntos de historia. Si conseguimos un rendimiento más
ponderada con un mayor peso de los descartásemos los dos primeros sprints, constante, y también debido a la propia
Sprints más recientes. Por ejemplo: el promedio sería de unos 110 puntos, naturaleza de los promedios.
que es por lo general una medición más
acertada.
Importante
Únicamente se contabilizan los puntos de historia de las historias de usuario “completas” hasta el final del Sprint. Por lo
tanto si una historia de 10 puntos estuviera casi hecha, incluso al 99%, no se incluiría para promediar la velocidad. La
historia volvería al Backlog de Producto y se volverá a estimar en base al esfuerzo restante.
¿Para qué emplear la velocidad?
ESTIMAR TRABAJO
1. Como una guía para estimar la cantidad de trabajo que podemos hacer
en el próximo sprint; si por ejemplo la velocidad es de 100 puntos de
historia, el equipo de desarrollo seleccionara la de la parte superior de la
Pila de Producto artículos (funcionalidades) por valor de unos 100 puntos
de historia.
2. COMO UNA GUÍA PARA ESTIMAR LA FECHA DE FINALIZACIÓN DEL PROYECTO; SI

LA VELOCIDAD ES DE 100 PUNTOS DE HISTORIA, Y LOS PUNTOS DE HISTORIA QUE
QUEDAN EN EL BACKLOG DE PRODUCTO SON 1.000 PUNTOS, PODEMOS ESTIMAR QUE
NECESITAREMOS UNOS 10 SPRINTS PARA TERMINAR EL PROYECTO, SIEMPRE QUE EL
BACKLOG DE PRODUCTO NO CAMBIE DEMASIADO. SIN EMBARGO EL DUEÑO DEL
PRODUCTO DEBE CONSIDERAR ESTE CÁLCULO COMO ALGO ORIENTATIVO PARA
DETERMINAR LA FECHA DE FINALIZACIÓN, Y CONSIDERAR ADEMÁS EL RESTO DE
FACTORES.
2. Como una guía para estimar la fecha de finalización del proyecto; si la
velocidad es de 100 puntos de historia, y los puntos de historia que quedan
en el Backlog de Producto son 1.000 puntos, podemos estimar que
necesitaremos unos 10 Sprints para terminar el proyecto, siempre que el
Backlog de Producto no cambie demasiado. Sin embargo el Dueño del
Producto debe considerar este cálculo como algo orientativo para
determinar la fecha de finalización, y considerar además el resto de
factores.
La velocidad es el número de unidades de trabajo realizadas en un cierto intervalo. En el caso de un proyecto Scrum es la
cantidad de puntos de la historia que el equipo de desarrollo puede completar durante un Sprint.
En scrum se emplea la velocidad por dos razones:
2.4 Ejemplo
Ejemplo Paso 4 - El Backlog del Sprint
Tras ordenar el Backlog del Producto ha llegado el momento Por el momento basta que sepamos que durante esta reunión
de comenzar con el primer sprint. Para ello necesitamos el equipo de desarrollo debe decidir cuántos puntos de
redactar el Backlog del Sprint a partir del Backlog de historia o cuantos elementos del Backlog del Sprint será
Producto. La preparación del Backlog del sprint tiene lugar capaz de completar durante el sprint que acaba de comenzar.
durante la Reunión de Planificación del Sprint, que es el Una buena manera de hacerlo es recurriendo al concepto de
primero de los eventos de scrum. Lo veremos en detalle en la velocidad que acabamos de ver.
próxima lección.

Volviendo al caso de Automatismos para el Hogar SL., veamos cuál sería el siguiente paso.

3.2 Resumen
Resumen
Tras el evento de Planificación del Sprint los
elementos del Backlog del Sprint se congelan, y el
equipo de desarrollo se centrará en entregar un
incremento "completo“.
Podemos emplear la velocidad como una guía
para estimar la cantidad de trabajo que podemos
hacer en el próximo sprint o como una guía para
estimar la fecha de finalización del proyecto.
La velocidad se calcula promediando el número
de puntos de historia completados en los sprints
anteriores.

3.3 Cierre

Conocer la importancia de la Planificación del

Sprint en scrum.
Usar la Planificación de Sprint para generar el

Backlog del Sprint.

Anteriormente hemos visto como a partir del Backlog de Producto se desarrolló el Backlog del Sprint. Este segundo
artefacto de scrum, es una especie de plan que contiene los detalles del trabajo que el equipo scrum desarrollará durante
el sprint.
En la siguiente lección veremos cómo y cuándo se genera el Backlog del sprint, y aprenderemos algunas de sus
particularidades.
2.1 La Planificación del Sprint

La Planificación del Sprint
BACKLOG DE PRODUCTO
Por ello, tan pronto como el Backlog de Producto esté lo bastante maduro,
tenga el número de historias de usuario suficientes para proporcionar la
información necesaria del primer Sprint, el Dueño del Producto y el Equipo
de Desarrollo comienzan con el primer Sprint.
PLANIFICACIÓN
La Planificación del Sprint, según establece La Guía Scrum, es una reunión
de tiempo limitado a 8 horas para Sprints con una duración de un mes, y
que será proporcionalmente más corta en el caso de Sprints que duren
menos.
REUNIÓN
Durante esta reunión, el equipo de desarrollo debe estimar la capacidad de
trabajo que puede ofrecer en el sprint (ya hemos visto anteriormente el
concepto de velocidad). Previamente el Dueño del Producto ya habrá
clasificado y ordenado los elementos del Backlog del Producto en base al
valor de los artículos. El Dueño del Producto también es responsable de
asegurarse que el Equipo de Desarrollo comprenda los elementos (historias)
del Backlog de Producto.
¿Cómo se lleva a cabo la reunión de Planificación del sprint?

1. EL EQUIPO DE DESARROLLO SELECCIONA UN 2. UNA VEZ SELECCIONADOS LOS ELEMENTOS A
NÚMERO DE ELEMENTOS DE LA PARTE SUPERIOR ENTREGAR Y ESTABLECIDO EL OBJETIVO DEL
DEL BACKLOG DEL PRODUCTO Y LOS MUEVE SPRINT, ES MOMENTO DE PLANIFICAR CÓMO LOS
HASTA EL BACKLOG DEL SPRINT DISTINTOS ARTÍCULOS DEL BACKLOG DEL SPRINT
VAN A “TRANSFORMARSE” EN UN INCREMENTO
DEL PRODUCTO "COMPLETO"
Para completarlos y entregarlos en el Sprint actual. Es el

Equipo de Desarrollo el que estima la cantidad de esfuerzo
(puntos de historia) que requiere cada artículo. La cantidad Y como a través de estos se hará realidad el objetivo del
total de esfuerzo de los elementos seleccionados del Backlog Sprint. Esta es la última parte del Backlog del Sprint.
del Producto, debería estar cerca de la capacidad de trabajo
estimada del Equipo de Desarrollo. No es necesario desarrollar un plan detallado para todos y
cada uno de los elementos del Backlog del Sprint durante la
Seleccionados los artículos, el Equipo Scrum debería redactar sesión de Planificación del Sprint. Es suficiente con tener un
el objetivo del Sprint. El objetivo del Sprint es el objetivo que plan detallado de los elementos en los que se trabajará los
debería alcanzarse durante el Sprint a través del desarrollo de primeros días; el equipo de desarrollo puede ir preparando el
los elementos seleccionados del Backlog del Producto, y resto de planes detallados posteriormente durante el Sprint.
proporciona orientación al Equipo de Desarrollo sobre por qué
se está llevando a cabo el sprint y construyendo el ¿A que nos referimos por plan detallado? Un plan detallado es
incremento. un elemento del Backlog de Producto (historias de usuario)
descompuesto en tareas que habrá que hacer con el fin crear
dicho elemento. Cada tarea puede contener estimaciones,
dependencias y cualquier otra información similar necesaria
para su seguimiento.
Importante
El Backlog del Sprint estará listo al final de la Planificación del Sprint, y el equipo de desarrollo debe ser capaz de describir
los elementos que van a entregar a través del Sprint, y cómo lo hará.

El Backlog del Sprint se genera durante la reunión de planificación del sprint, una vez que el Backlog de Producto está
ordenado.
Al respecto, es fundamental recordar que el Equipo de desarrollo no tiene que esperar hasta que el Backlog de Producto
esté completamente desarrollado o completo al 100% para comenzar a trabajar en desarrollar el producto.
¿Por qué? En tal caso no se estaría trabajando en base a un enfoque Ágil (adaptativo), sino que se estaría siguiendo un
enfoque predictivo.
De las ocho horas que como máximo debería durar la reunión de planificación para sprints de 4 semanas, el tiempo debe
dividirse en partes iguales para llevar a cabo dos tareas fundamentales:
2.2 Ejemplo
Ejemplo Paso 5 – La Planificación del Sprint
Una vez tenemos suficientes elementos en el Backlog de En este punto se encuentra el equipo scrum de Automatismo
producto como para comenzar con el primer sprint, debemos para el Hogar SL: con un Backlog de producto que contiene
empezar a trabajar en el desarrollo del producto. Debemos historias de usuario suficientes como para empezar a
recordar que no es necesario esperar a tener un Backlog de trabajar. La siguiente decisión que han tomado es que por el
Producto 100%; pues este debería mantenerse vivo, y momento trabajarán con sprints de 2 semanas de duración.
cambiar a medida que avancemos en el proyecto. Esa es la Ha llegado el momento de la planificación del sprint, y aún
esencia de los enfoques Ágiles y de scrum: adaptación. tienen algunas dudas sobre esta reunión que como scrum
máster deberíamos poder resolver.


3.2 Resumen
Resumen
El Backlog del Sprint se genera durante la reunión
de planificación del sprint, una vez que el Backlog
de Producto está ordenado.
El equipo de desarrollo debe estimar la capacidad
de trabajo que puede ofrecer en el sprint.

3.3 Cierre

Reconocer cómo funciona scrum en base a sus

cinco eventos claves.
Conocer las características principales de los

distintos eventos.
Reconocer los roles que intervienen en cada uno

de los eventos.

Un proyecto que sigue Scrum se gestiona en base a cinco eventos o rituales, diseñados para permitir la transparencia, la
inspección, la regularidad y la adaptación. En scrum se emplean estas reuniones predefinidas que incluyen unos objetivos
fijos y una duración máxima (time box), en lugar de reuniones ad-hoc, que muy probablemente harán perder tiempo al
equipo.
2.1 Time Box

Time Box
La duración de estos bloques de tiempo debe
acordarse y prefijarse. Si bien somos libres de
cambiar la duración de dichos bloques en función
de las lecciones aprendidas, no deberíamos
hacerlo en base a circunstancias puntuales.
Por ejemplo, respecto de los sprints no podemos

decir "tenemos mucho que hacer en este sprint,
así que vamos a aumentar la duración del sprint”.
Lo que si podemos plantear es "en base a los diez
bloques de tiempo anteriores, nos hemos dado
cuenta de que la duración de nuestros bloques no
1. Tiempo 2. Agenda es la adecuada, y que un aumento del 30% en la
duración puede ser más adecuado a nuestras
Se refiere a una duración máxima Todos los eventos de scrum cuentan necesidades. Así que vamos a aumentarlo a partir
de tiempo predefinida. con una agenda que establece qué de ahora”.
se tiene que hacer. De esta manera
las cajas de tiempo contribuyen a
maximizar la productividad. Recuerda que...
Todos los acontecimientos de scrum funcionan
como cajas de tiempo.
Un concepto esencial en los métodos Ágiles es el de “cajas de tiempo”, time box en inglés. Esta característica implica
básicamente dos cosas:
2.2 El sprint
El sprint
INCREMENTO
El incremento que se hace es la suma de todos los elementos del Backlog de Producto completados hasta un momento
determinado del proyecto. El incremento como su nombre indica, continuará creciendo tras cada Sprint hasta que el proyecto
concluya.
Podemos considerar que cada nuevo Incremento creado al final de un Sprint es una versión actualizada del incremento anterior,
con nuevas características y funcionalidades, y que puede o no entregarse al cliente, pero siempre debe ser potencialmente
entregable.
TIME BOX
El sprint es un acontecimiento de tiempo limitado (time box), lo que significa que deberemos fijar su duración cuando se inicia el
proyecto y evitar modificarla con demasiada frecuencia. La Guia Scrum establece que los Sprints están limitados a un mes
calendario. Además, scrum también establece la agenda del sprint: los otros cuatro eventos que integran un sprint. Fíjate en el
diagrama siguiente:
Ajustar la duración del sprint

Debemos recordar que nuestro objetivo Otro punto clave para decidir sobre la Como ya hemos comentado, no está
es ofrecer al cliente el producto, o duración de los Sprints es la cantidad de permitido cambiar la duración de los
solución final, artículo por artículo, dentro adaptación necesaria para el proyecto; sprints “ad-hoc”. No podemos, por
de los límites de los Sprints; no queremos un proyecto con Sprints de dos semanas ejemplo, decir que, como durante este
dividir la realización de un artículo del recibe casi el doble de retroalimentación sprint tenemos que desarrollar un gran
Backlog de Producto entre varios Sprints. y tiene el doble de oportunidades de número de historias de usuario, vamos a
adaptarse, que un proyecto con sprints establecer un sprint más largo. Sin
de cuatro semanas. embargo, si nos damos cuenta de que la
duración de los sprints que hemos
elegido no es apropiada para el proyecto,
podemos revisar y cambiar la duración
para el resto de los sprints. No obstante,
esperamos que no sea necesario realizar
estos cambios a menudo.
¿Es posible cancelar un sprint?

Una cuestión diferente es la cancelación del Sprint. Es decir, si la lista de
historias de usuario, o el objetivo del Backlog del Sprint deviene obsoleto, o
deja de tener sentido por cualquier motivo; por ejemplo el cliente ya no lo
quiere o no lo necesita. Entonces se puede cancelar el sprint, y simplemente
se empieza otro a partir de una nueva reunión de planificación del sprint.
Respecto a la cancelación del sprint debemos considerar dos cosas:
EL ÚNICO CON AUTORIDAD PARA CANCELAR UN

SPRINT ES EL DUEÑO DEL PRODUCTO
Nadie más tiene autoridad para hacerlo.
LA CANCELACIÓN DEL SPRINT ES ALGO

EXCEPCIONAL
No algo que puede esperarse que suceda a menudo.

Cuando gestionamos la entrega de un producto o servicio siguiendo scrum, el producto final se entrega después de un
número indeterminado de iteraciones.
Las iteraciones en scrum se denominan sprints. Durante cada sprint se desarrolla un incremento y finalizado este, dicho
incremento será potencialmente entregable.
La mayoría de las organizaciones trabajan con Sprints de entre 2 y 4 semanas. Si trabajamos con Sprints más largos es
probable que los cambios no aplicados sean lo suficientemente “grandes” como para generar problemas, aumentando la
complejidad y el riesgo.
Por lo tanto debemos limitar los Sprints a no más de un mes de calendario. Pero por otro lado, los Sprints tampoco deben
ser demasiado cortos porque entonces no seremos capaces de producir artículos completos durante los mismos.
2.3 La Planificación del Sprint

La Planificación del Sprint
En este punto es conveniente recordar que la
Planificación del Sprint es una reunión de tiempo
limitado a 8 horas para Sprints con una duración
de un mes, y que será proporcionalmente más
corta en el caso de Sprints que duren menos.

En la lección anterior tratamos la Planificación del sprint en profundidad. Si tenemos alguna duda al respecto podemos
volver atrás y revisar la lección anterior.
2.4 El scrum diario

El scrum diario
CUESTIONES
Durante el Scrum Diario cada miembro del Equipo
de Desarrollo debe responder a estas tres
preguntas:
1. ¿Qué he hecho desde la última

reunión?
2. ¿Qué voy a hacer antes de la
próxima reunión?
3. ¿Qué obstáculos he encontrado en
el camino?
EVALUACIÓN
El Equipo de Desarrollo debe evaluar el progreso hacia el objetivo del Sprint
y pronosticar la probabilidad de completar los artículos antes de que
concluya el Sprint.
Para evitar complicaciones el Scrum Diario debería celebrarse siempre en el

mismo lugar y a la misma hora durante todo el Sprint. Es una reunión sólo
para el Equipo de Desarrollo, no una reunión para todos los interesados en
el proyecto. Esto no quiere decir que el resto de interesados en el proyecto
no puedan asistir; pueden asistir, pero no participar.
MONITORIZACIÓN
El Equipo de Desarrollo también debe monitorear el progreso del Sprint
cada día y por lo tanto es una buena idea que el tablón del Sprint, que
podría ser un mural o un grafico en la pared, este visible durante esta
reunión. Podríamos además utilizar un gráfico de avance (burn-down chart)
para monitorear el trabajo restante y prever si todos los artículos se
completaran antes del final del Sprint. Veremos más al respecto en el
siguiente capítulo sobre los artefactos.

El Scrum Diario es una reunión de pie de 15 minutos máximo para que el Equipo de Desarrollo inspeccione el trabajo
realizado desde la última reunión, se sincronice, y establezca el plan para las próximas 24 horas. Debe realizarse, como su
nombre indica a diario.
2.5 La revisión del Sprint

La revisión del Sprint
Durante esta reunión se marcan como "Completo" los artículos hechos, se añaden nuevos elementos, o se modifican los ya
existentes si fuera necesario. El propósito de presentar el incremento en esta reunión, es recabar información y conocer las
solicitudes de cambio a la mayor brevedad.
1. El equipo de desarrollo no presentará un 2. Cualquier historia de usuario que no se
elemento a menos que esté completo al 100%. encuentre “completa” al final del Sprint, vuelve
En base a la definición acordada de “Completo”. El Dueño del al Backlog del Producto y el Dueño del Producto
Producto debe asegurarse antes de la Revisión del Sprint, que deberá reordenarla.
los elementos que se presentan están "completos". El Equipo Si dicho elemento/os todavía está en la parte superior del
de Desarrollo es responsable de demostrar y explicar los Backlog de Producto, se escogerán para completarse en el
elementos. próximo Sprint, si se situaran más abajo deberán esperar
hasta que llegue su turno.

La duración de esta reunión es de cuatro horas para Sprints de un mes. Si los Sprints son más cortos, la reunión será
proporcionalmente más corta.
Al final del sprint el Equipo Scrum y las otras partes interesadas se reúnen y mantienen una de tiempo limitado en función
de la duración del Sprint, para presentar y revisar los artículos "Completos", el incremento del actual Sprint, y actualizar el
Backlog del Producto.
2.6 La retrospectiva del sprint

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 (implementar lecciones aprendidas), que se conoce como Retrospectiva del Sprint.
Importante
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; debemos buscar y aplicar mejoras constantemente. Durante la Retrospectiva
del Sprint inspeccionaremos el Sprint actual en lo referente a las personas, los procesos y las herramientas, e
identificaremos formas de mejorar para el próximo sprint, que ponemos en práctica.
La retrospectiva del sprint es una reunión de tres horas para Sprints de un mes, y proporcionalmente más corta en función
de la duración del Sprint.
2.7 Ejemplo
La retrospectiva del sprint
El equipo scrum de Automatismos para
el Hogar S.L. ya ha implementado scrum
durante un par de interacciones. Sin
embargo aún siguen surgiendo dudas
sobre el funcionamiento de scrum, y no
saben muy bien cuál es el mejor evento
parar tratar algunas cuestiones. Como
scrum máster deberás ayudarlos en la
implementación de scrum y aclarar sus
dudas.


3.2 Resumen
Resumen
Cuando gestionamos la entrega de un producto o
servicio siguiendo scrum, el producto final se
entrega después de un número indeterminado de
iteraciones o sprint.
El Dueño del Producto debe asegurarse antes de

la Revisión del Sprint, que los elementos que se
presentan están "completos". El Equipo de
Desarrollo es responsable de demostrar y explicar
los elementos.
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.

3.3 Cierre

Identificar los artefactos scrum.
Reconocer las principales características de los

artefactos scrum.
Saber cuándo utilizar los artefactos scrum.

En Scrum nos referimos a los Artefactos como a los resultados, o productos, de las actividades de gestión (también como
productos de gestión). Los artefactos 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.
2.1 Los artefactos de scrum

Los artefactos de scrum
BACKLOG DE PRODUCTO
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.
BACKLOG DE SPRINT
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.
INCREMENTO
Incremento: se refiere al conjunto de todos los elementos “completos” del
Backlog del Producto hasta el fin del Sprint actual.
COMPLETO
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.
MONITOREO META
Monitoreo del progreso hacia la meta: se refiere a la medición de los
resultados y las previsiones para todo el proyecto.
MONITOREO SPRINT
Monitoreo del progreso hacia el Sprint: es la medición de los resultados y las
previsiones para un solo Sprint.
Importante
Los artefactos de monitoreo 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 verdaderos
artefactos los productos generados por estas actividades (información de seguimiento, graficas de seguimiento, etc.).
2.2 Artefacto 1: el Backlog de Producto

Artefacto 1: el Backlog de Producto
DINÁMICO
El Backlog de Producto es dinámico, cambia y mejora continuamente: nunca
está completo. Ya dijimos en su momento, que no era necesario esperar
hasta que esté completo para comenzar a trabajar en los artículos; el primer
Sprint puede empezar tan pronto como el Backlog de Producto tenga
definidas un número suficiente de historias.
VALOR
El Dueño del Producto establece una serie de factores que le ayudarán a
determinar el valor de cada artículo; el Retorno de la Inversión, por ejemplo,
suele ser uno de esos factores. Todos los factores pueden resumirse en un
único valor que determina la importancia de cada elemento del Backlog del
Producto y que se muestra junto a este.
ESTIMACIÓN
Además, cada elemento del Backlog de Producto incluye una estimación de
trabajo. Estas estimaciones las realiza exclusivamente el equipo de
desarrollo y se utilizan para determinar el número de elementos que se
pueden seleccionar durante cierto Sprint, en comparación con la capacidad
de trabajo que el equipo pueda desarrollar en un Sprint. También puede
añadirse información adicional que contribuya a que el Equipo Scrum
monitoree a cada elemento.
DETALLES
El Equipo Scrum debe añadir detalles, estimaciones y ordenar los elementos
del Backlog de Producto durante todo el proyecto. A esta actividad ya nos
hemos referido anteriormente como “refinamiento” de la Backlog del
Producto, y sabemos que no debería consumir más de 10% del tiempo del
Equipo.
DISCUSIONES
El Backlog del Producto se va configurando en base a “discusiones” en lugar
de hacerse en base a una documentación. Los elementos del Backlog del
Producto, también conocidos como historias, deben ser fáciles de entender
para los interesados que no tengan un perfil técnico.
Importante
En ocasiones varios Equipos Scrum trabajan en un mismo proyecto. Dado que el Backlog del Producto es una
representación del producto final, sólo puede existir uno, sin importar el número de Equipos de Scrum que estén trabajando
en el proyecto.

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. Cada requisito y cada cambio en el proyecto, debe reflejarse en el
Backlog de Producto.
2.3 Artefacto 2: Backlog del Sprint
Artefacto 2: Backlog del Sprint
Después de la Planificación del Sprint los
elementos del Backlog del Sprint se
congelan, y el equipo de desarrollo se
centrará en entregar un incremento
"completo" siguiendo el plan establecido.
Debemos recordar que no pueden
añadirse ni eliminarse artículos (historias
de usuario) del Backlog del Sprint
durante el Sprint. Sin embargo, podría
ser necesario obtener más información,
justificar o aclarar algunos de los
artículos, lo que debe realizarse siempre
en presencia del Dueño del Producto. El
plan detallado del Sprint que
1. Un conjunto de 2. El objetivo del Sprint normalmente no está completo al final
funcionalidades Que ayudará a comprender el
del evento de Planificación del Sprint,
continuará actualizando a medida que
(Historias de usuario) seleccionadas de significado real de las funcionalidades y
avanza el Sprint.
la parte superior del Backlog de a dirigir los esfuerzos del equipo de
Producto en base a la capacidad y la desarrollo.
carga de trabajo estimado del Equipo
de Desarrollo. Un plan detallado para la entrega de los Cuando escalamos Scrum, cada Equipo
productos y la realización del objetivo de Desarrollo debe contar con su propio
del Sprint durante el Sprint. Este plan Backlog del Sprint.
detallado se actualizará continuamente
durante el Sprint.

El Backlog del Sprint se crea durante el evento de Planificación del Sprint, que es el primer evento en un Sprint. Durante el
evento de Planificación del Sprint, el Equipo Scrum colabora en la creación del Backlog del Sprint, que consiste en lo
siguiente:
2.4 Artefacto 3: Incremento

Artefacto 3: Incremento
El diagrama siguiente muestra cómo el número de historias del Backlog de Producto disminuye Sprint a Sprint, mientras que el
número de funcionalidades incrementa (incremento). Ten en cuenta que el concepto de incremento es acumulativo: cada
incremento contiene las características (funcionalidades) anteriores.
1. “Incremento” es un 2. Cuando varios equipos
concepto acumulativo. están trabajando en el
Cada incremento contiene también mismo producto.
las características de los anteriores. Cada equipo produce un incremento
“completo”. Los incrementos se
combinan creando uno único para
todo el proyecto.

Un incremento es la suma de todos los elementos del Backlog de producto completados al finalizar un Sprint. Recuerda
que cada incremento debe estar “completo” y ser entregable. El Dueño del Producto puede o no puede entregar un cierto
incremento, pero debe ser potencialmente entregable.
2.5 Artefacto 4: Definición de 'Completo'

Artefacto 4: Definición de "Completo"
Generalmente una definición de “Completo” contiene:
LOS PROCESOS DE DESARROLLO

Especificación, diseño, programación, integración, prueba, documentación.
LOS PROCESOS ORGANIZACIONALES

Otras cosas podrían tener que hacerse en base a las directrices de la
organización.
REQUISITOS NO FUNCIONALES
Rendimiento, seguridad, escalabilidad, facilidad de mantenimiento, facilidad
de uso, extensibilidad, etc.
CRITERIOS DE CALIDAD
Por ejemplo, los estándares de codificación.
Importante
Cuando varios equipos Scrum están trabajando en un mismo proyecto, puede que no sea posible que todos los equipos
utilicen la misma definición de "Completo”, ya que podrían estar trabajando en unidades de diferente naturaleza. En tal
caso, cada Equipo Scrum establecerá su propia definición de "Completo" y entregará sus elementos en función de dicha
definición. Sin embargo, la integración de las definiciones de "Completo" debe ser capaz de generar un Incremento
potencialmente entregable a nivel de proyecto.

Debe existir un entendimiento común entre los miembros del equipo Scrum de lo que significa que una pieza de trabajo
esté "Completa" (100% hecha). Esta definición de "Completo" debe ser discutida y acordada por el Equipo Scrum al
comienzo del proyecto a fin de que los incrementos futuros puedan ser entregables.
2.6 Artefacto 5: Seguimiento del progreso hacia la meta

Artefacto 5: Seguimiento del progreso hacia la meta
Es común emplear un gráfico “burn-
down” para visualizar el progreso de
todo el proyecto. El gráfico de avance de
un proyecto muestra la cantidad de
trabajo restante, en lugar de la cantidad
de trabajo realizado. Por lo tanto, la línea
de desempeño real va hacia abajo a
medida que avancemos y cuanto más Por lo general agregamos una segunda Observa como en el gráfico de arriba la
rápido desciende, más contentos línea para representar la distribución del línea que representa el desempeño real
estaremos. volumen de trabajo estimado va por encima de la línea que representa
inicialmente para los Sprints. Esta línea el desempeño planificado. Esto significa
actúa como nuestro indicador del que los puntos de historia se reducen a
progreso planificado, y la utilizaremos menor velocidad de lo planificado
En el eje vertical (Puntos de Historia comparándola con nuestros valores inicialmente, y que por lo tanto vamos
Pendiente) se muestra la cantidad de reales (Desempeño Real). con retraso.
trabajo pendiente, que es la suma de las
estimaciones de cada uno de los
elementos del Backlog de Producto, y en
el eje horizontal se muestra la cantidad
de tiempo transcurrido desde el inicio del
proyecto o el número de sprints pasados.

El Dueño del Producto es responsable de monitorear el progreso de todo el proyecto hacia su meta. Esto debe hacerse por
lo menos una vez por Sprint. El Dueño del Producto determina la cantidad de trabajo que queda, y comparándolo con el
resto de trabajo de los Sprints anteriores pronostica la fecha de finalización del proyecto. Todas las partes interesadas
deben tener acceso a esta información.
2.7 Artefacto 6: Seguimiento del progreso del Sprint

Artefacto 6: Seguimiento del progreso del Sprint
La información del progreso Sprint puede representarse en un gráfico de avance, que puede ser una parte del tablón del Sprint, y
estar visible para todo el mundo.
Además de monitorear el progreso del proyecto hacia la meta, también hay que controlar el progreso de cada uno de los
Sprint a lo largo de la vida del proyecto. Esto es responsabilidad del Equipo de Desarrollo y debe hacerse al menos una vez
durante el Scrum Diario.
Esta información es necesaria para calcular la probabilidad de alcanzar el objetivo del Sprint y completar todos los
elementos del Backlog del Sprint.
2.8 Radiadores de Información

Radiadores de Información
El concepto de radiador de Información Los radiadores de información se ubican Considerando la anterior definición, un
se refiere a cualquier elemento o forma en los lugares comunes de trabajo para tablero de un Sprint que se mantiene
de presentar la información relativa al que todos los involucrados puedan ver y actualizado puede considerarse un
proyecto de manera visible. Pueden ser entender en qué situación se encuentra radiador de información. En este caso
grandes pantallas o simples tablones, el proyecto o cualquier otra información sería una combinación de varios
aunque la mayoría de las personas que que ofrezcan. Es más, cualquiera que conceptos (historias de usuario, tareas,
participan en proyectos Ágiles la pase por allí, puede ver y entender el objetivo, definición de hecho, progreso,
presentan en tablones. proyecto, lo que contribuye a aumentar etc.), aunque hay otros radiadores de
la transparencia del proyecto. información que se centran en una sola
parte de la información.


Hay cierta confusión entre el equipo scrum de Automatismos para el Hogar S.L. acerca de los artefactos y de cómo
emplearlos. Como scrum máster deberás ayudarlos en la implementación de scrum y aclarar sus dudas.
3.2 Resumen
Resumen
El Backlog de Producto es una lista ordenada de
todos los elementos que podría necesitar el
producto final, conocidos como historias o
historias de usuario.
Los radiadores de información se ubican en los

lugares comunes de trabajo para que todos los
involucrados puedan ver y entender en qué
situación se encuentra el proyecto.
El gráfico “burn-down” para visualizar el progreso

de todo el proyecto es un gráfico de avance de un
proyecto y muestra la cantidad de trabajo
restante, en lugar de la cantidad de trabajo
realizado.

3.3 Cierre

Comprender como escalar el marco de trabajo

scrum.
Emplear a más de un equipo scrum cuando sea

necesario.

Ya sabemos que en Scrum el tamaño del equipo de desarrollo es de entre 3 y 9 personas; se trata de un equipo muy
productivo y de alto rendimiento, que equipado con un scrum es capaz de entregar un proyecto mucho mejor y más rápido
de lo esperado.
Sin embargo puede ser que algunos proyectos muy grandes o de tamaño mediano, necesiten ser completados en un corto
tiempo, o que simplemente necesitemos acelerar nuestro proyecto. En cualquier caso, hay situaciones en las que el tamaño
estándar del equipo scrum no sea suficiente. ¿Qué hacer en esos casos? En dichos casos podemos utilizar una versión de
Scrum a escala con múltiples equipos, y en esta lección te explicaremos cómo hacerlo.
2.1 ¿Cómo escalar scrum?

¿Cómo escalar scrum?
Cada equipo actúa como un miembro virtual en
un equipo Scrum virtual de nivel superior (Scrum
de Scrums), y por lo tanto, no puede haber más de
9 equipos en un mismo nivel. Sin embargo,
podríamos añadir una nueva capa en función de
nuestras necesidades y tener hasta 9x9 equipos
virtuales (número máximo desarrolladores 9x9x9).
En este caso sería necesaria tener múltiples
Scrum de Scrums para cada grupo de equipos y
luego un Scrum de Scrums de Scrums para todo el
proyecto.

Lo primero que debemos saber al respecto es que no existe un modelo único de Scrum a escala y según la fuente de
referencia aparece definido de una u otra manera.
La idea esencial es tener un equipo Scrum “virtual” que este compuesto por equipos reales de Scrum en lugar de por
personas, y administrar el equipo virtual como si se tratara de un equipo Scrum real (aunque no exactamente igual en
todos los aspectos como ya veremos).
Si necesitamos tener todavía más gente en el proyecto, podemos trabajar con un equipo virtual de equipos virtuales.
2.2 Roles
Roles
Además de los roles estándar de Scrum, aparecen los siguientes:
SCRUM MÁSTER JEFE (TAMBIÉN CONOCIDO COMO

SCRUM DE SCRUMS MÁSTER)
Se trata de un Scrum Máster que ayuda a que todo el proyecto siga el
marco Scrum en colaboración con los Scrum Máster locales. Una persona
puede ser el Scrum Máster local para varios equipos, ya que Scrum Máster
no es necesariamente un trabajo a tiempo completo.
DUEÑO DEL PRODUCTO JEFE

Este rol es el principal responsable del Backlog de Producto y colabora con
los Dueños del Producto locales. Algunas fuentes son contrarias a tener
más de un Dueño del Producto, sin embargo, parece poco realista esperar
que una sola persona pueda colaborar con cientos de desarrolladores (por
ejemplo, aclarando las historias de usuario).
Propiedad del producto

La parte difícil es dividir el trabajo entre varios
equipos. Hay empresas que lo dividen en base a
los procesos de desarrollo; por ejemplo, tienen un
equipo para la programación, otro equipo para las
pruebas, etc. Sin embargo esto no es Ágil, ya que
no estaríamos trabajando en equipos
multifuncionales. Una buena manera de dividir el
trabajo es tener, por ejemplo, un equipo para la
funcionalidad basada en web, otro equipo de la
aplicación móvil, etc. Ya que las historias del
Backlog de Producto deben ser independientes,
podemos inferir que el trabajo de los equipos
también debería serlo; al menos en cierto grado.
Importante
Los equipos no están obligados a utilizar una misma definición de “completo”, debido a las potenciales diferencias que
pudieran existir entre ellos. Sin embargo, las definiciones de “completo” deberían ser compatibles, de manera que cuando
combinemos sus productos, se producirá un incremento potencialmente entregable.
Cada equipo real cumple con las mismas características de cualquier equipo scrum: es auto-organizado y multifuncional, y
es conveniente que incorpore un Scrum Máster.
Algunas fuentes sugieren que exista también un Dueño del Producto local (propio de cada equipo), mientras que otros
defienden que debe haber un solo Dueño del Producto para todo el proyecto.
No importa cuántos equipos están trabajando en el proyecto; sigue siendo un único proyecto, y por lo tanto, debemos tener
un solo Backlog de Producto.
2.3 Scrum de Scrums

Scrum de Scrums
EMBAJADOR
El embajador de cada equipo (representante) es por lo general el miembro
del equipo que está más involucrado en el desarrollo del actual Objetivo del
Sprint; por lo tanto, puede haber diferentes representantes cada vez.
Algunos equipos acostumbran a estar representados por su Scrum Máster
en el Scrum de Scrums, pero es mucho mejor contar con una persona
técnica involucrada en el desarrollo.
PREGUNTAS
Cada embajador responde a las tres preguntas estándar diarias, además de
a una cuarte pregunta extra: “¿Vas a hacer algo que se interponga o afecta
el trabajo de otro equipo?". La cuestión se refiere principalmente a los
bloqueos que un equipo podría crear para los demás. Al respecto, que
mantengamos los elementos del Backlog de Producto independientes
minimiza este tipo de problemas, aunque no los soluciona completamente.
Importante
Cada equipo actúa como un miembro virtual en un equipo Scrum virtual de nivel superior (Scrum de Scrums), y por lo tanto,
no puede haber más de 9 equipos en un mismo nivel. Sin embargo, podemos añadir una nueva capa de escalado para el
modelo y tener hasta equipos de 9x9 (número máximo de desarrolladores 9x9x9). En este caso sería necesario tener
múltiples Scrum de Scrums para cada grupo de equipos y luego un Scrum de Scrums de Scrums para todo el proyecto.
Jerarquía de Scrum
Algunas organizaciones mantienen
Scrum de Scrums todos los días,
mientras que otros prefieren tenerlas
una o dos veces a la semana.
1. En el Scrum de 2. En el Scrum de 3. En el Scrum Diario.

Scrum de Scrum se Scrums, segundo Se reúnen los miembros de
coordina todo el nivel. los equipos Scrum para
proyecto. Se reúnen cuatro miembros coordinar el trabajo diario
Y en este caso se reúnen virtuales que representan a de cada equipo.
cuatro miembros “virtuales”, los equipos Scrum de nivel
es decir que cada miembro inferior para coordinar los
cuenta como un miembro de quipos Scrum de primer
un equipo Scrum, aunque en nivel.
este caso representan a
cada uno de los equipos
Scrum del nivel inferior.

Cada uno de los equipos mantiene su reunión diaria (Scrums diario), preferiblemente al mismo tiempo que los demás.
Finalizadas las reuniones a nivel de equipo, un representante de cada equipo acude a la reunión de alto nivel denominado
Scrum de Scrums para coordinar los equipos.
Si observamos el gráfico podemos ver que:
2.4 Ejemplo
Ejemplo Paso 4 – Escalar scrum
Como scrum máster, el gerente te ha En la actualidad el equipo a cargo del Las nuevas incorporaciones son perfiles
consultado la situación y te ha pedido proyecto está compuesto por 8 técnicos: programadores e ingenieros
asesoramiento respecto a si es o no miembros: que pasarían a formar parte del equipo
posible seguir empleando scrum con el de desarrollo.
aumento de plantilla previsto, y la mejor - Dueño del Producto (1) – Marisol
manera de hacerlo.
- Scrum Master (1) – Manuel
- Equipo de Desarrollo (6): Juan, Lorenzo,

Paco, Ana, Javier y David.
Ha llegado a los oídos del gerente de Automatismos para el Hogar S.L. que su principal competidor está trabajando en un
producto similar. La nueva situación hace necesario reducir los plazos de entrega inicialmente previstos, y para ello el
gerente está dispuesto a incorporar hasta seis nuevos empleados.


3.2 Resumen
Resumen
No existe un modelo único de Scrum a escala y
según la fuente de referencia aparece definido de
una u otra manera.
Scrum Máster Jefe es un Scrum Máster que ayuda

a que todo el proyecto siga el marco Scrum en
colaboración con los Scrum Máster locales.
La parte difícil es dividir el trabajo entre varios

equipos.
3.3 Examen final


Ha llegado el momento de poner a prueba tus conocimientos sobre gestión Ágil y scrum. A continuación debes responder
al siguiente test de 20 preguntas. Para superarlo, debes responder correctamente a 12 de las 20 preguntas (60%).
3.4 Cierre

¡Enhorabuena! Has finalizado este curso sobre Gestión Ágil con Scrum.

Introducción A La Gestión de Proyectos Con Metodología Ágil SCRUM

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Introducción A La Gestión de Proyectos Con Metodología Ágil SCRUM

Cargado por

Copyright:

Formatos disponibles

1.

Conocer los valores del enfoque ágil.

Aplicar los principios del enfoque ágil.

Diferenciar entre maniﬁesto ágil y valores o

TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

2.1 El maniﬁesto ágil

RESPUESTA ANTE EL CAMBIO

El signiﬁcado del Maniﬁesto Ágil. Valor 1: Individuos e interacciones

Transparencia de todos los datos, acciones y

Conﬁanza en que cada persona respaldará al

Compromiso con el equipo y los objetivos del

El signiﬁcado del Maniﬁesto Ágil. Valor 2: Software funcionando sobre

El signiﬁcado del Maniﬁesto Ágil. Valor 3: Colaboración con cliente sobre

Los autores del Maniﬁesto Ágil sabían de qué estaban

El signiﬁcado del Maniﬁesto Ágil. Valor 4: Respuesta ante el cambio

TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

2.2 Preguntas de autoevaluación

2.3 El maniﬁesto ágil

El objetivo es lograr un cliente satisfecho, lo que contribuirá a

Empleando un ciclo de vida adaptable estamos abiertos al

El cliente tendrá una mejor comprensión de lo que quiere

Hay distintos marcos Agiles que emplean diferentes

En un entorno predictivo la participación de la empresa/cliente

Un entorno ágil se basa en un equipo multifuncional y auto-

En un entorno tradicional los miembros del equipo se centran

Aunque ciertamente es una gran ventaja contar con equipos

¡Un producto acabado al 99 % es un producto que esta 0 %

Trabajar no es el objetivo; alcanzar el producto es el objetivo.

No tener un diseño inicial no signiﬁca que no tengamos que

Debemos prestar atención a la excelencia técnica y el buen

Un proyecto Ágil se gestiona y entrega de manera simple. Por

Por lo general la gente trabaja mejor cuando se siente

¡Creemos que siempre hay margen de mejora, sin importar lo

TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

2.4 Preguntas de autoevaluación

3.1 Resumen y autoevaluación

La esencia de toda organización son los

TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

Deﬁnir qué es SCRUM en el ámbito de la gestión

Comprender el funcionamiento del SCRUM en

Aplicar el SCRUM más allá del desarrollo de

Conocer qué es un marco de gestión.

TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

2.1 Qué es SCRUM

Un sistema de gestión del riesgo integrado.

Y una herramienta de gestión de equipos.

Marco de trabajo SCRUM

TRANSCRIPCION DE LA LOCUCIÓN DE LA PÁGINA:

2.2 Cómo funciona

2. EL EQUIPO DE DESARROLLO ESCOGE UN NÚMERO DE

3. LOS ARTÍCULOS SELECCIONADOS DEL BACKLOG DE

4. REALIZAMOS TANTOS SPRINTS COMO SEA NECESARIO

Fin del Proyecto

SCRUM paso a paso

SCRUM paso a paso. Desglose

El Dueño del Producto; es la persona responsable de crear y

BACKLOG DEL PRODUCTO

La Planiﬁcación del Sprint, una breve reunión en la que se

NUEVOS BACKLOGS DE PRODUCTO

2.3 Cuando aplicar SCRUM

Cuando nos enfrentamos a problemas complejos los resultados se vuelven

LOS PLAZOS AGRESIVOS