Agile project management

Índice de contenidos
Introducción .............................................................................................................................................................. 3
Objetivos .................................................................................................................................................................... 3
Scrum: Fundamentos y Elementos ......................................................................................................................... 3
¿Qué es SCRUM? .............................................................................................................................................. 3
Fundamentos: base en procesos empíricos ................................................................................................ 5
Principios ágiles ............................................................................................................................................... 6
Scrum como proceso interactivo e incremental. Beneficios. Valores de scrum. Entornos de
aplicabilidad de scrum.................................................................................................................................... 9
Roles y responsabilidades ............................................................................................................................ 13
Periodos de trabajo....................................................................................................................................... 20
Sprint............................................................................................................................................................... 24
Reuniones en Scrum ..................................................................................................................................... 30
El producto (product backlog). Sprint backlog, Burn up y Burn Down: gráfico de cumplimiento y tabla
de lanzamiento de datos .............................................................................................................................. 35
Criterios para la estimación y métricas ...................................................................................................... 41
Estimación de poker ..................................................................................................................................... 44
Frecuencia de actualización de la tabla ...................................................................................................... 45
¿Qué es el scaling scrum? ............................................................................................................................. 45
Identificar los obstáculos mayores para usar scrum en una organización............................................ 46
Actividades y técnicas al equipo scrum puede emplear para alcanzar los objetivos de la reunión ... 47
Otras herramientas ágiles ............................................................................................................................ 49
Para terminar .......................................................................................................................................................... 52

Página 2 de 52
Introducción

En este curso nos centraremos en los aspectos técnicos relacionados con la metodología SCRUM y Agile, sus
fundamentos, elementos, metodologías, técnicas y habilidades que los integran. Finalmente, haremos un
repaso por los diferentes métodos de control y medición.

Objetivos
En esta unidad, veremos:

• Todo lo relacionado con el método de trabajo SCRUM.

• Las etapas por las que debemos pasar para desarrollar y planificar un proyecto bajo las directrices de las
metodologías ágiles.
• Estudiaremos las principales habilidades que debemos poseer para gestionar un proyecto ágil, sus fases
de desarrollo y qué obstáculos nos podremos encontrar en su confección.
• Por último, veremos los procesos y etapas de control a través de diversas metodologías e informes.

Scrum: Fundamentos y Elementos

¿Qué es SCRUM?
Según la Guía Definitiva de Scrum (Las reglas del juego), el SCRUM es un marco de trabajo a través del cual las
personas pueden abordar problemas complejos adaptativos, a la vez que se entregan productos de forma
eficiente y creativa con el máximo valor.

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.

¿Cómo es SCRUM?

El SCRUM se caracteriza por las siguientes características:

• Ligero
• Simple de entender
• Difícil de dominar

El marco de trabajo Scrum se compone de: los equipos Scrum, sus roles, eventos, artefactos y reglas
asociadas.

Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de
Scrum y para su uso.

Las reglas de Scrum relacionan los roles, eventos y artefactos, gobernando las relaciones e interacciones entre
ellos.
Página 3 de 52
Las estrategias específicas para usar el marco de trabajo Scrum son diversas y están descritas en otros
apartados del curso.

Fue desarrollado inicialmente para gestionar y desarrollar productos.

Desde principios de los años 90 Scrum se ha usado ampliamente en todo el mundo para diferentes cuestiones,
¡pasemos a verlas!

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

Desarrollar productos y mejoras.

Liberar productos y mejoras tantas veces como sea posible durante el día.

Desarrollar y mantener ambientes en la nube (en línea, seguros, bajo demanda) y otros entornos operacionales
para el uso de productos.

Mantener y renovar productos.

El Scrum se ha usado para desarrollar software, hardware, software embebido, redes de funciones
interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también para gestionar la operación
de organizaciones y casi todo lo que usamos en nuestra vida diaria, como individuo y como sociedad.

Dado que la complejidad de la tecnología, el mercado y del entorno y sus interacciones aumentan rápidamente,
la utilidad de Scrum para tratar con la complejidad está a prueba diariamente.

Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental de conocimiento.

Scrum se usa ahora ampliamente para productos, servicios y gestión de la organización matriz.
La esencia de Scrum es un pequeño equipo de personas. El equipo individual es altamente flexible y
adaptativo. Estas fortalezas continúan operando en un equipo, en varios, en muchos y en redes de equipos que
desarrollan, liberan, operan y mantienen el trabajo y los productos de trabajo de miles de personas. Colaboran
e interoperan a través de arquitecturas de desarrollo sofisticadas y ambientes finales de liberación.

Hoy en día, es un estándar de la industria y tanto grandes empresas como pequeños emprendedores están
adoptándolo cada vez más.

A diferencia de muchas otras metodologías, SCRUM es un sistema de trabajo en paralelo.

Es importante señalar que otra de las características que destacan dentro de SCRUM son los ciclos cortos: estos
pueden ser de dos a tres semanas y nos van a permitir ir creando un proyecto.

Siempre vamos a estar implementando entre todos los miembros del equipo un nuevo proyecto cada cierto
ciclo. Esto nos va a permitir a nosotros tener mejoras constantes dentro del producto y también vamos a poder
estar entregando constantemente un producto funcional. Precisamente por eso es que SCRUM se enfoca a la
entrega de resultados.

Siempre vamos a tener un resultado funcional dentro de poco tiempo. SCRUM también nos permite crear
productos y servicios que se adapten a necesidades cambiantes.

Página 4 de 52
Todo lo anterior nos conduce al concepto de mejora constante.

Dentro de SCRUM, nosotros podemos mantener diferentes ciclos para poder llegar a un producto final. O,
en el caso de una empresa grande, podemos mantener constantemente estos ciclos sin un fin específico,
manteniendo una mejora constante sobre nuestros productos, y saber que al final de cada ciclo vamos a tener
un producto cada vez mejor.

Tal vez la característica que más se destaca es el trabajo en equipo.

Además, dentro de SCRUM, lo más importante es el talento del equipo que está desarrollando el proyecto,
pues es muy importante que aprovechemos al máximo todos los talentos de todas las personas integrantes.

Fundamentos: base en procesos empíricos

Scrum se basa en la teoría de control de procesos empírica o empirismo.

Pero, ¿qué es el empirismo?

El empirismo asegura que el conocimiento procede de la experiencia y en poder tomar decisiones basándose
en lo conocido.

Scrum emplea un enfoque interativo e incremental para optimizar la predictibilidad y el control del riesgo.

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

¡Pasa de pantalla para ver estos tres procesos en el siguiente gráfico!

Ahora veamos cada uno de ellos con mayor detalle:

Transparencia
Los aspectos significativos del proceso deben ser visibles para todos aquellos que son responsables del
resultado.

Página 5 de 52
La transparencia requiere que dichos aspectos sean definidos en base a un estándar común, de tal modo que
los observadores compartan un entendimiento común de lo que se están viendo.

Veamos unos ejemplos:

• Deben compartir un lenguaje común todos los participantes para referirse al proceso.
• Aquellos que desempeñan el trabajo y quienes inspeccionan el incremento resultante deben compartir
una definición común de terminado (“Done”).

Inspección
Las personas usuarias de Scrum deben inspeccionar frecuentemente los artefactos de Scrum y el progreso
hacia un objetivo para detectar variaciones indeseadas.

Su inspección no debe ser tan frecuente como para que pueda interferir en el trabajo.

Las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el
mismo lugar de trabajo.

Adaptación
Si un inspector determina que uno o más aspectos de un proceso se desvían de los límites aceptables y que el
producto resultante será inaceptable, el proceso o el material que está siendo procesado deben ajustarse.

Dicho ajuste deberá realizarse cuanto antes para minimizar desviaciones mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación:

• Planificación del Sprint (Sprint Planning).

• Scrum Diario (Daily Scrum).
• Revisión del Sprint (Sprint Review).
• Retrospectiva del Sprint (Sprint Retrospective).

Principios ágiles
Veamos los principios del manifiesto ágil.

Críticos con los modelos de mejora del desarrollo de software basados en procesos, convocados por Kent Beck,
se reunieron para tratar sobre técnicas y procesos para desarrollar software.

En la reunión se acuñó el término “Métodos Ágiles” para definir a los métodos que estaban surgiendo como
alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente “pesadas” y rígidas
por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.

Cuando hablamos de esta filosofía “agile”, y el marco de trabajo que propugna, estamos indicando que se
están consolidando como un marco de trabajo ideal en muchas organizaciones, al permitir gestionar mejor los
requerimientos de los clientes y anticiparse a sus necesidades. Es precisamente en este marco de trabajo
que se reconoce a los equipos como el principal baluarte de los proyectos pues promueve:

• El empoderamiento.
• La involucración y autoorganización.
• El aumento de la motivación y participación de las personas involucradas.

Veamos las valoraciones que se llevan a cabo:

Página 6 de 52
 Valoramos más a los individuos y su interacción que a los procesos y
las herramientas
Este es el valor más importante del manifiesto.

Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la
eficiencia, pero hay tareas que requieren talento y necesitan personas que lo aporten y trabajen con una actitud
adecuada.

La producción basada en procesos persigue que la calidad del resultado sea consecuencia del know-how
“explicitado” en los procesos, más que en el conocimiento aportado por las personas que los ejecutan.

Sin embargo, en desarrollo ágil los procesos son una ayuda. Un soporte para guiar el trabajo. La defensa a
ultranza de los procesos lleva a afirmar que con ellos se pueden conseguir resultados extraordinarios con
personas mediocres, y lo cierto es que este principio no es cierto cuando se necesita creatividad e innovación.

Valoramos más el software que funciona que la documentación

exhaustiva
Poder anticipar cómo será el funcionamiento del producto final, observando prototipos previos, o partes ya
elaboradas ofrece un "feedback" estimulante y enriquecedor, que genera ideas imposibles de concebir en un
primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallado en el
comienzo del proyecto.

El manifiesto ágil no da por inútil la documentación, sólo la de la documentación innecesaria. Los documentos
son soporte de hechos, permiten la transferencia del conocimiento, registran información histórica, y en
muchas cuestiones legales o normativas son obligatorios, pero su relevancia debe ser mucho menor que el
producto final.

La comunicación a través de documentos no ofrece la riqueza y generación de valor que logra la comunicación
directa entre las personas, y a través de la interacción con prototipos del producto. Por eso, siempre que sea
posible debe preferirse reducir al mínimo indispensable el uso de documentación, que requiere trabajo sin
aportar un valor directo al producto. Si la organización y los equipos se comunican a través de documentos,
además de ocultar la riqueza de la interacción con el producto, forman barreras de burocracia entre
departamentos o entre personas.

Valoramos más la colaboración con el cliente que la negociación

contractual
Las prácticas ágiles están indicadas para productos cuyo detalle resulta difícil prever al principio del proyecto. y
si se detallara al comenzar, el resultado final tendría menos valor que si se mejoran y precisan con
retroinformación continua durante el.

También son apropiadas cuando se prevén requisitos inestables por la velocidad de cambio en el entorno de
negocio del cliente. El objetivo de un proyecto ágil no es controlar la ejecución conforme a procesos y
cumplimiento de planes, sino proporcionar el mayor valor posible al producto.

Resulta por tanto más adecuada una relación de implicación y colaboración continua con el cliente, más que
una contractual de delimitación de responsabilidades.

Valoramos más la respuesta al cambio que el seguimiento de un

plan
Para desarrollar productos de requisitos inestables, que tienen como factor inherente el cambio y la evolución
rápida y continua, resulta mucho más valiosa la capacidad de respuesta que la de seguimiento y aseguramiento
de planes. Los principales valores de la gestión ágil son la anticipación y la adaptación, diferentes a los de la
gestión de proyectos ortodoxa: planificación y control que evite desviaciones del plan.

Página 7 de 52
Los 12 principios que se deben seguir son:

1
Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al cliente.

3
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.

4
Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el
proyecto.

5
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.

6
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es
la conversación cara a cara.

7
El software funcionando es la medida principal de progreso.

8
Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos
ser capaces de mantener un ritmo constante de forma indefinida.

9
La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11
Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.

12
A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.

Página 8 de 52
Scrum como proceso interactivo e incremental. Beneficios. Valores de scrum.
Entornos de aplicabilidad de scrum
Scrum demuestra ser especialmente efectivo en la transferencia iterativa
e incremental de conocimiento.

Y bien, ¿qué es el proceso iteractivo e incremental?

Pues bien, es un proceso de desarrollo de software creado en respuesta a las debilidades del modelo
tradicional de cascada.

Básicamente este modelo de desarrollo, que no es más que un conjunto de tareas agrupadas en pequeñas
etapas repetitivas (iteraciones), es uno de los más utilizados en los últimos tiempos ya que, como se relaciona
con novedosas estrategias de desarrollo de software y una programación extrema, es empleado en
metodologías diversas.

El modelo consta de diversas etapas de desarrollo en cada incremento, las cuales inician con el análisis y
finalizan con la instauración y aprobación del sistema.

Se planifica un proyecto en distintos bloques temporales que se le denominan iteración. En una iteración
se repite un determinado proceso de trabajo que brinda un resultado más completo para un producto final, de
forma que quien lo utilice reciba beneficios de este proyecto de manera creciente.

Debemos tener en cuenta que para llegar a lograr esto, cada requerimiento debe tener un completo
desarrollo en una única interación que debe de incluir pruebas y una documentación. De esta manera se
consigue que el equipo pueda cumplir con todos los objetivos que sean necesarios y esté listo para ser dado al
cliente.

Así se evita tener arriesgadas actividades en el proyecto finalizado.

¿Qué se pretende? Lo que se busca es que en cada iteración los componentes logren evolucionar el
producto dependiendo de los completados de las iteraciones antecesoras, agregando más opciones de
requisitos y logrando así un mejoramiento mucho más completo.

