The Scrum Map

Este libro fue desarrollado por CertMind como guía complementaria para la guía oficial The Scrum
Guide: The Definitive Guide to Scrum: The Rules of the Game (2020) para la gestión exitosa de
proyectos ágiles usando Scrum. El contenido aquí descrito, es el resultado de varios años de
investigación realizada por nuestros consultores expertos, estudiantes y voluntarios que aportaron
su valioso conocimiento e hicieron posible la construcción de esta guía complementaria. Aún
cuando hoy en día existen varios marcos de referencia basados en Scrum, nuestro enfoque está
centrado principalmente en el artículo “The New New Product Development Game” escrito en la
Harvard Business Review por Hirotaka Takeuchi e Ikujiro Nonaka y posteriormente la guía
desarrollada por Jeff Sutherland y Ken Schwaber. Antes llamado “An Agile Approach to Manage
Successful Projects”

1. Introducción a Scrum

2. Modelo Core de Scrum

El equipo Scrum

Historias de Usuario

Artefactos en Scrum

Eventos en Scrum

3. Scrum aplicado a proyectos

Consideraciones para la gestión de un proyecto basado en Scrum

7.1 - Etapa 1: Inicio del proyecto

7.2 - Etapa 2: Planificación del Sprint

7.3 - Etapa 3: Desarrollo del Sprint

7.4 - Etapa 4: Revisión del Sprint

7.5 - Etapa 5: Implementación

7.6 - Etapa 6: Cierre del proyecto

4. Pilares de Scrum

4.1 - Control empírico de procesos (Pilar #1)

4.2 – Auto-gestión (Pilar #2)

4.3 – Simplicidad (Pilar #3)

4.4 - Centrado en el valor para cliente (Pilar #4)

4.5 – Cumplimiento (Pilar #5)

4.6 - Desarrollo iterativo (Pilar #6)
1. Introducción a Scrum
Este libro fue desarrollado por CertMind como guía complementaria para la guía oficial The
Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game (2020) para la
gestión exitosa de proyectos ágiles usando Scrum. El contenido aquí descrito, es el resultado de
varios años de investigación realizada por nuestros consultores expertos, estudiantes y voluntarios
que aportaron su valioso conocimiento e hicieron posible la construcción de esta guía
complementaria.

Aún cuando hoy en día existen varios marcos de referencia basados en Scrum, nuestro enfoque
está centrado principalmente en el artículo “The New New Product Development Game” escrito en
la Harvard Business Review por Hirotaka Takeuchi e Ikujiro Nonaka y posteriormente la guía
desarrollada por Jeff Sutherland y Ken Schwaber.

Este libro es la base fundamental para la obtención de las certificaciones CM-SFC (Scrum
Fundamentals Certified), CM-SMC (Scrum Master Certified), CM-SDC (Scrum Developer Certified),
CM-SPOC (Scrum Product Owner Certified) y CM-Scrum Expert que hacen parte del esquema de
certificación en Scrum de CertMind.

Antes llamado “An Agile Approach to Manage Successful Projects”

1.1 - Historia
La historia de Scrum se puede rastrear desde 1986 en un artículo de la Harvard Business Review,
“The New New Product Development Game” escrito por Hirotaka Takeuchi y Ikujiro Nonaka, en el
que analizaron el enfoque que utilizaban compañías como Fuji-Xerox, Canon, Honda, NEC, Epson,
Brother, 3M, Xerox, y Hewlett-Packard para el desarrollo de sus productos.

Durante sus investigaciones, se dieron cuenta que dichas empresas compartían seis
características: inestabilidad incorporada, equipos de proyectos autoorganizados, fases de
desarrollo superpuestas, multi-aprendizaje, control sutil y transferencia organizativa de
aprendizaje. Las seis piezas encajan como un rompecabezas, formando un proceso rápido y
flexible para el desarrollo de nuevos productos. Igual de importante, este nuevo enfoque puede
actuar como un agente de cambio: es un vehículo para introducir ideas y procesos creativos e
impulsados por el mercado en una organización antigua y rígida.

Es también en este artículo donde se hace la comparación de los procesos de Scrum con el juego
del Rugby, y de donde se origina su nombre Scrum.
El artículo original se puede leer en: https://hbr.org/1986/01/the-new-new-product-development-

game

Posteriormente son Ken Schwaber y Jeff Sutherland quienes trabajaron en Scrum desde 1995,
cuando conjuntamente lo presentaron en la conferencia OOPSLA en 1995. Esta presentación
documentó principalmente el aprendizaje que Ken y Jeff habían obtenido a lo largo de los años e
hicieron pública la primera definición formal de Scrum. Para hacer honor a los primeros lugares
donde fue probado y perfeccionado, reconocemos a Individual, Inc., Newspage, Fidelity
Investments e IDX (en la actualidad GE Medical).

La Guía de Scrum documenta Scrum tal y como ha sido desarrollado, evolucionado, y mantenido
por más de veinte años por Jeff Sutherland y Ken Schwaber. Otras fuentes proporcionan patrones,
procesos e ideas que complementan al marco de trabajo Scrum. Estas pueden incrementar la
productividad, valor, creatividad y satisfacción con los resultados.

1.2 - Definición de Scrum

Scrum es un marco de trabajo (framework en inglés) a través del cual las personas pueden
abordar problemas complejos de manera adaptativa, a la vez que se entregan productos de forma
eficiente y creativa con el máximo valor. Scrum es:

Ligero
Simple de entender
Difícil de dominar

Scrum está compuesto de prácticas que se han utilizado para gestionar el desarrollo de productos
complejos desde principios de los años 90.

Scrum no es un proceso, una técnica, o método definitivo. Todo lo contrario, es un marco de

trabajo donde se pueden emplear un conjunto de diferentes procesos y técnicas. Scrum muestra
la eficacia relativa de las técnicas de gestión de producto y de trabajo de modo que podamos
continuamente mejorar el producto, el equipo y el entorno de trabajo.

1.2.1 - Agilidad
La agilidad es una mejor manera de resolver problemas complejos, con enfoque en la generación
de espacios de colaboración, confianza e innovación.

La habilidad para aplicar estas técnicas de trabajo está determinada por el hecho de que los
equipos de trabajo sean multifuncionales, enfocados en el cliente y autogestionados, lo cual
contribuye de forma eficiente a generar estrategias enfocadas al cambio, permitiendo identificar
rápidamente la mejora en los procesos; haciendo que se defina y construya el producto de
acuerdo con las necesidades de la empresa y del cliente. Por lo general todos los métodos ágiles
están diseñados para que el equipo de trabajo realice el trabajo de manera incremental e
iterativamente.

Algunos elementos clave en la adopción de la agilidad son:

Visual Thinking (Pensamiento Visual)

Consiste en el desarrollo de ideas mediante el uso de imágenes y recursos visuales, los cuales
permiten identificar de manera más clara la estructura del mensaje que se quiere trasmitir.
También permite la identificación de problemas a través del uso de dibujos sencillos acompañados
de frases o palabras claves.

El Visual Thinking, ayuda a representar de forma gráfica las ideas, informes, planes, etc, de tal
forma que permita facilitar su construcción, análisis, y presentación. El Visual Thinking es clave en
el entendimiento de varias prácticas ágiles, es por ello que en Scrum se encuentran elementos
visuales como tableros, herramientas, e incluso informes presentados de la forma más vistosa
posible. El Visual Thinking tiene las siguientes características:

Texto: Se usan diferentes tipografías, tamaño y grosor para hacer más llamativa la
información.
Iconografía: Se usan bastantes elementos gráficos sencillos que permiten representar la
información
Color: El uso del color da valor a nuestras ideas y representaciones.

Además, muchas organizaciones combinan el Visual Thinking con herramientas como las
propuestas por Design Thinking (Pensamiento de Diseño) para hacer que las prácticas de Scrum
sean más eficientes y sencillas de entender por las partes interesadas.

dibujo

Motivación del equipo

Cuando se trabaja en entornos de trabajo multidisciplinarios, la motivación es uno de los aspectos
más importantes a tener en cuenta para conseguir un entorno de trabajo colaborativo y altamente
competitivo, para lo cual es necesario promover a través del aprendizaje y la confianza, el
desarrollo de habilidades de comunicación entre el colaborador y la empresa que garanticen el
cumplimiento de las metas y retos individuales de cada una de las partes.

Es aquí donde queremos destacar el esfuerzo realizado por el autor Jurgen Appelo, en su

publicación “Management 3.0”.

Optimización
Consiste en hacer el mejor uso de los recursos y tiempos disponibles en el desarrollo de procesos
y/o tareas, para lo cual es necesario identificar el problema correctamente y detallar los cambios
que se requieren para abordarlo, además de identificar el resultado que sea eficiente y productivo.
Este es un elemento clave en agilidad, que está directamente relacionado con la disminución de la
burocracia organizacional (la cual afecta negativamente cualquier iniciativa Scrum).

1.2.2 - Cultura Ágil

La cultura ágil o también llamada Cultura Agile consiste en trasformar la manera de trabajar,
adoptando metodologías que permiten reducir la complejidad y focalizar el trabajo en la creación
de productos o servicios de valor, que satisfagan las necesidades del cliente. La cultura agile tiene
como objetivo hacer que los equipos de trabajo se potencialicen con el fin de obtener resultados
en periodos de tiempo más cortos y dinámicos, orientados a la excelencia, la competitividad y la
colaboración de todos los miembros del equipo.

dibujo

Existen varias diferencias entre “Ser” y “Hacer” Ágil, por un lado, en el “Hacer” nos encontramos
con las prácticas, las ceremonias (eventos) y los roles, por otro lado, el “Ser” se enfoca más en la
mentalidad de las personas, la colaboración, el centrarse en el cliente y en fomentar los valores y
principios en los equipos ágiles. Así que existen varias organizaciones que hacen ágil, y otras que
son ágiles.

Recuerda que debería existir un poco de ambas en una correcta adopción de Scrum, así que no
debes centrarte sólo en una o en otra.

1.2.3 - ¿Es valioso trabajar con

procesos?
Si bien, en muchas organizaciones trabajar con procesos es visto como una gran ventaja porque
asegura el buen desempeño de sus colaboradores, cuando hablamos de entornos ágiles,
tendremos que ver la situación desde otro punto.

Las organizaciones cuentan con modelos de operación que tienden a comportarse de manera
“estática”, en los que generalmente encontramos una estructura de jerarquías y burocracia,
donde de manera rutinaria los colaboradores conocen los productos/servicios de la organización y
saben cómo operar en el día a día para garantizar su adecuada entrega; sin embargo con los
proyectos no siempre ocurre lo mismo debido a que los miembros del equipo de proyecto
comúnmente se enfrentan a nuevos desafíos que los impulsa a cambiar constantemente y tomar
una conducta autónoma en determinadas situaciones.

Por otro lado, vemos que las organizaciones fácilmente pueden percibir los beneficios de los
procesos (facilitan las revisiones de calidad, la inducción del personal, las auditorías, etc) siempre
y cuando estos procesos se lleven a la práctica y no permanezcan como simples documentos, ya
que por sí solos no traen valor a la organización. Esta premisa aplica tal cual, a los proyectos
ágiles, pues cuando hablamos de procesos en los proyectos debemos mantener un enfoque hacia
la práctica (que sean interiorizados y ejecutados naturalmente por todos los miembros),
manteniendo un sano equilibrio entre la típica burocracia organizacional (que desfavorece la
agilidad) y la anarquía (que disminuye la credibilidad en el equipo). Cuando se encuentra y
mantiene el punto medio entre estas dos, el equipo se encuentra en un entorno de agilidad: sin
burocracia absoluta y sin anarquía absoluta.

dibujo

1.3 - Anglicismos
En este libro se utilizan varios términos utilizados originalmente en inglés, esto con el fin de no
causar confusiones con las distintas traducciones que a estos se les pueden dar. A continuación,
se encuentra el listado de términos que NO fueron traducidos en esta publicación, es decir, que se
mantienen en su forma original:

Burndown chart: Cuadro de quemado hacia abajo o avance

Developer: Desarrollador, quien ejecuta o desarrolla el trabajo
Framework: Marco de trabajo
Product Backlog: Lista de pendientes del producto
Product Goal: Objetivo de producto
Product Owner: Propietario (Dueño) del producto
Scrum Board: Tablero Scrum
Scrum Master: Maestro Scrum
Sprint: Iteración
Sprint Backlog: Lista de pendientes del Sprint
Sprint Goal: Objetivo del Sprint

1.4 - Estructura de la guía

Esta guía se compone por:
 Modelo Core de Scrum: Explica los roles y conceptos para entender el núcleo del marco,
como: El Equipo Scrum, Eventos, Artefactos y lineamientos relacionados.
Scrum aplicado a proyectos: Donde se explican los elementos clave que se deben tener
en cuenta para garantizar el correcto desarrollo de un proyecto.
Ciclo de vida de un proyecto Scrum: Esta sección explica cómo poner en marcha todos
los conceptos aprendidos, describiendo las prácticas clave y su “orden lógico” en un
proyecto de la vida real.
Pilares de Scrum: Donde se habla de 6 elementos esenciales para garantizar el éxito en la
aplicación de Scrum.

Cada componente dentro de la guía tiene un propósito específico y es esencial para el éxito en la
adopción de Scrum

dibujo

1.5 - Usos de Scrum

Scrum inicialmente fue desarrollado para gestionar y desarrollar productos. Sin embargo, su uso
no se vio limitado a este campo, y con el tiempo la experiencia recaudada nos muestra que es útil
para:

1. Investigar e identificar mercados viables, tecnologías, y capacidades.

2. Desarrollo de mejoras a productos ya existentes.
3. Desarrollo de productos que requieren lanzamientos diariamente o tantas veces como
sea posible.
4. Desarrollo y mantenimiento en la Nube (online, seguridad, por-demanda) y otros
entornos operacionales de desarrollo para el uso de productos.
5. Mantenimiento y renovación de productos.
6. Scrum se ha demostrado especialmente efectivo en la transferencia de conocimiento
iterativa e incrementalmente. Scrum es ampliamente utilizado para la construcción de
productos y servicios.

1.5.1 - ¿Cuándo utilizar las

metodologías ágiles?
dibujo
1.6 - Aclaraciones de la guía
Esta es una guía llena de conceptos, ideas y técnicas para adoptar Scrum de forma sencilla,
esto no significa que sea un plan de implementación exacto, por lo que debe tomarse como
consejos y no como una plantilla.
En el desarrollo de esta guía el término “Producto” se refiere a productos, servicios y
cualquier otro entregable que pueda surgir como resultado de un ejercicio de proyecto.
Cuando los conceptos “Desarrollo” y “Desarrollar” se utilizan en esta guía de Scrum, se
refieren al desarrollo de las actividades propias del proyecto, no se ven limitados al campo
del desarrollo de software.

1.7 - Escalabilidad de Scrum

Scrum puede ser utilizado en grandes proyectos sin importar la cantidad de personas o
actividades a desarrollar, esto siempre y cuando se respete la regla de formar pequeños equipos
de personas, ya que este tipo de equipos son muy flexibles y adaptivos. Las fortalezas de los
equipos Scrum que permiten su fácil escalamiento son:

Pueden operar individualmente, en varios, muchos, e incluso en redes de equipos.

Su capacidad multifuncional les permite desarrollar, lanzar, operar y mantener el trabajo y el
producto con la menor cantidad de dependencias posibles.
La colaboración y la interacción continua entre equipos y con el cliente les permite
desarrollar arquitecturas más sofisticadas en los entornos de desarrollo.

1.8 - ¿Scrum se implementa

o se adopta?
El marco de trabajo Scrum consiste más en un cambio cultural en toda la organización que en
simplemente la implementación de las herramientas o técnicas aquí descritas, así que es erróneo
pensar en la “implementación” de Scrum, lo más apropiado es hablar de la “adopción” de Scrum,
ya que se necesita poner en marcha las prácticas propuestas, realizar experimentos y estar
ajustando continuamente el marco de trabajo a las necesidades cambiantes de la organización.

Para la adopción de las prácticas Scrum se requiere el apoyo de toda la organización, esta cultura
orientada hacia lo ágil está basada en la simplicidad, el valor y el alto rendimiento que se necesita
para la gestión de proyectos modernos.

Los detalles para adoptar Scrum se encuentran en la Guía de Adopción de Scrum.

2. Modelo Core de Scrum
2. Modelo Core de Scrum

El equipo Scrum

Un Equipo Scrum consiste en un Propietario del Producto (Product Owner), un Scrum Master y los
Developers.

Los Equipos Scrum son autoorganizados y multifuncionales. El modelo de Equipo en Scrum está
diseñado para optimizar la flexibilidad, la creatividad y la productividad. El Equipo Scrum ha
demostrado ser incrementalmente efectivo en diferentes contextos y para cualquier trabajo
complejo.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las
oportunidades para poder obtener retroalimentación. Las entregas incrementales de producto
“Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional
del producto.

Tamaño del Equipo Scrum

El tamaño óptimo del Equipo Scrum es de máximo 10 miembros, esto le permite ser lo
suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para
poder completar una cantidad significativa de trabajo.
 No se recomienda tener menos de 3 miembros en el Equipo pues se reduce la interacción y
resulta en baja productividad.
Los Equipos más pequeños pueden encontrar limitaciones en cuanto a las habilidades
necesarias durante un Sprint, haciendo que el Incremento pudiese no ser significativo parael
cliente.
Tener más de 10 miembros en el equipo requiere demasiada coordinación.
Los Equipos muy grandes generan demasiada complejidad como para que un proceso
empírico pueda ser de utilidad.
Los roles de Product Owner y Scrum Master no se cuentan como Developers, a menos que
también estén contribuyendo al desarrollo del trabajo durante el Sprint.

1. El Product Owner (Dueño

de Producto)

El Product Owner es el responsable de maximizar el valor entregado por los Developers.

El Product Owner es la única persona responsable de gestionar el Product Backlog. La gestión del
Product Backlog incluye:

Expresar claramente los elementos del Product Backlog.

Ordenar los elementos en el Product Backlog para alcanzar los objetivos y las misiones de la
mejor manera posible.
Garantizar que el Product Backlog sea visible, transparente y clara para todos y que
muestre, lo que el equipo trabajará a continuación.
Asegurar que los Developers entienden los elementos del Product Backlog a nivel necesario.
El Product Owner es una única persona, no un comité. El Product Owner podría representar
los deseos de un comité en el Product Backlog, pero aquellos que quieran cambiar la
prioridad de un elemento del Product Backlog deben hacerlo a través del Product Owner.

Para que el Product Owner pueda hacer bien su trabajo, toda la organización debe respetar sus
decisiones. Las decisiones del Product Owner se reflejan en el contenido y en la priorización del
Product Backlog.
El Product Owner también es responsable de:

Participar en las reuniones de apertura y cierre del proyecto.

Participar en las reuniones de planificación y revisión de las iteraciones (sprints).
Entender las necesidades de las partes interesadas para posteriormente levantar los
requerimientos que harán parte del Product Backlog.
Mantener comunicación frecuente con el cliente (ya que es el único punto de contacto entre
el cliente y el Equipo Scrum).
Gestionar los riesgos globales del proyecto.
Presentar informes del proyecto al cliente u otras partes interesadas.
Aprobar cambios en el proyecto.
Asegurar que se administran correctamente los recursos financieros del proyecto al inicio y
durante su ejecución.

Normalmente el rol del Product Owner se asocia con un Gerente de Proyecto, dadas sus
responsabilidades de gestión, sin embargo, estos roles NO son iguales. Es más preciso asociarlo
al rol que representa “La voz del cliente”.

2. Desarrolladores
(Developers)

Los Developers son los profesionales que realizan el trabajo de entregar un Incremento de
producto “Terminado” (Done) que potencialmente se pueda poner en producción al final de cada
Sprint. Un Incremento de producto “Terminado” es obligatorio en la Reunión Revisión del Sprint.
Solo los Developers participan en la creación del Incremento.

La organización es la encargada de estructurar y empoderar a los Developers para que estos

organicen y gestionen su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad
del Equipo Scrum en conjunto.

Los Developers tienen las siguientes características:

Son autogestionados. Nadie (ni siquiera el Scrum Master) les da órdenes o imposiciones
sobre cómo convertir elementos del Product Backlog en Incrementos de funcionalidad
 potencialmente desplegables.
Nadie fuera del Scrum Master y el Product Owner puede pedir a los Developers que trabajen
en un conjunto diferente de requisitos que previamente hayan sido planeados y acordados.
Los Developers son multifuncionales, con todas las habilidades necesarias para crear un
Incremento de producto.
Scrum no reconoce títulos para los miembros de un Equipo Scrum, independientemente del
trabajo que realice cada persona, quienes ejecuten el trabajo necesario para construir el
producto se conocen como Developers.
No existen sub-equipos en el Equipo Scrum, no importan los dominios particulares que
requieran tenerse en cuenta, como pruebas, aseguramiento de calidad, arquitectura,
operaciones, o análisis de negocio.
Los Developers pueden tener habilidades especializadas y áreas en las que estén más
enfocados, pero la responsabilidad del producto recae sobre los Developers como un todo.

3. El Scrum Master (Maestro

Scrum)

El Scrum Master es el responsable en promover y apoyar Scrum como se define en la Guía de

Scrum. Su principal responsabilidad entonces es garantizar que todos conocen y aplican
correctamente la teoría y práctica de Scrum.

El Scrum Master es un líder que sirve al Equipo Scrum y en general a toda la organización.
El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué
interacciones con el Equipo Scrum pueden ser útiles y cuáles no.

El Scrum Master al servicio del

Equipo Scrum
El Scrum Master sirve al Equipo de varias formas, incluyendo:

Guiar al Equipo de Desarrollo para que aprendan a ser autogestionados y multifuncionales.

Ayudar al Equipo a centrarse en crear productos de alto valor además de cumplir con la
Definición de Terminado.
Eliminar impedimentos para el progreso del Equipo.
Facilitar los eventos de Scrum según se requiera o necesite, para que sean productivos,
respetando el tiempo designado para cada uno (time-box).
Guiar al Equipo Scrum en entornos organizacionales en los que Scrum aún no haya sido
adoptado y entendido por completo.

dibujo

El Scrum Master al servicio del

Product Owner
El Scrum Master sirve al Product Owner de varias formas, incluyendo:

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos
en el Equipo de la mejor manera posible.
Ayudar a encontrar técnicas para gestionar el Product Backlog, definir el Objetivo de
Producto (Product Goal) y gestionar los atrasos en el producto.
Ayudar al Equipo Scrum a entender la necesidad de contar con elementos del Product
Backlog claros y concisos.
Entender la planificación del producto en un entorno empírico y complejo.
Ayudar a entender y practicar la agilidad.
Facilitar la colaboración de las partes interesadas y/o cliente según sea necesario.

El Scrum Master al servicio de la

Organización
El Scrum Master sirve a la organización de varias formas, incluyendo:

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

Planificar y asesorar en la adopción de Scrum en la organización.
Ayudar a los empleados e interesados a entender y poner en práctica un enfoque empírico
en el desarrollo del trabajo.
Motivar cambios que incrementen la productividad en la organización.
 Junto con otros Scrum Masters, incrementar la efectividad de la adopción de Scrum en la
organización.
Eliminar las barreras de comunicación entre los Equipos Scrum y las diferentes partes
interesadas.

4. Comunicación en el
equipo

5. Los valores del equipo

Es importante que entre los miembros del equipo se genere y mantenga una filosofía basada en
valores que fomenten la confianza, la comunicación y la entrega de resultados. El Scrum Master es
el encargado principal de promover estos valores en el equipo. A continuación, se relacionan los
valores que deberían existir en un equipo Scrum.
Compromiso
El compromiso se refiere a que cada miembro del Equipo hará el máximo esfuerzo posible,
además pondrá dedicación a todas las actividades necesarias para el desarrollo del producto.

Respeto
Los miembros del Equipo Scrum respetan el conocimiento, las habilidades y la experiencia
profesional no solo del resto de miembros del equipo, sino también de aquellas personas con las
que se relacionan, sean de su propia organización o de otra.

Proactividad
La proactividad les permite a los miembros del Equipo el desarrollo exitoso de su trabajo. Este
valor es fundamental para lograr buenos resultados en los entornos cambiantes a los que se
encuentran expuestos los proyectos ágiles, este valor no se limita a la adaptabilidad (responder al
cambio), la proactividad se trata de iniciar el cambio.

Receptividad + Apertura
Los miembros del Equipo Scrum deben estar abiertos a aprender nuevas habilidades o adquirir
nuevos conocimientos que les permitan ser Equipos multi-funcionales. Este valor también está
relacionado con la transparencia, la colaboración y el libre conocimiento.

Foco
Este principio les permitirá a los miembros del Equipo Scrum centrarse en solo aquellas
actividades clave que permitirán ofrecer el mejor producto o servicio, el foco se trata de centrarse
en todo aquello que es realmente importante no sólo para el producto sino también para el
bienestar del equipo.
2. Modelo Core de Scrum

Historias de Usuario
Las Historias de Usuario (User History) son la forma recomendada en entornos ágiles para escribir
los requisitos del producto expresados por los usuarios. Dado que son afirmaciones breves,
simples y fáciles de entender, resultan en una mejor comunicación entre los Stakeholders y el
equipo Scrum.

Al redactar una Historia de Usuario se debe tener en cuenta describir el rol, la funcionalidad y el
resultado esperado en una frase corta. Debe venir acompañada de los criterios de aceptación que
debe cumplir la Historia de Usuario.

Las Historias de Usuarios centran la atención en los usuarios finales, por lo que no utilizan un
lenguaje técnico, con el fin de facilitar el entendimiento para los usuarios y asimismo ofrecer un
contexto suficiente para guiar el esfuerzo de los Developers.

“ “Las historias centran la atención en el usuario. Una lista de tareas pendientes

mantiene al equipo centrado en tareas que deben completarse, pero un
conjunto de historias lo mantiene centrado en solucionar problemas para
usuarios reales.”

Estructura de una Historia de

Usuario
Las Historias de Usuario suelen expresarse como una frase simple y breve que cumple con la
siguiente estructura:

Como: Describe el Rol del Stakeholder que solicita (o usaría) la funcionalidad o requerimiento.

Quiero: Describe la necesidad o requerimiento del usuario, por lo general, es una frase corta.

Para: Describe el beneficio esperado por el Stakeholder una vez se desarrolle el requerimiento

Ejemplos de Historias de Usuario

 “ Como: Cliente, Quiero: pagar mi suscripción mensual vía sitio web por medio
de transferencia bancaria o tarjeta de crédito, Para: evitar el desplazamiento
hasta la sucursal de pago.

“ Como: Supervisor de ventas, Quiero: consultar un listado de los pedidos de

venta que han sido registrados y aún no han sido procesados, Para: Tener un
reporte detallado a la mano.

“ Como: Ejecutivo de cuenta, Quiero: consultar los datos de un cliente

suministrándole al sistema únicamnte su documento de identidad o código de
cliente, Para: facilitar el proceso de busqueda y reducir el tiempo de atencion.

“ Como: asesor de ventas, Quiero: disponer de una diadema inalámbrica, Para:

poder levantarme regularmente de mi puesto y disminuir el estrés y el
cansancio.

Componentes adicionales de una

Historia de Usuario
Una Historia de Usuario puede tener componentes adicionales que permitan mejorar su
entendimiento tanto para el usuario como para los Developers. Usualmente estos componentes
son:

Criterios de aceptación (detalle técnico)

Estimaciones
Prototipos, Diagramas, etc.

1. Criterios de aceptación (detalle técnico)

“
 Microsoft define a los criterios de aceptación como las condiciones que un
producto de software debe satisfacer para ser aceptado por un
usuario, cliente o stakeholder.

“ Para Google, son estándares pre-establecidos o requerimientos que un

producto o proyecto debe satisfacer.

Concretamente en Scrum, se los define como un conjunto de sentencias redactadas de tal manera
que conduzcan a una respuesta clara de “aceptado/rechazado”. Detallan las especificaciones
técnicas de cada Historia de usuario o Tarea.

El Product Owner es el responsable de redactar los criterios de aceptación para cada Historia de
Usuario en conjunto con el cliente y/o los interesados, para posteriormente confirmarlos con los
Developers antes de desarrollar la Historia de Usuario. Esta confirmación se realiza durante la
Reunión de Planificación del Sprint (Ceremonias).

Los criterios de aceptación ayudan a los Developers a entender el funcionamiento del producto, de
manera que estimarán mejor el trabajo necesario, además de servir como guía para tomar
decisiones más acertadas de acuerdo a lo que se espera de la Historia de Usuario.

Un criterio de aceptación debe poder probarse o testearse, cuando no es posible probar algun
criterio de aceptación es un claro indicio de una mala redacción del mismo. Se debe tener en
cuenta que al probar una Historia de Usuario frente a un criterio de aceptación se obtiene una
respuesta binaria: Cumple o No cumple; no existe el concepto de cumplir parcialmente un criterio
de aceptación.

Algunos beneficios de contar con buenos criterios de aceptación:

Permite que los Developers entiendan una funcionalidad desde la perspectiva del usuario.
Reduce las ambigüedades al desarrollar las Historias de Usuario.
Promueve la calidad del producto permitiendo que los Developers se adhieran a los criterios
de aceptación antes de una demostración de los resultados.
Permiten confirmar si una Historia de Usuario se comporta de acuerdo a lo esperado.

Una manera opcional de construir los criterios de aceptación es la siguiente:

Cuando (Rol) hace (Acción) consigue (Resultado / Comportamiento esperado)

Algunos ejemplos:

Cuando el cliente (Rol) pide dinero (Acción), si hay saldo positivo, el dinero se debita de la
cuenta y es entregado al cliente.
Cuando el cliente (Rol) pide dinero (Acción), si hay saldo negativo, se muestra mensaje
 "Saldo no disponible", y no se entrega el dinero al cliente.

2. Estimaciones
Es muy importante realizar la estimación del trabajo requerido para desarrollar las Historias de
Usuario y las tareas relacionadas, de esta manera se logran planificaciones más precisas.

La estimación no la determina el cliente o el Product Owner, sino los Developers en conjunto con
el Scrum Master y el Product Owner, ya que ellos son quienes ejecutarán directamente el trabajo
necesario.

Para garantizar una estimación más precisa, se pueden considerar elementos como:

Dificultad / complejidad: Hace referencia a qué tanto esfuerzo se requiere para ejecutar
determinado trabajo. Se utilizan los Puntos de historia como unidad de medida.
Duración: Hace referencia a cuánto tiempo se requiere para ejecutar determinado trabajo.
Se puede utilizar horas o días como unidad de medida.
Costo: Hace referencia al dinero requerido para la ejecución de un determinado trabajo, el
cual se calcula a partir del trabajo de los developers más los recursos necesarios para su
ejecución.

Uno de los problemas más comunes con la estimación de las historias de usuario, es sólo se
estimar la dificultad (puntos de historia), o sólo estimar la duración (horas / días); por lo que es
altamente recomendable estimar los dos. Muchos equipos prefieren unificar esto mediante una
relación entre los puntos de historia y la duración, es decir que para cada punto de historia se
asigna un tiempo determinado.

El manejo de puntos de historia es específico de cada equipo, no es recomendable comparar

diferentes equipos basados en sus estimaciones (aunque sean equipos del mismo proyecto) ya
que cada equipo tiene diferente capacidad de trabajo.

A continuación se muestra un ejemplo de ello:

Un equipo A definió la siguiente tabla de estimaciones para el proyecto en el que esta trabajando
actualmente:

El equipo B definió la siguiente tabla de estimaciones para su proyecto:

3. Prototipos, Diagramas, etc
Los prototipos, diagramas, esquemas de una Historia de Usuario nos sirven para mostrar un
acercamiento al resultado que se espera obtener en cuanto los Developers ejecuten su trabajo, de
esta manera se puede probar el producto antes de construirlo para identificar posibles errores y
generar un mejor entendimiento para los Developers.

Permiten a los Developers desarrollar su trabajo en torno a una guia clara sobre las
expectativas del cliente/usuario final.
Constituyen un gran apoyo para lograr mejores estimaciones de trabajo.
Son más fáciles de abordar con los usuarios finales.
Permite que el usuario se sienta involucrado en construcción del producto, ya que puede
"verlo por adelantado".
Se reduce el riesgo o la incertidumbre sobre el resultado de producto esperado.

Épica
Es comun que existan Historias de Usuario de gran tamaño y/o gran complejidad Cuando se
permiten agrupar los elementos del Product Backlog, permitiendo una mejor navegación por el
mismo. Algunas ideas de las que se podrían definir las épicas son: • Módulos. • Componentes. •
Hitos. • Entregables. • Funcionalidades.

![]Una épica no es más que un nivel de agrupación por encima de las historias de usuario que
permite clasificar las mismas por funcionalidades, módulos, subsistemas, etc. En muchas
ocasiones las épicas, son demasiado largas (o complejas) para ser completadas en un solo Sprint
(http://books.certmind.org/loading.gif#uploadimage-359f4a12bf4c8)
2. Modelo Core de Scrum

Artefactos en Scrum
Los artefactos de Scrum representan el trabajo o el valor en diversas formas, los cuales son útiles
para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos
definidos por Scrum están diseñados específicamente para maximizar la transparencia de la
información clave, necesaria para asegurar que todos tengan el mismo entendimiento sobre el
Producto.

Cada artefacto está vinculado con un compromiso para garantizar que se cuenta con información
suficiente sobre el producto, esto mejora la transparencia y el enfoque con el que se puede medir
el progreso:

Para el Product Backlog el compromiso es el Objetivo de Producto (Product Goal).

Para el Sprint Backlog el compromiso es el Objetivo del Sprint (Sprint Goal).
Para el Incremento el compromiso es la Definición de Terminado (Definition of Done - DoD).

4.1 - Product Backlog

El Product Backlog es una lista ordenada de todo los elementos que podrían ser necesarios para el
producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto, y
también es la única fuente de trabajo para el Equipo Scrum. El Product Owner es el responsable
del Product Backlog, incluyendo su contenido, disponibilidad y ordenación.

Un Product Backlog siempre esta en constante actualización. El desarrollo inicial de los elementos
del Product Backlog solo refleja los requisitos conocidos y mejor entendidos al principio.

El Product Backlog evoluciona a medida que el producto y el entorno en el que se usará también lo
hacen. El Product Backlog es dinámico; cambia constantemente para identificar lo que el producto
necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Product Backlog
también existe.

El Product Backlog enumera todas las características, funcionalidades, requisitos, mejoras,

correcciones y cambios a realizarse sobre el producto para entregas futuras. Los elementos del
Product Backlog tienen como mínimo los siguientes atributos:
 La descripción (en función del valor para el negocio)
El orden (prioridad)
La estimación
Los criterios de aceptación

A medida que un producto es utilizado y se incrementa su valor y el mercado proporciona

retroalimentación, el Product Backlog se convierte en una lista más larga y exhaustiva. Los
elementos estan en constante actualización así que el Product Backlog es un artefacto vivo. Los
cambios en los requisitos de negocio, las condiciones del mercado o la tecnología podrían causar
cambios en el Product Backlog.

¡Nota Importante! Para evitar proyectos que nunca terminan, es importante considerar el
alcance del producto a la hora de refinar el Product Backlog.

4.2 - Sprint Backlog

El Sprint Backlog es el conjunto de los elementos del Product Backlog seleccionados para
desarrollar durante un Sprint, el cual constituye un plan para entregar el Incremento de producto y
conseguir el Objetivo del Sprint.

El Sprint Backlog es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad
formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad en
un Incremento “Terminado”.

Cuando se requiere nuevo trabajo, el Equipo de Desarrollo lo adiciona al Sprint Backlog. A medida
que el trabajo se ejecuta o se completa se va actualizando la estimación de trabajo restante.
Cuando algún elemento del plan se considera innecesario, es eliminado. Solo el Equipo de
Desarrollo puede cambiar su Sprint Backlog durante un Sprint. El Sprint Backlog es una imagen
visible en tiempo real del trabajo que el Equipo de Desarrollo planea llevar a cabo durante el
Sprint y pertenece únicamente al Equipo de Desarrollo.

El Sprint Backlog hace visible todo el trabajo que el Equipo de Desarrollo debe completar
para alcanzar el Objetivo del Sprint.
Para asegurar el mejoramiento continuo, en el Sprint Backlog se incluye por lo menos una
actividad que permita la mejora de procesos (normalmente identificadas en la Retrospectiva
inmediatamente anterior).
El Sprint Backlog es un plan con un nivel de detalle suficiente como para que los cambios en
el progreso se puedan entender en el Scrum Diario.

4.2.1 - Incremento
Un Incremento es la suma de todos los elementos del Product Backlog completados durante un
Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint el nuevo
Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y
que cumple la Definición de “Terminado” del Equipo Scrum.

El incremento es un paso hacia la visión o meta del proyecto.

El incremento debe estar en condiciones de utilizarse sin importar si el Product Owner,
decide liberarlo o no.

4.3 - Emisores de
Información
Los emisores de información son artefactos que permiten visualizar gráficamente el estado de los
Sprints o del proyecto en general. Sirven para garantizar la transparencia y para realizar
seguimiento y control del proyecto.

4.3.1 - Scrum Board

El Scrum Board o también conocido como tablero Scrum es una adaptación del tablero Kanban
que nos permite dar seguimiento a cada Sprint Backlog dentro de un proyecto Scrum.

El Scrum Board es un emisor de información que le permite al Equipo garantizar la transparencia

en los Sprints, mantiene la coordinación y permite realizar al Scrum Master sus labores de
Inspección.

Está compuesto por 4 columnas: Pendiente, En Progreso, En Prueba (En Revisión), “Terminado”.

Cada elemento por desarrollar debe ponerse en una tarjeta individual, y dado que el Scrum Board
se actualiza constantemente, todas las tarjetas deberán pasar por las 4 columnas. (No se pueden
hacer saltos de columnas).

dibujo

Aclaraciones sobre el Scrum Board

Cuando el tablero está físico en el lugar de trabajo del equipo, generalmente las tarjetas que
se manejan son “sticky notes” de distintos colores.
Cuando se van a desarrollar múltiples historias de usuario en un solo Sprint conviene dividir
 el tablero en filas, donde cada fila representa un componente o épica del producto.
Al final de un Sprint se “borra” el Scrum Board (para así poderlo usar para el próximo Sprint)
Para considerar “terminado” un elemento y moverlo a esta zona en el Scrum Board, se debe
considerar la “definición de terminado (DoD)” (Sección 7.1.1.3).
Para facilitar la lectura del Scrum Board, a cada miembro del equipo puede asignársele un
color de tarjetas (a manera de convenciones).
Aunque por lo general el Scrum Board se actualiza durante la reunión diaria, cada integrante
del Equipo de Desarrollo tiene autonomía para actualizar su conjunto de elementos
asignados en el Sprint Backlog.

4.3.2 - Burndown chart del Sprint

El “Burndown Chart” es un emisor de información que muestra la cantidad de trabajo pendiente
que queda en el Sprint actual.

Es un emisor gráfico de 2 dimensiones:

El eje vertical se construye a partir de la sumatoria de puntos de historia a desarrollar en el

Sprint
El eje horizontal corresponde a la duración del Sprint en días hábiles.

dibujo

Aclaraciones sobre el Burndown Chart

Una posible variación es el Burnup chart que muestra el trabajo completado en el Sprint
El Equipo de Desarrollo es el responsable de la actualización del Burndown Chart
Por lo general la actualización se realiza durante los Scrum Diarios.

4.3.3 – Diagrama de flujo

acumulado
El Diagrama de Flujo Acumulado (CFD - Cumulative Flow Diagram) es un emisor de información
bastante útil para la elaboración de informes y el seguimiento de los resultados del proyecto.

Este emisor de información muestra el progreso del proyecto respecto a los ítems del Product
Backlog.

dibujo
 La zona “gris” muestra el comportamiento del Product Backlog.
Los incrementos significan la adición de nuevos requerimientos/tareas/historias de
usuario.
Los decrementos significan el retiro de requerimientos/tareas/historias de usuario que
ya no generan valor (producto de cambios).
La zona “azul” muestra el trabajo que fue seleccionado por el equipo para desarrollar en los
distintos Sprints.
La zona “verde” muestra el trabajo terminado en el proyecto alrededor del tiempo.
Cuando la zona azul está por encima de la zona verde, normalmente significa que el
equipo seleccionó más trabajo del que podía terminar, esto se conoce como “deuda
técnica”.
La diferencia entre la zona “verde” y la zona “gris”, está relacionada con el progreso
del proyecto.
Los puntos marcados en el gráfico muestran los distintos Sprints.
El eje vertical podría ser el “tamaño de los requerimientos”, esto permitiría tener mayor
precisión a la hora de calcular el progreso del proyecto.
El diagrama de flujo acumulado es único por proyecto.
La técnica originalmente es de la metodología Kanban.
El responsable de este radiador de información es el Scrum Master, aunque normalmente es
el Product Owner quien lo utiliza para mostrar el progreso del proyecto a las partes
interesadas.

4.4 – Registro de
obstáculos/impedimentos
El registro de obstáculos, o también llamado registro de impedimentos es un artefacto en el que
se registran todos los obstáculos que se presentan en los proyectos y su respectiva solución.

Este artefacto es responsabilidad de los Scrum Masters y se actualiza por lo general durante los
Scrum Diarios.

En algunas organizaciones este artefacto es global para todos los proyectos y sirve como base de
conocimiento para todos los integrantes de los distintos equipos Scrum.
4.5 – Registro de lecciones
aprendidas
Registrar las lecciones aprendidas es una parte fundamental para la mejora continua de las
prácticas Scrum dentro de una organización. En este artefacto se registran las prácticas que
favorecieron el desempeño del equipo en términos de costo, tiempo y calidad, también se
registran aquellos errores que se cometieron y a los que se les dió solución. Estas soluciones
hacen parte de las lecciones aprendidas, útiles para resolver problemas similares en el futuro.

Las lecciones aprendidas, además, favorecen el aprendizaje organizacional y la gestión del

conocimiento. Así que las lecciones aprendidas deben almacenarse, alimentarse y transferirse de
manera apropiada. Para esto, es importante que cada lección tenga una estructuración que
permita su búsqueda, una manera de hacerlo sería definiendo:

Una identificación (ID)

Título
Categoría (Ej: Fase del ciclo de vida del proyecto)
Descripción
Proyecto asociado.

Este artefacto normalmente es una de las responsabilidades del Scrum Master.

4.6 – Portafolio de proyectos

El portafolio de proyectos consiste en un registro de información histórica, esta información podría
ser útil (por ejemplo) cuando la organización empieza un proyecto similar a uno que haya
ejecutado en el pasado y por tanto algunos elementos sean similares, esto reduce el tiempo de
planificación, desarrollo, revisión, implementación y/o cierre, además de hacer uso de las
lecciones aprendidas y brindar los insumos para la gestión del conocimiento.

Al igual que las lecciones aprendidas, el portafolio de proyectos debería tener información
detallada y organizada que permita su alimentación, almacenamiento y transferencia. Un software
específico para la gestión del portafolio de proyectos es útil, por lo que una organización debería
considerar esta posibilidad.

Algunos de los elementos que podrían incluirse en el portafolio de proyectos son:

Una identificación (ID)

Nombre del Proyecto
Categoría (Ej: Software – Implementación – Construcción – Investigación, Etc)
Descripción corta del proyecto (buscando resumir la visión del mismo)
Tiempo total de proyecto
Costo total del proyecto
Enlace a repositorio o herramienta de información (donde se podrá encontrar más
información del proyecto)
2. Modelo Core de Scrum

Eventos en Scrum
En Scrum existen diferentes eventos predefinidos con el fin de crear regularidad, minimizar la
necesidad de reuniones innecesarias y permitir la transparencia.

Todos los eventos tienen un periodo de tiempo limitado (time-box), de tal modo que todos tienen
una duración máxima, y se llevan a cabo al mismo tiempo y en el mismo lugar para reducir la
complejidad.

3.1 - El Sprint
Los Sprints son el latido del corazón de Scrum, donde todas las ideas se convierten en valor. El
Sprint es un evento con un tiempo asignado (time-box) de 1 a 4 semanas durante el cual se crea
un incremento de producto “Terminado” utilizable y potencialmente desplegable.

Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint anterior. Los
Sprints contienen y consisten en la Planificación del Sprint, los Scrum Diarios, el desarrollo del
trabajo, la Revisión del Sprint, y la Retrospectiva del Sprint.

Durante el Sprint:

No se realizan cambios que puedan afectar al objetivo del Sprint.

La calidad del producto no debe disminuir.
El alcance puede clarificarse y renegociarse con el Product Owner a medida que se va
aprendiendo más.

Cada Sprint puede considerarse como un “mini-proyecto” con un horizonte no mayor de un mes.
Al igual que los proyectos, los Sprints se usan para alcanzar una meta. Cada Sprint tiene un
objetivo de lo que se construirá, es decir, el Objetivo del Sprint (Sprint Goal), un diseño y un plan
flexible que guiará su construcción, el trabajo del equipo y el incremento de producto resultante.

Los Sprints están limitados a mínimo 1 semana y máximo un mes calendario (4 semanas). Cuando
el horizonte de un Sprint es mayor a un mes, la definición de lo que se está construyendo podría
cambiar, la complejidad podría incrementarse y el riesgo podría aumentar.

Los Sprints habilitan la predictibilidad al asegurar la inspección y adaptación del progreso al

menos en cada mes calendario.
dibujo

3.1.1 - Consideraciones sobre la

duración del Sprint
Una vez que comienza un Sprint, su duración es fija y no puede acortarse o alargarse.
Todos los eventos relacionados con el Sprint deben ejecutarse (Reunión de Planificación,
Reunión Diaria, Reunión de Revisión y Reunión de Retrospectiva), la falta de alguno de estos
eventos da como resultado una reducción de la transparencia y constituye una oportunidad
perdida de inspección y adaptación.
Los Sprints pueden tener duración variable (conservando la regla de 1 a 4 semanas). La
duración de los Sprint dependerá de los siguientes factores:
Fechas de entrega acordadas
Experiencia del equipo (a menor experiencia con Scrum, los Sprints deberían ser más
cortos)
Restricciones propias para la construcción del producto
La duración del Sprint es definida por todo el Equipo Scrum con las recomendaciones del
Scrum Master, quienes a su vez deberán llegar a un consenso con el Product Owner, por lo
general la definición aproximada de la duración de los Sprints se hace durante la Definición
del Cronograma de Entregas.

3.1.2 - Cancelación del Sprint

Un Sprint puede cancelarse antes que el periodo de tiempo llegue a su fin. Algunas de las razones
por las que se podría cancelar un Sprint son:

La organización cambia el Objetivo del Producto (Product Goal) y eso afecta el entregable
del Sprint que se está ejecutando.
Las condiciones del mercado o de la tecnología cambian.
El objetivo del Sprint quedó obsoleto.
Surge un error sobre un producto que está en ambiente de producción y el equipo de
desarrollo debe resolverlo cuanto antes.
Surge un cambio urgente que debe introducirse de inmediato al incremento de producto.

Algunas consideraciones que se deben tener en cuenta sobre la cancelación de los Sprint son:

Solo el Product Owner tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo
la influencia de los interesados, de los Developers o del Scrum Master.
Debido a la corta duración de los Sprints, su cancelación rara vez tiene sentido.
Cuando se cancela un Sprint se revisan los elementos que se hayan completado y
 “Terminado”. Si una parte del trabajo es potencialmente entregable, el Product Owner
normalmente la acepta.
Si el Sprint ha sido cancelado, todos los elementos del Sprint Backlog que no hayan sido
completados se vuelven a estimar para el siguiente Sprint o se vuelven a introducir en el
Product Backlog para desarrollarse en futuros Sprints.
Las cancelaciones de Sprint consumen recursos ya que todos se reagrupan en otra
Planificación de Sprint para empezar otro Sprint.
Las cancelaciones del Sprint son a menudo traumáticas para el Equipo Scrum y son muy
poco comunes.

dibujo

3.2 – Reunión de
Planificación del Sprint
(Sprint Planning)
En este evento se planifica el trabajo a realizar durante un Sprint.
Este plan se crea mediante el trabajo colaborativo de todo el Equipo Scrum.
El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan
su propósito.
El Scrum Master enseña al Equipo Scrum a mantenerse dentro del tiempo máximo del
evento.

3.2.1 - Datos del evento

Duración: 2 horas por cada semana de Sprint a planificar. (Duración máxima de 8 horas
para un Sprint de 4 semanas).
Participantes: Todo el Equipo Scrum (Product Owner + Scrum Master + Developers).
Agenda de la reunión:

1. ¿Por qué este Sprint es valioso?

 El Product Owner propone cómo el producto podría aumentar su valor y utilidad en
el Sprint.
Todo el equipo de Scrum colabora para definir el Objetivo de Sprint (Sprint Goal)
durante la Reunión de Planificación.

2. ¿Qué puede hacerse en este Sprint?

Se identifican los cambios y/o riesgos que puedan afectar este Sprint.
En equipo se seleccionan los elementos del Product Backlog que harán parte de
este Sprint, es decir, definen el Sprint Backlog.
Identificar las dependencias que puedan existir.
Se realiza la estimación de los elementos seleccionados para su desarrollo.
El equipo se autoasigna los elementos del Sprint Backlog.

3. ¿Cómo se conseguirá completar el trabajo seleccionado?

Identificar (desglosar) las tareas que deben ejecutarse para “terminar” los
elementos del Sprint Backlog.
Asegurar que todo el Equipo entiende cómo crear un incremento cumpliendo con la
Definición de Terminado (Definition Of Done).

3.3 - Daily Scrum (Scrum

Diario)
El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos que tiene el propósito de
inspeccionar el progreso hacia el Objetivo del Sprint (Sprint Goal). El Scrum Diario se realiza
diariamente para cada día del sprint.

Nota: Si el Product Owner o el Scrum Master están desarrollando elementos del Sprint Backlog,
entonces pueden participar como Developers.

3.3.1 - Datos del evento

Duración: 15 minutos máximo.
Participantes: Los Developers y el Scrum Master
Agenda de la reunión: El Scrum Master y los Developers tienen la libertad de seleccionar
la estructura y técnicas que deseen para la ejecución de esta reunión; sin embargo, el Scrum
Master tiene la opción de hacer las siguientes preguntas a los Developers:
¿Qué hice hoy?
 ¿Qué haré mañana?
¿Existe algún impedimento que esté afectando o nos pueda afectar?
Consideraciones:
Durante el Scrum Diario el Equipo coordina y planea el trabajo para las siguientes 24
horas.
El Scrum Diario optimiza la colaboración y el desempeño del equipo inspeccionando el
trabajo avanzado desde el último Scrum Diario y proyectando el trabajo a realizar a
continuación.
Es muy común que el Equipo se vuelva a reunir después del Scrum Diario, para tener
discusiones detalladas, o para adaptar o replanificar el resto del trabajo del Sprint.
El Scrum Diario se realiza a la misma hora y lugar todos los días para reducir la
complejidad. Por lo general se realiza antes de finalizar la jornada de trabajo del
Equipo.
El Equipo usa el Scrum Diario para evaluar el progreso hacia el Objetivo del Sprint.
El Scrum Master se asegura de que el Equipo lleve a cabo la reunión, pero son los
Developers los responsables de dirigir el Scrum Diario, es decir que, no es obligatoria
la presencia del Scrum Master para que se lleve a cabo el Scrum Diario.
El Scrum Master enseña al Equipo a mantener el Scrum Diario dentro de un bloque de
tiempo de 15 minutos.
El Scrum Diario es una reunión interna del Equipo. Si otras personas están presentes,
el Scrum Master se asegura de que no interrumpan la reunión ni alteren la
planificación del trabajo.
Los Scrum Diarios mejoran la comunicación, identifican los impedimentos relacionados
con desarrollo del trabajo, resaltan y promueven la toma rápida de decisiones y
mejoran el nivel de conocimiento del Equipo.
Durante los Scrum Diarios se actualizan el Burndown chart y el Scrum Board.
Esta reunión por lo general se realiza de pie con el fin de garantizar el cumplimiento
del tiempo asignado, por lo que también se le puede conocer como el Scrum Diario de
Pie (Daily Standup Meeting).

3.4 – Reunión de Revisión

del Sprint (Sprint Review)
Al final del Sprint se lleva a cabo la Reunión de Revisión de Sprint para inspeccionar el Incremento
que se produjo durante el Sprint y adaptar el Product Backlog si fuese necesario. El Equipo Scrum
realiza una demostración del incremento y se revisa el progreso con respecto al Objetivo de
Producto; basándose en esto y en cualquier cambio que deba considerarse, los asistentes
colaboran para determinar los elementos que podrían desarrollarse en el siguiente Sprint para
optimizar el valor.

Se trata de una sesión de trabajo, no de una reunión de seguimiento, y la presentación del

Incremento tiene como objetivo facilitar la retroalimentación para el equipo Scrum y fomentar la
colaboración.

El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su
propósito. El Scrum Master enseña a todos a mantener el evento dentro del bloque de tiempo
fijado.

3.4.1 Datos del evento

Duración: 1 hora por cada semana de Sprint a revisar. (Duración máxima de 4 horas para
un Sprint de 4 semanas).
Participantes: Todo el Equipo Scrum + Los Interesados clave que sean invitados por el
Product Owner
Agenda de la reunión:
El Equipo habla acerca de qué estuvo bien durante el Sprint, qué problemas
aparecieron y cómo fueron resueltos esos problemas.
El Equipo hace una demostración del trabajo que ha “Terminado” y responde
preguntas acerca del Incremento y su funcionalidad.
El Product Owner habla acerca del Product Backlog en su estado actual. Proyecta
objetivos probables y posibles fechas de entrega basándose en el progreso obtenido
hasta la fecha (si fuera necesario).
El Product Owner realiza la aprobación de los elementos del Sprint Backlog que se han
“Terminado” y rechaza los que no se han “Terminado” y con esto determinar la Deuda
Técnica.
Seguimiento y control del presupuesto, capacidades potenciales y mercado para la
próxima entrega prevista del producto.
Revisión del estado de los cambios que fueron planificados para este Sprint y revisión
del estado de los riesgos que afectaron este Sprint.
Refinamiento (grooming) del Product Backlog, en el que todo el Equipo colabora
acerca de qué hacer a continuación, de modo que esta reunión proporcione
información de entrada valiosa para Reuniones de Planificación de Sprints
subsiguientes.

El resultado de la Revisión de Sprint es un Sprint Backlog revisado, además de una identificación

de alto nivel de los posibles elementos del Product Backlog que se pueden desarrollar para el
siguiente Sprint. Es posible además que el Product Backlog reciba un ajuste general para
enfocarse en nuevas oportunidades.

3.5 – Reunión de
Retrospectiva del Sprint
(Sprint Retrospective)
El tema principal de la Reunión de Retrospectiva del Sprint es la identificación de posibles mejoras
que puede incorporar el Equipo Scrum en próximos Sprints.

3.5.1 - Datos del evento

Duración: 1 hora por cada semana de Sprint a revisar. (Duración máxima de 4 horas para
un Sprint de 4 semanas).
Participantes: Los Developers y el Scrum Master (no se recomienda que el Product Owner
haga parte de esta reunión).
Agenda de la reunión:
Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y
herramientas.
Inspeccionar sobre si el equipo entendió y cumplió con la Definición de Terminado
(Definition Of Done).
Identificar y ordenar los elementos más importantes que salieron bien y las posibles
mejoras que puede incorporar el Equipo Scrum en próximos Sprints.
Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum
desempeña su trabajo.
3. Scrum aplicado a
proyectos
Scrum fue diseñado como un Marco de Trabajo basado en la simplicidad, por lo que NO utilizamos
el concepto “proceso” para describir las prácticas Scrum que permiten el desarrollo de un
proyecto. Los procesos tal como se conocen es mejor dejarlos a las metodologías tradicionales. Se
denominan prácticas ya que proponen recomendaciones flexibles que no son de obligatorio
cumplimiento y además no cuentan con la estructura tradicional de un proceso (entradas,
herramientas, procedimientos, salidas); por lo que resultan en más facilidad a la hora de ponerlas
en marcha. Un proyecto desarrollado con Scrum tiene 6 etapas definidas en su ciclo de vida, cada
etapa con un respectivo conjunto de prácticas (17 en total).
3. Scrum aplicado a proyectos

Consideraciones para la
gestión de un proyecto
basado en Scrum
Las consideraciones para la gestión de proyectos basados en Scrum describen 6 elementos que
debe considerar el Equipo Scrum para garantizar que un proyecto entrega los resultados
esperados.

Estas consideraciones se relacionan con las prácticas descritas en el Ciclo de vida de un proyecto
basado en Scrum.

Las 6 consideraciones, son:

Contratación: Esta consideración toma un enfoque en la contratación del personal, el

contrato del proyecto, y la contratación de proveedores que son externos al Equipo Scrum
Finanzas: Esta consideración aborda principalmente la definición del presupuesto del
proyecto
Seguimiento y control: Esta consideración aborda el concepto de la APMO (Oficina de
Gestión de Proyectos Ágiles) y su rol frente al seguimiento, control y apoyo a los proyectos
basados en Scrum
Gestión de riesgos: Esta consideración comprende el tratamiento que se recomienda dar a
los riesgos. El ciclo propuesto permite asegurar que durante toda la construcción del
producto se ejecute la gestión de riesgos dada la naturaleza iterativa de Scrum.
Gestión de cambios: En esta consideración se define el flujo para el tratamiento de los
cambios que puedan surgir durante la construcción de un producto con Scrum. Cabe
mencionar que según los postulados del manifiesto ágil, se busca la "Respuesta ante el
cambio sobre seguir un plan", por lo que desde Scrum se asegura cumplir con esta premisa.
Diseño de producto: En esta consideración se abordan recomendaciones para el diseño
iterativo de producto, manteniendo el enfoque ágil de que no es necesario contar con el
diseño detallado de producto para iniciar con su construcción.

6.1. Contratación
Esta consideración toma un enfoque en la contratación (selección) del personal del equipo, el
contrato del proyecto, y la contratación de proveedores que son externos al Equipo Scrum

El primer enfoque que veremos es la contratación (selección) del personal del equipo:

1. Contratación (selección) del

personal del equipo
Las personas ocupan un papel clave en la gestión de proyectos ágiles, su participación se da a
través del conjunto de responsabilidades que les son asignadas, es decir, su rol en el proyecto. En
un proyecto Scrum se consideran 2 categorías de clasificación para los roles:

Roles Comprometidos
Los comprometidos son los roles que obligatoriamente se requieren para construir el
producto del proyecto, por ende, son los responsables del éxito de cada iteración del producto y
del proyecto en sí.

Los roles comprometidos son:

El Product Owner.
El Scrum Master.
El Equipo de Desarrollo.

Roles Involucrados
Los involucrados son los roles que no son obligatoriamente necesarios durante la ejecución
del proyecto Scrum. Ellos pueden interactuar con el equipo Scrum, pero NO son responsables del
éxito del proyecto.

Los roles involucrados son:

Clientes.
Usuarios.
Proveedores (Ej: Freelancers; Proveedores de servicios; etc).
Oficina de Gestión de Proyectos Ágiles (APMO) (Más detalles de la APMO en la consideración
6.3 Seguimiento y control).

Criterios para la contratación/Selección

del equipo Scrum
A continuación, se describen algunos de los elementos que se deben considerar para la
asignación/contratación/selección de las personas que ocuparán los distintos roles en un proyecto
Scrum.

Product Owner Scrum Master Developers

Experto en Scrum Experto en Scrum Conocimiento básico de Scrum

Amplia experiencia y conocimiento Capacidad para la resolución de

Expertos técnicos
del negocio y el cliente problemas

Buen negociador Habilidades de coordinación Multifuncionales

Organizado con la captura de

información y redacción de Historias Líder al servicio del equipo Proactivos
de usuario

Experiencia en gestión de proyectos

(recomendable)

Líder al servicio del equipo y el

cliente (partes interesadas)

Líderes al servicio del equipo

Los roles del Scrum Master y el Product Owner se consideran como líderes que están al servicio
del equipo, para lo cual deben contar con varias características que les permiten apoyar a los
Developers y el equipo en general:

Capacidad de escucha: Escuchan con atención y son receptivos a lo que se dice y no se dice
para comprender y reflexionar sobre la situación.
Empatía: Aceptan y reconocen las diferentes necesidades de las personas, ya sea que hagan
parte del equipo o sean las partes interesadas.
Persuasión: Logran el consenso con el Equipo o con el cliente (según la situación) en la toma
de decisiones.

Competencias del equipo: Matriz de

competencias
La matriz de competencias permite identificar las competencias necesarias en los miembros que
hacen o harán parte de los distintos equipos y de esta manera poder identificar los miembros que
necesitarán capacitación adicional en un área o competencia específica, e incluso diseñar una
estrategia de tutoría entre los miembros del equipo.

Nota: Esta matriz está basada en el Modelo de desarrollo de habilidades de Dreyfus explicado
más adelante.

Aunque generalmente para la contratación de los miembros del equipo se realiza con base en el
conocimiento o habilidades técnicas, en Scrum se reconoce que también es necesario que los
miembros del equipo cuenten con otro tipo de habilidades que le permitan desarrollar mejores
interacciones, mejor comunicación y mayor cohesión. Las necesidades del equipo Scrum, se
toman como criterios adicionales a tener en cuenta para la adecuada contratación de los
miembros.

Los elementos necesarios para el buen desempeño de un equipo son:

Habilidades técnicas: Son las habilidades especificas que requieren los miembros que
desarrollarán los entregables del proyecto. (Ej, Diseño – Desarrollo de Software –
Conocimiento de una herramienta específica, etc)
Habilidades esenciales: También llamadas habilidades blandas, son las habilidades que
permiten lograr la empatía y buenas relaciones entre todos los Stakeholders del proyecto.
Procesos y prácticas: Las personas deben conocer los entregables, eventos, o
herramientas a usar dentro del proyecto. Scrum, por ejemplo, describe 17 prácticas
aplicables a los proyectos.
Herramientas: Para desarrollar los entregables del proyecto siempre será indispensable el
uso de herramientas, por ejemplo, herramientas de prototipado, herramientas colaborativas,
herramientas de integración, etc.
Competencias de los Developers
Se suele pensar que en los equipos multifuncionales no pueden existir roles ni especialistas,
siendo esta afirmación totalmente falsa, por lo general un equipo está compuesto por distintos
especialistas tales como:

Analistas.
Desarrolladores.
Probadores.
Integradores.
Diseñadores.
Arquitectos.
Etc.

¿Contratar Novatos o Expertos?

Si el objetivo es terminar el proyecto en poco tiempo y con muy alta calidad deberás contratar
expertos técnicos, considerando que esto tendrá un impacto significativo en el costo; por otro
lado, se podrían contratar solo novatos, pero el proyecto tardará bastante en desarrollarse debido
a la curva de aprendizaje, además la calidad podría verse comprometida.
Realizar una combinación entre novatos y expertos, puede desmotivar a los expertos, aunque
también puede darse la situación en la que los novatos crezcan rápido y se logre el equilibrio
esperado.

2. Contrato del proyecto

Contrato de precio fijo
Se define un precio total fijo para todo lo que se desarrolle en el proyecto.
Mayor riesgo financiero si no se da cumplimiento a todo el proyecto en función del contrato.
Los entregables son fijos y definidos al inicio del proyecto.
No son ideales para el uso de Scrum.

Contrato de Unión Temporal

Generalmente se utiliza cuando dos o más socios ejecutan un proyecto.
El ROI (ingresos o beneficios) será compartido entre todos los socios.
Es importante definir los % de participación y las responsabilidades en el proyecto.
Es ideal centralizar los equipos o dividir el proyecto en componentes.

Contrato de desarrollo en fases

Se considera el concepto de Producto Mínimo Viable.
Se “fragmenta” el proyecto en varias fases, donde al final de cada fase se hacen pagos.
Cada fase genera un conjunto importante de entregables.
Útil para proyectos de gran tamaño.
Se reduce el riesgo monetario, ya que los despliegues sin éxito no son financiados.

Contrato de entrega incremental

El cliente/patrocinador puede tomar decisiones sobre el proyecto en cada inspección: Puede
aceptar el entregable, Detener el desarrollo o Solicitar modificaciones.
Cada Sprint debe generar un incremento por lo general es una épica o componente
completo.
El pago/facturación se hace con cada Iteración (se utiliza generalmente en proyectos
internos).
También se le llama “Contrato por Sprints”.

Contrato de tiempo y materiales

Este tipo de contrato cuenta con un componente fijo: el precio, el cual puede estar definido por
(horas, unidades, metro cuadrado…, etc.,) y, un componente variable, el cual se refiere a
cantidades, es decir, (número de horas, número de unidades y/o metros cuadrados, etc.,)
invertidos finalmente en el desarrollo de un trabajo.

3. Contratación de proveedores
Para garantizar que se trabaja con los mejores proveedores, la selección se realiza considerando
las opiniones de todo el Equipo Scrum.

Algunos de los criterios que se pueden considerar para la selección de los proveedores son:

Precio.
Curva de Aprendizaje.
Facilidad de uso.
Velocidad de la Solución.
Soporte.
Seguridad.
Complejidad para la migración de Datos.
Tiempo de Implementación.
Reputación.
Facilidad de Pago.
Referencias.

Los “Freelancers”
En algunos proyectos, podría ser necesario el apoyo de personal no disponible en el Equipo de
Desarrollo, por ejemplo “Arquitectos”, “Diseñadores”, “Administradores de Bases de Datos”, etc.

Este tipo de personal es considerado como proveedor, y normalmente solo se contrata por días, y
en momentos muy específicos del proyecto.
6.2 Finanzas
Las finanzas del proyecto son una de las consideraciones más importantes en la gestión de un
proyecto (sobre todo en proyectos externos a la organización), ya que, de no realizarse una
adecuada gestión financiera, el proyecto podría generar pérdidas, comportamiento no deseados, e
incluso la cancelación total de un proyecto.

Las finanzas del proyecto se ven reflejadas principalmente en los siguientes momentos:

Inicio del proyecto: En la definición del presupuesto inicial del proyecto, que permitirá
evaluar la viabilidad de iniciar un proyecto, además de asegurar los recursos financieros del
proyecto, e incluso identificar posibles riesgos financieros.
Ejecución del Proyecto: Al final de cada Sprint, podría realizarse seguimiento y control
financiero del proyecto, para así evitar desviaciones o la ocurrencia de posibles problemas,
al ser realizada de forma iterativa, supone menor desgaste para la persona que asuma esta
responsabilidad (normalmente es el Product Owner), además de garantizar que siempre se
encuentra actualizada la información.
Cierre del Proyecto: Por lo general, las organizaciones solicitan a los equipos de proyecto
un reporte final que describa los costos del proyecto, en relación al presupuesto solicitado.
En Scrum la función encargada de analizar dicha información se conoce como la APMO (Agile
Project Management Office). Además esta información servirá para alimentar el portafolio de
proyectos.
Presupuesto inicial del proyecto
Una de los momentos clave en las prácticas Scrum es la definición del Presupuesto inicial del
proyecto, para lo cual se deben tener en cuenta como mínimo los siguientes elementos:

Personas que harán parte del proyecto.

Materiales.
Servicios.
Infraestructura.
Capacitación del equipo.
Reservas.
Otros gastos que afecten la ejecución del proyecto.

Nota: Es responsabilidad del Product Owner y el Patrocinador del proyecto (cliente), discutir,
negociar y aceptar el presupuesto para asegurar que haya suficientes fondos disponibles para el
proyecto.

Algunas de las técnicas y herramientas que se pueden utilizar para gestionar las finanzas del
proyecto son:

Retorno de la Inversión
El ROI (Return Of Investment) es el cálculo de las utilidades (o valor financiero) generado por un
proyecto. Esto sirve a muchas organizaciones para determinar si los proyectos externos son
exitosos o no.

Nota: No todos los proyectos están diseñados para generar utilidades (ganancias), así que,
cuando a un proyecto no se le puede calcular el ROI, lo que se mide es el valor entregado (es
decir, los beneficios) utilizando VOI (Value of Investment).

Estimación basada en históricos

Los datos históricos del mismo proyecto o de otros proyectos serán de gran utilidad para lograr
mejores estimaciones de los elementos que hacen parte del Product Backlog.
Dependiendo de la información disponible en la organización, se puede utilizar:

Históricos reales de proyectos anteriores: Esta técnica funcionará siempre y cuando la

organización mantenga el registro del esfuerzo y duración reales del proyecto (la técnica
más recomendable en Scrum).
Históricos planeados: En los que se cuenta con un estimado original, aunque no se haya
tenido un seguimiento a los datos reales (la técnica más común). Esto es por ejemplo el
histórico de cotizaciones de proyectos externos o casos de negocio de proyectos no
ejecutados o no aprobados.

Coeficiente de conocimiento del negocio

Esta técnica está basada en la idea de que a mayor conocimiento o experiencia del
negocio/proyecto, más precisa será la estimación del presupuesto, y, a menor conocimiento o
experiencia del negocio/proyecto, habrá mayor riesgo y menor precisión en la estimación.

El objetivo de esta técnica es calcular en una escala porcentual el grado de conocimiento sobre el
negocio y a partir de allí calcular la reserva financiera o presupuestal.

Algunos factores para el cálculo del coeficiente de conocimiento sobre negocio son:

Experiencia en proyectos similares.

Calidad de requerimientos iniciales del proyecto.
Grado de riesgo al que está expuesto el proyecto.
Desviación (%) en las estimaciones de proyecto.

El seguimiento y control del proyecto, es una actividad que debe hacerse de forma continua a lo
largo del ciclo de vida del proyecto. Por lo general los momentos donde se realiza de forma
intensiva son: Al inicio, a intervalos predefinidos durante el proyecto o en cualquier momento
cuando surgen problemas o riesgos de viabilidad.

6.3. Seguimiento y control

6.3.1 - Oficina de Gestión de

Proyectos Ágiles (APMO)
Una APMO (Agile Project Management Office) está conformada por un Grupo de expertos en Scrum
u otros Marcos de Trabajo ágiles.

La Oficina de Gestión de Proyectos Ágiles (APMO) tiene como responsabilidades:

Estudiar la viabilidad de las iniciativas de proyectos.

Generar guías de apoyo.
Brindar asesoría a los diferentes Equipos Scrum de la Organización.
Dar seguimiento a los proyectos.
Reportar a la Alta Dirección.
Mantener actualizado el portafolio de proyectos.
Definir los “Criterios de terminado” globales para la organización (Ver sección - Definición de
terminado (DoD)).
Por lo general se encarga de guiar las retrospectivas de proyecto.
Garantizar la correcta gestión de las lecciones aprendidas de los proyectos.
No toma decisiones sobre los proyectos, pero funciona como apoyo de consultoría,
asesoramiento u orientación para todos los proyectos, programas y portafolios de proyectos
de la organización.

dibujo

6.3.2 - Informes y reportes del

proyecto
En cualquier momento es posible conocer el progreso del proyecto tan solo con sumar el trabajo
total restante para alcanzar el objetivo. El Product Owner hace seguimiento de este trabajo
restante total al menos en cada Revisión de Sprint. El Product Owner compara esta cantidad con el
trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del
trabajo proyectado en el tiempo deseado para el objetivo. Esta información se muestra de forma
transparente a todos los interesados.

Varias prácticas de proyección de tendencias se han utilizado para predecir el progreso, como
trabajo pendiente (Burn Down), trabajo completado (Burn Up) y el flujo acumulado (Cumulative
Flow). Estas han probado ser útiles, sin embargo, no reemplazan la importancia del empirismo. En
entornos complejos se desconoce lo que ocurrirá. Solo lo que ya ha ocurrido puede utilizarse para
la toma de decisiones con miras al futuro.

6.3.2.1 - Velocidad del Equipo Scrum

La velocidad del Equipo es la velocidad con la que el equipo puede completar el trabajo en un
Sprint. Por lo general se expresa en las mismas unidades que las utilizadas para la estimación,
normalmente puntos de historia.

Todos los equipos tienen diferente velocidad, así hagan parte del mismo proyecto. A
continuación, la fórmula para calcular la velocidad de un equipo Scrum:

dibujo

6.3.2.2 – Métricas en proyectos Scrum

Algunas de las métricas que son realmente útiles cuando se trabaja usando Scrum son:

¿Para qué se
Métrica ¿Qué se mide? Responsable Responsable
utiliza?

Historias de Usuario
• Monitorear el
Completadas
progreso del equipo.
Historias de Usuario
Flujo acumulado • Evitar la deuda Scrum Master Sprint
Pendientes Historias
técnica del equipo
de Usuario En
en cada sprint.
Progreso

Disminuir el riesgo
Costos mensuales
Costos de Proyecto de desvíos Product Owner Mes
del Proyecto
financieros.

Encontrar el punto
de equilibrio del
trabajo al que se
Velocidad de Equipo Velocidad de Equipo Scrum Master Sprint
puede comprometer
el equipo en cada
sprint.

Evitar que el equipo

Cantidad de tenga
Equipo de Desarrollo
Impedimentos Impedimentos inconvenientes o Sprint
/ Scrum Master
Resueltos atrasos en el
próximo sprint.

# Cambios Garantizar la
aceptados # estabilidad de los
Cambios rechazados proyectos y
Cambios Product Owner Semanal
# Cambios Garantizar que los
pendientes por cambios son
revisar atendidos a tiempo.

Errores en pruebas
unitarias Errores en
pruebas de colegas Garantizar la calidad
Errores Equipo de Desarrollo Sprint
Errores en del producto.
producción Errores
en Validación
 ¿Para qué se
Métrica ¿Qué se mide? Responsable Responsable
utiliza?

Riesgos Garantizar la calidad

Materializados del producto y la
Riesgos Product Owner Sprint
Riesgos Mitigados estabilidad del
Riesgos No tratados proyecto

6.3.2 - Seguimiento de Calidad

En Scrum, la calidad se define como la capacidad del producto para cumplir criterios de
“terminado” y alcanzar el valor que espera el cliente. En los proyectos Scrum es sumamente
importante realizar un seguimiento constante a la calidad del producto y así evitar inconvenientes
en el futuro (esta es una práctica iterativa que se realiza en todos los Sprints).

6.3.3.1 - Control de calidad

El Control de Calidad se refiere a la ejecución de las actividades de calidad que se realizan a los
incrementos de producto que están potencialmente listos para la entrega y posteriormente sobre
el Producto.

Normalmente los controles de calidad son realizados por el Equipo de Desarrollo y el Scrum Master
durante la práctica de Desarrollo del Sprint, y por el Product Owner en la Revisión del Sprint.

6.3.3.2 - Aseguramiento de calidad

El Aseguramiento de la Calidad se refiere a la evaluación de los procesos y normas que están
definidos en el Ciclo de vida de un proyecto Scrum.

Normalmente el aseguramiento de calidad se hace por medio de auditorías de proceso, realizadas

por la APMO (Sección 6.3.1).

Para realizar las actividades de Aseguramiento de calidad, puede usarse el Marco para la
Evaluación y Mejora de Procesos de Tecnologías de la Información (MEMPTI).

6.4. Riesgos
La gestión de riesgos es una actividad que se realiza proactivamente y a través del ciclo de vida
del proyecto.
 Un riesgo es definido como una situación inesperada que puede afectar los objetivos de un
proyecto.
Los riesgos pueden tener un impacto tanto positivo como negativo sobre el proyecto.

6.4.1 - Ejemplos de riesgos

comunes:
Falta de capacidad del recurso humano actual: En algunas organizaciones, el personal
disponible para la ejecución de los proyectos tiene asignadas otras responsabilidades que le
impiden tener total disponibilidad para ejecutar las actividades del proyecto.

Algunas de las posibles acciones a tomar son:

Planificar las actividades del personal actual.

Evitar en lo posible los cambios urgentes.
Considerar la contratación de personal o de proveedores externos que puedan aportar a la
ejecución de los proyectos.

Falta de seguimiento y control sobre los proyectos: La falta de seguimiento y control del
portafolio de proyectos puede provocar su obsolescencia y/o fracaso.

Algunas de las posibles acciones a tomar son:

Usar una herramienta para el seguimiento y control de los proyectos.

Realizar una actualización continua del portafolio de proyectos, para confirmar la entrega de
valor.
Monitorear el cronograma y el presupuesto de cada proyecto.

El presupuesto se agota o no es suficiente: Se debe considerar que, para el desarrollo de la

mayor parte de los proyectos internos, se necesitan considerables sumas de dinero, que deberán
ser proyectadas dentro del presupuesto general de la organización.

Falta de compromiso por parte de los involucrados en los proyectos: Los proyectos Scrum
requieren una colaboración entre los miembros del equipo y las partes interesadas, por lo que es
importante contar con el compromiso de todos los involucrados.

Para este fin, se recomienda:

Definir claras y correctas expectativas para todos los involucrados.

Comunicar a tiempo y con el detalle suficiente los compromisos e importancia de la
participación de los involucrados.
Mantener siempre informados a los involucrados sobre los avances y/o cambios que puedan
 tener los proyectos (utilizar un lenguaje sencillo que todos los involucrados puedan
entender).
Evitar reuniones que no generen valor o reuniones demasiado extensas que interrumpan
significativamente las actividades de los involucrados.
Comunicar siempre los resultados y beneficios logrados con la ejecución de cada proyecto.
Agradecer al equipo involucrado y funcionarios su participación y resaltar la importancia de
sus ideas y revisiones.

Posible rotación del personal actualmente involucrado en el proyecto: Uno de los

mayores riesgos a los que normalmente se encuentra expuesto un proyecto, es la posible renuncia
de los miembros del equipo, por lo que se recomienda:

Realizar transferencia de conocimiento entre los miembros del equipo.

Constituir una base de conocimiento y lecciones aprendidas.
Garantizar la documentación continua.

6.4.2 - Apetito de Riesgo

El Apetito de Riesgo es un modelo utilizado para medir la preferencia de las Partes Interesadas por
el riesgo o su actitud hacia el riesgo. Esto define el nivel de las Partes Interesadas para aceptar
riesgos.

dibujo

6.4.3 - Tolerancia al Riesgo

La tolerancia al riesgo es la cantidad máxima de riesgo que la organización está dispuesta a
aceptar para lograr los objetivos del proyecto; la tolerancia al riesgo sirve como una alerta para
evitar llegar a la capacidad de riesgo.

Capacidad de Riesgo

La capacidad de riesgo es el nivel de riesgo máximo que se puede permitir antes de que el
proyecto se desvíe de tal forma que no entregue valor al cliente. En caso de superar la capacidad
de riesgo, por lo general se da por terminado el proyecto (Sección - Etapa 6: Cierre del proyecto).
6.4.4 - Ciclo de vida de la gestión
de riesgos
La gestión de riesgos se compone de cinco pasos que se enuncian a continuación:

dibujo

6.4.4.1 - Identificación del riesgo (1)

La identificación de riesgos permite conocer los posibles riesgos que pueden afectar el desarrollo
del proyecto y de sus respectivos Sprints.

Existen 2 momentos importantes donde se realiza la identificación de riesgos:

Al inicio del proyecto: Se identifican los riesgos globales del proyecto, por ejemplo,
riesgos relacionados con el presupuesto, el personal, etc.
Los Sprints: Se identifican los riesgos que pueden afectar el desarrollo de ese Sprint
particular, por ejemplo, riesgos del producto. Esta actividad se realiza se forma iterativa
durante todo el proyecto principalmente en las reuniones de Planificación de los Sprint.

Solo mirando el proyecto desde diferentes perspectivas y utilizando una variedad de técnicas, se
puede hacer la identificación de los posibles riesgos. La técnica más utilizada es la lluvia de ideas.

6.4.4.2 - Evaluación del riesgo (2)

La evaluación de riesgos ayuda a entender el impacto potencial de un riesgo, ¿qué tan probable es
que se produzca, y cuándo es posible que el riesgo se materialice? Con ello una decisión podrá ser
tomada y determinar si sería buena idea continuar con el Sprint o incluso el Proyecto.

La evaluación de riesgos se hace considerando 3 factores:

Proximidad = Cantidad de días o fecha estimada en la que se podría presentar el riesgo.

Probabilidad = Medida porcentual que ayuda a determinar la posibilidad de que el riesgo
ocurra.
Impacto = Mide el daño que ocasiona el riesgo, suele clasificarse numéricamente según las
siguientes categorías: Crítico (6), Muy Alto (5), Alto (4), Medio (3), Bajo (2), Muy Bajo (1)

dibujo
6.4.4.2.1 – Valor Monetario Esperado
Esta técnica se utiliza para calcular el impacto monetario que podrá tener un riesgo, y con esta
información realizar reservar monetarias para la prevención y/o mitigación de riesgos.

La técnica considera 2 factores: El impacto monetario del riesgo y la probabilidad de ocurrencia.

dibujo

Ejemplo: Una organización que implementa sistemas de energía solares detecta una posible
tormenta tropical que le impediría continuar con la instalación de los paneles previstos para el
próximo Sprint. Para calcular el impacto que esto tendría en el proyecto se identifican factores
como posibles multas, salario de las personas, etc. Llegando a la conclusión de que para este
riesgo se perderían 538 dólares. El siguiente paso es calcular la probabilidad de ocurrencia del
riesgo, que según el instituto meteorológico es del 35%. Al aplicar la técnica como se explica, el
Valor Monetario de ese riesgo es de 188.3 dólares.

dibujo

6.4.4.3 - Priorización del riesgo (3)

La priorización de riesgos permite establecer un orden para la mitigación de los riesgos. Para
realizar la priorización de los riesgos se siguen los siguientes pasos:

Identificar la fecha aproximada en la que se presentaría el riesgo. (Considerar que los

riesgos más próximos deben ser atendidos primero).
Calcular el factor de exposición (Relación entre probabilidad e impacto) y con este factor,
prioriza entre los riesgos más próximos.

dibujo

6.4.4.4 - Mitigación del riesgo (4)

En la etapa de mitigación, el Equipo Scrum determina la acción a tomar con el riesgo. En Scrum
existen 3 posibles respuestas a los riesgos:

dibujo

La respuesta a cada riesgo dependerá de la probabilidad y el impacto del riesgo.

La naturaleza iterativa de Scrum, con sus ciclos de tiempo de respuesta y retroalimentación
rápida permite que las fallas se detecten de forma temprana; por lo tanto, hablando en
términos prácticos, tiene una función de mitigación natural construida dentro del sistema.
Los riesgos pueden ser mitigados mediante la implementación de una serie de respuestas
 que pueden ser Proactivas/preventivas o reactivas.

6.3.4.4.1 – Mitigación
La mitigación se enfoca en reducir la probabilidad de ocurrencia o el impacto del riesgo.
Comprende acciones que se toman por adelantado o acciones Proactivas.
Se reduce la exposición al riesgo (probabilidad vs impacto) dentro de límites aceptables para
el proyecto.

6.4.4.4.2 – Contingencia
La contingencia se enfoca en definir una respuesta que se utiliza si el riesgo se materializa o
se identifican señales de advertencia.
Comprende acciones Reactivas y acciones de monitoreo en caso de que el riesgo sea
inevitable.

6.4.4.5 - Comunicación del riesgo (5)

Las Partes Interesadas deben ser informadas continuamente acerca del estado de los riesgos,
incluyendo el impacto potencial de estos riesgos y los planes para responder a cada riesgo.

Por lo general, la comunicación del Riesgo es llevada a cabo por el Scrum Master hacia el Product
Owner y por el Product Owner hacia el cliente.

Esta comunicación siempre está en curso y debe ocurrir en paralelo durante los cuatro pasos
secuenciales discutidos hasta ahora.

6.5. Cambios
Ágil implica la apertura al cambio, por lo que es común que todos los proyectos ágiles estén
expuestos a cambios, y es de vital importancia que los miembros del equipo estén preparados
para enfrentar los cambios en cualquier etapa del proyecto.

Es aún más importante que la organización sea consciente de la exposición a los cambios para
crear sinergia con los equipos Scrum y buscar aprovechar los beneficios minimizando el impacto
negativo que pudiese resultar del cambio.
Dada la naturaleza iterativa o incremental de Scrum, es posible manejar los cambios sobre el
producto de una manera ordenada y cíclica, respondiendo continuamente a lo que espera el
cliente; en correspondencia con el manifiesto ágil, “Aceptamos que los requisitos cambien, incluso
en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar
ventaja competitiva al cliente”.

Aunque en Scrum hay una fuerte inclinación a no mantener grandes cantidades de información sin
valor, una forma apropiada de solicitar los cambios sobre los productos Scrum, es a través del
formato para Solicitud de Cambios – RFC (Request For Change), sin embargo esto no implica que
necesariamente haya documentación de por medio.

Un buen RFC, debería tener como mínimo los siguientes componentes:

¿Quién solicita el cambio? ¿Por qué? ¿Para qué necesitamos hacerlo?

¿Para cuándo se necesita?
¿Qué tan importante es?
¿Qué pasa si no se realizara/aprobara el cambio?
¿Quién lo va a ejecutar? ¿Qué necesita? ¿Es un empleado o debemos contratar?

Es importante que detrás de cada cambio solicitado exista un “iniciador” para mantener la traza
entre el cambio y saber de dónde proviene. Además dentro de la gestión de cambios en Scrum se
reconoce la autoridad del Product Owner en la aprobación/rechazo de los cambios, por lo que es
importante que durante todo el proyecto, el Product Owner esté enterado de lo que sucede con el
producto.

A continuación, se describe el flujo de los cambios:

dibujo

El Product Owner es el rol responsable de aprobar/rechazar los cambios, sin embargo, en

algunas ocasiones cuando los cambios se salen de su conocimiento o están por fuera del
alcance definido para el proyecto podrá escalar los cambios a la gerencia de la organización.
Los cambios pueden venir de distintas fuentes, las más comunes son:
Cambios solicitados por las partes interesadas.
Solicitudes realizadas por los miembros del Equipo.
Nuevas tecnologías emergen y es necesario realizar cambios al producto.
El producto definido comienza a perder vigencia y es necesario cambiar el alcance.

6.6. Diseño de producto

Scrum es usado comúnmente para la Gestión de Proyectos ágiles orientados a la construcción de
productos/servicios, sin embargo, etapas previas al proyecto como la concepción, prototipado y
diseño del producto no siempre se explican al detalle, siendo altamente importantes para el buen
desarrollo del proyecto.

Algunos de los conceptos que se deben considerar en esta etapa son:

6.6.1 - Producto mínimo viable

El definir el Producto Mínimo Viable o también llamado Características Mínimas de Mercado es una
actividad extremadamente importante, de modo que la primera versión del producto se construye
tan pronto como sea posible, lo que lleva a un aumento de rendimiento de la inversión.

Normalmente, estos requerimientos se ubicarían como alta prioridad dentro del Product Backlog.

El Producto Mínimo Viable se define entre el Cliente y el Product Owner.

6.6.2 - Análisis de viabilidad del

producto
El objetivo del modelo Lean Canvas (adaptado de Business Model Canvas) es el de identificar la
viabilidad de un producto o servicio y así disminuir el riesgo y los posibles obstáculos.

En muchas ocasiones el Lean Canvas se utiliza como el artefacto sustituto del caso de negocio.

Las claves a la hora de construir un Lean Canvas son:

Crear: Plantear la idea y probar con prototipos de bajo costo.

Medir: Comprobar el interés de posibles usuarios y medir resultados.
Aprender: Con los resultados se decide si se continua con la idea o se cambia algo.

El Lean Canvas está compuesto por 9 cuadrantes, tal como los que se describen a continuación:

dibujo

6.6.3 – Principios para el diseño

de un producto
Cuando se realiza el diseño de Productos Innovadores, se podrían considerar los siguientes
principios:

1. División: Dividir el producto en partes independientes (permitirá construirlo iterativamente),

crear productos modulares o fáciles de desarmar o dar mantenimiento o soporte. Ej: Arquitectura
de microservicios.

2. Multifuncionalidad: Considera que el producto pueda ejecutar múltiples funciones, o que se

elimine la dependencia de otros productos para funcionar.
Ej: Centralización de funcionalidades en una sola aplicación

3. Simplicidad: Reducir el número de acciones que debe realizar el usuario o consumidor del
producto para poder operarlo, en función de la experiencia de usuario (UX) Ej: Reducir la cantidad
de botones de un producto; Reducir la cantidad de clics necesarios para lograr una acción en una
aplicación.

4. Personalización: Garantizar que los consumidores o usuarios de un producto, pueden

personalizarlo de tal forma que se ajuste a sus necesidades Ej: Personalización de colores,
tamaños, cantidades, tipografías, imágenes, productos on-demand, etc

5. Curvatura y flexibilidad: En lugar de usar componentes, superficies o formas cuadradas,

rectangulares, cúbicas, planas o rígidas, usar las curvas redondeadas, trabajar con estructuras o
materiales flexibles esto permitirá un mejor uso del producto, facilidad en las interacciones e
incluso aumenta la resistencia del mismo Ej: Teléfonos plegables, autos de chasis flexible,
tendencia hacia el uso de diseños con formas redondeadas

6. Diseño o apariencia: Construir productos con diseños atractivos, simples y que reflejen la
calidad de los materiales o componentes. Además, realizar un cambio de imagen a los productos,
refleja a los clientes que existe una innovación constante.

7. Retroalimentación: Permitir la recolección de datos, estadísticas o comentarios del producto

para realizar mejora continua. Ej: Aplicaciones que recolectan datos de uso o consumo; Productos
que permiten enviar comentarios o recibir calificaciones.

8. Autoservicio: Se refiere a que el producto sea útil por sí mismo y no dependa de acciones de
terceros para ser utilizado (diagnóstico de fallas, configuración, implementación) Ej: Autos
modernos con sistema de ayuda para la identificación y prevención de fallas; Aplicaciones en la
nube que no requieren de capacitación previa para ser usadas.
9. Homogeneidad: Si tu organización diseña varios productos o servicios, debe crearse un
ecosistema consistente de elementos como interoperabilidad, diseños similares, o productos
secundarios. Ej: Suites ofimáticas “Google Apps” – “Microsoft Office”; Ecosistema de funciones de
Apple, etc.

Estos principios son genéricos y aplicables a cualquier producto o servicio, y harán parte de la
práctica “Definición de la Arquitectura de Producto”.
3. Scrum aplicado a proyectos

7.1 - Etapa 1: Inicio del

proyecto
Esta etapa del ciclo de vida, está compuesta por 6 prácticas. El objetivo principal de esta etapa es
establecer las condiciones básicas de conocimiento y planificación del producto, que permitirán su
correcto desarrollo durante la ejecución de los distintos Sprints.

Nota: Las prácticas de esta etapa no suelen ser prácticas iterativas

dibujo

ID Práctica Rol vs Nivel de Involucramiento

Etapa 1: Inicio del proyecto

7.1.1 - Definir la visión del proyecto Product Owner: Alto - Scrum Master:
1
(1) Nulo - Equipo de desarrollo: Nulo

Product Owner: Alto - Scrum Master:

2 7.1.2 - Formar el Equipo Scrum (2)
Alto - Equipo de desarrollo: N/A

7.1.3 - Construir el Product Backlog Product Owner: Alto - Scrum Master:

3
(3) Medio - Equipo de desarrollo: Medio

Product Owner: Alto - Scrum Master:

4 7.1.4 - Priorizar el Backlog (4)
Medio - Equipo de desarrollo: Medio

7.1.5 - Definir el cronograma de Product Owner: Alto - Scrum Master:

5
entregas (5) Alto - Equipo de desarrollo: Alto

Product Owner: Medio - Scrum

7.1.6 - Definir la Arquitectura de
6 Master: Medio - Equipo de desarrollo:
Producto (6)
Alto

7.1.1 - Definir la visión del

proyecto (1)
En la práctica de “Definir la visión del proyecto” se estructura la visión del proyecto, explicandolas
necesidades empresariales que el proyecto busca satisfacer, considerando el alcance, eltiempo, el
presupuesto y la calidad esperada por el patrocinador del proyecto.

Algunas de las actividades clave dentro de esta práctica son:

7.1.1.1 - Restricciones de un proyecto

Los proyectos siempre tienen limitaciones, también llamadas “restricciones”. Por lo general se
contemplan 4 restricciones principales (tiempo, presupuesto, alcance y calidad), sin embargo,
según la naturaleza del proyecto y/o el estilo de la organización, podrían existir otras restricciones.

dibujo

7.1.1.2 - Identificar las partes interesadas

Al inicio del proyecto, el Product Owner, se encarga de garantizar que todas las Partes Interesadas
son identificadas. Para ello, se recomienda que todas a su vez sean registradas, en lo que
comúnmente se llama “Matriz de Partes Interesadas”

Esta matriz contiene la siguiente información:

Empleados que trabajan para el proyecto, su respectivo rol y el tiempo en horas que dedican
al proyecto.
Proveedores del proyecto.
Clientes / Usuarios que serán entrevistados, revisarán el proyecto o brindarán información
útil para la construcción del producto.

7.1.1.3 - Definición de terminado (DoD)

Cuando un elemento del Product Backlog o del Incremento se describe como “Terminado”, todo el
mundo debe entender lo que significa “Terminado” (Done); aunque esto puede variar
significativamente para cada Equipo Scrum.

Los miembros del equipo deben tener un entendimiento compartido de lo que significa que el
trabajo esté completado para asegurar la transparencia. Esta es la definición de “Terminado”
(“Done”) para el Equipo Scrum, y se utiliza para evaluar cuándo se ha completado el trabajo sobre
el Incremento de producto.
Esta misma definición guía al Equipo de Desarrollo en saber cuántos elementos del Product
Backlog puede seleccionar durante la Planificación del Sprint. El propósito de cada Sprint es
entregar Incrementos de funcionalidad que potencialmente se puedan poner en producción y que
se ajusten a la Definición de “Terminado” (Done) actual del Equipo Scrum.

Los Equipos de Desarrollo (Development Team) entregan un Incremento de funcionalidad de

producto en cada Sprint. Este Incremento es utilizable, de modo que el Product Owner podría
elegir liberarlo inmediatamente. Si la definición de “Terminado” (Done) para un incremento es
parte de las convenciones, estándares o guías de la organización de desarrollo, al menos todos los
Equipos Scrum (Scrum Team) deben seguirla. Si “Terminado” (“Done”) para un incremento no es
una convención de la organización, el Equipo de Desarrollo del Equipo Scrum debe especificar una
definición de “Terminado” (Done) apropiada para el producto. Si hay múltiples Equipos Scrum
(Scrum Teams) trabajando en la entrega del sistema o producto, los equipos de desarrolladores en
todos los Equipos Scrum (Scrum Teams) deben definir en conjunto la definición de “Terminado”
(Done).

Cada Incremento se integra con todos los Incrementos anteriores y es probado de manera
exhaustiva, asegurando que todos los Incrementos funcionan en conjunto.

A medida que los Equipos Scrum maduran, se espera que su definición de “Terminado” (Done) se
amplíe para incluir criterios más rigurosos para una mayor calidad. El uso de las nuevos criterios
puede descubrir trabajo por hacer en los incrementos previamente “Terminados” (Done).
Cualquier producto o sistema debería tener una definición de “Terminado” (Done) que es un
estándar para cualquier trabajo realizado sobre él.

La Definición de Terminado puede ser definida para:

Un sólo Sprint.
Un Conjunto de Sprints.
Un Proyecto.
Un Programa.
Toda la Organización.

Un ejemplo genérico de criterios de terminado puede ser:

Los elementos fueron revisados por otros miembros del equipo (se realizaron las pruebas de
colegas).
Todos los defectos están arreglados.
Se completaron las pruebas unitarias de la Historia de Usuario.
Se finalizó toda la documentación técnica y de usuario final.
Todos los archivos y documentos del proyecto están en el repositorio de la organización.
Se hizo la demostración exitosa a los Socios y/o representantes de la empresa.
El cliente dio su visto bueno a los entregables.
7.1.2 - Formar el Equipo Scrum (2)
Durante esta práctica se eligen los miembros que harán parte de los distintos Equipos Scrum.

7.1.2.1 - Plan de colaboración

Este artefacto define cómo las distintas partes interesadas y miembros del equipo de proyecto
participan, se comunican y colaboran durante todo el proyecto. También se pueden definir las
herramientas o técnicas específicas que se utilizarán para este fin.

Por ejemplo, cuándo y cómo se llevarán a cabo las reuniones, qué tipo de herramientas de
comunicación se utilizarán, y quién debe estar involucrado en las diversas reuniones.

En proyectos grandes y complejos, especialmente con equipos distribuidos, este artefacto tiene
mucha más formalidad. En otros proyectos pequeños, a veces puede ser simplemente un
entendimiento verbal.

Por lo general es un artefacto que se construye en una reunión breve (30 minutos máximo), y se
tiene en cuenta la opinión del todo el equipo.

7.1.2.2 - Reunión de inicio de proyecto o

Kickoff
En esta reunión participan los responsables de ejecutar el proyecto y el cliente para formalizar el
nuevo proyecto y en qué momento inicia. Esta reunión también resulta una herramienta que
facilita la comunicación en el proyecto. (Esta reunión la dirige el Product Owner).

Los principales objetivos de la reunión de Kickoff son:

Presentar los objetivos, beneficios y alcance del proyecto.

Presentar el equipo de proyecto.
Obtener el compromiso del equipo y partes interesadas frente al proyecto.
Presentar el plan de trabajo inicial.
Presentar la identificación inicial de riesgos.
Definir la comunicación durante el proyecto.

7.1.2.3 - Modelo de desarrollo de equipos

– Dr. Bruce Tuckman
El Dr. Bruce Tuckman definió el modelo para describir el curso que la mayoría de los equipos
siguen en su camino hacia un alto rendimiento.

dibujo

1. Formación (Dirección) Esta es la etapa en que se conforma el equipo y los

miembros del equipo están empezando a conocerse, por lo que inicialmente su
comportamiento tiende a ser individualista. Durante esta fase de Formación se
establecen las primeras interacciones entre ellos, por lo que es común que no se
presenten conflictos o discusiones.

En esta etapa también se definen las reglas del equipo, su propósito y su identidad (un nombre
para el equipo), lo cual hace parte de un buen entorno de trabajo para el equipo.

En esta fase el Scrum Master toma una posición de “director” dado que los miembros del equipo
dependen de él para la definición del rumbo del equipo y su orientación.

2. Enfrentamiento/Conflicto En esta fase ya se ha generado confianza entre los

miembros del equipo, por lo que se presentan diferencias en el equipo y los
miembros compiten entre sí, estableciendo o rompiendo relaciones entre ellos.
Dado que cada miembro tiene su propia personalidad y estilo de trabajo, será
necesario que se alcance un acuerdo de convivencia para evitar la disminución de
la motivación.

Aunque la fase hace alusión al enfrentamiento, también es necesario que esos enfrentamientos se
resuelvan para asegurar el buen rendimiento del equipo.

En esta fase el Scrum Master toma una posición de “coach”, brindando acompañamiento al equipo
y guiando a los miembros para mantener los conflictos bajo control. También debe mantener la
calma y dar ejemplo del comportamiento deseado para que los demás miembros del equipo lo
imiten y adopten sanamente. El Scrum Master también es responsable de promover actividades
que aumenten la motivación del equipo e identificar cuáles son las interacciones que mejoran o
deterioran la convivencia en el equipo.

3. Normalización En esta fase los conflictos se reducen y se generan acuerdos que

mejoran las interacciones entre los miembros del equipo. Durante esta fase los
miembros comprenden mejor cuáles son sus responsabilidades, fortalezas y
debilidades, lo cual propicia un entorno de mayor confianza y colaboración.

Cada miembro ya es consciente de su lugar en el equipo y es capaz de entender y aceptar el estilo

de trabajo de los demás miembros, por lo que los intereses personales pasan a un segundo plano
para dar prioridad a los intereses del equipo como un todo.

En esta fase el Scrum Master es un “facilitador”, ya que toma un enfoque hacia la mejora y
acondicionamiento del entorno para facilitar el rendimiento del equipo. Dado que en esta fase el
Scrum Master conoce más al equipo, puede identificar de qué manera encajan mejor sus
miembros y cómo puede aumentar su rendimiento y motivación.

Es común que en esta fase se puedan incorporar nuevos miembros al equipo, por lo que el Scrum
Master tiene que velar por mantener la estabilidad del equipo asegurando que los nuevos
miembros se integren fácilmente al equipo sin disminuir su rendimiento ni su motivación.

4. Desempeño En esta fase se cuenta con un equipo maduro con suficiente confianza,
motivación y autonomía por lo que los miembros están en la capacidad de tomar
ciertas decisiones sin la presencia de un “jefe”, y se le pueden delegar tareas que
antes eran exclusivas del Scrum Master (como llevar a cabo reuniones diarias,
identificar impedimentos, etc.). Además, los miembros del equipo ya son capaces
de resolver los desacuerdos o diferencias positivamente y en poco tiempo.

Se debe reconocer que no todos los equipos llegan a esta etapa pues se logra después de
enfrentar conflictos y grandes dificultades, convivir y compartir experiencias, lo que implica que
muchos equipos no logren completamente la etapa de Normalización y se queden estancados en
la etapa de Enfrentamiento.

En esta etapa no se requiere de mucho esfuerzo por parte del Scrum Master, lo que le permite
enfocarse mucho más en mantener y mejorar el entorno de trabajo del equipo favoreciendo el alto
rendimiento de los miembros.

5. Finalización/Disolución Esta etapa comprende dos situaciones: la disolución del

equipo o la finalización del equipo. La disolución se presenta cuando
eventualmente durante el proyecto, uno o más integrantes se van del equipo, lo
que provoca un atraso en el avance que ya se había logrado, conllevando a una
disminución de la motivación y del rendimiento, pues el equipo queda resentido
tras la pérdida de su estabilidad.

La finalización del equipo se presenta cuando acaba el proyecto y los miembros del equipo pasan
a ser parte de otro proyecto o de otra empresa, lo cual implica que, aunque se haya alcanzado
exitosamente el objetivo del proyecto, entre los miembros se genera una sensación de “pérdida”
pues las interacciones que ya estaban establecidas y que ya funcionaban adecuadamente se
terminarán junto con el proyecto. En algunos casos el mismo equipo puede hacer parte de un
próximo proyecto, sin embargo, al tratarse de un nuevo proyecto no necesariamente significa que
las interacciones permanecerán de la misma manera.

Es necesario que el Scrum Master brinde acompañamiento al equipo, pues ya sea si se trata de la
disolución o la finalización, representa un cambio significativo para los miembros del equipo.

7.1.2.4 - Equipos de alto rendimiento

Un equipo de alto rendimiento es aquel que tiene un desempeño notablemente superior al
promedio. En Scrum normalmente el rendimiento se asocia a la velocidad con la que el equipo
consigue entregar valor. Para lograr equipos de alto rendimiento, se necesitan considerar como
mínimo los siguientes factores:

Se debe medir el rendimiento continuamente.

Se deberían utilizar herramientas para automatizar la mayor cantidad de tareas posibles.

La visión y reglas deben estar claras desde el inicio del proyecto.
Se debe garantizar la presencia de elementos que fomenten la creatividad.
Los objetivos definidos deben suponer un reto para el equipo.
El equipo debe mantenerse motivado.

7.1.2.5 - Modelo de desarrollo de

habilidades de Dreyfus
Cuando se consideran temas como la contratación de personal para un proyecto Scrum, y se
cuenta con el tiempo apropiado, con los recursos suficientes y una complejidad aceptable para
desarrollar una curva de aprendizaje, o cuando se quiere formar un equipo multidisciplinar con
una visión de largo plazo, entonces un modelo de desarrollo de habilidades y competencias es
aplicable y rendirá sus frutos en términos de calidad del trabajo, gestión del conocimiento,
cumplimiento de tiempos y reducción de costos.

Este modelo permite a las organizaciones identificar jóvenes talento con potencialidad para
desarrollar sus habilidades desde un nivel novato a un nivel experto a través de una combinación
de aprendizaje y práctica, así como determinar los perfiles necesarios para el desarrollo de un
proyecto. El modelo Dreyfus se divide en cinco (5) etapas:

1. Novato: Carece de experiencia, utiliza razonamiento analítico y reglas para determinar

una acción (causa-efecto), le es difícil sintetizar o alcanzar un nivel de generalización o
priorización de información. Necesita monitoreo y retroalimentación.
2. Principiante: Identifica puntos recurrentes o patrones significativos que componen la
situación, o unidades de comprensión, independientes del contexto. Utiliza el
razonamiento analítico y el reconocimiento de patrones para resolver problemas, además
puede abstraer la información más general de un problema.
3. Competente: Tiene un equilibro entre el razonamiento clínico metódico y analítico que le
permite reconocer e identificar con mayor facilidad patrones y aspectos comunes de un
problema. Depende del razonamiento analítico para el abordaje de problemas complejos
 o poco frecuentes.
4. Profesional: Evalúa situaciones conocidas y las extrapola a otras desconocidas, haciendo
frente a la ambigüedad, con visión de conjunto y un reconocimiento aparentemente
intuitivo obtenido a través de la experiencia, es capaz de construir perspectivas
particulares con base en el conocimiento y la experiencia.
5. Experto: Dicta intuitivamente una acción adecuada, descubre conscientemente las
normas o reglas presentes en una situación, está abierto a situaciones inesperadas, va
más allá de la imagen global, considerando aspectos culturales y de contextos más
amplios a cada situación.

dibujo

7.1.3 - Construir el Product

Backlog (3)
Durante esta práctica se construye el Product Backlog (Ver Sección 4.1 - Product Backlog).

Los elementos que hacen parte del Product Backlog son:

Épicas.
Historias de Usuario.
Errores.
Tareas.
Pruebas de Concepto.

Algunas de sus características más relevantes son:

Sus elementos están ordenados según la prioridad.

Su contenido está directamente relacionado con lo acordado con el patrocinador del
proyecto.
Cada elemento que hace parte del Product Backlog se llama PBI (Product Backlog Ítem).

7.1.3.1 - Clasificando el Product Backlog

Durante la construcción del Product Backlog es importante clasificar los elementos del Product
Backlog, para lo cual se podría utilizar el concepto de “épicas”.

Las épicas permiten agrupar los elementos del Product Backlog, permitiendo una mejor
navegación por el mismo. Algunas ideas de las que se podrían definir las épicas son:

Módulos.
 Componentes.
Hitos.
Entregables.
Funcionalidades.

7.1.4 - Priorizar el Backlog (4)

Priorizar los elementos del Product Backlog es una práctica clave para garantizar la entrega de
valor al cliente. Algunos de los factores que se deben considerar para la priorización de las
Historias de usuario dentro del Product Backlog son:

Tiempo.
Esfuerzo.
Valor Funcional.
Dependencias.
Riesgos.
Opinión de los Stakeholders.
Opinión del equipo de desarrollo.
Valor de Mercado ($).

Nota: La prioridad de los elementos puede cambiar durante la ejecución del proyecto.

7.1.4.1 – Priorización por urgencia

Una de las técnicas de priorización del Product Backlog está determinada por la urgencia y el valor
que representan los elementos del Product Backlog para las Partes Interesadas.

Los elementos que aporten más valor al negocio y tengan una mayor urgencia tendrán una mayor
prioridad dentro del Product Backlog:

dibujo

7.1.4.2 - Visual Story Mapping

Esta es una técnica para proporcionar un esquema visual del producto y sus componentes claves.
El Visual Story Mapping, fue formulado por Jeff Patton en 2005, y es comúnmente utilizado para
ilustrar la trayectoria del producto.

Este representa la secuencia de iteraciones de desarrollo de los productos (de izquierda a derecha
se organizan los componentes según su prioridad de desarrollo, tal como se ve en la imagen):
dibujo

7.1.5 - Definir el cronograma de

entregas (5)
En esta práctica, el Product Owner en compañía de los demás miembros del Equipo Scrum,
definen el cronograma de alto nivel del proyecto.

En esta práctica, podrían determinarse la duración estimada de los diferentes Sprints (dado que se
ya tienen los elementos del Product Backlog priorizados).

Este cronograma incluye la descripción de alto nivel de las actividades, compromisos, tareas
asignados específicamente a los miembros del equipo de desarrollo, los cuales se irán refinando a
lo largo del proyecto, en las reuniones de Planificación de cada sprint.

dibujo

Nota: Este cronograma se irá actualizando de manera iterativa durante los Sprints.

7.1.5.1 - Calendario del equipo

El calendario del equipo contiene información sobre la disponibilidad de los miembros del equipo,
considerando la información correspondiente a:

Las vacaciones de los miembros del Equipo Scrum.

Fechas de licencia.
Acontecimientos importantes en la organización.
Días festivos.
Eventos de la oficina.
Proyectos en curso.
Etc.

7.1.6 - Definir la Arquitectura de

Producto (6)
El objetivo de esta práctica es establecer o refinar el diseño técnico del producto o del
componente de producto a desarrollar. Aunque esta actividad es obligatoria siempre al inicio del
proyecto, podría hacerse también de forma iterativa antes de desarrollar componentes en los
distintos Sprint.

Para garantizar que la arquitectura de producto que se defina cumple exactamente con los
requerimientos del cliente se debe hacer en conjunto entre el equipo de desarrollo y el Product
Owner.

Antes de iniciar la construcción del producto es importante identificar la relación entre todos los
componentes que harán parte del mismo.

Ejemplo: Una empresa de desarrollo de software planea construir una aplicación para realizar
cursos virtuales. Al ser un proyecto de software, en la definición de arquitectura se deberán tener
en cuenta los siguientes elementos:

Bases de datos.
Servidores de almacenamiento.
Servidores de procesamiento.
Nombres de dominio.
Servidores de procesamiento de correo electrónico.
Firewall.
Web services.
Entre otros.

7.1.6.1 - Sprint Cero

Esta iteración es la primera en realizarse. El objetivo del Sprint Cero es preparar el equipo de
proyecto desde una perspectiva tecnológica, metodológica y organizativa, buscando conformar un
equipo y no simplemente un grupo de personas.

En esta actividad se analizan y evalúan las posibles soluciones que se pueden establecer para el
desarrollo del proyecto.

Estas posibles soluciones pueden ser:

Herramientas.
Soluciones Tecnológicas.
Soluciones técnicas.

Por cada solución escogida se deberá realizar una prueba de concepto, en donde se deben tener
en cuenta los siguientes criterios:

Curva de aprendizaje.
Escalabilidad (Solo si es solución técnica o tecnológica).
Soporte.
Costo. Nota: Este sprint solo se utiliza para los casos en que el equipo de proyecto tiene
 poca o nula experiencia en la tecnología en la cual se va a construir el producto o incluso si
cuenta con poca o nula experiencia en el tipo de producto que se va a desarrollar.

7.1.6.2 - Evaluación y Selección de

Proveedores
El propósito de esta actividad es garantizar la selección objetiva de los proveedores, utilizando los
criterios definidos por la organización. (Ver más información en la sección - Contratación de
Proveedores).
3. Scrum aplicado a proyectos

7.2 - Etapa 2: Planificación

del Sprint
Durante esta etapa del ciclo de vida, se realiza la planificación de cada uno de los Sprints, está
compuesta por 3 prácticas, 2 de las cuales (7 y 8) pueden ser ejecutadas bajo el concepto
“Planificación en paralelo”

Nota: Las 3 prácticas de esta fase son iterativas

dibujo

ID Práctica Rol vs Nivel de Involucramiento

Etapa 2: planificación

7.2.1 - Escribir las historias de Product Owner: Alto - Scrum Master:

7
usuario y tareas (7) Medio • Equipo de desarrollo: Alto

7.2.2 - Priorizar las Historias de Product Owner: Alto - Scrum Master:

8
Usuario (8) Medio - Equipo de desarrollo: Alto

7.2.3 - Reunión de Planificación del Product Owner: Alto - Scrum Master:

9
Sprint (9) Alto - Equipo de desarrollo: Alto

7.2.1 - Escribir las historias de

usuario y tareas (7)
7.2.1.1 - ¿Qué son las Historias de
Usuario?
Las historias de usuario son una forma más entendible y precisa para la escritura de los
requerimientos a desarrollar en el proyecto.
Están compuestas por 3 elementos principalmente:

Como: Describe el Rol de la persona o grupo que solicita (o usaría) la funcionalidad o

requerimiento.
Quiero: Describe la necesidad o requerimiento del usuario, por lo general, es una frase
corta.
Para: Describe el beneficio esperado por el usuario una vez se desarrolle el requerimiento.

Por lo general, las historias de usuario se complementan de otros aspectos que ayudan al equipo a
entenderlas mejor, algunos de estos pueden ser:

Criterios de aceptación
Criterios de prueba
Prototipos

Desarrollando mejores historias de usuario

Bill Wake inventó el acrónimo INVEST para describir las características de una buena historia de
usuario:

Independiente: Las historias pueden completarse en cualquier orden.

Negociable: Los detalles de la historia son co-creados por los desarrolladores y los clientes
durante el desarrollo.
Valiosa: La funcionalidad es valiosa para los clientes o los usuarios del producto.
Estimable: Los desarrolladores pueden encontrar una estimación razonable para construir
la historia.
Pequeña (Small): Las historias deberían construirse en poco tiempo, generalmente
alrededor de "días/persona". Se tiene que poder construir muchas historias en una iteración.
Probable (Testeable): Se debe poder escribir pruebas que verifiquen que el producto de la
historia funcione adecuadamente.

Criterios de aceptación para las historias de usuario

Los criterios de aceptación describen con mayor detalle el trabajo que debe ser completado en
cada historia de usuario. En la mayoría de ocasiones, estos criterios describen a nivel técnico el
trabajo a desarrollar. Algunas características de estos criterios son:

Los criterios de aceptación son únicos para cada historia de usuario o tarea a completar
Estos criterios suelen ser definidos por el Product Owner
Estos criterios permiten saber si esa historia de usuario es funcional y cumple las
necesidades, expectativas y/o requerimientos de los usuarios y/o clientes.
7.2.1.2 - Mockups y prototipos iniciales de
proyecto
Los Mockups representan el diseño del producto antes de su desarrollo, consideran el flujo que
debe seguir el producto, y sirven para mostrar las posibles funcionalidades al cliente y así
confirmar que estas entregarán el valor esperado.

Los mockups normalmente son un conjunto de bocetos, diseños, diagramas y/o representaciones;
y es especialmente necesario contar con un mockup o prototipo previo al Sprint, pues éstos
servirán de guía a los miembros del equipo.

dibujo

7.2.1.3 - Planificación en paralelo

Una actividad que puede representar una gran diferencia es la planificación en paralelo. Esta
actividad consiste en formar un pequeño equipo de personas que se encargan de realizar las
actividades de planificación paralelamente al desarrollo de los elementos realizados. Con esto se
logrará que las reuniones de planificación del Sprint sean muchísimo más eficientes. Algunas de
las cosas que se puedan hacer en paralelo al desarrollo son:

Realizar las entrevistas o investigaciones necesarias para escribir las historias de usuario.
Realizar los prototipos y confirmar el valor con el usuario.

7.2.1.4 - Desglosar las Historias de

Usuario en tareas
Esta actividad sirve para identificar las posibles dependencias entre las historias de usuario, para
ello, se elabora un listado con todas las tareas que se deben llevar a cabo para completar la
Historia de Usuario.

Normalmente se distinguen 4 tipos de dependencias entre historias de usuario:

Dependencias obligatorias.
Dependencias discrecionales.
Dependencias externas.
Dependencias internas. Algunas técnicas que pueden ser usadas para desglosar las Historias
 de Usuario en tareas son:
Los Diagramas de Flujo.
Los Diagramas de Gantt.

7.2.2 - Priorizar las Historias de

Usuario (8)
Esta práctica está relacionada con la planificación en paralelo, debido a que mientras el equipo
termina de desarrollar lo establecido para el último Sprint, el Product Owner realiza una
priorización de las historias de usuario que pueden considerarse para el siguiente Sprint y que se
pueden tomar como base para guiar el rumbo del equipo.

Es importante que esta priorización se realice antes de que se lleve a cabo la Reunión de
Planificación del Sprint con el fin de optimizar el tiempo.

Los elementos que se deben considerar para la priorización de las historias de usuario son:

Valor para el negocio.

Riesgo.
Dependencia.

7.2.3 - Reunión de Planificación

del Sprint (9)
7.2.3.1 - Seleccionar el trabajo a
desarrollar
El Product Owner expone el objetivo que el Sprint debería lograr y los elementos del Product
Backlog que, si se completan en el Sprint, lograrían el objetivo del Sprint, con esto el Equipo de
Desarrollo trabaja para proyectar la funcionalidad que se desarrollará durante el Sprint.

La entrada a esta reunión está constituida por el Product Backlog y tomando la priorización de
historias de usuario realizada por el Product Owner, incluyendo además:

El último incremento de producto.

 La capacidad proyectada del Equipo de Desarrollo para el Sprint.
La velocidad del Equipo de Desarrollo.
Fallos encontrados al producto o incrementos de producto (registro de errores).

El número de elementos del Product Backlog seleccionados para el Sprint depende únicamente del
Equipo de Desarrollo. Solo el Equipo de Desarrollo puede evaluar qué es capaz de lograr durante
el Sprint que comienza.

Durante la Planificación del Sprint el Equipo Scrum define el objetivo del Sprint. El objetivo del
Sprint debería lograrse durante el Sprint a través de la implementación del Product Backlog y
proporciona una guía al Equipo de Desarrollo del por qué se está construyendo el incremento.

7.2.3.2 - Estimación del trabajo

seleccionado
Es muy importante realizar la estimación del trabajo seleccionado (comúnmente escrito en forma
de historias de usuario) para poder hacer planificaciones más precisas.

Para garantizar una estimación más precisa, se deberían considerar criterios como:

Tamaño.
Complejidad.
Duración.
Cantidad de recursos.
Riesgos.
Limitaciones.

Normalmente las técnicas de estimación usadas por Scrum están basadas en el juicio de expertos,
sin embargo existen otras técnicas que se pueden utilizar y combinar:

Planning Poker

El póker de planificación consiste en un conjunto de tarjetas numéricas que sirven para realizar la
estimación de tareas o historias de usuario.

El póker puede ir numerado de 1 a 10 o utilizando la sucesión de Fibonacci.

El uso del póker promueve una mayor interacción y una mejor comunicación entre los
participantes, además de hacer más dinámica la reunión de planificación del Sprint.

Fist of Five
Es una técnica que permite lograr el consenso en los Equipos Scrum. Se hace usando los dedos de
la mano, donde el número de dedos que se utiliza para la votación indica el nivel de acuerdo y el
deseo para el debate:

Un dedo: no estoy de acuerdo con la conclusión del grupo y tienen grandes preocupaciones.
Dos dedos: no estoy de acuerdo con la conclusión del grupo y me gustaría hablar de algunos
problemas menores.
Tres dedos: no estoy seguro y me gustaría asumir la conclusión de consenso del grupo.
Cuatro dedos: Estoy de acuerdo con la conclusión del grupo, pero me gustaría discutir
algunos problemas menores.
Cinco dedos: Estoy totalmente de acuerdo con la conclusión del grupo.

7.2.3.3 - Compromiso del equipo

Una de las actividades clave durante la Planificación de un Sprint es la apropiación de las Historias
de Usuario y tareas por parte del equipo de desarrollo, esto se logra cuando los miembros del
equipo se auto-asignan el trabajo a desarrollar, a su vez que adquieren el compromiso público de
terminar dicho trabajo.

Es sumamente importante garantizar que existe equilibrio en la cantidad de trabajo seleccionado

por cada uno de los integrantes del equipo.

Suele suceder que en equipos Scrum donde se encuentran combinados miembros expertos y
miembros novatos existirá un “desequilibrio” en etapas tempranas del proyecto, pues los
miembros expertos contarán con más capacidad de trabajo mientras los miembros novatos se
nivelan en su curva de aprendizaje.

7.2.3.4 - ¿Cómo se conseguirá “terminar”

el trabajo seleccionado?
Una vez que se ha establecido el objetivo y se han seleccionado los elementos del Product Backlog
para el Sprint, el Equipo de Desarrollo decide cómo construirá esta funcionalidad para formar un
Incremento de producto “Terminado” durante el Sprint. Los elementos del Product Backlog
seleccionados para este Sprint, junto con el plan para terminarlos, recibe el nombre de Sprint
Backlog.

Durante la Planificación del Sprint se debe asegurar que se planifica el suficiente trabajo como
para que el Equipo de Desarrollo pueda hacer una proyección de lo que cree que puede completar
en el Sprint que comienza.

Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros
días del Sprint es descompuesto en unidades de un día o menos. El Equipo de Desarrollo se
autoorganiza para asumir el trabajo del Sprint Backlog, tanto durante la Planificación del Sprint
como a lo largo del Sprint.

El Product Owner puede ayudar a clarificar los elementos del Product Backlog seleccionados y
hacer concesiones. Si el Equipo de Desarrollo determina que tiene demasiado trabajo o que no
tiene suficiente trabajo, podría renegociar los elementos del Product Backlog seleccionados por el
Product Owner. El Equipo de Desarrollo podría también invitar a otras personas a que asistan para
proporcionar asesoría técnica o relacionada con el dominio.

7.2.3.4.1 - Objetivo del Sprint

El objetivo del Sprint es una meta que se establece para cada Sprint durante la Reunión de
Planificación del Sprint. Dicha meta describe el alcance de cada Sprint en alineación con el Product
Backlog, a su vez proporciona una guía al Equipo de Desarrollo acerca de por qué está
construyendo el incremento.

Definir el objetivo del Sprint brinda al Equipo de Desarrollo cierta flexibilidad con respecto a la
funcionalidad que ha de ser construida en el Sprint.

Los elementos seleccionados del Product Backlog ofrecen una orientación sobre lo que
puede ser el objetivo del Sprint.
El objetivo del Sprint garantiza que el Equipo de Desarrollo trabaje en conjunto y no en
iniciativas separadas.
Por lo general el objetivo del Sprint suele ser una frase corta que explica de forma simple el
incremento esperado al final del Sprint. A medida que el Equipo de Desarrollo trabaja
mantiene el objetivo del Sprint en mente. Si el trabajo resulta ser diferente de lo esperado,
los miembros del equipo escalan la situación con el Scrum Master para contactar al Product
Owner y se pueda negociar el alcance del Sprint.

7.2.3.4.2 - Spikes
Un Spike sirve para incluir en un sprint tareas que NO implican desarrollar una historia de usuario
y por tanto NO aportan directamente al incremento de producto que se está desarrollando.

Algunos ejemplos de Spikes son:

Capacitación del Equipo.

Documentación del proyecto y/o producto (ejemplo: Documentar el código fuente).
Despliegues / Implementaciones.
Adopción de nuevas herramientas.
3. Scrum aplicado a proyectos

7.3 - Etapa 3: Desarrollo del

Sprint
Esta etapa contiene 2 prácticas que se realizan durante el desarrollo de los incrementos del
producto. Ambas prácticas son iterativas y se realizan en todos los Sprints del proyecto.

Como se aprecia en el gráfico a continuación, el Scrum Diario es una práctica que se realiza en
forma paralela al desarrollo de los entregables del Sprint.

dibujo

ID Práctica Rol vs Nivel de Involucramiento

Etapa 3: desarrollo del sprint

7.3.1 - Desarrollar los entregables Product Owner: Bajo - Scrum Master:

10
(10) Medio - Equipo de desarrollo: Alto

Product Owner: Nulo - Scrum Master:

11 7.3.2 - Scrum diario (11)
Alto - Equipo de desarrollo: Alto

7.3.1 - Desarrollar los entregables

(10)
El objetivo de esta actividad es el desarrollo de los entregables del Sprint, los manuales o
documentación relacionada considerando siempre la definición de “terminado”.

Nota: En conjunto con esta práctica, se ejecutan los Scrums Diarios, y Las pruebas de los
entregables.

7.3.1.1 – El ciclo de desarrollo para

proyectos de software
Para el desarrollo de proyectos de software, normalmente se sigue el flujo que se muestra en el
gráfico a continuación:

dibujo

7.3.1.1.1 – Las pruebas

Las Pruebas son una forma de comprobar el correcto funcionamiento del producto. Por lo general
existen varios tipos de pruebas, siendo los principales:

Pruebas unitarias: Son escritas por el mismo desarrollador siguiendo los criterios de
aceptación de la historia de usuario. Estas pruebas suelen realizarse de manera
automatizada.
Pruebas de colegas: Suelen ser manuales, en las cuales el colega revisan no solo el
funcionamiento, sino la calidad del código, y compara el resultado vs prototipos.
Pruebas de integración: Suelen ser automatizadas. Éstas se ejecutan en cada integración y
antes de cada entrega.

También se distinguen 2 tipos de ejecución de las pruebas:

Pruebas manuales.
Pruebas automatizadas.

Las 2 posibles salidas de una prueba son:

Aprobada: Se cumple con todas las expectativas y/o criterios de aceptación de las historias
de usuario que se están probando.
Rechazada: NO se cumple con todas las expectativas y/o criterios de aceptación de las
historias de usuario que se están probando. Cuando se rechaza una historia de usuario
durante las pruebas, se debe reportar el error en un “Log de Errores”, normalmente dentro
del Product Backlog.

Reporte de errores Es importante tener en cuenta que los errores deben pasar por un proceso
de estimación igual que las Historias de Usuario (se planifica su resolución en los diferentes
Sprints del proyecto).

Cuando se reporten los errores, se debe tener en cuenta:

Evitar escribir declaraciones vagas o suposiciones no probadas.

Poner títulos genéricos a los errores.
Se deberían categorizar los errores, ej: Errores en producción, Errores de colegas, Errores en
la revisión, etc.
Deberían describirse como pasos de reproducción sencillos y repetibles para que la persona
que corregirá el error pueda seguir la secuencia.

7.3.1.1.2 – Integración continua

La Integración Continua es una práctica de desarrollo de software mediante la cual los
desarrolladores combinan los cambios en el código en un repositorio central de forma periódica,
tras lo cual se ejecutan versiones y pruebas automáticas para asegurar la integridad del código.

Para facilitar la integración continua:

Se debe tener un repositorio único para el código fuente.

Se debe garantizar que el código se actualiza constantemente tanto en el repositorio, como
en el ambiente de trabajo de cada desarrollador.
Siempre ejecutar pruebas automatizadas para garantizar que cuando se mezcla el código,
no se pierden o dañan las funcionalidades existentes.

7.3.1.1.3 – Documentación
La documentación es un aspecto vital en los proyectos de software, esto permitirá el posterior
entendimiento del código fuente y así garantizar la propiedad colectiva del producto. Para que la
documentación sea efectiva, se debe garantizar que:

Sea fácil de redactar y entender.

Debe estar compartida con todos.
Se actualiza diariamente.
Debe tener un índice o búsqueda.
Debe estar organizada por módulos o componentes.
Debe ser alimentada por todo el equipo.

7.3.1.1.4 – Refactorización
El objetivo de esta técnica es mejorar el mantenimiento del código existente y hacerlo más simple,
más conciso y más flexible. Refactorizar significa mejorar el diseño del código actual, sin cambiar
el comportamiento del código. Algunas de las ventajas de la refactorización son:

Mejorar la facilidad de comprensión del código.

Mejorar su estructura y diseño.
Eliminar código muerto.
Facilitar el mantenimiento en el futuro.

Algunos de los momentos clave para realizar la refactorización, son:

Después de pasar una prueba automatizada.

Cuando agregar una nueva característica es bastante complicado.
Cuando mejora el conocimiento o experiencia del equipo de desarrollo.
Cuando el equipo dedica bastante tiempo a entender el detalle del código.

Algunos ejemplos de refactorización son:

Organizar el repositorio de documentos/archivos.

Separación de funciones.
 Renombrar variables.
Simplificación de las interfaces.

7.3.2 - Scrum diario (11)

Para más detalles ver la Sección 3.3 - Daily Scrum (Scrum Diario)

7.3.2.1 - Seguimiento del Progreso del

Sprint
En cualquier momento durante un Sprint es posible conocer el progreso del Sprint sumando el
trabajo restante total en los elementos del Sprint Backlog. El Equipo de Desarrollo hace
seguimiento de este trabajo restante total al menos en cada Scrum Diario para proyectar la
posibilidad de conseguir el objetivo del Sprint. Haciendo seguimiento del trabajo restante a lo
largo del Sprint el Equipo de Desarrollo puede gestionar su progreso.
3. Scrum aplicado a proyectos

7.4 - Etapa 4: Revisión del

Sprint
El objetivo de esta etapa es recolectar retroalimentación de cada uno de los Sprints, y así, permitir
la adaptación y mejora continua tanto del producto como de las prácticas ejecutadas por el Equipo
Scrum. Está compuesta por 2 prácticas que son iterativas y deberán ejecutarse en cada Sprint.

Durante esta etapa del ciclo de vida, también se realiza el monitoreo y control del proyecto, dando
paso a: Gestión de Cambios, Gestión de Riesgos y la Gestión Financiera.

dibujo

ID Práctica Rol vs Nivel de Involucramiento

Etapa 4: Revisión del Sprint

7.4.1 - Reunión de Revisión del Sprint Product Owner: Alto - Scrum Master:
12
(12) Alto - Equipo de desarrollo: Alto

7.4.2 - Reunión de Retrospectiva del Product Owner: Nulo - Scrum Master:

13
Sprint (13) Alto - Equipo de desarrollo: Alto

7.4.1 - Reunión de Revisión del

Sprint (12)
En esta reunión de revisión se realiza la demostración del incremento de producto al Product
Owner y partes interesadas invitadas, con el fin de obtener aprobación sobre lo que se esperaba y
lo que fue desarrollado por el equipo.

A continuación, se listan las actividades que se realizan durante la Reunión de Revisión del Sprint:

Presentar el incremento de producto: El equipo de desarrollo presenta al Product Owner y al

Scrum Master el incremento del producto desarrollado.
Probar el incremento de producto (Validación): El Product Owner y las partes interesadas
invitadas (solo si las hay) prueban el incremento de producto con base en la comparación
del desarrollo frente a cada historia de usuario y sus criterios de aceptación. (Es válido que
se cuente con una lista de chequeo para llevar el registro de lo que se cumple y lo que no se
 cumple).
Aprobación del incremento de producto: Con base en el incremento presentado y la
validación el Product Owner da la aprobación del incremento de producto. En caso que el
incremento no cumpla con lo esperado puede darse el Rechazo del incremento.
Monitoreo, control y seguimiento del proyecto: Ver más en Sección 6.2 Seguimiento y
control del proyecto.
Ritmo/velocidad del equipo: Se identifica el ritmo/velocidad del Equipo de Desarrollo.
Compromisos del equipo: Se identifican compromisos por parte del equipo en caso del
rechazo del incremento de producto o de historias de usuario puntuales.
En caso de rechazo se agregan las mejoras al Product Backlog con la prioridad más
alta posible, con el fin de corregirlas en el próximo sprint de ser posible.
Actualizar el Product Backlog: Se debe actualizar el Product Backlog y dar por terminado el
sprint actual.

¿Cómo se realizan las validaciones? En esta reunión se presenta el incremento de producto ante
los interesados, los cuales se cerciorarán que cada una de las funcionalidades establecidas y
solicitadas en el Sprint estén terminadas (bajo los lineamientos de los criterios de aceptación y los
criterios de “terminado”).

7.4.1.1 - Deuda técnica

La deuda técnica se refiere al trabajo que los equipos omiten o no se completa durante uno o
varios Sprints.

Si la deuda técnica se acumula, puede conllevar a un mantenimiento, integración y costos

elevados en el despliegue del producto.
La priorización frecuente de Historias de Usuario contribuye a disminuir la deuda técnica.
Cualquier deuda técnica no debería llevarse más allá de un sprint.

Algunas de las causas de la deuda técnica son:

Evaluación inadecuada o incompleta de Historias de Usuario

Falta de coordinación entre los miembros del equipo
Intercambio deficiente del conocimiento empresarial

7.4.1.2 - Refinamiento del Product Backlog

El refinamiento del Product Backlog es el acto de añadir detalle, estimaciones y orden a los
elementos del Product Backlog; se trata de una actividad continua en la cual el Product Owner y el
Equipo de Desarrollo examinan, revisan y detallan los elementos del Product Backlog.

Los elementos del Product Backlog pueden actualizarse en cualquier momento por El
Product Owner o a criterio suyo.
 El refinamiento usualmente consume no más del 10% del tiempo de la Reunión de Revisión
del Sprint.

7.4.2 - Reunión de Retrospectiva

del Sprint (13)
La Retrospectiva del Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo
y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint. La Retrospectiva
debería realizarse en un ambiente liberador que permita al equipo fluir todo tipo de ideas.

La Retrospectiva del Sprint tiene lugar después de la Revisión de Sprint (Sprint Review) y antes de
la siguiente Planificación de Sprint. Se trata de una reunión restringida a lo máximo de 4 horas
para Sprints de un mes.

El Scrum Master enseña a todos a mantener el evento positivo y productivo; y participa de esta
reunión como un miembro del equipo ya que parte de la responsabilidad de los incrementos recae
sobre él.

El Scrum Master motiva al equipo para que mejore su proceso de desarrollo y sus prácticas para
hacerlos más efectivos y amenos para el siguiente Sprint. Durante cada Retrospectiva del Sprint el
Equipo Scrum identifica y planifica formas de mejorar la calidad del producto mediante el
mejoramiento de la calidad de las prácticas, que pueden ser implementadas en el próximo Sprint.

El hecho de implementar estas mejoras en el siguiente Sprint constituye la adaptación

subsecuente a la inspección del Equipo de Desarrollo mismo. Aunque las mejoras pueden
implementarse en cualquier momento, la Retrospectiva del Sprint ofrece un evento dedicado para
este fin, enfocado en la inspección y la adaptación.

En resumen, durante la Retrospectiva:

El equipo de trabajo se enfoca en responder a las siguientes preguntas:

Qué cosas han funcionado bien.
Cuáles hay que mejorar.
Qué cosas quiere probar el equipo en la siguiente iteración.
Qué ha aprendido el equipo.
El equipo identifica las mejoras accionables para mantener o mejorar el trabajo del equipo, y
mantener la motivación de los miembros.
El equipo documenta y actualiza el registro de lecciones aprendidas.

7.4.2.1 - Técnicas para la realización de la

Retrospectiva del Sprint
La retrospectiva es una de las ceremonias más importantes dentro del desarrollo de un proyecto
usando Scrum, ya que es una de las principales fuentes de aprendizaje continuo que tiene el
equipo, además sirve para mantener la motivación y el compromiso con el proceso de desarrollo.

Uno de los elementos que se deben tener en cuenta, es que el realizarla siempre de la misma
manera (monotonía), podría disminuir el interés de los equipos en participar. Así que muchos de
los Scrum Máster, suelen utilizar la reunión de retrospectiva del Sprint como un evento en el cual
experimentar e introducir nuevas técnicas.

Por lo general una retrospectiva suele tener 5 momentos importantes:

1. Preparación de la sesión
2. Recolección/Análisis de los datos
3. Generar ideas de mejora/cambio
4. Definir los planes de acción (experimentos a aplicar en los próximos Sprint)
5. Recolección de retroalimentación de la retrospectiva

A continuación, se mencionan algunas de las tantas técnicas disponibles que se pueden realizar
como parte de una Retrospectiva del Sprint.

Índice de felicidad del Equipo El índice de felicidad del equipo es una técnica utilizada para
medir el nivel de felicidad alrededor del tiempo de cada uno de los miembros de un equipo. Se
caracteriza por su facilidad de aplicación, además de tener el anonimato como uno de sus pilares
centrales.

Para aplicar la técnica, el Scrum Master suele construir un tablero (canvas) como el que se
muestra a continuación:

dibujo

Suele estar en un lugar visible de las oficinas de trabajo del equipo Scrum
Si está físico (recomendable), se utilizan stickers de colores para completar el tablero y así
mapear el estado de ánimo
Las variaciones en la felicidad del equipo, pueden ser el reflejo de las situaciones vividas en
la organización.
Es una medición subjetiva, por lo que los resultados deben manejarse con precaución
Le aportan bastante valor a las labores realizadas por el Scrum Master, ya que se puede
enfocar en hacer la vida más feliz a todos los miembros de los equipos que lidera.
Siempre se debe garantizar el anonimato, ya que, de lo contrario, los resultados mostrados
en el tablero no serán precisos o acordes a la realidad
Aunque los datos se recolectan a lo largo del desarrollo de un Sprint, su análisis se puede
hacer en conjunto con todo el equipo como parte de una retrospectiva.
4L’s

Esta técnica descrita ampliamente en el libro “Agile Retrospectives” se utiliza como ejercicio en
las retrospectivas. Consiste en un tablero (canvas) dividido en 4 cuadrantes:

1. Liked: Aquí cada uno de los miembros puede poner todas las cosas que les gustaron
durante el desarrollo del Sprint (Ej: La planificación organizada, la nueva herramienta con
la que se trabajó, una nueva técnica implementada por el Scrum Master, etc)
2. Learned: En esta sección, se listan todos aquellos elementos que el equipo siente que
aprendió y que le servirán para próximos Sprints (Ej: La importancia de comentar el
código, nuevas técnicas para revisar los entregables, nuevas técnicas de retrospectiva,
etc)
3. Lacked: Aquí se colocan todas las cosas que faltaron durante el Sprint, así como las
necesidades que el equipo tiene. (Por lo general suelen estar asociadas a impedimentos
que haya tenido el equipo)
4. Longed For: Acá los integrantes del equipo colocan todas aquellas cosas que quieren que
sucedan en el futuro próximo (Ej: Mayor participación del cliente, mejor redacción en las
historias de usuario, una nueva herramienta, etc)

dibujo

Suele tenerse el canvas impreso y disponible en la oficina, para ser completado con sticky-
notes
Todos los datos son analizados por el Scrum Master, en conjunto con los miembros del
equipo para así definir planes de acción para los próximos Sprint.

Feedback

Con el fin de que los equipos de trabajo tengan oportunidades de mejora en sus enfoques y
desarrollo del trabajo, es necesario que el líder del equipo o incluso entre colegas, una vez
finalizado un Sprint (o en cualquier momento que se considere necesario), se brinden
retroalimentación.

El objetivo de la retroalimentación es hablar de situaciones buenas, para alentar dichos

comportamientos, o de situaciones malas, para que la otra persona pueda convertirlas en
oportunidades de cambio. Las sesiones de retroalimentación están orientadas a mejorar y
fortalecer al equipo de trabajo, ayudando al desarrollo de competencias y crecimiento personal,
individual y grupal.

Las sesiones de retroalimentación suelen tener las siguientes características:

1. Son reuniones en privado por lo general

2. No solo deberían usarse para hablar de cosas negativas
3. No sólo deberían realizarse por los líderes, también debería alentarse la realización de
retroalimentación entre compañeros de equipo, así que por lo general la
retroalimentación hace parte de una cultura de mejora y aprendizaje continuo.
 4. La retroalimentación debe realizarse de forma continua
5. Siempre debería realizarse de forma inmediata al hecho o hechos que se vayan a tratar
durante la sesión.

Feedforward El feedforward es una variación de la retroalimentación, esta técnica se centra más

en las posibilidades futuras que en errores pasados, no solo se trata de comunicar, sino de hacerlo
pensando en las oportunidades de mejoramiento de las prácticas a futuro, todo bajo un ambiente
de motivación, optimismo y pensando en todo aquello que se pueda lograr para trasformar las
oportunidades en casos de éxito.

Son características que se deben tener en cuenta:

• Dar sugerencias para el futuro y aprender tanto como se pueda. • No se deberían tratar hechos
pasados. • Es más productivo que el feedback, puesto que ayuda a las personas a hacer lo
“correcto” más que probar que estaban “equivocados”.
3. Scrum aplicado a proyectos

7.5 - Etapa 5:
Implementación
Durante la etapa de implementación se realiza la entrega y/o puesta en marcha de todos los
entregables desarrollados por el Equipo Scrum, durante esta etapa, se realiza el valor del
producto. Está compuesta por 2 prácticas que se realizaran en forma iterativa (hasta donde sea
posible y así lo permita la naturaleza del producto).

dibujo

ID Práctica Rol vs Nivel de Involucramiento

Etapa 5: Implementación

Product Owner: Medio - Scrum

7.5.1 - Planificación de la
14 Master: Bajo - Equipo de desarrollo:
implementación (14)
Alto

Product Owner: Medio - Scrum

7.5.2 - Implementación de
15 Master: Bajo - Equipo de desarrollo:
entregables (15)
Alto

El objetivo de esta etapa es la puesta en producción de los incrementos aprobados en la Revisión

del Sprint, para su inmediata utilización y aprovechamiento por parte del cliente y/o interesados.
En los proyectos Scrum, suele ser una etapa iterativa, para así aprovechar todos los incrementos
utilizables desde etapas tempranas del proyecto.

Según la naturaleza de la organización, es común que éstas prácticas sean ejecutadas por grupos
distintos al Equipo Scrum, sin embargo es altamente recomendable que sea el mismo Equipo el
que se haga responsable de este trabajo, así se garantiza un real compromiso por la calidad de los
entregables, a la vez que se evita la aparición de una cultura de la culpa.

7.5.1 - Planificación de la
implementación (14)
El objetivo de esta práctica es preparar todos los elementos necesarios para realizar una
implementación exitosa de los incrementos generados en los Sprint, disminuyendo
significativamente los riesgos que puedan impactar negativamente las operaciones de los
usuarios/clientes.

La cantidad de entregas (despliegues) dependerá de lo acordado con el cliente o patrocinador del

proyecto, y por lo general, dependen del valor para la organización.

7.5.1.1 - Coordinación con operaciones

Una actividad clave es la coordinación con los distintos equipos de operaciones del cliente para
preparar la implementación.

Algunos elementos clave en esta actividad son:

¿Cuándo se hará la implementación?

¿Qué usuarios recibirán el nuevo producto?
¿La implementación del producto afectará las operaciones?
¿Cómo se notificará a los usuarios?
¿Los usuarios están capacitados para usar el nuevo producto?
¿Qué hará el Equipo de Desarrollo en caso de que la implementación tenga fallos?

Nota: Es altamente recomendable que los equipos de operaciones hayan participado de las
reuniones de Revisión de los Sprint.

7.5.2 - Implementación de
entregables (15)
Esta práctica busca poner a disposición de los usuarios los incrementos finalizados y utilizables
previamente desarrollados por el Equipo Scrum.

Cabe aclarar que esta práctica no es posible aplicarla en todos los tipos de proyectos, ni es
obligatorio ejecutarla al finalizar cada Sprint, solo será aplicable cuando el incremento de producto
genere valor para los usuarios o para la organización.

La implementación de entregables puedes realizarse de varias formas, las 2 más comunes son:

Big bang: Este tipo de implementación, busca poner el incremento a disposición de toda la
comunidad de usuarios al mismo tiempo. También se le llama “Implementación masiva”.
Por fases: Este tipo de implementación se usa en caso de que se quiera hacer una
segmentación de los usuarios para implementar el incremento (ej: entregarlos solamente a
usuarios específicos).
7.5.2.1 - Confirmación de implementación
exitosa
Una vez el incremento de producto está en ambientes productivos, es importante confirmar que
no hubo afectaciones a la operación, por lo que podrían ejecutarse revisiones o pruebas post-
implementación.

En muchas ocasiones luego de la confirmación de implementación exitosa, se realiza la

notificación formal al cliente (incluso se firma algún artefacto como constancia), y así disminuir la
probabilidad de que surjan nuevas solicitudes de cambios sobre los elementos ya entregados.

7.5.2.2 - Despliegues Fallidos

En caso de que los resultados de la implementación sean negativos se evaluará de manera rápida
si se pueden solucionar durante una ventana de mantenimiento, en caso contrario se deberá
realizar un “rollback” y planear un nuevo Sprint en el que se solucionen los problemas
encontrados, dando paso a un nuevo despliegue.
3. Scrum aplicado a proyectos

7.6 - Etapa 6: Cierre del

proyecto
Esta es la etapa final de un proyecto Scrum, tiene como objetivos formalizar el cierre del proyecto
de cara a las partes interesadas y recolectar lecciones aprendidas que permitan mejorar el
desarrollo de futuros proyectos. Esta etapa es crucial en el trabajo de una APMO (Agile Project
Management Office), ya que en esta etapa es donde se elaboran comúnmente informes que
permiten a la organización determinar el valor realizado por un proyecto.

dibujo

ID Práctica Rol vs Nivel de Involucramiento

Etapa 6: Cierre del proyecto

Product Owner: Alto - Scrum Master:

16 7.6.1 - Cierre del proyecto (16)
Bajo - Equipo de desarrollo: Bajo

7.6.2 - Reunión de Retrospectiva del Product Owner: Alto - Scrum Master:

17
proyecto (17) Alto - Equipo de desarrollo: Medio

7.6.1 - Cierre del proyecto (16)

En la reunión de cierre de proyecto se dejará registro del cierre y motivo del cierre del proyecto,
para este fin podría construirse un acta de Cierre del proyecto. Los siguientes pueden ser motivos
para el cierre del proyecto:

Cierre exitoso del proyecto: Se cumplió con todos los entregables programados dentro del
presupuesto asignado y de acuerdo con los criterios de aceptación (satisfacción total del
cliente).
Cierre parcial del proyecto o aplazamiento: Se cumplió parcialmente con los entregables
programados, se está superando el presupuesto asignado o no se ha cumplido
completamente con todos los criterios de aceptación (satisfacción parcial del cliente).
Cancelación del proyecto: No se cumplió con ninguno de los entregables programados, se
agotó el presupuesto asignado antes de tiempo, no se cumplió con ningún criterio de
aceptación (insatisfacción total del cliente).
¿Qué hacer durante esta etapa?

Entregar el producto terminado.

Obtener la aprobación de los entregables del proyecto por parte del cliente.
Cerrar formalmente el proyecto.
Verificar la satisfacción por parte del cliente y las partes interesadas.

¿Qué se necesita para la reunión?

Producto o incremento de producto desarrollado por el equipo: Para registrar el estado del
producto al momento de cierre del proyecto.
Acta de Inicio del Proyecto: Para validar el alcance, objetivos y aspectos iniciales del
proyecto.
Resultados de las pruebas de integración: Incluye un informe de las pruebas que se
realizaron tras la entrega de cada incremento del producto para garantizar la correcta
integración entre componentes.
Criterios de aceptación del producto: Para verificación y validación de lo esperado en
comparación con lo que se entregó.
Documentación/Capacitación al cliente: Para garantizar que el cliente cuenta con el
conocimiento sobre el uso, instalación, configuración o soporte básico del producto.
Informes de proyecto: Que muestran el estado actual del progreso del proyecto (Se
mostrarán informes como: diagrama de flujo acumulado y diagrama de presupuesto).

Es importante que quede un artefacto como evidencia del cierre del proyecto, con lo cual se
garantiza la terminación oficial de las actividades del proyecto, o el cumplimiento de los
compromisos posteriores (en caso que existan).

7.6.2 - Reunión de Retrospectiva

del proyecto (17)
Dentro de los objetivos de esta práctica encontramos:

Analizar y aprender de los aciertos y errores que se cometieron a lo largo de todo el

proyecto.
Analizar los informes generados por Aseguramiento de Calidad durante todo el proyecto.
Crear un Informe de mejoras y lecciones aprendidas a lo largo del proyecto.

¿Quienes participan de la reunión?

Scrum Master.
Product Owner.
Equipo de Desarrollo.
En algunas ocasiones incluso podría participar el cliente.
4. Pilares de Scrum
Scrum define 6 pilares (antes denominados “principios”) que son clave para el buen
funcionamiento del Marco de Trabajo. Se puede asegurar que son las “reglas” que deben conocer
y aplicar los miembros del Equipo Scrum para garantizar el correcto funcionamiento de este marco
de trabajo. El Scrum Master suele ser el responsable de que estos pilares hagan parte de la cultura
del equipo.
4. Pilares de Scrum

4.1 - Control empírico de

procesos (Pilar #1)

Scrum se basa en la teoría de control empírico de procesos o empirismo. El empirismo asegura

que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se
conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el
control del riesgo.

Los 3 pilares que soportan toda la implementación del control empírico de procesos son:
transparencia, inspección y adaptación.

4.1.1 - Transparencia
Los aspectos significativos del proyecto deben ser visibles para las partes interesadas. La
transparencia requiere que dichos aspectos sean definidos por un estándar común, de tal modo
que los observadores compartan un entendimiento común de lo que se está viendo.

Por ejemplo:

Todos los participantes deben compartir un lenguaje común para referirse al proceso.
Aquellos que desempeñan el trabajo y aquellos que aceptan el producto de dicho trabajo
deben compartir una definición común de “Terminado”.

4.1.1.1 - Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se
toman basadas en el estado percibido de los artefactos. En la medida en que la transparencia sea
completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son
completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el
riesgo puede aumentar.

El Scrum Master debe trabajar con el Product Owner, el Equipo de Desarrollo y otras partes
interesadas para entender si los artefactos son completamente transparentes. Hay prácticas para
hacer frente a la falta de transparencia; el Scrum Master debe ayudar a todos a aplicar las
prácticas más apropiadas si no hay una transparencia completa.

Un Scrum Master puede detectar la falta de transparencia inspeccionando los artefactos,

reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencias entre los
resultados esperados y los reales.

La labor del Scrum Master es trabajar con el Equipo Scrum y la organización para mejorar la
transparencia de los artefactos. Este trabajo usualmente incluye aprendizaje, convicción y cambio.
La transparencia no ocurre de la noche a la mañana, sino que es un camino.

4.1.2 - Inspección
En los proyectos Scrum se deben inspeccionar frecuentemente los artefactos y el progreso hacia
un objetivo, para detectar variaciones.

La inspección no debe ser tan frecuente como para que interfiera en el trabajo, las inspecciones
son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo
lugar de trabajo (normalmente el Scrum Master).

4.1.3 - Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables,
y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado
deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones
mayores.

Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y
adaptación, tal y como se describen en la sección Eventos de Scrum de esta guía:

Reunión de Planificación del Sprint.

Scrum Diario.
Revisión del Sprint.
Retrospectiva del Sprint.
4. Pilares de Scrum

4.2 – Auto-gestión (Pilar #2)

Para Scrum, es altamente recomedable que el equipo tenga la capacidad de autogestionarse, esto
significa que son los miembros del equipo quienes eligen la mejor opción de llevar a cabo su
trabajo sin ser dirigidos por personas externas al equipo.

A continuación, se listan algunos elementos clave que hace posible la Auto-Gestión del Equipo
Scrum:

Los desarrolladores deberían autoasignarse el trabajo a realizar en los diferentes Sprints,

nadie, ni siquiera el Product Owner debe imponer el trabajo al Equipo.
El equipo decide la mejor distribución del trabajo, garantizando la equidad y el trabajo en
equipo.
El Equipo debe conocer muy bien sus límites de decisión para así poder tener mayor
autonomía. (delegación)
El Equipo debe tener espacios que le permitan realizar jornadas de investigación y
capacitación.
Se debe trabajar continuamente en la motivación del equipo.
No se deben cambiar los miembros del equipo (a menos que sea inevitable)

4.2.1 - Colaboración de equipo

La colaboración se da gracias a la constante comunicación que existe en los Equipos Scrum, tanto
entre sus miembros como con las Partes interesadas del Proyecto, este concepto es parte integral
del Manifiesto Ágil “La forma más eficiente y efectiva de transmitir información hacia y dentro del
Equipo de Desarrollo es la conversación cara a cara”.

El Scrum Master es el rol responsable de garantizar una sana comunicación entre todas las partes
interesadas del proyecto, en especial de su Equipo de Desarrollo.
Se debe considerar que, según la naturaleza del proyecto, las necesidades de la organización e
incluso factores externos, determinan la ubicación de los miembros del Equipo. Es por esto que en
Scrum los Equipos se clasifican en 2 categorías:

4.2.1.1 - Equipos Centralizados

Las características de un Equipo Centralizado son:

Los miembros del Equipo se encuentran en la misma ubicación, lo que les permite
comunicarse con gran facilidad.
La resolución de problemas es prácticamente inmediata, ya que al estar ubicados en el
mismo lugar es fácil realizar sesiones de diálogo.

4.2.1.2 - Equipos Distribuidos

Un Equipo Distribuido es aquel en el que sus miembros no se encuentran en una misma ubicación,
por lo general está disperso debido a factores como:

La subcontratación (outsourcing – freelance).

Oficinas ubicadas en diferentes ubicaciones físicas.
Trabajo desde casa.
Etc.

Para garantizar la comunicación permanente en este tipo de equipos se hacen necesarias las
siguientes herramientas:

Groupware.
Software Videollamadas o chat.
Software de gestión de proyectos ágiles.
Herramientas de software que simulan la funcionalidad de Scrum boards.

4.2.2 - Colaboración con el cliente

En los proyectos tradicionales, los clientes por lo general se mantenían a distancia y solo se
involucraban al principio y al final del proyecto. En Scrum es altamente recomendable que el
cliente participe de las revisiones del producto y brinde retroalimentación en todos los puntos de
"inspección y adaptación". Esto minimiza el riesgo y le brinda más opciones al cliente y a las
partes interesadas.

Por ejemplo, en otros Marcos Ágiles como XP, es obligatorio que el Cliente forme parte del equipo.

El cliente (o sus representantes) deberían trabajar junto al Product Owner para definir las historias
de usuario y detallar dichas historias antes o durante las reuniones de planificación.

El cliente y las partes interesadas por lo general participan en la Reunión de Revisión de los Sprint
y, dependiendo de la relación entre el cliente y el Product Owner, el Cliente incluso podría
participar de algunas reuniones de Retrospectiva de los Sprint.

4.2.3 - Equipos multifuncionales

Los equipos multifuncionales (también llamadas células ágiles) tienen todas las competencias y
habilidades necesarias para llevar a cabo el trabajo sin depender de otras personas que no formen
parte del equipo.

Contrario a lo que piensa un equipo multifuncional, no se trata de que todos sus integrantes hagan
de todo, se trata de que los integrantes adquieran conocimiento en distintas disciplinas (aplicables
a los proyectos de la organización) y así puedan contribuir eficazmente con la colaboración.

La realidad es que incluso cuando un equipo sea experto técnico, siempre necesitarán
capacitación adicional, así es que el Product Owner deberá decidir si aprobará el dinero y el
tiempo para capacitarse o por el contrario serán los miembros del equipo quienes se encargarán
del tema.

4.2.3.1 – Gestionar el conocimiento

Realizar este ejercicio permitirá identificar, recopilar, organizar, transferir y retener el
conocimiento necesario para dar soporte a todo el personal en sus actividades laborales, para la
toma de decisiones bien fundadas y para aumentar la productividad.

4.2.4 - Propiedad colectiva del

producto
Para garantizar una colaboración constante y evitar con el tiempo la aparición de una cultura de la
culpa, es importante fomentar una propiedad colectiva del producto, esto significa que todo el
Equipo Scrum es dueño del producto, y por tanto cualquiera de sus integrantes podría contribuir al
desarrollo de cualquier parte del producto aun cuando no haya sido quien lo desarrolló
inicialmente.
Así mismo no deberían existir reconocimientos individuales a los miembros del equipo por sus
contribuciones al producto.

4.2.5 – Motivación del equipo

Los equipos Scrum se caracterizan por mantener un enfoque hacia la entrega frecuente de
resultados; y aunque los miembros del equipo son conscientes de la responsabilidad que esto
implica, existe un factor de fondo que facilita el impulso y el esfuerzo para cumplir con los
objetivos; la motivación.

La motivación hace referencia a que los miembros del equipo mantengan determinada conducta y
estado de ánimo que propicien las interacciones sanas y el alto rendimiento en el proyecto.

Tipos de motivación

Intrínseca: este tipo de motivación es propio de cada persona, es decir que por su propia
voluntad e inspiración es capaz de mantener una conducta específica y el impulso necesario
para cumplir con una meta que brinda satisfacción interna y realización personal. (Ref:
CHAMPFROGS – Moving Motivators)
Extrínseca: este tipo de motivación hace referencia a mantener una conducta específica
para responder a un impulso externo, es decir que en este caso la voluntad e inspiración de
la persona se ven influenciadas por una recompensa externa (que puede ser algo físico,
monetario o psicológico).

Según cómo se maneje la motivación en el equipo Scrum, eventualmente la motivación extrínseca

tiende a convertirse en motivación intrínseca, pues los miembros del equipo van adaptando su
conducta y mejorando su rendimiento para cumplir los objetivos sin necesidad de que todo el
tiempo estén recibiendo recompensas o algo a cambio.

Identificar los motivadores

Cuando hablamos de motivación, es el Scrum Master quien tendrá la mayor participación y
responsabilidad pues al estar al servicio del equipo Scrum puede identificar fácilmente qué es lo
que aumenta o disminuye la motivación de los miembros del equipo; es por esto que dentro de las
tareas del Scrum Master se incluye la identificación y análisis de los elementos motivadores del
equipo para construir y desarrollar un Plan de Motivación que posteriormente negociará con el
Product Owner para asegurar los recursos necesarios para su ejecución.

Incentivar la investigación
Dentro del conjunto de factores que aumentan la motivación del equipo en Scrum se recomienda
impulsar la investigación de nuevos productos o tecnologías lo cual favorece que los miembros del
equipo adquieran nuevo conocimiento y se inclinen hacia el logro de nuevos objetivos.

La investigación también propiciará que los miembros del equipo se propongan metas basadas en
la autorrealización y desarrollo de sus propias competencias.

Algunas metodologías en el mercado hablan de las técnicas que pueden incentivar la investigación
en los equipos, tales como: DemoDay – Hackathon – Exploration Days – TED days, etc.

Los factores claves de la motivación son:

Tener un Propósito.
El trabajo debería suponer un "reto" intelectual (esto permitirá el aprendizaje, la
investigación y el desarrollo de nuevo conocimiento).
Compañerismo y buena relación con los demás miembros del equipo.
4. Pilares de Scrum

4.3 – Simplicidad (Pilar #3)

Scrum no sería considerada una metodología ágil de no ser por su simplicidad, es por ello que se
intenta al máximo reducir la burocracia en sus prácticas, se trabaja con los artefactos que son
esenciales para el proyecto y se sigue un flujo de prácticas simple, sin descuidar todos los
elementos necesarios para la correcta gestión del proyecto.

Es responsabilidad del Scrum Master garantizar que la simplicidad será el pilar fundamental
para la adopción de Scrum.

4.3.1 - Diseño simple

Lo más importante en el desarrollo de un producto usando el marco Scrum, es el valor que
entrega para los clientes/usuarios, considerando además que su desarrollo debería tardar el
menor tiempo posible.

Es por esto que es altamente recomendable establecer un alcance para el proyecto que considere
suficientes características para que el producto sea de alto valor para el usuario pero que tenga el
menor tiempo de desarrollo posible, sin descuidar la calidad.

Este concepto tiene su justificación en los principios del Manifiesto Ágil “El producto funcional es
más importante que la documentación exhaustiva”. (Ver más en la sección 6.6)

4.3.2 - Uso de herramientas de

software
Las herramientas de software para la gestión de proyectos ágiles se han convertido en un
elemento indispensable para garantizar la simplicidad. Algunas de las ventajas de usar estas
herramientas son:

Centralizan la información de los proyectos, permitiendo un mejor control de la información.

Permiten automatizar tareas, por ejemplo:
Estimaciones basadas en históricos.
Calcular la velocidad del equipo.
Elaborar gráficos para el seguimiento del presupuesto, progreso del Sprint (Burndown),
progreso del proyecto (Diagrama de flujo acumulado), etc.
Generar actas de reuniones.
Generan notificaciones sobre elementos del Product Backlog con atraso.
Facilitan la interacción de los Equipos Distribuidos geográficamente.
Si los proyectos son de desarrollo de software, permiten, además:
Integración continua.
Pruebas automatizadas.
Trazabilidad bidireccional entre código e historias de usuario.
4. Pilares de Scrum

4.4 - Centrado en el valor

para cliente (Pilar #4)

En un proyecto Scrum, la máxima prioridad es satisfacer al cliente desde el inicio y continuamente

entregándole el máximo valor posible, para lo cual es importante considerar los siguientes
aspectos:

Es importante que en cada uno de los Sprints se generen incrementos de producto que
entreguen valor para el cliente y estos a su vez estén “terminados”.
Para realizar la priorización de los elementos que hacen parte del Product Backlog los
miembros del Equipo Scrum deberán considerar principalmente el valor que el elemento
puede generar, para ello es importante el concepto de transparencia (Sección 5.1.1).
Cada incremento de producto “terminado” debe ser validado con el cliente para asegurar la
recolección de retroalimentación.
Es altamente importante que el cliente participe activamente de las revisiones de los
prototipos del producto antes de realizar cualquier desarrollo; incluso y según la naturaleza
del proyecto, el cliente podrá participar activamente del diseño del producto.
4. Pilares de Scrum

4.5 – Cumplimiento (Pilar

#5)

Cumplir con las reglas establecidas por el Equipo Scrum y por la organización es de vital
importancia para garantizar una sana convivencia entre todos los miembros del Equipo Scrum,
evitar desvíos en los proyectos y, por último, pero no menos importante, garantizar la satisfacción
del cliente.

A continuación, se listan las reglas esenciales que deben ser cumplidas:

Reglas establecidas por el Equipo Scrum.

Reglas establecidas por la organización.
Bloques de tiempo asignados a los eventos Scrum.
Definición de terminado y criterios de aceptación.

4.5.1 - Bloques de tiempo

Los bloques de tiempo asignados a los eventos Scrum, garantizan que no se desperdicia tiempo en
los proyectos. Algunas ventajas de respetar los Bloques de Tiempo asignado son los siguientes:

Se evita que el equipo pierda motivación.

Menos gastos generales para el proyecto.
Se garantiza una alta velocidad para los equipos.
Las prácticas relacionadas con el desarrollo de entregables son más eficientes.
4.5.2 - Reglas del Equipo
Gracias al principio de la autoorganización, son los miembros del Equipo Scrum, quienes
establecen sus propias reglas, claro, considerando el cumplimiento de las reglas establecidas por
la organización. Por lo general, estas reglas se establecen una única vez al inicio del proyecto, y
en algunas ocasiones podrán ser globales para múltiples proyectos o múltiples equipos. Al
artefacto donde se registran estas reglas suele llamarse “Plan de Colaboración del Equipo Scrum”.

Algunos de los ítems que pueden hacer parte del Plan de Colaboración del Equipo Scrum son:

Principios del equipo.

Herramientas de comunicación.
Horarios de las reuniones.
Penalizaciones por incumplimiento.
4. Pilares de Scrum

4.6 - Desarrollo iterativo

(Pilar #6)

Cuando Scrum se aplica a la gestión de proyectos, el desarrollo del mismo se debería realizar por
iteraciones, también conocidas como Sprints.

El método iterativo es flexible y abierto a los cambios, lo que permite adaptar el proyecto a las
necesidades cambiantes del mercado, del cliente o de la organización.
Cada iteración está compuesta por las siguientes etapas del Ciclo de vida del Proyecto y sus
respectivas prácticas:

Etapa 2: Planificación.
Etapa 3: Desarrollo del Sprint.
Etapa 4: Revisión del Sprint.
Etapa 5: Implementación.

Esto significa que las siguientes etapas tienen prácticas que no necesariamente son iterativas:

Etapa 1: Inicio del proyecto.

Etapa 6: Cierre del proyecto.

Algunas de las ventajas del desarrollo iterativo son:

Permite realizar entregas incrementales del producto, permitiendo a los clientes/usuarios

disfrutar del valor entregado desde etapas tempranas.
Permite la adaptación continua del proyecto, ya que se puede recolectar retroalimentación
de las partes interesadas en cada una de las iteraciones.
La realización de las reuniones de retrospectiva de los distintos Sprint, permiten el
aprendizaje continuo del equipo.
El realizar Sprints, le agrega puntos de control frecuentes al proyecto, además proporciona
estabilidad a los equipos.
Las reuniones de revisión del Sprint, se realizan frecuentemente, permitiendo reducir la
incertidumbre de las partes interesadas respecto a los entregables del proyecto.