“Priorizar los objetivos y requerimientos en función del valor que ofrece el cliente”
¿En qué consiste la mejora iterativa?

La mejora iterativa consiste en desarrollar un sistema de programas de manera incremental, permitiéndole al

desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando,
versiones entregables del sistema.

Es importante señalar que la idea principal detrás de mejoramiento iterativo es desarrollar un sistema de
programas de manera incremental, permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido
a lo largo del desarrollo anterior, incrementando, versiones entregables del sistema.

De esta forma debemos indicar que el aprendizaje viene de dos vertientes: el desarrollo del sistema, y su
uso. Los pasos claves en el proceso son comenzar con una implementación simple de los requerimientos del
sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo esté
implementado.

El proceso en sí mismo consiste de dos etapas que se señalan a continuación:

Etapa de inicialización
Esta etapa consiste en crear una versión del sistema.

Podemos señalar que el fin de esta etapa es crear un producto con el que la persona usuaria pueda
interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del
problema y proveer una solución lo suficientemente simple para ser comprendida e implementada fácilmente.

Página 9 de 52
¿Cómo se guía el proceso de iteración? Pues bien, se crea una lista de control de proyecto, que contiene
un historial de todas las tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para
ser implementadas, y áreas de rediseño de la solución ya existente.

Esta lista de control se revisa periódica y constantemente como resultado de la fase de análisis.

Etapa de iteración
En segundo lugar, esta etapa involucra el rediseño e implementación de una tarea de la lista de control de
proyecto, y el análisis de la versión más reciente del sistema.

La meta del diseño e implementación de cualquier iteración debe ser: simple, directa y modular, para poder
soportar el rediseño de la etapa o como una tarea añadida a la lista de control de proyecto.

El código puede, en ciertos casos, representar la mayor fuente de documentación del sistema. El análisis de una
iteración se basa en la retroalimentación del usuario y en el análisis de las funcionalidades disponibles del
programa. Involucra el análisis de la estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia
(alcanzar las metas).

La lista de control del proyecto se modifica bajo la luz de los resultados del análisis.

Respecto a los beneficios, se indica la entrega periódica de resultados mensual (los requisitos más
prioritarios en ese momento se van completando) lo cual proporciona las siguientes ventajas que veremos a
continuación, ¡veámoslas!

Gestión regular de las expectativas del cliente

El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera
que esté completado.

El cliente comprueba de manera regular si se van cumpliendo sus expectativas, da feedback, ya desde el inicio
del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del
proyecto, iteración a iteración, hacia su meta. Se ahorra esfuerzo y tiempo al evitar hipótesis.

Resultados anticipados (“time to market”)

El cliente puede empezar a utilizar los resultados más importantes del proyecto antes de que esté finalizado
por completo. Siguiendo la ley de Pareto (el 20% del esfuerzo proporciona el 80% del valor), el cliente puede
empezar antes a recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un producto al que sólo le
faltan características poco relevantes, puede sacar al mercado un producto antes que su competidor, puede
hacer frente a urgencias o nuevas peticiones de clientes, etc.

Flexibilidad y adaptación
De manera regular el cliente redirige el proyecto en función de sus nuevas prioridades, de los cambios en el
mercado, de los requisitos completados que le permiten entender mejor el producto, de la velocidad real de
desarrollo, etc.

Al final de cada iteración el cliente puede aprovechar la parte de producto completada hasta ese momento
para hacer pruebas de concepto con usuarios o consumidores y tomar decisiones en función del resultado
obtenido.

Retorno de inversión (ROI)

De manera regular, el cliente maximiza el ROI del proyecto. Cuando el beneficio pendiente de obtener es menor
que el coste de desarrollo, el cliente puede finalizar el proyecto.

Página 10 de 52
 Mitigación de riesgos
Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega
del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigación de manera anticipada. "Si hay que
equivocarse o fallar, mejor hacerlo lo antes posible". El feedback temprano permite ahorrar esfuerzo y tiempo
en errores técnicos.

La cantidad de riesgo a que se enfrenta el equipo está limitada a los requisitos que se puede desarrollar en una
iteración. La complejidad y riesgos del proyecto se dividen de manera natural en iteraciones.

Productividad y calidad
De manera regular el equipo va mejorando y simplificando su forma de trabajar.

Los miembros del equipo sincronizan su trabajo diariamente y se ayudan a resolver los problemas que pueden
impedir conseguir el objetivo de la iteración. La comunicación y la adaptación a las diferentes necesidades entre
los miembros del equipo son máximas (se van ajustando iteración a iteración), de manera que no se realizan
tareas innecesarias y se evitan ineficiencias.

Las personas trabajan más enfocadas y de manera más eficiente cuando hay una fecha límite a corto plazo para
entregar un resultado al que se han comprometido. La consciencia de esta limitación temporal favorece la
priorización de las tareas y fuerza la toma de decisiones.

Las iteraciones (Sprints) son regulares y de un mes para facilitar la sincronización sistemática con otros equipos,
con el resto de la empresa y con el cliente.

El equipo minimiza su dependencia de personas externas para poder avanzar (depender de la disponibilidad
de otros puede parar tareas).

La estimación de esfuerzo y la optimización de tareas para completar un requisito es mejor si la realizan las
personas que van a desarrollar el requisito, dadas sus diferentes especializaciones, experiencias y puntos de
vista. Asimismo, con iteraciones cortas la precisión de las estimaciones aumenta.

Las personas trabajan de manera más eficiente y con más calidad cuando ellas mismas se han comprometido
a entregar un resultado en un momento determinado y deciden cómo hacerlo, no cuando se les ha asignado
una tarea indicado el tiempo necesario para realizarla.

El equipo se evita caminar mucho tiempo por un camino equivocado que le obligue a realizar un gran esfuerzo
para llegar al objetivo esperado.

Se asegura la calidad del producto de manera sistemática y objetiva, a nivel de satisfacción del cliente, requisitos
listos para ser utilizados y calidad interna del producto.

Alineamiento entre cliente y equipo

Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio.
Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las
aportaciones de todos.

Equipo motivado
Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando
pueden decidir organizar su trabajo. Las personas se sienten más satisfechas cuando pueden mostrar los logros
que consiguen.

Página 11 de 52
Veamos a continuación lo referente a los entornos, ¿dónde se aplica SCRUM?

Muchas personas piensan que SCRUM es una metodología que se aplica principalmente a empresas grandes,
pero, por el contrario, SCRUM se puede aplicar en una gran cantidad de escenarios posibles:

• Desarrollo de software. • Productos multimedia

• Sitios web .
• Aplicaciones.
• Dentro de emprendimientos o "startups" porque aprovecha al máximo los recursos con un mínimo de
inversión.
• Proyectos mucho más complejos como, por ejemplo, empresas grandes o proyectos que necesiten una
gran cantidad de elementos, podemos verlo también implementado aplicando los principios de
mejoramiento continuo.
• Nivel de servicios, por ejemplo, en elementos en los cuales intervengan clientes, especialmente porque
nos va a permitir a nosotros madurar productos ante escenarios que nosotros desconocemos.

Scrum es adecuado para aquellas empresas en las que el desarrollo de los productos se realiza en entornos
que se caracterizan por tener:

Página 12 de 52
 Incertidumbre
Sobre esta variable se plantea el objetivo que se quiere alcanzar sin proporcionar un plan detallado del
producto. Esto genera un reto y da una autonomía que sirve para generar una “tensión” adecuada para la
motivación de los equipos.

Autoorganización
Los equipos son capaces de organizarse por sí solos, no necesitan roles para la gestión, pero tienen que reunir
las siguientes características.

Autonomía
Son los encargados de encontrar la solución usando la estrategia que encuentren adecuada.

Autosuperación
Las soluciones iniciales sufrirán mejoras.

Autoenriquecimiento
Al ser equipos multidisciplinares se ven enriquecidos de forma mutua, aportando soluciones que puedan
complementarse.

Control moderado
Se establecerá un control suficiente para evitar descontroles. Se basa en crear un escenario de “autocontrol
entre iguales” para no impedir la creatividad y espontaneidad de los miembros del equipo.

Transmisión del conocimiento

Todo el mundo aprende de todo el mundo. Las personas pasan de unos proyectos a otros y así comparten sus
conocimientos a lo largo de la organización.

Roles y responsabilidades

Autoridad del grupo

En esta metodología de trabajo, cada uno de las personas integrantes de nuestro equipo va a tener una
misión en concreto.

Si bien podemos decir que en general, estos roles son simples, pero son fundamentales para que todo fluya
correctamente.
Existirá un rol para cada una de las personas, el cual se verá complementado con el que lleven a cabo las demás
personas integrantes del equipo. Es importante tenerlo en cuenta, ya que uno de los elementos que se necesita
para que SCRUM funcione es mantener los procesos, los cuales siempre van a ser muy sencillos de
implementar, pues en general tienen un costo nulo o muy bajo, y cada persona va a tener un rol en específico.

Además, cada rol va a tener un objetivo, siendo el objetivo final de todo esto, y de todos los roles en conjunto
que podamos obtener un proyecto funcional, un proyecto avanzado.

Veamos pues los diferentes roles que podemos encontrarnos dentro de un equipo SCRUM regular.

Veamos una breve introducción al respecto:

En primer lugar nos encontramos con el rol de Propietario del Producto (Product Owner), quien va a ser la
persona que se encarga de velar por los intereses del producto final.

Muchas veces es el propio cliente quien se encarga de esta parte.

Página 13 de 52
En segundo lugar, el ScrumMaster quien es el eje fundamental de nuestros equipos. Esta figura facilitará todos
los requerimientos que tengamos que llevar a cabo dentro del ciclo de trabajo o "sprint".

Junto al ScrumMaster nos encontraremos con el Equipo Scrum (Scrum Team). Concentra la mayor cantidad
de personas y este equipo va a ser el que se encarga de implementar las ideas y los objetivos que vamos a tener
dentro de un "sprint" (lo veremos ampliamente más adelante).

¿Qué significa el Sprint? Según la Guía de Scrum™ (2017), el corazón de Scrum es el Sprint, es un bloque de
tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado” utilizable
y potencialmente desplegable. Es más conveniente si la duración de los Sprints es consistente a lo largo del
esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización del
Sprint anterior.

Se destaca que los roles dentro del equipo no están completamente definidos.Si bien es cierto, cada uno
de las personas puede tener alguna especialidad, podemos intercambiar los roles siempre y cuando la personas
componentes del equipo deseen hacerlo.

El Equipo Scrum (Scrum Team)

El Equipo Scrum (Scrum Team) se compone de:

• Propietario del Producto (Product Owner).

• Equipo de Desarrollo (Development Team).
• Scrum Master.

Los Equipos Scrum son autoorganizados y multifuncionales: los equipos autoorganizados eligen la mejor
opción de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo. Por otra parte, los equipos
multifuncionales tienen todas las competencias y habilidades necesarias para llevar a cabo el trabajo sin
depender de otras personas que no formen parte del equipo.
El modelo de Equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad.El
Equipo Scrum ha demostrado ser incrementalmente efectivo para todos los usos anteriores y para cualquier
trabajo complejo.

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

Scrum Master (Director de proyecto)

De acuerdo a la Guía de Scrum™ (2017): “El Scrum Master es un líder que está al servicio del Equipo Scrum. 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 ayuda a todos a modificar estas interacciones para maximizar el
valor creado por el Equipo Scrum.”

Scrum Master es un rol clave para impulsar el cambio dentro de cualquier organización al servir al
equipo en el uso de Scrum.

La actualización de la Guía de Scrum aumenta la claridad de este rol agregando algunas palabras sobre lo que
hacen y cómo lo hacen.
El Scrum Master es el responsable en promocionar y apoyar Scrum como se define en la Guía de Scrum. Los
Scrum Masters hacen esto ayudando a todos a entender la teoría de Scrum, prácticas, reglas y valores.

El Scrum Master es un sirviente líder que está al servicio del y para el Equipo Scrum. De acuerdo a la Guía
de Scrum™ (2017), 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 ayuda a todos a modificar estas
interacciones para maximizar el valor creado por el Equipo Scrum.

Veamos las diferentes formas en las que el Scrum Master puede proporcionar servicio:

Página 14 de 52
El servicio del Scrum Master al Propietario del Producto (Product
Owner)
El Scrum Master sirve al Propietario del Producto de varias formas, incluyendo:

• Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo
Scrum de la mejor manera posible.
• Encontrar técnicas para gestionar la Pila del Producto (Product Backlog) de manera efectiva.
• Ayudar al Equipo Scrum a entender la necesidad de contar con elementos de Pila del Producto claros y
concisos.
• Entender la planificación del producto en un entorno empírico.
• Asegurar que el Propietario del Producto conozca cómo ordenar la Pila del Producto (Product Backlog)
para maximizar el valor.
• Entender y practicar la agilidad.
• Facilitar los eventos de Scrum según se requiera o necesite.

El servicio del Scrum Master al Equipo de Desarrollo

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

• Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional.

• Ayudar al Equipo de Desarrollo a crear productos de alto valor.
• Eliminar impedimentos para el progreso del Equipo de Desarrollo.
• Facilitar los eventos de Scrum según se requiera o necesite.
• Guiar al Equipo de Desarrollo en entornos organizacionales en los que Scrum aún no haya sido adoptado
y entendido por completo.

El servicio del Scrum Master a 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 las implementaciones de Scrum en la organización.

• Ayudar a los empleados e interesados a entender y llevar a cabo Scrum y el desarrollo empírico de
producto.
• Motivar cambios que incrementen la productividad del Equipo Scrum y con otros Scrum Masters para
incrementar la efectividad de la aplicación de Scrum en la organización.

Product Owner (representa a los interesados)

El Propietario del Producto (Product Owner) es el responsable de maximizar el valor del producto del trabajo
del Equipo de Desarrollo (Development Team).
Cómo se lleva a cabo puede variar ampliamente entre distintas organizaciones, equipos Scrum y personas.

El Propietario del Producto es la única persona responsable de gestionar la Lista del Producto (Product
Backlog).

Recordemos que el Product Backlog, de acuerdo a la Guía de Scrum™ (2017) es una lista ordenada de todo lo
que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio a

Página 15 de 52
realizarse en el producto. El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto,
incluyendo su contenido, disponibilidad y ordenación.
La gestión de la Lista del Producto (Product Backlog) incluye:

• Expresar claramente los elementos de la Lista del Producto.

• Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y las misiones de la mejor
manera posible.
• Optimizar el valor del trabajo que realiza el Equipo de Desarrollo. que la Lista del Producto sea visible,
transparente y clara para todos y que muestre, lo que el equipo trabajará a continuación.
• Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto a nivel necesario.

De acuerdo a la Guía de Scrum™ (2017), el Propietario del Producto podría hacer el trabajo anterior o
delegarlo en el Equipo de Desarrollo. Sin embargo, en ambos casos el Propietario del Producto sigue siendo
el responsable de dicho trabajo. El Propietario del Producto es una única persona, no un comité. Podría
representar los deseos de un comité en la Lista del Producto, pero aquellos que quieran cambiar la prioridad
de un elemento de la Lista deben hacerlo a través del Propietario del Producto.
Para que el Propietario del Producto pueda hacer bien su trabajo, toda la organización debe respetar sus
decisiones. Sus decisiones se reflejan en el contenido y en la priorización de la Lista del Producto. Nadie puede
pedir al Equipo de Desarrollo que trabaje en un conjunto diferente de requisitos.

Team (desarrolladores). Roles auxiliares

El Equipo de Desarrollo (Development Team) se compone de 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 Revisión del Sprint (Sprint Review).

¿Qué significa "Terminado"? De acuerdo a la Guía de Scrum™ (2017), cuando un elemento de la Lista de
Producto o un Incremento se describe como “Terminado”, todo el mundo debe entender lo que significa
“Terminado”. 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” para el Equipo Scrum y se utiliza para evaluar cuándo se ha
completado el trabajo sobre el Incremento de producto.
Solo las personas integrantes del Equipo de Desarrollo participan en la creación del Incremento.

La organización es la encargada de estructurar y empoderar a los Equipos de Desarrollo para que estos
organicen y gestionen su propio trabajo.

Y bien, ¿cuáles son las principales características de los Equipos de Desarrollo?

• Son autoorganizados. Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir
elementos de la Lista del Producto (Product Backlog) en Incrementos de funcionalidad potencialmente
desplegables.
• Los Equipos de Desarrollo son multifuncionales, con todas las habilidades necesarias para crear un
Incremento de producto.
• Scrum no reconoce títulos para las personas integrantes de un Equipo de Desarrollo, independientemente
del trabajo que realice cada persona.
• Scrum no reconoce sub-equipos en los Equipos de Desarrollo, no importan los dominios particulares que
requieran tenerse en cuenta, como pruebas, arquitectura, operaciones, o análisis de negocio.
• Los miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en
las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo.

Según la Guía de Scrum™ (2017), el tamaño óptimo del Equipo de Desarrollo debe ser lo suficientemente
pequeño como para permanecer ágil y lo suficientemente grande como para poder completar una
cantidad de trabajo significativa.

Página 16 de 52
Tener menos de tres miembros en el equipo reduce la interacción y resulta en ganancias de productividad
más pequeñas.

Los Equipos de Desarrollo más pequeños podrían encontrar limitaciones en cuanto a las habilidades necesarias
durante un Sprint, haciendo que el Equipo de Desarrollo no pudiese entregar un Incremento que
potencialmente se pueda poner en producción.

Tener más de nueve miembros en el equipo requiere demasiada coordinación. Los Equipos de Desarrollo
grandes generan demasiada complejidad como para que un proceso empírico pueda ser de utilidad. Los roles
de Propietario del Producto y Scrum Master no se contabilizan en el cálculo del tamaño del equipo a menos
que también estén contribuyendo a trabajar en la Lista del Sprint (Sprint Backlog).
¿Qué es la Lista de Pendientes del Sprint (Sprint Backlog)?
De acuerdo a la Guía de Scrum™ (2017): la Lista de Pendientes del Sprint es el conjunto de elementos de la Lista
de Producto seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el
Objetivo del Sprint. La Lista de Pendientes del Sprint 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”.

Los roles auxiliares en los "equipos Scrums" son aquellos que no tienen un rol formal y no se involucran
frecuentemente en el "proceso Scrum", sin embargo, deben ser tomados en cuenta. Un aspecto importante de
una aproximación ágil es la práctica de involucrar en el proceso a los usuarios, expertos del negocio y otros
interesados ("stakeholders"). Es importante que esa gente participe y entregue retroalimentación con respecto
a la salida del proceso a fin de revisar y planear cada sprint.

• Stakeholders: Clientes, Proveedores, Vendedores, etc. Son las personas que hacen posible el proyecto y
para quienes el proyecto producirá el beneficio acordado que justifica su desarrollo. que generalmente
interactúan con el Product Owner, el Scrum Master y el Equipo Scrum para proporcionarles las entradas
y facilitar la creación del producto del proyecto, servicio, o cualquier otro resultado. Los stakeholders
influyen en el proyecto a lo largo del desarrollo del mismo.
• Administradores (Managers): Son los responsables de establecer el entorno para el desarrollo del
proyecto.

Equipos y creación de equipos autoorganizados. Razones para no tener un líder designado en el equipo

• Equipos autoorganizados

Los miembros del Equipo de Desarrollo pueden tener habilidades especializadas y áreas de enfoque
diferentes, pero la responsabilidad pertenece al Equipo de Desarrollo como un todo.

Para que los equipos autoorganizados puedan desplegar su potencial se requieren de un entorno de gestión
que los apoye, y una cultura organizacional que establezca, comunique, refuerce y recompense el conjunto
correcto adecuado de valores y principios (Manifiesto Ágil). Es por ello que, sin el apoyo de los niveles de gestión,
y sin una cultura de liderazgo adecuada hay una alta probabilidad de que los equipos autoorganizados sean
incapaces de crear buenos resultados.

Un equipo autoorganizado es dirigido y organizado por sus propios miembros, para alcanzar los objetivos
especificados por la gerencia, dentro, obviamente, de las limitaciones de su entorno.

Básicamente en un equipo ágil autoorganizado, las personas integrantes deciden colectivamente y hacen lo
necesario con el fin de cumplir con los compromisos, desarrollar un producto de calidad, responder y
adaptarse a los cambios.

A partir de esta breve descripción podemos decir que un equipo autoorganizado es:

Página 17 de 52
Veamos estas tres características detenidamente:

Autónomo
No existe un único centro de toma de decisiones o de autoridad.
El control se distribuye conjuntamente por todo el equipo. En este sentido, es un equipo dirigido y organizado
por sus propios miembros, para alcanzar los objetivos especificados por la gerencia, dentro, obviamente, de las
limitaciones establecidas. Por otro lado, no existe un único “líder” del equipo durante la vida del equipo o
proyecto.
El “líder” no es una asignación estática, sino rol dinámico. Esto significa que la persona que dirige el equipo en
un momento dado puede cambiar, dependiendo de la actividad o problema que se aborda en un contexto o
situación particular. Respecto a la gerencia, si bien la gerencia puede dar forma y empujar al equipo y sus
miembros, no debería dictar los detalles de cuál es la solución ni el proceso de cómo crearla.

Responsable
El equipo comparte colectivamente la responsabilidad de los resultados.

Adaptable
Es responsable no sólo de dirigir y organizarse para alcanzar sus objetivos, sino también de controlarse y
adaptarse para corregir y mejorar su propio desempeño. Esto significa que el equipo puede cambiar la forma
en que se dirige y organiza, con el fin de responder a las limitaciones de su entorno.
En otras palabras: el equipo se ajusta dinámicamente (iteraciones) según sea necesario, con el fin de resolver
sus propios problemas y mejorar su propio desempeño.

Página 18 de 52
 • Liderazgo servicial (Servant Leadership)

Con la llegada de las metodologías ágiles aparece la figura del líder servicial, tal es así que el estilo de liderazgo
preferido para los proyectos Scrum es el liderazgo servicial.

En SCRUM los conocimientos funcionales los aporta el Product Owner, con el apoyo del Product Manager
en sistemas complejos que involucran a varios equipos. El diseño de bajo nivel lo realiza el propio equipo
de desarrollo y, si la complejidad es alta, un arquitecto de sistemas se integra dentro del grupo. El Scrum Master
se asegura de que se realice la función de seguimiento de la actividad.
El líder servicial es primero que nada un servidor.Empieza con el sentimiento natural de que uno quiere
servir, servir primero. Luego la selección consciente será la que le conduzca a aspirar a liderar. Podemos
indicar que esa persona es completamente diferente a aquel que es líder primero, tal vez debido a la necesidad
de mando inusual o de adquirir posesiones materiales.
El líder primero y el líder servicial son dos tipos opuestos. Entre ellos hay matices y mezclas que forman parte

de la infinita variedad de la naturaleza humana. Se identifican diez rasgos que cada líder servicial eficaz debe

poseer:

Escuchar
Se busca que los líderes serviciales escuchen con atención y sean receptivos a lo que se dice o no se dice. Estos
son capaces de ponerse en contacto con su voz interior para comprender y reflexionar sobre sus propios
sentimientos.

Empatía
Los líderes serviciales buenos aceptan y reconocen a los individuos por sus destrezas únicas y habilidades
especiales. Asumen que los trabajadores tienen buenas intenciones y los aceptan como individuos, incluso
cuando existen problemas de comportamiento o rendimiento.

Recuperación
La motivación y la capacidad de recuperarse a sí mismo y la relación con los demás es un fuerte rasgo de los
líderes serviciales. Reconocen y se dan la oportunidad de ayudar a sus colegas que están pasando por dolor
emocional.

Toma de conciencia
Ser consciente, especialmente ser autoconsciente, es un rasgo de los líderes serviciales. Esto les permite
entender mejor e integrar los problemas, tales como los relacionados con la ética, el poder y los valores.

Persuasión
Los líderes serviciales usan la persuasión, en vez de su posición de autoridad para obtener el consenso colectivo
y tomar decisiones. En vez de forzar el cumplimiento y la coerción como es costumbre en algunos estilos
autoritarios de gestión, los líderes serviciales practican la persuasión.

Conceptualización
Una habilidad especial de los líderes serviciales es ver y analizar los problemas (en una organización) desde una
perspectiva conceptual y visionaria más amplia, en vez de centrarse en los objetivos inmediatos a corto plazo.

Prospectiva
Su mente intuitiva les permite a los líderes serviciales utilizar y aplicar las lecciones del pasado y la realidad
actual para prever el resultado de situaciones y decisiones actuales.

Página 19 de 52
Administración
La administración (Stewardship) exige un compromiso de servir a los demás. Los líderes serviciales prefieren la
persuasión por encima del control para obtener la confianza de los demás en la organización.

Compromiso con el crecimiento de los demás

Los líderes serviciales tienen un profundo compromiso con el crecimiento de las personas dentro de su
organización. Asumen la responsabilidad de nutrir el crecimiento personal, profesional y espiritual de los demás
(por ejemplo, facilitando el acceso a los recursos para el desarrollo personal y profesional, alentando a los
trabajadores a participar en la toma de decisiones).

Desarrollo de una comunidad

Los líderes serviciales están interesados en el desarrollo de comunidades dentro de un ambiente de trabajo.
Esto es de gran importancia, en especial dado al cambio en muchas sociedades que dejan de ser comunidades
pequeñas para convertirse en grandes instituciones que dan forma y que controlan las vidas humanas.

Scrum cree que todos los líderes de proyectos Scrum (incluyendo al Scrum Master y el Product Owner) deben
ser líderes serviciales que tengan las características mencionadas anteriormente.

Periodos de trabajo

En SCRUM se diferencian 19 procesos que abordan actividades concretas, siendo agrupados en cinco fases
(SBOK™ Guide):

Fase de Inicio
1. Crear la visión del proyecto.
2. Identificar al Scrum Master y Stakeholder(s).
3. Formar Equipos Scrum.
4. Desarrollar épica(s).
5. Crear el Backlog Priorizado del Producto.
6. Realizar la planificación de lanzamiento.

Fase de planificación y estimación

7. Crear historias de usuario.
8. Estimar historias de usuario.
9. Comprometer historias de usuario.
10. Identificar tareas.
11. Estimar tareas.
12. Crear el Sprint Backlog.

Fase de implementación
13. Crear entregables.
14. Realizar Daily Standup.
15. Refinar el Backlog Priorizado del Producto.

Fase de revisión y restrospectiva

16. Demostrar y validar el sprint.
17. Retrospectiva del sprint.

Página 20 de 52
Fase de lanzamiento
18. Enviar entregables.
19. Retrospectiva del proyecto.

FASE DE INICIO Dentro de esta fase, según SBOK (2017), se llevan a

cabo 6 procesos:

Crear la visión del proyecto

En este proceso se revisa el caso de negocio del proyecto (Project Business Case) a fin de crear una Declaración
de la Visión del Proyecto, que servirá de inspiración y proporcionará un enfoque para todo el proyecto. En
este proceso se identifica al Product Owner.

Identificar al Scrum Master y Stakeholder(s)

En este proceso se identifica al Scrum Master y stakeholders utilizando criterios de selección específicos.

Formar Equipos Scrum

En este proceso se identifican a los miembros del Equipo Scrum. Normalmente, el Product Owner es el
responsable principal de la selección de los miembros del equipo, pero con frecuencia lo hace en colaboración
con el Scrum Master.

Desarrollar épica(s)
En este proceso la Declaración de visión del proyecto sirve como base para el desarrollo de épicas. Se pueden
llevar a cabo reuniones de grupos de usuarios para hablar sobre las épicas adecuadas.

Crear el Backlog Priorizado del Producto

En este proceso se refinan y se crean las épicas, y después se priorizan para crear un Backlog Priorizado
del Producto para el proyecto. A este punto también se establecen los criterios de terminado.

Realizar la planificación del lanzamiento

En este proceso el equipo principal de Scrum revisa las historias de usuario en el Backlog Priorizado del
Producto para desarrollar un cronograma de planificación del lanzamiento, que es esencialmente un
programa de implementación por fases que se puede compartir con los stakeholders del proyecto. En este
proceso también se determina la duración del sprint.

FASE DE PLANIFICACIÓN Y ESTIMACIÓN Dentro de esta fase, según

SBOK (2017), se llevan a cabo 6 procesos:

Crear historias de usuario

En este proceso se crean las historias de usuario y los criterios de aceptación de las historias de usuario. Las
historias de usuario generalmente las escribe el Product Owner y están diseñadas para asegurar que los
requisitos del cliente estén claramente representados y puedan ser plenamente comprendidos por
todos los stakeholders. Se pueden llevar a cabo ejercicios de redacción de historias de usuario, lo cual incluyan
a los miembros del Equipo Scrum, resultando en la creación de dichas historias. Estas se incorporan al Backlog
Priorizado del Producto.

Página 21 de 52
Estimar historias de usuario
En este proceso, el Product Owner aclara las historias de usuario para que el Scrum Master y el Equipo
Scrum puedan estimar el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia
de usuario.

Comprometer historias de usuario

En este proceso, el Equipo Scrum se compromete a entregar al Product Owner las historias de usuario
aprobadas para un sprint. El resultado de este proceso serían las historias de usuario comprometidas.

Identificar tareas
En este proceso, las historias de usuario comprometidas se desglosan en tareas específicas y se compilan
en una lista de tareas.

Estimar tareas
En este proceso, el equipo principal de Scrum estima el esfuerzo necesario para cumplir con cada tarea
en la lista de tareas. El resultado de este proceso es una: Effort Estimated Task List.

Crear el Sprint Backlog

En este proceso, el equipo principal de Scrum elabora un Sprint Backlog que contiene todas las tareas a
ser completadas en un sprint como parte de la Reunión de Planificación del Sprint.

FASE DE IMPLEMENTACIÓN

Dentro de esta fase, según SBOK (2017), se llevan a cabo 3 procesos:

Crear entregables
En este proceso, el Equipo Scrum trabaja en las tareas en el Sprint Backlog para crear los entregables del
sprint. Generalmente se utiliza un Scrumboard para dar seguimiento a las actividades que se llevan a cabo. Las
asuntos o problemas que enfrenta el equipo Scrum pudieran actualizar se en un Impediment Log (o registro de
impedimentos).

Realizar Daily Standup

En este proceso, se lleva a cabo diariamente una reunión altamente focalizada con un time-box, conocida
como Daily Standup. Es aquí donde los miembros del Equipo Scrum se actualizan el uno al otro referente a
sus progresos y sobre los impedimentos que pudieran enfrentar

Refinamiento del Backlog Priorizado del Producto

En este proceso, el Backlog Priorizado del Producto se actualiza y se refina continuamente. Se puede
considerar realizar una reunión de revisión del Backlog Priorizado del Producto, en la que se analiza
cualquier cambio o actualización al backlog y se incorpora a dicho backlog según sea necesario.

FASE DE REVISIÓN Y RETROSPECTIVA Dentro de esta fase, según

SBOK (2017), se llevan a cabo 2 procesos:

Demostrar y validar el sprint

En este proceso, el Equipo Scrum muestra los entregables del sprint al Product Owner y a los stakeholders
relevantes en una Reunión de Revisión del Sprint. El propósito de esta reunión es asegurar que se obtenga
la aprobación y aceptación del Product Owner respecto a los entregables elaborados en el sprint.
Página 22 de 52
Retrospectiva del sprint
En este proceso, el Scrum Master y el Equipo Scrum se reúnen para analizar las lecciones aprendidas
durante todo el Sprint. Esta información se documenta en forma lecciones aprendidas que pueden aplicarse
a futuros sprints. Frecuentemente, como resultado de esta discusión, puede haber mejoras aceptadas (Agreed
Actionable Improvements) o recomendaciones actualizadas por parte del Scrum Guidance Body.

FASE DE LANZAMIENTO

Dentro de esta fase, según SBOK (2017), se llevan a cabo 2 procesos:

Enviar entregables
En este proceso, los entregables aceptados se entregan o se envían a los stakeholders relevantes. Un
documento denominado Working Deliverables Agreement (Acuerdo de entregables funcionales) documenta la
conclusión satisfactoria del sprint.

Retrospectiva del proyecto

En este proceso, mismo que concluye el proyecto, los stakeholders y miembros del equipo principal de
Scrum se reúnen para hacer una retrospectiva del proyecto e identificar, documentar e internalizar las
lecciones aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed Actionable
Improvements, que se implementarán en futuros proyectos.

Timeboxing: limitar el tiempo de reunión

El timeboxing “consiste en fijar el tiempo máximo para conseguir unos objetivos, tomar una decisión o realizar
unas tareas, y hacer lo mejor que podamos en ese intervalo”.

La consciencia de esta limitación temporal favorece la priorización de objetivos/tareas y fuerza la toma de

decisiones. Los elementos del timeboxing en Scrum incluyen:

Sprints
Se trata de una iteración con un timebox de una a seis semanas de duración durante el cual el Scrum Master
guía, facilita y protege al Equipo Scrum de impedimentos tanto internos como externos durante el proceso de
Crear entregables.

Daily Standups
Consiste en una breve reunión diaria con un timebox de 15 minutos.

Reunión de planificación del sprint

Esta reunión se lleva a cabo antes del sprint, como parte de los procesos de Comprometer historias de usuario,
Identificar tareas, Estimar tareas y Crear el Sprint Backlog

Reunión de revisión del sprint

Este tipo de reunión tiene un timebox de cuatro horas en un sprint de un mes.

Reunión de retrospectiva del sprint

Esta reunión tiene un timebox de cuatro horas en un sprint de un mes, y se lleva a cabo como parte del proceso
Retrospectiva del sprint.

Página 23 de 52
Scrum trata al tiempo como uno de los limitantes más importantes en la gestión de un proyecto. Para
hacer frente a la restricción del tiempo, Scrum introduce el concepto de Timeboxing (o asignación de un
bloque de tiempo), que propone la fijación de una cierta cantidad de tiempo para cada proceso y actividad en
un proyecto Scrum.

Esto garantiza que los miembros del Equipo Scrum no ocupen demasiado o muy poco tiempo para un trabajo
determinado, y que no desperdicien su tiempo y energía en un trabajo para el cual tienen poca claridad.

Algunas de las ventajas del Timeboxing son las siguientes:

• Proceso de desarrollo eficiente.

• Menos gastos generales.
• Alta velocidad para los equipos.
• Estimación del coste temporal.

El Timeboxing puede utilizarse en muchos procesos de Scrum, por ejemplo, en el proceso de Realizar Daily
Standup, la duración de dicha reunión tiene un timebox asignado. A veces, el Timeboxing puede utilizarse
para evitar la mejora excesiva de un elemento (por ejemplo, gold-plating, un término en inglés que indica la
incorporación de características o refinamientos costosos e innecesarios en un producto o servicio).

El Timeboxing es una práctica muy importante en Scrum y debe aplicarse con cuidado. Un timebox arbitrario
puede llevar a la desmotivación del equipo y tener como consecuencia la creación de un ambiente tenso, por
lo que se debe utilizar de manera apropiada.

Sprint

Periodos de tiempo

El timeboxing “consiste en fijar el tiempo máximo para conseguir unos objetivos, tomar una decisión o realizar
unas tareas, y hacer lo mejor que podamos en ese intervalo”.

Recordemos que para hacer frente a la restricción del tiempo, Scrum introduce el concepto de Timeboxing
(o asignación de un bloque de tiempo), que propone la fijación de una cierta cantidad de tiempo para cada
proceso y actividad en un proyecto Scrum. Esto garantiza que los miembros del Equipo Scrum no ocupen
demasiado o muy poco tiempo para un trabajo determinado, y que no desperdicien su tiempo y energía en un
trabajo para el cual tienen poca claridad.

Algunas de las ventajas del Timeboxing son las siguientes:

• Proceso de desarrollo eficiente.

• Menos gastos generales.
• Alta velocidad para los equipos.
• Estimación del coste temporal.

El Timeboxing puede utilizarse en muchos procesos de Scrum, por ejemplo, en el proceso de Realizar Daily
Standup, la duración de dicha reunión tiene un timebox asignado. A veces, el Timeboxing puede utilizarse para
evitar la mejora excesiva de un elemento (por ejemplo, gold-plating, un término en inglés que indica la
incorporación de características o refinamientos costosos e innecesarios en un producto o servicio).

Los Sprints contienen y consisten en los siguientes procesos:

• La Planificación del Sprint (Sprint Planning).

• Los Scrums Diarios (Daily Scrums).
• El trabajo de desarrollo.
• La Revisión del Sprint (Sprint Review).

Página 24 de 52
 • La Retrospectiva del Sprint (Sprint Retrospective).

¿Qué te parece si vemos cada unos con mayor detalle? Veamos a

continuación algunos de estos procesos, los más relevantes:

Planificación de Sprint (Sprint Planning)

Si bien el trabajo a realizar durante el Sprint se planifica en la Planificación de Sprint, este plan se crea mediante
el trabajo colaborativo del Equipo Scrum completo.

Scrum Diario (Daily Scrum)

Cuando nos referimos a Scrum Diario, indicamos que es una reunión con un bloque de tiempo de 15 minutos
para el Equipo de Desarrollo.

Revisión de Sprint (Sprint Review)

Será al final del Sprint cuando se lleva a cabo una revisión del mismo para así poder inspeccionar el
Incremento y adaptar la Lista de Producto en caso de que fuese necesario.

Retrospectiva de Sprint (Sprint Retrospective)

Se trata de una oportunidad para el Equipo Scrum de forma que pueda inspeccionarse a sí mismo así como
crear un plan de mejoras que sean abordadas durante el siguiente Sprint.

Es importante recalcar que cada Sprint puede considerarse un proyecto con un horizonte no mayor de un
mes.
Al igual que los proyectos, los Sprints se usan para lograr algo.
Debemos indicar así mismo que cada Sprint tiene una meta de lo que se construirá, un diseño y un plan
flexible que reconducirá tanto la construcción, como el trabajo del equipo y el incremento de producto
resultante.

Finalmente, debemos valorar que los Sprints están limitados a un mes calendario.

Cuando el horizonte de un Sprint es demasiado grande 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.

Cabe indicar que los Sprints también limitan el riesgo al costo de un mes calendario.

Pero, ¿puede cancelarse un sprint?

Si bien un Sprint puede cancelarse antes de que el bloque de tiempo llegue a su fin.

Solo el Dueño de Producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la
influencia de los interesados, del Equipo de Desarrollo o del Scrum Master.

¿Qué ocurriría si un Sprint se queda obsoleto? La respuesta es que un Sprint se podría cancelar, siempre que
el Objetivo del Sprint llegara a quedar obsoleto.

¿Por qué podría ocurrir esto? Pues bien , esto podría ocurrir si la compañía cambia la dirección o si las
condiciones del mercado o de la tecnología cambian.

En general, un Sprint debería cancelarse si no tuviese sentido seguir con él dadas las circunstancias.Sin
embargo, y esto es algo que tenemos que tener muy en cuenta, debido a la corta duración de los Sprints, su
cancelación rara vez tiene sentido.

Página 25 de 52
Productos potencialmente entregables al final de cada sprint

Los productos potencialmente entregables al final de cada sprint hacen referencia a aquellos que han sido
finalizados durante los ciclos iterativos.

Para indicar que efectivamente se ha completado un producto, todas las personas deben tener un
entendimiento común del significado de trabajo completo.
Los productos potencialmente entregables deberían tener las características que se prometieron al inicio de la
iteración de forma que el dueño pueda liberarlo.
Tal como acabamos de ver, las cancelaciones de Sprint consumen recursos ya que todos se reagrupan en otra
Planificación de Sprint para empezar otro Sprint.

Finalmente, como hemos visto, las cancelaciones de Sprint son a menudo traumáticas para el Equipo
Scrum y son muy poco comunes.

Sprint planning. Definición de la magnitud de cada sprint. Estimación de tareas. Tipos de tareas

Aquel trabajo que se debe realizar durante el Sprint se planifica en la Planificación de Sprint.
Es reseñable que este plan se crea mediante el trabajo colaborativo del Equipo Scrum completo.
Para un Sprint de un mes, la Planificación de Sprint tiene un máximo de duración de ocho horas. Por otra parte,
para Sprints más cortos el evento es usualmente más corto.

Recordemos la importancia del Scrum Master, que se asegura de que el evento se lleve a cabo y que los
asistentes entiendan su propósito, así como también enseña al Equipo Scrum a mantenerse dentro del bloque
de tiempo.

Tres son las magnitudes que tiene en cuenta la gestión de proyectos:

• Velocidad.
• Trabajo. • Tiempo.

Miden la gestión de proyectos ágil, y componen la fórmula de la velocidad, definida como: cantidad de trabajo
realizada por unidad de tiempo.
Velocidad = Trabajo / Tiempo
¿Cómo se realiza la estimación de tareas en SCRUM?

En primer lugar, cabe señalar que las tareas en Scrum se estiman con una técnica llamada Planning poker o
Scrum poker, para la cual cada participante tiene una baraja con las siguientes cartas ½, 1, 2, 3, 5, 6, 7 e infinito.
En la estimación de cada tarea cada participante, y al mismo tiempo, pone boca arriba la carta con el número
de horas que cree que se necesitan para realizar completamente la tarea.

Si la estimación de la tarea resulta ser infinito significa que la tarea ha de ser dividida en varias tareas más
pequeñas.

En el caso de que las estimaciones sean muy dispares, es necesario abrir el debate y que los participantes que
han realizado las estimaciones más alejadas de la media justifiquen su elección y aclarar con el propietario de
producto o cliente el alcance de la tarea con el fin de ir consiguiendo aproximar las estimaciones de los
miembros del equipo.
En último lugar, se debe llegar a un consenso o, si el grupo es grande y no se logra un consenso, se puede optar
por tomar una decisión más conservadora (la mayor) o la media.

Respecto a los tipos de tareas, nos encontramos con la lista de tareas de la iteración, llamada Sprint Backlog.

Es un subconjunto de objetivos/requisitos del Product Backlog seleccionado para la iteración actual y su plan
de tareas de desarrollo. El equipo lo elabora en la reunión de planificación de la iteración (Sprint planning)
seleccionando lo que prevé que podrá completar y demostrar al cliente al finalizar la iteración, en forma de
incremento de producto preparado para ser entregado.

Página 26 de 52
Incrementos del producto

Nos referimos al incremento del producto como la suma de todos los elementos de la lista de productos
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.

Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final

del Sprint. El incremento es un paso hacia una visión o meta y además debe estar en condiciones de utilizarse
sin importar si el Dueño de Producto decide liberarlo o no.

Requisitos de alto nivel priorizados o Product backlog

TM
La Guía de Scrum (Las reglas del juego), explica que los artefactos de Scrum representan trabajo o valor en
diversas formas que 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 del
artefacto.

Introduzcamos la idea al Product Backlog, que hace referencia a la Lista de Producto, una lista ordenada de
todo lo que se conoce que es necesario en el producto. Es la única fuente de requisitos para cualquier cambio
a realizarse en el producto.
El Dueño de Producto (Product Owner) es el responsable de la Lista de Producto, incluyendo su contenido,
disponibilidad y ordenación.

Esta lista nunca se da por finalizada, está en continuo crecimiento y evolución. Al comenzar el proyecto
incluye los requisitos inicialmente conocidos y mejor entendidos, y evoluciona conforme avanza el desarrollo.
Mientras el producto exista, su Lista del Producto también existe.

En todo momento refleja aquello que el producto necesita incorporar para adecuarse a las circunstancias.

La Lista de producto

TM
Según la Guía de Scrum (Las reglas del juego), la Lista de Producto enumera todas las características,
funcionalidades, requisitos, mejoras y correcciones que constituyen cambios a realizarse sobre el
producto para entregas futuras.
Los elementos de la Lista de Producto tienen como atributos la descripción, el orden, la estimación y el valor.Los
elementos de La Lista de Producto muchas veces incluyen descripciones de las pruebas que demostrarán la
completitud de tales elementos cuando estén “Terminados”.

A medida que un producto es utilizado y se incrementa su valor y el mercado proporciona retroalimentación, la

Lista de Producto se convierte en una lista más larga y exhaustiva. Los requisitos nunca dejan de cambiar así
que la Lista de Producto es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del
mercado o la tecnología podrían causar cambios en la Lista de Producto.

A menudo, varios Equipos Scrum trabajan juntos en el mismo producto. Para describir el trabajo a realizar
sobre el producto se utiliza una única Lista de Producto. En ese caso podría emplearse un atributo de la Lista
de Producto para agrupar los elementos.

¿Qué formato debe de tener?

Scrum prefiere la comunicación verbal o devisualización directa, a la escrita.

No es un documento de requisitos, sino una herramienta de información para el equipo.

La información mínima que debe incluir es...

Descripción de la funcionalidad/requisito, denominado “historia de usuario”.
Prioridad.
Estimación del esfuerzo necesario.
Código o identificador único de la historia.

Página 27 de 52
Podemos añadir información adicional como...
Observaciones.
Criterio de validación.
Persona asignada.
Nº de Sprint en el que se realiza.
Módulo del sistema al que pertenece.

Veamos finalmente los siguientes aspectos relacionados.

Condiciones necesarias
• Realizada de forma conjunta por todos los miembros del equipo.
• Cubre todas las tareas identificadas por el equipo para conseguir el objetivo del sprint.
• Sólo el equipo la puede modificar durante el sprint.
• Las tareas demasiado grandes deben descomponerse en otras más pequeñas. En ningún caso una tarea
puede tener un tamaño tal que necesite más de un día de trabajo.
• Es visible para todo el equipo. Idealmente en un tablero o pared en el mismo espacio físico donde trabaja
el equipo.

Formatos (diferentes soportes)

• Tablero físico o pared.
• Hoja de cálculo.
• Herramienta colaborativa o de gestión de proyectos. (Trello, Scoro, Zoho Sprints, etc).

Y sobre el más adecuado a las características del proyecto, oficina y equipo, lo apropiado es diseñar el formato
más cómodo para todos.

Desafíos

TM
Respecto a los valores SCRUM, debemos indicar siguiendo la Guía de Scrum (Las reglas del juego), cuando
el Equipo Scrum incorpora y vivencia los valores de compromiso, coraje, foco, apertura y respeto, los pilares
Scrum de transparencia, inspección y adaptación se materializan y fomentan la confianza en todo el
mundo.
El uso exitoso de Scrum depende de que las personas lleguen a ser más virtuosas en la convivencia con
estos cinco valores.
Las personas se comprometen de manera individual a alcanzar las metas del Equipo Scrum.Los miembros del
Equipo Scrum tienen coraje para hacer bien las cosas y para trabajar en los problemas difíciles. Todos se
enfocan en el trabajo del Sprint y en las metas del Equipo Scrum. El Equipo Scrum y sus interesados acuerdan
estar abiertos a todo el trabajo y a los desafíos que se les presenten al realizar su trabajo. Los miembros
del Equipo Scrum se respetan entre sí para ser personas capaces e independientes.

En cualquier momento durante un Sprint es posible sumar el trabajo restante total en los elementos de la
Lista de Pendientes del Sprint.
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.
Implementaciones: notas amarillas, pizarras, paquetes de software

Podemos indicar que existen varias implementaciones de sistemas para gestionar el proceso de Scrum,
que van desde notas amarillas "post-it", pizarras hasta paquetes de software.

Página 28 de 52
Cabe señalar que requiere muy poco esfuerzo para comenzarse a utilizar.

Así, si se utiliza una pizarra con notas autoadhesivas cualquier miembro del equipo podrá ver tres columnas:

• Trabajo pendiente ("backlog").

• Tareas en proceso ("in progress").
• Hecho ("done").
De un solo vistazo, una persona puede ver en qué están trabajando los demás en un momento determinado.

Es recomendable, que el propietario del producto emplea una hoja de cálculo o alguna herramienta similar para
guardar en formato digital la lista del producto. Aunque no es aconsejable usarla como base para trabajar sobre
ella en la reunión.

En la reunión es preferible usar una pizarra o un tablero y fichas o etiquetas removibles.

El tablero facilita la comunicación y el trabajo de la reunión.

Los soportes habituales son: pizarra blanca y notas adhesivas tipo post-it; tablero de corcho laminado y
chinchetas para sujetar las notas; tablero de acero vitrificado y soportes magnéticos para sujetar notas.

Finalmente, con respecto a los paquetes de software, debemos señalar que son las primeras herramientas
que muchos equipos utilizan. Es más, en los primeros Sprints esto suele ser suficiente.
Aunque lo más común es llevar la gestión de un proyecto Scrum utilizando un soporte “artesanal” (postit,
pizarras, etc.), también hay quien prefiere gestionarlo todo con algún tipo de herramienta web para la
gestión de proyectos.
Bien porque necesite dejar evidencias de la gestión del proyecto, porque el equipo esté distribuido, o por
cualquier otra razón. Una herramienta puede introducir complejidades adicionales como una elevada curva de
aprendizaje, exceso o falta de características del producto.

Algunas herramientas software son las siguientes:

Trello
Trello es posiblemente una de las mejores herramientas que vas a tener para organizar tus proyectos scrum en
línea y crear tus propios tableros. Se organiza en "boards". (Es la forma en que nosotros vamos a crear
proyectos). Dentro de Trello, cada uno de estos "boards" nos permite crear diferentes tareas. Trello es
realmente muy sencillo y además es completamente gratuito.

Target Process
Proporciona visibilidad a los incrementos de producto y los ciclos de entrega en los niveles de producto y
programa.

Active Collab
Es el software de gestión de proyectos que le brinda control total sobre su trabajo. la herramienta más
establecida en gestión de proyectos tradicional.

Taiga
Proyecto Español que lleva poco tiempo en el mercado, pero es muy prometedor. Taiga incorpora una gestión
simple de Product Backlog Ítems.

Página 29 de 52
Reuniones en Scrum

Daily Scrum. Scrum de Scrum

El Scrum Diario se lleva a cabo cada día del sprint.

El Equipo de Desarrollo planea el trabajo para las siguientes 24 horas. Podemos indicar que esto optimiza
la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario
y haciendo una proyección del trabajo del Sprint a realizar a continuación.
El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.

Es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo.

El Equipo de Desarrollo usa el Scrum Diario para evaluar el progreso hacia el objetivo del Sprint y para
evaluar qué tendencia sigue este progreso hacia la finalización del trabajo contenido en la lista de pendientes
del Sprint.

El Scrum Diario optimiza las posibilidades de que el equipo de desarrollo cumpla el objetivo del Sprint.

Cada día, el equipo de desarrollo debería entender cómo intenta trabajar en conjunto como un equipo
autoorganizado para lograr el objetivo del Sprint y crear el incremento esperado hacia el final del Sprint.

El equipo de desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir

de diferentes maneras si se enfoca en el progreso hacia la meta de Sprint.

Algunos equipos de desarrollo usarán preguntas, algunos se basarán más en discusiones.

Durante el Scrum Diario se responderán únicamente tres preguntas para ayudar al equipo de desarrollo a
lograr el Objetivo del Sprint:

¿Qué hiciste ayer?

¿Qué harás hoy?
¿Ves algún obstáculo que evite cumplir los objetivos marcados para el día de hoy?

Scrum de Scrum

Es un elemento importante en el escalamiento de Scrum para grandes proyectos. En la reunión típicamente hay
un representante de cada Equipo Scrum, por lo general el Scrum Master, aunque también es común que
cualquiera en el Equipo Scrum asista a la reunión en caso de ser necesario.

Esta reunión generalmente la organiza el Chief Scrum Master (es responsable de moderar las reuniones de
Scrum de Scrums (SoS) y eliminar los impedimentos que afectan a los varios equipos) y la intención es enfocarse
en áreas de coordinación e integración entre los distintos equipos Scrum.

De preferencia estas reuniones son breves (aunque generalmente sin un timebox para permitir el intercambio
de información entre los equipos) donde un representante de cada Equipo Scrum se reúne para compartir el
estado de los equipos respectivos. Las reuniones Scrum de Scrum (SoS) se llevan a cabo en intervalos
predeterminados o cuando lo requieran los equipos Scrum para facilitar el intercambio de información entre
los distintos equipos.

Se pueden monitorear los problemas, las dependencias y los riesgos que afectan a los múltiples equipos
Scrum, lo cual ayuda a integrar y coordinar mejor el trabajo de los varios equipos que trabajan en un proyecto
grande. Es responsabilidad del Scrum Master asegurarse de que todos los representantes cuenten con un
ambiente conductivo para el intercambio abierto y honesto de información, que incluya la retroalimentación
de los representantes de otros equipos.

Para los grandes proyectos que involucran a una cantidad considerable de equipos, se pueden convocar a
múltiples niveles de dichas reuniones para compartir el estado de los equipos respectivos.

Cada representante de los equipos Scrum proporcionará actualizaciones sobre su equipo. Dichas
actualizaciones generalmente se presentan en forma de respuesta a cuatro preguntas específicas:

Página 30 de 52
 1
¿En qué ha estado trabajando mi equipo desde la última reunión?

2
¿Qué hará mi equipo hasta la próxima reunión?

3
¿Qué esperaban otros equipos que mi equipo hiciera y que aún no se ha hecho?

4
¿Qué planea hacer nuestro equipo que pudiera afectar a otros equipos?

Las respuestas a estas cuatro preguntas proporcionan información que permite a cada equipo entender
claramente la situación de trabajo de todos los demás equipos.

La agenda

Las reuniones de Scrum son parte de reuniones ágiles donde todos los miembros del equipo pueden
sincronizarse con el trabajo que hicieron en las últimas 24 horas y repasar lo que llevarán a cabo en las 24
siguientes.

Es conveniente que la frecuencia sea diaria y que la duración mínima sea de 10 minutos.

Reunión de planificación del sprint (sprint planning meeting)

Cuando nos referimos a la reunión de planificación de sprint (el llamado sprint planning meerting), se cuenta
con la participación del Product owner, el Scrum Master y todo el equipo de Scrum, del cual ya hemos hablado.

La reunión de planificación de sprint tiene un máximo de duración de ocho horas para un Sprint de un mes.

Para Sprints más cortos, el evento es usualmente más corto. En esta reunión se toman como base las
prioridades y necesidades de negocio del cliente, y se determinan cuáles y cómo van a ser las funcionalidades
que se incorporarán al producto en el siguiente sprint.

Se trata de una reunión conducida por el responsable del funcionamiento del marco scrum (normalmente
Scrum Master en scrum técnico o un miembro del equipo en scrum avanzado) a la que deben asistir el
propietario del producto y el equipo completo, y a la que también pueden asistir otros implicados en el
proyecto.

Además, esta reunión debe dar respuesta a dos cuestiones:

¿Qué se entregará al terminar el sprint?
¿Cuál es el trabajo necesario para realizar el incremento previsto, y cómo lo llevará a cabo el equipo?

La reunión se articula en dos partes de duración similar, para dar respuesta a una de estas cuestiones, en
cada una.

Precondiciones
• La organización tiene determinados y asignados los recursos disponibles para llevar a cabo el sprint.
• Ya están “preparadas” las historias de usuario de mayor prioridad de la pila del producto, de forma que
ya tienen un nivel de concreción suficiente y una estimación previa del trabajo que requieren.
• El equipo tiene un conocimiento de las tecnologías empleadas, y del negocio del producto suficiente para
realizar estimaciones basadas en juicio de expertos, y para comprender los conceptos del negocio que
expone el propietario del producto.

Página 31 de 52
 Entradas
• La lista del producto.
• El producto ya desarrollado en los incrementos anteriores (excepto si se trata del primer sprint).
• Dato de la velocidad o rendimiento del equipo en el último sprint, que se emplea como criterio para
estimar la cantidad de trabajo que es razonable suponer para el próximo sprint.
• Circunstancias de las condiciones de negocio del cliente y del escenario tecnológico empleado.

Resultados
• Lista del sprint.
• Duración del sprint y fecha de la reunión de revisión.
• Objetivo del sprint.

Formato de la reunión
• Esta reunión marca el inicio de cada sprint.

• Duración máxima: un día.

• Asistentes: Propietario del producto, equipo de desarrollo y Scrum Master.
• Pueden asistir: todos aquellos que aporten información útil, ya que es una reunión abierta.
• Consta de dos partes separadas por una pausa (de café o comida, según la duración).

¿Qué se entregará al terminar el sprint?

Pues bien, el propietario del producto presenta la lista del producto, exponiendo las historias de usuario de
mayor prioridad que necesita y que prevé que se podrán desarrollar en el siguiente sprint. Si la lista del producto
ha tenido cambios significativos desde la anterior reunión, explica las causas que los han ocasionado.

El objetivo es que todo el equipo conozca las razones y los detalles con el nivel suficiente para comprender el
trabajo del sprint.

En lo que se refiere al propietario del producto...

• Presenta las historias de usuario de la pila del producto que tienen mayor prioridad y que estima que se
pueden realizar en el sprint.
• La presentación se hace con un nivel de detalle suficiente para transmitir al equipo toda la información
necesaria para construir el incremento.

El equipo...
• Realiza las preguntas y solicita las aclaraciones necesarias.
• Propone sugerencias, modificaciones y soluciones alternativas.

Los aportes del equipo pueden suponer modificaciones en la lista.

Esta reunión es un punto caliente de scrum para favorecer la fertilización cruzada de ideas en equipo y añadir
valor a la visión del producto. Tras reordenar y replantear las historias de la lista del producto, el equipo define
el “objetivo del sprint,” o frase que sintetiza cuál es el valor que se le va a entregar al cliente.

¿Cómo se conseguirá hacer el incremento?

Página 32 de 52
El equipo desglosa cada funcionalidad en tareas, y estima el esfuerzo para cada una de ellas, componiendo
así las tareas que forman la pila del sprint. En este desglose, el equipo tiene en cuenta los elementos de diseño
y arquitectura que deberá incorporar el sistema.

Los miembros del equipo establecen cuáles van a ser las tareas para los primeros días del sprint, y se las
autoasignan tomando como criterios sus conocimientos, intereses y una distribución homogénea del trabajo.
El papel del propietario del producto es atender a dudas y comprobar que el equipo comprende y comparte
su objetivo.
El Scrum Master actúa de moderador de la reunión.

Las funciones del Scrum Master son...

1. Realizar esta reunión antes de cada sprint.
2. Asegurar que se cuenta con una pila del producto preparada por el propietario del producto.
3. Ayudar a mantener el diálogo entre el propietario del producto y el equipo.
4. Asegurar que se llegue a un acuerdo entre el propietario del producto y el equipo respecto de lo que
incluirá el incremento.
5. Ayudar al equipo a comprender la visión y necesidades de negocio del cliente.
6. Asegurar que el equipo ha realizado una descomposición y estimación del trabajo realistas, y ha
considerado las posibles tareas necesarias de análisis, investigación o apoyo.
7. Asegurar que al final de la reunión están objetivamente determinados:

• Los elementos de la lista del producto que se van a ejecutar.

• El objetivo del sprint.
• La lista del sprint con todas las tareas estimadas.
• La duración del sprint y la fecha de la reunión de revisión.

Revisión (sprint review): diaria, de cierre y retrospectiva (sprint retrospective)

Al final del sprint se lleva a cabo una revisión de sprint para inspeccionar el incremento y adaptar la lista de
producto si fuese necesario.

Durante la revisión de sprint, el equipo scrum y los interesados colaboran acerca de lo que se hizo durante el
sprint.
Basándose en esto y en cualquier cambio a la lista de producto durante el sprint, los asistentes colaboran para
determinar las cosas que podrían hacerse para optimizar el valor. Se trata de una reunión informal, no una
reunión de seguimiento, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de
información y fomentar la colaboración.

El equipo scrum demuestra los logros del sprint, incluyendo las nuevas funcionalidades o los productos
elaborados. Esto brinda una oportunidad para que el product owner y el(los) stakeholder(s) inspeccionen lo que
se ha completado hasta el momento y determinen si deban realizarse cambios en el proyecto o en los procesos
en sprints posteriores.

Respecto a la duración, se trata de una reunión que tiene una duración como mucho de cuatro horas para
sprints de un mes.

Para sprints más cortos, el evento usualmente más corto.

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. La Revisión de Sprint
incluye los siguientes elementos:

Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de Producto.
Página 33 de 52
El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado” y cuales no se han
“Terminado”.

El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo
fueron resueltos esos problemas.

El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca
del Incremento.

El Dueño de Producto habla acerca de la Lista de Producto en su

estado actual. Proyecta objetivos probables y fechas de entrega en el
tiempo basándose en el progreso obtenido hasta la fecha (si fuera
necesario).

El grupo completo colabora acerca de qué hacer a continuación, de

modo que la Revisión del Sprint proporcione información de entrada
valiosa para Reuniones de Planificación de Sprints subsiguientes.

Revisión de cómo el mercado o el uso potencial del producto podría

haber cambiado lo que es de más valor para hacer a continuación.

Revisión de la línea de tiempo, presupuesto, capacidades potenciales

y mercado para las próximas entregas de funcionalidad o capacidad
prevista del producto.
El resultado de la revisión de sprint es una lista de producto revisada que define los elementos de la lista de
producto posibles para el siguiente sprint. Es posible además que la lista de producto reciba un ajuste general
para enfocarse en nuevas oportunidades.

La retrospectiva de sprint es una oportunidad para el equipo scrum de analizarse a sí mismo y de crear un
plan de mejoras que sean abordadas durante el siguiente sprint. La retrospectiva de sprint tiene lugar después
de la revisión de sprint y antes de la siguiente planificación de sprint.

Respecto a la duración...
Se trata de una reunión de, a lo sumo, tres horas para Sprints de un mes. Para Sprints más cortos el evento es
usualmente más corto.

Respecto a las tareas del scrum master...

• Asegurarse de que el evento se lleve a cabo y que los asistentes entiendan su propósito.
• Asegurarse de que la reunión sea positiva y productiva.
• Enseñar a todos a mantener el evento dentro del bloque de tiempo fijado.
• Participar en la reunión como un miembro del equipo ya que la responsabilidad del proceso Scrum recae
sobre él.
• Alentar al equipo para que mejore.

El propósito de la retrospectiva de sprint es...

Página 34 de 52
 • Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas.
• Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras.
• Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo.

El scrum master alienta al equipo para que mejore, dentro del marco de proceso Scrum, su proceso de
desarrollo y sus prácticas para hacerlos más efectivos y amenos para el siguiente sprint.
Durante cada retrospectiva de sprint, el equipo scrum planifica formas de mejorar la calidad del producto
mediante el mejoramiento de la calidad de los procesos o adaptando la definición de “terminado” según sea
conveniente y no entre en conflicto con los estándares del producto u organizacionales.Para el final de la
retrospectiva de sprint el equipo scrum debería haber identificado mejoras que implementará 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 de sprint ofrece un evento dedicado para este fin, enfocado en la
inspección y la adaptación.

Sprint Grooming o Refinement

El refinamiento del Product Backlog es una práctica recomendada para asegurar que éste siempre esté
preparado.
Esta ceremonia sigue un patrón similar al resto y tiene una agenda fija específica en cada Sprint.

La duración es de 2 horas máximo por semana del sprint.

Es responsabilidad del product owner agendar, gestionar y dirigir esta reunión.

Los participantes de esta reunión son todo el equipo scrum, así como cualquier recurso adicional que
considere necesario el product owner y que pueda contribuir a aclarar el requerimiento. Es necesario, por tanto,
que antes de la reunión todos conozcan los requerimientos o historias de usuario que van a ser tratados en la
misma y sólo asistan aquellos cuya presencia sea estrictamente relevante.

El producto (product backlog). Sprint backlog, Burn up y Burn Down: gráfico de

cumplimiento y tabla de lanzamiento de datos

¿Qué es la lista de producto (product backlog?

Es una lista ordenada de todo lo que se conoce que es necesario en el producto. Es la única fuente de
requisitos para cualquier cambio a realizarse en el producto. El dueño de producto (product owner) es el
responsable de la lista de producto, incluyendo su contenido, disponibilidad y ordenación.

Una lista de producto nunca está completa.

El desarrollo más temprano de la misma solo refleja los requisitos conocidos y mejor entendidos al principio.
La lista de producto evoluciona a medida de que el producto y el entorno en el que se usará también lo hacen.
La lista de producto es dinámica; cambia constantemente para identificar lo que el producto necesita para
ser adecuado, competitivo y útil.

Si un producto existe, su lista de producto también existe.

La lista de producto enumera todas las características, funcionalidades, requisitos, mejoras y correcciones que
constituyen cambios a realizarse sobre el producto para entregas futuras. Los elementos de la lista de producto
tienen como atributos la descripción, el orden, la estimación y el valor. Los elementos de la lista de producto
muchas veces incluyen descripciones de las pruebas que demostrarán la completitud de tales elementos
cuando estén “terminados”.

Página 35 de 52
A medida que un producto es utilizado y se incrementa su valor y el mercado proporciona retroalimentación,
la lista de producto se convierte en una lista más larga y exhaustiva. Los requisitos nunca dejan de cambiar
así que la lista de producto es un artefacto vivo. Los cambios en los requisitos de negocio, las condiciones del
mercado o la tecnología podrían causar cambios en la lista de producto.

A menudo, varios equipos scrum trabajan juntos en el mismo producto. Para describir el trabajo a realizar
sobre el producto se utiliza una única lista de producto.
En ese caso podría emplearse un atributo de la lista de producto para agrupar los elementos.

El refinamiento (refinement) de la lista de producto es el acto de añadir detalle, estimaciones y orden a los
elementos de la lista de producto.
Se trata de un proceso continuo en el cual el dueño de producto y el equipo de desarrollo colaboran acerca de
los detalles de los elementos de la lista de producto. Durante el refinamiento de la lista de producto, se
examinan y revisan sus elementos.

El equipo scrum decide cómo y cuándo se hace el refinamiento. Usualmente consume no más del 10% de la
capacidad del equipo de desarrollo. Sin embargo, los elementos de la lista de producto pueden actualizarse en
cualquier momento por el dueño de producto o a criterio suyo.

Los elementos de la lista de producto de orden más alto son generalmente más claros y detallados que
los de menor orden.
Se realizan estimaciones más precisas basándose en la mayor claridad y detalle; cuanto más bajo es el orden,
menor es el detalle. Los elementos de la lista de producto de los que se ocupará el equipo de desarrollo en el
siguiente sprint tienen una granularidad mayor, habiendo sido descompuestos de forma que cualquier
elemento pueda ser “terminado” dentro de los límites del bloque de tiempo del sprint.

Los elementos de la lista de producto que pueden ser “terminados” por el equipo de desarrollo en un sprint son
considerados “preparados” o “accionables” para ser seleccionados en una reunión de planificación de sprint.
Los elementos de la lista de producto normalmente adquieren este grado de transparencia mediante las
actividades de refinamiento descritas anteriormente.
El equipo de desarrollo es el responsable de proporcionar todas las estimaciones. El dueño de producto podría
influenciar al equipo ayudándoles a entender y seleccionar sus compromisos, pero las personas que harán el
trabajo son las que hacen la estimación final.

¿Qué es la lista de pendientes del sprint (Sprint Backlog)?

Es el conjunto de elementos de la lista de producto seleccionados para el sprint, más un plan para entregar el
incremento de producto y conseguir el objetivo del sprint.

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”.

Hace visible todo el trabajo que el equipo de desarrollo identifica como necesario para alcanzar el
objetivo del sprint. Para asegurar el mejoramiento continuo, la lista de pendientes del sprint incluye al menos
una mejora de procesos de alta prioridad identificada en la retrospectiva inmediatamente anterior.

Es un plan con un nivel de detalle suficiente como para que los cambios en el progreso se puedan
entender en el scrum diario. El equipo de desarrollo modifica la lista de pendientes del sprint durante el sprint
y esta lista de pendientes del sprint emerge a lo largo del sprint. Esto ocurre a medida que el equipo de
desarrollo trabaja en lo planeado y aprende más acerca del trabajo necesario para conseguir el objetivo del
sprint.

Cuando se requiere nuevo trabajo, el equipo de desarrollo lo añade a la lista de pendientes del sprint. 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 lista
de pendientes del sprint durante un sprint. La lista de pendientes del sprint 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.

Página 36 de 52
Es común que el sprint backlog esté representado en un scrumboard o tablero de tareas.

Este proporciona una constante representación visual del estado de las historias de usuario en el backlog.
Una vez que el equipo scrum finaliza y se compromete al sprint backlog no se deben agregar nuevas historias
de usuario; sin embargo, las tareas que pudieron haberse pasado por alto o ignoradas de las historias de
usuario comprometidas pudieran ser agregadas. Si durante un sprint surgen nuevos requerimientos, estos
serán agregados al backlog priorizado del producto e incluidos en un futuro sprint.

Conozcamos en este punto el Burn up y Burn Down: gráfico de cumplimiento y tabla de lanzamiento de
datos. ¡Veamos en qué consisten!
El Burn down muestra la cantidad de trabajo pendiente y el Burn up muestra el trabajo concluido como parte
del sprint.

Burn up (El gráfico de producto)

Es una herramienta de planificación del propietario del producto, que muestra visualmente la evolución
previsible del producto.
Proyecta en el tiempo su construcción, en base a la velocidad del equipo.

La proyección se realiza sobre un diagrama cartesiano que representa en el eje de ordenadas el esfuerzo
estimado para construir las diferentes historias de la pila del producto, y en el de las abscisas el tiempo, medido
en sprints o en tiempo real.

Se traza en el gráfico la línea que representa el ritmo de avance previsto, según la velocidad media del equipo.

Imagen extraída de Scrum Manager

Página 37 de 52
Es recomendable trazar también los ritmos de avance con una previsión pesimista y otra optimista. Se
dibujan basándose en la velocidad obtenida en sprints anteriores con los peores y mejores resultados, o en su
defecto estableciendo un margen según el criterio del equipo (ej. +- 20%).

Imagen extraída de Scrum Manager

Respecto a las versiones, el propietario del producto puede lanzar diferentes versiones cuando disponga de
un número determinado de historias con un esfuerzo estimado.

Para trazar la previsión, se sitúa cada versión en el eje vertical en la posición corespondiente al esfuerzo
calculado para construir todas las historias que incluye.

Los puntos de corte que marca esta posición con las líneas de velocidad del equipo (pesimista, realista y
optimista) proyectan en el eje horizontal la fecha o sprint en el que se espera completar la versión. De igual
forma se pueden proyectar las estimaciones tempranas de las futuras versiones previstas. Esta herramienta
proyecta la previsión de la lista del producto, que es un documento vivo cuya evolución prevé la del producto.

Página 38 de 52
Imagen extraída de Scrum Manager

Burn-down (Gráfico de avance)

Lo actualiza el equipo en el scrum diario, para comprobar si el ritmo de avance es el previsto, o se puede ver
afectada la entrega del sprint.

El seguimiento se basa con los principios de seguimiento del proyecto ágil que son medir el trabajo que
falta, no el realizado (registra en el eje Y el trabajo pendiente) y el seguimiento cercano del avance diario (se
actualiza a diario).

Página 39 de 52
Imagen extraída de Scrum Manager

El equipo dispone en la lista del sprint, de la lista de tareas que va a realizar, y en cada una registra el esfuerzo
pendiente.

Esto se relaciona con que el primer día, en la lista de tareas figura para cada tarea el esfuerzo que se ha
estimado, puesto que aún no se ha trabajado en ninguna de ellas.

Día a día, cada miembro del equipo actualiza en la lista del sprint el tiempo que le queda a las tareas que
va desarrollando, hasta que se terminan y queda 0 como tiempo pendiente.

El avance ideal de un sprint estaría representado por la diagonal que reduce el esfuerzo pendiente de forma
continua y gradual hasta completarlo el día que termina el sprint.

Veamos pues un ejemplo de un patrón de avance:

Imagen extraída de Scrum Manager

El siguiente ejemplo que vemos hace referencia al aspecto de la gráfica en un “sprint subestimado":

Página 40 de 52
La estimación que realizó el equipo en la reunión de inicio del sprint es inferior al esfuerzo real que están
requiriendo las tareas.
Y el siguiente sería el patrón de gráfica de un “sprint sobreestimado”:

Imágenes extraídas de Scrum Manager

Criterios para la estimación y métricas

La información es la materia prima para la toma de decisiones, y la que puede ser cuantificada proporciona
criterios objetivos de gestión y seguimiento.

Página 41 de 52
Desde el nivel concreto de la programación, hasta los más generales de la gestión global de la organización,
tres son los fondos de escala con los que se puede medir el trabajo:

• Desarrollo y gestión de la solución técnica, por ejemplo disponibilidad.

• Gestión de proyecto, por ejemplo % realizado.
• Gestión de la organización, por ejemplo nivel de satisfacción laboral.

¿Cómo podemos aplicar las métricas? ¡Veámoslo! Criterios...

• Cuantas menos, mejor.
• Medir es costoso.
• Medir añade burocracia.
• El objetivo de un equipo scrum es ofrecer la mejor relación valor / coste.

¿Qué debo de tener en cuenta?

• ¿Por qué?

• ¿Qué valor proporciona esta medición?

• ¿Qué valor se pierde si se omite?

El objetivo de scrum es producir el mayor valor posible de forma continua, y la cuestión clave para la
incorporación de indicadores en la gestión de proyectos es la siguiente:

Algunos consejos...
• Antes de incorporar un procedimiento de medición, se debe cuestionar su conveniencia, y la forma en la
que se aplicará.
• Medir no es, o no debería ser, un fin en sí mismo.
• ¿Cuál es el fin?
• ¿Cumplir agendas, mejorar la eficiencia del equipo, las previsiones…?
• Sea crítico. Si después de analizarlo no le convence, si prefiere no incorporar un indicador, o cambiarlo:
usted es el gestor.
• Determinar qué medir es la parte más difícil. En el mejor de los casos, las decisiones erróneas sólo
supondrán un coste de gestión evitable; pero también pueden empeorar lo que se intenta mejorar.
• ¿Lo que vamos a medir es un indicador válido de lo que queremos conocer?

Ejemplos prácticos...
• LOC/Hour: Número total de líneas de código nuevas o modificadas en cada hora.
• Test Defects/KLOC, Compile Defects/KLOC y Total Defects/KLOC, para controlar que no crezca el número
de errores deslizados en el código, e indicadores “appraisal time” para medir tiempo y costes del diseño y
la ejecución de las revisiones de código.
• (COQ) Ante el temor a que el sistema de medición pueda resultar excesivamente costoso se incluyen
indicadores de coste de calidad que miden los tiempos de revisión y los contrastan con las mejoras en los
tiempos eliminados por reducción de fallos.
• Cantidad de líneas, o el valor entregado al cliente.
• El tiempo de tarea, los tiempos delta, y los de las interrupciones, el nº de puntos de función, la inestabilidad
de los requisitos, la proporción de acoplamiento, el nº de errores por línea de código…
Página 42 de 52
Velocidad, trabajo y tiempo
En estos siguientes puntos veremos las tres magnitudes que componen la fórmula de la velocidad, en gestión
de proyectos ágil, definiéndola como la cantidad de trabajo realizada por unidad de tiempo.

Velocidad = Trabajo / Tiempo

Ejemplo: La velocidad de un equipo de 4 miembros es de 20 puntos por semana o de 80 puntos por sprint.

Tiempo
Respecto al tiempo, para mantener un ritmo de avance continuo, el desarrollo ágil emplea dos tácticas posibles:

• Incremento iterativo: mantiene el ritmo apoyándose en pulsos de sprints. Por esta razón emplea
normalmente el sprint como unidad de tiempo, y expresa la velocidad como trabajo o tareas realizadas
en un sprint.
• Incremento continuo: mantiene un flujo de avance constante sin puntos muertos ni cuellos de botella.
No hay sprints, y por tanto las unidades de tiempo son días, semanas o meses, de forma que la velocidad
se expresa en “puntos” (cantidad de trabajo) por semana, día, o mes .

Por otra parte, se hace referencia a la diferencia entre el tiempo "real" y el tiempo "ideal":

• Tiempo real: Es el tiempo de trabajo y equivale a la jornada laboral.

Ejemplo: Para un equipo de cuatro personas con jornada laboral de ocho horas el tiempo real en
una semana (cinco días laborables) es: 4 * 8 * 5 = 160 horas

• Tiempo ideal (estimación): Se refiere al tiempo de trabajo en condiciones ideales, esto es, eliminando
todo lo que no es estrictamente “trabajo”, suponiendo que no hay ninguna pausa por interrupción o
atención de cuestiones ajenas a la tarea y que la persona se encuentra en buenas condiciones de
concentración y disponibilidad. Se emplea normalmente en estimaciones, como unidad de trabajo o
esfuerzo necesario.

Ejemplo: “Esa tarea tiene un tamaño de 3 horas ideales”. “Tiempo ideal no es una unidad de tiempo, sino
de trabajo o esfuerzo necesario”.

Trabajo
Respecto al trabajo, es conveniente medirlo por dos razones concretas:

• Registrar el ya hecho.
• Estimar anticipadamente, el que se debe realizar. En ambos casos se necesita una unidad, y un criterio
objetivo de cuantificación.
En ambos casos se necesita una unidad, y un criterio objetivo de cuantificación. Medir el trabajo ya realizado
no entraña especial dificultad.
Se puede hacer con unidades relativas al producto (p. ej. líneas de código) o a los recursos empleados (coste,
tiempo de trabajo…)

“La gestión ágil no determina el grado de avance del proyecto por el trabajo realizado, sino por el pendiente de
realizar”.

Es posible que otros procesos de la organización necesiten registrar el esfuerzo invertido, y por lo tanto sea
necesario su registro, pero no debe emplearse para calcular el avance del proyecto.

Scrum mide el trabajo pendiente de realizar para:

• Estimar esfuerzo y tiempo previsto para realizar un trabajo (tareas, historias de usuario).
• Determinar el grado de avance del proyecto, y en especial en cada sprint.

Página 43 de 52
No es realista hablar de la cantidad o de la calidad del trabajo que realiza una persona por unidad de tiempo,
porque son muy grandes las diferencias de unas personas a otras. Una misma tarea, realizada por una misma
personar requerirá diferentes tiempos en o situaciones distintas.
No es posible estimar con precisión, ni la cantidad de trabajo de un requisito, ni el tiempo necesario para llevarla
a cabo.La complejidad de las técnicas de estimación crece exponencialmente en la medida que:

• Intentan incrementar la fiabilidad y precisión de los resultados.

• Aumenta el tamaño del trabajo estimado.

Unidades de trabajo

Un trabajo puede dimensionarse midiendo el producto que se construye, como los tradicionales puntos de
función de COCOMO (Modelo Constructivo de Costos) o el tiempo que cuesta realizarlo.

En gestión ágil se suelen emplear “puntos” como unidad de trabajo, empleando denominaciones como
“puntos de historia” o simplemente “puntos” “puntos.

Cada organización, según sus circunstancias y su criterio institucionaliza su métrica de trabajo definiendo el
nombre y las unidades, de forma que puede definir su unidad, su “punto”:

Como tamaño relativo de tareas conocidas que normalmente emplea.

Ejemplo: El equipo de un sistema de venta por internet, podría determinar que un “punto” representara el
tamaño que tiene un “listado de las facturas de un usuario”.

En base al tiempo ideal necesario para realizar el trabajo.

Ejemplo: un equipo puede determinar que un “punto” es el trabajo realizado en 4 horas ideales.

Es importante que la métrica empleada, su significado y la forma de aplicación sea consistente en todas las
mediciones de la organización, y conocida por todas las personas: “Que se trate de un procedimiento de trabajo
institucionalizado”.

Velocidad

La velocidad es la magnitud determinada por la cantidad de trabajo realizada en un periodo de tiempo.

Velocidad en scrum es la cantidad de trabajo realizada por el equipo en un sprint.
Ejemplo: una velocidad de 150 puntos indica que el equipo realiza 150 puntos de trabajo en cada sprint.Al
trabajar en implantaciones de scrum avanzado, que pueden realizar sprints de diferentes duraciones, o no
siempre con el mismo número de miembros en el equipo, la velocidad se expresa indicando la unidad de tiempo
y en su caso también si se refiere a la total del equipo, o a la media por persona.
Ejemplo: “La velocidad media del equipo es de 100 puntos por semana.” “La velocidad media de una persona
del equipo es de 5 puntos por día.”

Estimación de poker
Esta técnica de estimación implementa el consenso para estimar los tamaños relativos de las historias de
usuario o el trabajo necesario para desarrollarlos. Permite hacer una estimación inicial del proyecto rápida
y fiable, dado que todos los miembros del equipo comparten sus diferentes informaciones y expresan su
opinión sin sentirse condicionados por el resto.

El planning poker promueve una mayor interacción y una mejor comunicación entre los participantes.

Página 44 de 52
Facilita el pensamiento independiente por parte de los participantes, evitando con ello el fenómeno del
pensamiento en grupo.

Para estimar tareas puede ser válido un juego de cartas como éste que se indica en el enlace siguiente: Cartas
planing-poker.

Es frecuente emplear una carta con un símbolo de duda o interrogación para indicar que, por las razones
que sean, no se puede precisar una estimación. También es posible incluir otra carta con alguna imagen
alusiva, para indicar que se necesita un descanso.

Algunas recomendaciones al respecto son las que se plantean a continuación:

1
Estima cuánto esfuerzo o trabajo (no tiempo) es necesario para implementar un product backlog item (PBI) en
base a tres factores: cantidad, complejidad y riesgo o incertidumbre.

2
Usa las cartas story point (números) para estimar los PBI’s de un sprint backlog. Utiliza las cartas de tallas en
fases iniciales de un proyecto o para grandes bloques de un product backlog.

3
Antes de empezar se debe acordar qué incluye y qué no la estimación de un PBI desde el principio hasta el final
de su creación: documentación, test unitarios, test de integración, etc.

Frecuencia de actualización de la tabla

Recordemos en este punto que la estructura de trabajo de Scrum divide el tiempo en partes predeterminadas
para completar cada tarea de la acumulación, conocida como Sprint.
Los Sprints son iteraciones, periodos de tiempo predeterminados para completar una parte de un proyecto. La
representación gráfica de un sprint se llama un gráfico de burndown. Estos son útiles para visualizar el
progreso con el fin de mantenerse en el camino.
La reunión diaria es una reunión para que todos los miembros del equipo discutan su progreso y planteen
cualquier problema que requiera atención.

La mayoría de los scrum software tienen funciones de programación o reunión para planificar y coordinar
fácilmente las reuniones diarias.
En este enlace podrás encontrar diez de las mejores herramientas De Scrum (tablero scrum) para aumentar la
productividad de tu equipo.

¿Qué es el scaling scrum?

En el caso de las grandes organizaciones que desarrollan soluciones complejas para sus clientes es posible
encontrar diversos grupos de trabajo en torno a una misma metodología Scrum que realizan esfuerzos
dirigidos hacia un objetivo común.

Página 45 de 52
El scrum aplicado al desarrollo de software

Aunque la popularidad de la metodología Scrum para el desarrollo de proyectos no basados en la tecnología

de la información y la comunicación cuenta cada día con más adeptos, es cierto que el origen de este método
de trabajo lo puedes encontrar dentro del marco de desarrollo de software.

¡Descubre qué implicaciones ha tenido este origen!

Veamos un ejemplo:

“Una reconocida empresa de desarrollo de programas informáticos necesita dotar a un software ya

comercializado de nuevos atributos más acordes a los nuevos requerimientos del mercado. Esta nueva versión
supone una mejora en la arquitectura y en el diseño del programa, pues se deberá implementar una nueva
funcionalidad a la pila del producto.

Imagina que eres tú el responsable de este desafío y debes incorporar una nueva herramienta de preparación
para la impresión desde un software de impresión 3D. Tendrás que diseñar una exclusiva herramienta
integrada en el software que ya comercializas que permita a los usuarios descargar directamente los prototipos
editados en diversos programas conocidos e importarlos directamente a la impresora 3D para su impresión.
Con esta herramienta el usuario podrá utilizar varios programas de creación de archivos y unificar el resultado
en una sola herramienta.”

¿Ves lo complicado que resulta ser el desarrollo de este tipo de proyectos?

¿Comprendes ahora los beneficios que aporta una metodología Scrum para unificar el esfuerzo de un equipo
multidisciplinar?

Desarrollar trabajos tan complejos como el desarrollo de un software o crear una nueva versión del ya existente
no podría ser viable si se tuvieran que aplicar métodos tradicionales donde priman los extensos informes y
pesada documentación.

Ahora bien, ¿qué ocurre cuando el scrum va más allá de un área departamental? En las empresas de gran
tamaño tratan el scaling scrum como una técnica de entendimiento entre diversos equipos scrum con un
único product owner.

Hasta aquí no solo has profundizado en el origen de la metodología scrum como herramienta eficiente de
desarrollo de software, sino que también has visto cómo es posible que en una organización grande pueda
replicarse esta fórmula de trabajo como versión ampliada en diferentes equipos multidisciplinares y
autoorganizados, y que todos trabajen hacia una causa común como un proyecto integral de gran
complejidad.

Identificar los obstáculos mayores para usar scrum en una organización.

Implantar en una organización un método de trabajo como scrum no requiere únicamente del conocimiento
de las técnicas y mecánicas, también es necesario y vital para tener éxito en el empeño contar con el
talante y la actitud apropiada de quienes van a ponerlas en práctica.

Hasta ahora, cada vez que hemos nombrado el adjetivo complejo lo hemos asociado al tipo de proyectos en el
que participa la metodología Scrum.

Sin embargo, en ocasiones, la mayor dificultad no es la desentrañar la solución que demanda el plan, sino un
peligro que nace de las exigencias del propio método.

Página 46 de 52
¡Aquí las conoceremos!

Veamos este ejemplo:

“Por primera vez Manuel decide poner en marcha el scrum como fórmula de gestión de proyectos denominados
ágiles. El equipo que ha conformado, aunque es multidisciplinar, independiente y saben autoorganizarse bien,
lo cierto es que, en ocasiones, su ritmo de trabajo no es el adecuado. Manuel, como scrum master y para
salvaguardar el objetivo del proyecto, decide aplicar uno de los valores representados en el manifiesto ágil. De
esta manera conseguirá garantizar la viabilidad del proceso y alcanzar los objetivos propuestos."

¿Puedes imaginarte a qué principio del manifiesto nos estamos refiriendo?

Pues bien es el principio de sostenibilidad, que hace que todo el esfuerzo en el desarrollo del proyecto deba
estar orientado hacia que el resultado obtenido sea sostenible en el tiempo.
Los componentes del Scrum team deben saber gestionar adecuadamente la energía destinada en el proceso
desde el inicio hasta el final.
De lo contrario brotarán inconvenientes y dificultades asociadas al rendimiento del equipo que pueden poner
en peligro la integridad del proyecto.

¿Te gustaría conocer los errores más comunes en el desarrollo de proyectos ágiles?

Te recomendamos que visites el siguiente enlace: 20 obstáculos en el desarrollo de proyectos ágiles.

Actividades y técnicas al equipo scrum puede emplear para alcanzar los

objetivos de la reunión
Aunque en el desarrollo de los procesos que engloban el proyecto, pueden surgir muchos de los obstáculos
anteriormente vistos, existen técnicas que un equipo scrum puede manejar con el fin de alcanzar los
objetivos fijados en cada reunión.

El más popular es el siguiente, que presentamos y que explicamos a continuación: la matriz Stacey.

Página 47 de 52
Tal como acabamos de ver, una de las herramientas más populares para solventar los obstáculos es el
diagrama o matriz de Stacey, que está basada en el trabajo de Ralph Douglas Stacey y habitualmente su
representación difiere de su trabajo original sobre los sistemas adaptativos y la teoría del caos.

Esta matriz puede ayudar a seleccionar las acciones de gestión adecuadas en un sistema complejo basado en
el grado de certeza y el nivel de acuerdo sobre el tema en cuestión.

Se trata de un mapa conceptual o matriz que ayuda a los participantes del scrum a tomar el mejor camino
para alcanzar el objetivo propuesto en el desarrollo de un proyecto ágil.

Se puede utilizar cuando tratamos de solucionar estas situaciones...

• Elegir entre los enfoques de gestión o liderazgo para un tema o decisión específica.
• Dar sentido a una serie de decisiones (o agenda para un grupo).
• Comunicarse con otros sobre el porqué un enfoque particular es apropiado.
• Cuando se necesitan innovaciones y alternativas creativas, esta matriz se puede usar para tratar
deliberadamente de aumentar la incertidumbre y el desacuerdo para llevar al sistema al borde del caos.

En este diagrama observamos cuatro dominios de la complejidad:

• Dominio simple: donde se conoce todo.

• Dominio complicado: donde se conoce más de lo que se desconoce.
• Entorno complejo: se desconoce más de lo que se conoce.
• Caos: todo es descnocido o casi todo.

Página 48 de 52
Un equipo scrum está continuamente sometido al factor de la incertidumbre.

Esta incertidumbre no facilita la toma de decisiones, pudiendo ser muy complicado llegar a acuerdos que hagan
avanzar el proyecto. Para evitar que los desacuerdos impidan que no puedan extraerse conclusiones en las
reuniones, existe la técnica del diagrama de Stacey, que hace posible la visualización de la causa-efecto para
la toma de decisiones.
Este acercamiento a la certeza ayuda a que todos los integrantes del equipo remen hacia una misma dirección
Y bien, ¿por qué es necesario utilizar el diagrama de Stacey en la toma de decisiones en las reuniones
Scrum?

Gracias a la matriz de Stacey es posible que los integrantes del equipo scrum puedan visualizar cuál será el
mejor camino o la mejor decisión para avanzar con el proyecto, puesto que facilita la interpretación de la causa
– efecto según los valores del scrum.

La gestión de proyectos ágiles no se trata de una tarea sencilla y puede presentar muchos obstáculos que
impidan alcanzar los objetivos propuestos.

Sin embargo, scrum pone a disposición de los participantes técnicas que sirven para tomar las mejores
decisiones y llegar rápidamente a acuerdos. De esta manera las incidencias relativas a desavenencias son
resueltas ágilmente con una herramienta objetiva y fácil de utilizar.

¡Seguro que con este recurso será mucho más fácil trabajar con un equipo altamente cualificado y
orientado a un mismo objetivo!

Otras herramientas ágiles

Poco a poco hemos conseguido hilar todas las directrices que están atribuidas a la metodología scrum de
tal manera que cada paso y movimiento imprime un carácter especial al proyecto.

Ahora verás alguna herramienta que puede ser utilizada como un recurso scrum y que definitivamente
eliminará cualquier duda que te pueda surgir a la hora de implementar ciertas ecuaciones, maniobras y técnicas
propias de scrum.

Este método encandila a quien decide adentrarse en él y difícilmente no dejará huella en la manera de hacer
de quien lo conozca.

Las empresas, las organizaciones e, incluso, instituciones más diversas, ven en esta metodología la mejor
manera de empoderar al talento humano, permitiendo desarrollar proyectos complejos que ofrecen
resultados de extrema calidad.

Una de las primeras cuestiones a la hora de organizar las tareas de un equipo es poner a disposición de este
el instrumento radiador de información. Como recordarás, la pizarra Scrum o tablero sirve para mostrar al
equipo las tareas pendientes que deberán acometer. Además, proporcionará la funcionalidad de planificar cada
iteración.

En cuanto al tipo de tablero, puedes utilizar uno físico o uno virtual.

En el caso de hacer uso de la tecnología, la variedad de software de gestión de proyectos ágiles es enorme. Lo
importante es poder hacer uso de la herramienta capaz de seguir la estructura del scrum.

¿Qué es el software de gestión de proyectos ágiles scrum?

Página 49 de 52
Son programas específicos con un diseño y una arquitectura basada en la metodología scrum y que,
además de muchas aplicaciones, permite disfrutar de un tablero o pizarra interactiva donde gestionar las tareas
pendientes de cada iteración.

¡Pasa de pantalla para ver algunas de estas herramientas! Veamos

algunas de las herramientas:

1
IceScrum. Software de gestión.

2
Trello.com. Software de gestión.

3
Kezmo. Software de gestión.

Respecto a Kezmo, se trata de una de las herramientas de gestión de proyectos ágiles que cuenta con un diseño
propio de la metodología Scrum. Se trata de una práctica plataforma de comunicación y organización de tareas
de trabajo en equipo.

El siguiente vídeo es un tutorial en el que podrás comprobar el manejo de todos aquellos elementos que
conforman la técnica del Scrum.

¡Presta atención!

Vídeo Kezmo

¿Qué es mejor utilizar: pizarras Scrum o algún software específico de desarrollo de proyectos ágiles?
Aunque los programas específicos cuentan con una estructura propia del scrum y están especialmente
preparados para guiar al equipo, proporcionando mayor independencia y total comunicación, es importante
que al menos el scrum master conozca y tenga dominio del manejo manual del tablero. También es posible
utilizar ambos recursos, de tal manera que en las reuniones diarias la pizarra física ofrezca una información
mucho más visual, siempre y cuando esto no suponga duplicidad y pérdida del recurso tiempo.

Método Kanban

Sabemos que encontrar el mejor método para realizar nuestro trabajo, ya sea en solitario o bien en equipo, así
como obtener los mejores resultados, no es tarea fácil. Sin embargo, tal como ya hemos visto, existen sistemas
que resultan muy prácticos como el método Kanban, que podemos adaptar a nuestras necesidades diarias.

Este método lo asociamos con productividad, eficiencia, optimización… seguro que son palabras que te
suenan pues son utilizadas muy a menudo en la mayoría de empresas, objetivos ideales que no siempre se
consiguen por no tener un buen sistema de organización o por no aplicarlo correctamente.

En el caso de que hayas decidido utilizar este tipo de metodología Kanban, debes saber que puede ayudar con
el flujo de trabajo que tengas en tu organización de forma que facilite la identificación de cuellos de botella
en tu forma de trabajar actual.

Y bien, ¿qué es un cuello de botella? Se debe tener en cuenta que si en algún momento se acumulan en un
bloque del panel más tareas que lo que tienes establecido, es ahí donde tendremos el cuello de botella. Una
vez localizados los atascos en Kanban... nos tocará solucionarlos.

Un cuello de botella en el flujo de trabajo se produce porque los miembros del equipo de un área
determinada no son capaces de ejecutar las tareas que tienen encomendadas al ritmo esperado. En esta

Página 50 de 52
situación el grupo de trabajo previo ha superado el límite establecido sin que se haya dado salida a ninguna
tarea.

¿Quieres conocer cuáles son los elementos que componen el método Kanban?

Pues bien, los elementos que componen la lista de Kanban son:

• Lista de tareas.
• Tareas que están listas.
• Tareas que están en proceso.

¡Pasa de página para poder ver un ejemplo de las mismas!

Es necesario tener un tablero donde se pueda visualizar el trabajo, lo recomendable es utilizar una pizarra física
porque aporta otros múltiples beneficios, como la transparencia y la colaboración hacia otras áreas de la
organización.

Imagen extraída de: Jerónimo Palacios.

Además, es fundamental hacer partícipe a todas las personas, así como dedicar un poco de tiempo a explicar
qué es la metodología Kanban a todo el personal que trabaja en la empresa y cómo además puede mejorar el
flujo de trabajo diario. Tener un acuerdo de que queréis intentar usar el método Kanban o al menos un tablero
Kanban para visualizar vuestro trabajo es fundamental.

Página 51 de 52
Imagen extraída de: Jerónimo Palacios.

Para terminar...

Como hemos visto, SCRUM es una metodología ágil que permite enfocar los recursos de la organización en el
desarrollo de proyectos y tareas pero de una manera altamente eficiente, con todos los beneficios que ello
supone.

No obstante, para aprovecharnos de todas sus ventajas se necesita un gran trabajo de planificación y
organización.

Página 52 de 52