Diccionario 
Scrum: El 3-5-3 

 
Por  
Marcelo Garcia 
Octavio Levy   

 
 

Introducción 
Los equipos Scrum que desean recibir el retorno de la inversión asociado con un 
buen Scrum deben tener un método inmediato para verificar si están 
implementando las mismas prácticas observadas en los equipos documentados de 
alto rendimiento.  

Para apoyar esto, los animamos a que se comparen con los elementos 
fundamentales de Scrum: 

● 3 roles 
● 5 eventos 
● 3 artefactos.  

Este recordatorio abreviado se usa en nuestros entrenamientos y esperamos que 

presente a algunos equipos una herramienta de verificación rápida para ganar los 
beneficios de velocidad y felicidad observados en los equipos que implementan los 
11 componentes de Scrum. 

Scrum es un marco de trabajo liviano que puede ser aplicado en cualquier industria 
y dominio. Sin embargo, mientras que Scrum es adaptable a diferentes contextos, 
el núcleo del marco permanece igual en todas las implementaciones.  

El hecho de tener diferentes interpretaciones de Scrum entre los Equipos 

presentará desafíos significativos cuando se escalan las implementaciones de 
Scrum.   

1 
 

El Product Owner 
Definición 
El Product Owner es uno de los 3 roles del marco de trabajo Scrum, cada rol en 
Scrum tiene su objetivo. El objetivo del Product Owner es maximizar el valor del 
producto entregado por el equipo, es quien debe lograr que entreguemos el 
producto «correcto», el producto que quiere el mercado y stakeholders. Para ello 
contará con grandes responsabilidades como por ejemplo el ordenamiento del 
Product Backlog. 

Responsabilidades del Product Owner 

Co-creación de la visión del producto 

La visión es lo que nos define hacia donde va nuestro producto. Básicamente en 
una visión tienen que quedar en claro: quienes son nuestros clientes, qué problema 
les vamos a resolver y beneficios clave del producto. 

La co-creación de la visión es una actividad colaborativa en la cual participan 

stakeholders e integrantes de los equipos. La visión no es algo fijo que se define al 
principio del proyecto, sino que es algo que se co-crea durante toda la vida del 
producto, la visión puede cambiar pero es importante que esta esté clara en todo 
momento para el Product Owner. 

Gestión del Product Backlog 

El Product Owner es el responsable de que el Product Backlog sea: 

Visible y transparente: debe ser visible para stakeholders y equipo. 

Expresado claramente: sus ítems Product Backlog Items (PBIs) deben estar 
especificados de manera clara y estar lo suficientemente detallados para ser 
entendidos por el equipo. 

Ordenado: debe estar ordenado de manera que maximice el valor del producto 
creado por el equipo. 

2 
 

El Product Owner ordena el Product Backlog 

Una de las principales y más importantes responsabilidades del Product Owner es 
la priorización del Product Backlog. A la hora de priorizar consideraremos la 
conocida «Regla de Pareto», buscaremos encontrar el 20% de características del 
producto que aportan el 80% del valor, lo cual no es una tarea fácil. 

Cuando hablamos de valor de producto es importante considerar que ese valor no 
sólo es el valor de mercado que le aporta a nuestros usuarios, sino también el valor 
de aprendizaje (cuánto podemos aprender de nuestro contexto y reducir riesgos 
con esos PBIs) y el valor de desarrollo de competencias (qué competencias 
podemos desarrollar con esos PBIs). 

Existen diferentes técnicas de priorización que puede aplicar un Product Owner, 

desde las más simples cómo «Burbujeo» (donde se prioriza por comparación de 
cada PBI contra el resto), hasta un análisis completo de flujos de caja NPV (Net 
Present Value). La estrategia a utilizar puede tener mayor o menor complejidad, 
puede ser más o menos precisa, la decisión sobre cuál utilizar dependerá del 
contexto y criterio del Product Owner. 

Es importante considerar que la única persona que tiene la última palabra en el 
ordenamiento del Product Backlog es el Product Owner. No puede aparecer otra 
persona que fuerce al equipo a trabajar en algo diferente a lo priorizado por el 
Product Owner. 

El Product Owner maneja las expectativas de los stakeholders 

El Product Owner pasa gran parte de su tiempo con los stakeholders (interesados), 
teniendo conversaciones sobre el producto, su visión, características y 
funcionalidades. La comunicación efectiva es una competencia clave en un 
Product Owner ya que tiene que poder comunicarse efectivamente con múltiples 
stakeholders y el equipo. 

Por otro lado el Product Owner no es el único que debe comunicarse con los 
stakeholders, eso es algo que sucede frecuentemente y se le llama: «El Product 
Owner Proxy», quien es un intermediario de la comunicación del equipo con 
stakeholders. El Product Owner debe ser un facilitador de esas conversaciones, de 
manera que exista comunicación directa y efectiva entre las partes. 

3 
 

Release Plan y estrategia de producto 

El Product Owner tiene un plan de entregas en el cual refleja la visión del producto 
a lo largo del tiempo. Un Relese Plan contiene entre otras cosas: 

La visión del producto descompuesta en objetivos, funcionalidades y épicas. 

Un Release Burndown Chart que muestre de qué manera avanzamos hacia la 
entrega del release. 

Un Roadmap que muestre la cronología de entrega de funcionalidades y épicas a 

futuro, tiene el objetivo de facilitar conversaciones con stakeholders. 

El Release Plan no es fijo sino que cambia de manera contínua y se adapta a los 
cambios de contexto. 

Experimentación & MVP 

Cuando trabajamos en contextos complejos y particularmente en el inicio de un 

nuevo producto, el valor que más buscamos generar es el aprendizaje de nuestros 
clientes a la par que reducimos riesgos. En busca de maximizar ese aprendizaje 
validado, el Product Owner prioriza la construcción de ciertas funcionalidades o 
experimentos que nos permitan aprender lo más que podamos en el menor tiempo 
posible. Para lograrlo se crea un producto mínimo viable (MVP) del cual recibimos 
feedback y validemos las hipótesis más importantes de nuestro producto.   

4 
 

El Equipo de Desarrollo 
Definición 
El Equipo de Desarrollo (o Development Team) es uno de los tres roles en Scrum y 
se compone de todas las personas que se encargan de construir el Incremento de 
Producto en cada Sprint. 

El Equipo de Desarrollo es auto-organizado 

Cuando nos referimos a esta cualidad en Scrum, queremos decir que nadie (ni 
siquiera el Scrum Master) le dice al equipo cómo convertir el Product Backlog en 
Incrementos de Producto a lo largo de cada Sprint. Para lograr que este nivel de 
madurez resulte efectivo necesitamos que todo el equipo tenga muy en claro y 
presente la Visión del producto. 

¿Qué significa ser multifuncional? 

Significa que está compuesto por personas con diferentes competencias 
necesarias para completar cada Incremento de Producto. Ser multifuncional busca 
no depender de personas externas al equipo, de manera que no se ponga en 
peligro el cumplimiento del Objetivo de cada Sprint. 

No se reconocen títulos ni jerarquías 

Dentro de este marco ágil no se reconocen títulos para los miembros del Equipo de 
Desarrollo, independientemente del trabajo que realiza cada persona. Tampoco se 
reconocen sub-equipos internos, independientemente de los dominios que deben 
abordarse, como pruebas o calidad, arquitectura, operaciones o análisis. 

Las personas del Equipo de Desarrollo pueden especializarse en ciertas áreas pero 
la responsabilidad de los objetivos pertenece al Equipo de Desarrollo como un todo. 

Comunicación con los Stakeholders. 

Si bien el Product Owner mantiene principalmente las relaciones con los 
Stakeholders buscando optimizar la entrega de valor, es muy importante que 
también fomente la comunicación directa entre ellos y el Equipo de Desarrollo. En 

5 
 

Scrum esta relación directa se produce principalmente durante el evento del Sprint 
Review donde el equipo de desarrollo recibe el feedback del Incremento sin ningún 
tipo de filtro de comunicación por parte de terceros. 

¿Cuál es el tamaño de un Equipo de Desarrollo en 

Scrum? 
El tamaño, según la guía Scrum, es de tres a nueve miembros (no se considera el 
Product Owner ni el Scrum Master). 

Trabajar con menos de tres personas puede resultar en falta de habilidades 

necesarias para construir un Incremento de Producto de valor durante un Sprint. 

Por el otro lado, tener más de nueve personas hace que aumente 
considerablemente los canales de comunicación, lo que implica mayor 
complejidad y al final requiere demasiada coordinación para que un proceso 
empírico sea útil. 

Buenas prácticas 
Perfiles multidisciplinarios 

Dentro del sistema de producción de Toyota existen algunos conceptos que tienen 
como objetivo la mejora en las diferentes etapas del proceso productivo. Uno de 
ellos es «Muri» que significa sobrecarga. Este concepto se refiere a cualquier 
actividad que requiere un estrés o esfuerzo muy alto por parte de cierta persona o 
equipo, provocando cuellos de botella o tiempos muertos. 

Un problema de no tener un equipo con perfiles multidisciplinarios hace que, por 

ejemplo, cuando aumenta la demanda de cierto tipo de tarea, solamente una o 
pocas personas del equipo pueden trabajar en ello. 

Equipos estables 

Los equipos estables tienden a conocer mejor su capacidad, lo que hace posible 
que la organización tenga cierta previsibilidad. La recomendación es dedicar a los 
miembros del equipo a un solo equipo siempre que sea posible.   

6 
 

El Scrum Master 
¿Qué es un Scrum Master? 
El Scrum Master es uno de los 3 roles del marco de trabajo Scrum. Scrum define los 
siguientes roles: Equipo de Desarrollo, Product Owner y Scrum Master, cada rol 
tiene un objetivo diferente lo cual crea un equilibrio saludable en el equipo Scrum. 

Objetivo del Scrum Master 

Cada rol en Scrum tiene su objetivo, el Product Owner por su parte busca que el 
equipo construya el producto correcto, el producto que necesita el mercado y los 
stakeholders alineado con la visión. El equipo de desarrollo tiene como objetivo 
construir correctamente el producto, con la calidad requerida, usando la 
tecnología, arquitectura y herramientas correctas. Sin embargo tener el producto 
que quiere el mercado y con la calidad requerida no es suficiente, necesitamos ser 
productivos y entregar valor de acuerdo a los tiempos del mercado. 

El Scrum Master busca potenciar tanto al Equipo de Desarrollo cómo al Product 

Owner, es el responsable de la eficiencia del equipo Scrum y de que el equipo 
mejore de manera continua hacía su mejor versión. 

Roles Scrum Master 

El Scrum Master cumple diferentes roles, entre ellos los principales: 

El Scrum Master entrena al equipo y a la organización 

Enseña Scrum y Agilidad al equipo, al Product Owner y a la organización. Ayuda a 

que Scrum sea entendido y pueda ser adoptado, para ello es fundamental que 
pueda transmitir efectivamente conocimientos. Generalmente cuando un equipo 
comienza a trabajar con Scrum la mayoría del esfuerzo del Scrum Master está 
puesto en estas tareas. 

El Scrum Master facilita eventos de Scrum y espacios de conversación 

El Scrum Master cumple este rol frecuentemente en el Sprint, cada evento de 
Scrum (Sprint Planning, Daily Scrum, Sprint Review y Retrospectiva) es facilitado 
por el Scrum Master. 

7 
 

El rol de facilitador de una reunión, evento o conversación es principalmente que se 

cumpla el objetivo de ese espacio, que estén disponibles todos los recursos que se 
necesitan y que todas las voces sean escuchadas. El facilitador es «neutral» sobre 
las decisiones: interviene sobre el proceso no sobre el resultado. 

Por ejemplo en una Retrospectiva en su rol de facilitador va a buscar que cada 

persona del equipo pueda ser escuchada, que tengamos disponible el acceso a las 
herramientas digital que usaremos para la dinámica y lo más importante que se 
cumpla el objetivo de la retrospectiva (Que el equipo reflexione y defina uno o 
varios accionables de mejora para el siguiente Sprint). 

El Scrum Master es líder servicial 

El enfoque de liderazgo del Scrum Master es diferente al de un líder tradicional, el 

equipo NO está al servicio de él sino que por el contrario el Scrum Master está al 
servicio del equipo Scrum para lo que este necesite. 

El Scrum Master sirve al Product Owner de varias formas 

● Se asegura que la visión, los objetivos y alcance del producto sean 

entendidos por el equipo Scrum de la mejor manera posible. 
● Ayuda a tener un Product Backlog priorizado, claro y conciso que maximice 
el valor del producto construido por el equipo. 
● Facilita eventos de Scrum o espacios de descubrimiento de producto según 
sea necesario. 

El Scrum Master sirve al equipo de desarrollo 

● Guía al equipo a ser autoorganizado y multifuncional. 

Lo acompaña para que pueda lograr entregar productos de alto valor y 
mejorar continuamente. 
Remueve impedimentos que pueda tener el equipo durante el Sprint. 
● Facilita eventos de Scrum o espacios de conversación que el equipo necesite. 

El Scrum Master guía a la organización 

● Liderar otras implementaciones de Scrum en la organización. 

● Trabajar en conjunto con otros Scrum Masters para potenciar la 
transformación. 
● Ayudar a interesados y personas de la organización a entender y practicar 
Agilidad y Scrum. 

8 
 

El Scrum Master remueve impedimentos dentro y fuera del equipo 

Cuando hablamos de impedimentos, podemos tener desde un impedimento físico 

(Ej: necesidad de una oficina), pasando por impedimentos que tienen que ver con 
relaciones con otros equipos (Ej: dependencias) o hasta conversaciones que están 
faltando o conflictos a resolver, ya sea dentro o fuera del equipo. 

Remover impedimentos es una tarea que requiere mayor esfuerzo del Scrum 
Master en contextos de mayor complejidad, en los cuales múltiples equipos 
trabajan en el mismo producto o servicio. 

El Scrum Master es un agente de cambio en la transformación 

organizacional 

El Scrum Master es agente y «catalizador» de cambios tanto en el equipo cómo en 

la organización. En química cuando hablamos de catalizador nos referimos a una 
sustancia que acelera una reacción, básicamente hace más rápido el cambio. Si lo 
llevamos a las organizaciones, los cambios algunas veces se dan por sí mismos, 
pero en la mayoría de los casos necesitamos personas que los aceleren e impulsen. 

¿Qué hace un Scrum Master? 

Es común que aparezca la siguiente pregunta en los entrenamientos: ¿Qué hace 
un Scrum Master todo el día?. Te comparto un listado de tareas concretas que veo 
desde mi experiencia que hace un Scrum Master (son ejemplos no necesariamente 
se hace todo esto, también se pueden hacer muchas otras tareas que no aparecen 
en este listado): 

● Manejar un backlog de impedimentos visible para todo el equipo.  

● Tener conversaciones con personas de la organización para resolver 
dependencias e impedimentos del Sprint. 
● Facilitar la creación de acuerdos del equipo y visibilizarlos. 
● Crear radiadores de información que permitan generar conversaciones (Ej: 
Un Scrum Board con objetivo de Sprint, Sprint Backlog y Burndown Chart). 
● Trabajar con el Product Owner en la creación de las historias de usuario de 
manera que sean INVEST. 
● Preparar una dinámica para hacer en la próxima retrospectiva. 
● Intervenir en la Retrospectiva si se está finalizando sin medidas accionables. 
● Hacer visibles los accionables de la retrospectiva y acompañar al equipo en 
su ejecución en el Sprint. 

9 
 

● Reunirse frecuentemente con otros Scrum Masters para compartir 

experiencias y aprendizajes. 
● Organizar workshops o entrenamientos para equipos de la organización. 
● Tener reuniones con líderes de la organización para trabajar en la 
transformación y cambio a nivel organizacional. 
● Cuestionar la manera en que se hacen las cosas, preguntar y preguntar, 
aunque esto a veces resulte incómodo para el equipo y organización. 
● Experimentar frecuentemente, co-crear experimentos que le permitan a la 
organización evolucionar su forma de trabajar. 
● Organizar una agenda en conjunto con el Product Owner para los diversos 
Stakeholders en la Sprint Review. 
● Impulsar y colaborar en la creación de un DoD (Definition of Done) y DoR 
(Definition of Ready). 
● Intervenir en la Sprint Planning en caso que no quede claro el objetivo del 
sprint o alguna característica del producto. 
● Colaborar con el equipo para que pueda encontrar mejoras en la calidad del 
producto y reducir la deuda técnica. 
● Intervenir en la Daily Scrum si no se están visibilizando realmente los 
impedimentos. 
● Observar al equipo y sus conversaciones. 
● Dar feedback y facilitar que el equipo se de feedback entre sí 
frecuentemente. 
● Facilitar la resolución de conflictos en el equipo. 
● Trabajar en conjunto con el equipo en reducir los ciclos de entrega de 
producto y feedback (Lead Time / Cycle Time) 
● Hacer coaching al equipo, identificar lo que el equipo quiere lograr y 
acompañarlo en ese camino de reflexión mediante preguntas poderosas y 
otras técnicas. 
● Leer, compartir y aprender continuamente de Agilidad y Scrum. 

   

10 
 

El Product Backlog 
Definición de PRODUCT BACKLOG 
El Product Backlog (o Lista de Producto) es una lista ordenada de todo lo que se 
conoce que es necesario que un producto o servicio cumpla. Es uno de los 3 
artefactos de Scrum. También es la única fuente de requisitos para cualquier 
cambio. El Product Backlog es emergente durante todo el proyecto, es decir, nunca 
está completo sino que es dinámico; cambia constantemente para identificar lo 
que el producto necesita para ser competitivo y útil en el mercado que se 
encuentra. 

¿Qué contiene el PRODUCT BACKLOG? 

Este artefacto contiene todas las características, funcionalidades, mejoras y 
correcciones (o bugs) a realizarse sobre el producto o servicio. A cada elemento del 
Product Backlog se lo conoce como Product Backlog Item (PBI) y tiene una 
descripción, un orden y una estimación. A medida que el producto es utilizado, el 
mercado comienza a proporcionar retroalimentación y esto hace que se convierta 
en una lista más larga y detallada. Por esto podemos decir que es un artefacto vivo 
ya que constantemente los requisitos están cambiando. 

¿Quién es el responsable del Product Backlog? 

El responsable del Product Backlog es el Product Owner, incluyendo su contenido, 
disponibilidad y priorización. 

¿Cómo priorizar el BACKLOG? 

El Product Owner ordena los PBI en busca de generar ROI (retorno de inversión) a 
largo plazo. Para ello debe considerar tanto los ingresos como los costos de cada 
ítem. El Product Owner, dueño del producto, tiene el poder para tomar decisiones 
en nombre de todos los stakeholders, aunque debería considerar todas las ideas y 
pedidos para de todos ellos para equilibrar la ecuación de valor. 

Me parece interesante aclarar en este punto que el ROI no tiene que estar solo 
relacionado al dinero, sino que se trata de valor: El valor no solamente es el que 

11 
 

comúnmente escuchamos refiriéndose al que se basa en la teoría económica del 

valor: intercambiar un activo por otro de igual valor. 

Una empresa también puede valorar la retención de los empleados, las buenas 
relaciones con los clientes, una buena imagen pública o muchos otros objetivos 
que quedan fuera de la teoría económica del valor. 

Considerando esto, podemos decir que el Product Owner debe ordenar la lista de 
manera tal que queden arriba los ítems que aportan mayor ROI y hacer esos 
primero. 

Principios INVEST 
Los principios o criterios INVEST son una lista de 6 cualidades que nos ayudan a 
comprobar la calidad de una User Story: 

● «I»ndependent (independiente): Debe ser independiente de otras historias. 

● «N»egotiable (negociable): Su alcance y criterios deben ser variables. El 
Equipo de Desarrollo debe poder negociar con el Product Owner estos 
criterios al comienzo del Sprint. 
● «V»aluable (valorable): Deben aportar valor real al cliente, un incremento de 
producto completo. 
● «E»stimable (estimable): Deben poder estimarse por el Equipo de Desarrollo 
por lo cual no deben ser demasiado grandes y debemos tener cierto 
conocimiento de esta a nivel negocio y técnico. 
● «S»mall (pequeña): Debe poder completarse dentro de un Sprint. 

«T»estable (comprobable): Debe ser posible verificar que la misma está completa 
una vez desarrollada. Para ello debe tener claros criterios de aceptación con los 
cuales verificamos que esté realmente lista. 

¿Cómo gestionar el BACKLOG con varios equipos? 

Es común que varios Equipos Scrum trabajen juntos en un mismo producto. En 
estos casos los equipos trabajan sobre un único Product Backlog y para agrupar 
elementos de la lista por similitudes se suelen agregar etiquetas o atributos. 

¿Qué es el Definition of Done? 

El Definition of Done «DoD» (o definición de terminado) es un acuerdo común que 
nos sirve para determinar cuándo un elemento de la lista del producto está 

12 
 

finalizado. Este mismo acuerdo guía al Equipo de Desarrollo durante la Sprint 

Planning para saber cuántos ítems podrán completar durante el Sprint. 

Usualmente un equipo Scrum al comienzo del proyecto define un Definition of 

Done básico, por ejemplo, que cumpla con los criterios de aceptación establecidos 
por el Product Owner. A medida que el equipo madura a este acuerdo se expandirá 
para incluir criterios más estrictos, lo que llevará a aumentar la calidad del 
producto. 

Si bien en la mayoría de los casos este acuerdo se aplica a todos los elementos de la 
lista podríamos identificar elementos que requieran tener su propia definición. Por 
ejemplo, podríamos tener un DoD para todos los elementos que sean de nuevas 
funcionalidades y otro DoD solamente que se aplique a los requerimientos de 
documentación legal. 

Quien es responsable de su definición es el Equipo de Desarrollo. Cuando hay 

muchos Equipos de Desarrollo trabajando sobre un mismo producto, deberán 
establecerlo en conjunto. 

¿Qué es el Definition of Ready? 

El Definition of Ready «DoR» (o Definición de Listo) es un acuerdo del Equipo Scrum 
para determinar si un elemento está apto para ingresar a un Sprint. 

Al contrario del Definition of Done, que se aplica a elementos dentro de un Sprint 

en curso, el Definition of Ready apunta a elementos que están por entrar en el 
Sprint. Si el Equipo de Desarrollo no comprende correctamente los PBIs el tiempo 
de desarrollo dentro del Sprint tiende a subir mucho y pone en peligro el 
cumplimiento del Objetivo del Sprint; por lo que es muy importante que se genere 
este acuerdo se cumpla, es decir, que no entren al Sprint PBIs que no están en 
estado «Ready». 

Podemos decir que el Product Backlog está «Ready» cuando tiene suficientes PBIs 
en su parte superior para llenar un Sprint y que están en «Ready». 

¿Quién ESTIMA los ítems del Product Backlog? 

El Equipo de Desarrollo es el responsable de proporcionar todas las estimaciones. El 
Product Owner podría influenciar al Equipo ayudándoles a entender y seleccionar 
el Objetivo del Sprint, pero las personas que harán el trabajo son las que hacen la 
estimación final.   

13 
 

El Sprint Backlog 
Definición del SPRINT BACKLOG 
El Sprint Backlog es la suma de todos los elementos del Product Backlog elegidos 
para el Sprint, más un plan de cómo crear el Incremento de Producto que permita 
alcanzar el Sprint Goal (Objetivo del Sprint). Es uno de los 3 artefactos de Scrum y es 
el que se construye durante la segunda parte de la Sprint Planning. 

El equipo generalmente subdividen este trabajo en elementos llamados Sprint 

Backlog Items (SBI). Estos elementos pueden representar tareas que el equipo 
debe completar, bloques de construcción intermedios que se combinan en una 
entrega, o cualquier otra unidad de trabajo que ayude al equipo a comprender 
cómo lograr el Sprint Goal dentro del Sprint. 

Visibilidad del avance del Sprint 

Es importante que este artefacto esté visible para todo el equipo, ya que tiene 
como objetivo proporcionar transparencia sobre el estado del trabajo planificado 
para el Sprint. Es por esta razón que me gusta llamarlo un radiador de información. 

El equipo de desarrollo realiza un seguimiento del trabajo total restante al menos 

una vez por día en la Daily Scrum para proyectar la probabilidad de lograr el Sprint 
Goal. Al reconocer el trabajo restante a lo largo del Sprint, el Equipo de Desarrollo 
puede administrar su progreso. 

Tablero Kanban 

Si bien la guía Scrum no define cómo implementar este artefacto, creo que una 
manera recomendada de hacerlo es a través de la implementación de un tablero 
Kanban. 

El tablero Kanban es una herramienta compuesta por columnas para representar el 
estado de una tarea y filas que representan diferentes tipos de actividades. Cada 
tablero de Kanban tiene al menos tres columnas con estados base: 

● «To Do» / Por hacer (punto de entrada de una tarea) 

● «W.I.P» / Trabajo en proceso 
● «Done» (Terminado) 

14 
 

Si bien soy partidario de tener este artefacto de manera física para fomentar la 
comunicación cara a cara, hoy en día, existen soluciones de tableros Kanban 
digitales como Trello muy buenas en especial para equipos remotos. 

A este tablero se le pueden agregar más columnas como por ejemplo «QA» (En 
etapa de pruebas) 

¿Quién es el responsable del SPRINT BACKLOG? 

El Sprint Backlog pertenece únicamente al Equipo de Desarrollo. El equipo de 
desarrollo modifica este artefacto durante todo el Sprint. Este surgimiento ocurre 
cuando el Equipo de Desarrollo trabaja a través del plan y aprende más sobre el 
trabajo necesario para lograr el Sprint Goal. 

Cuando los elementos del plan se consideran innecesarios, se eliminan. Solo el 
Equipo de Desarrollo puede cambiar su Sprint Backlog durante un Sprint. 

La diferencia entre Product Backlog y SPRINT 

BACKLOG 
El Sprint Backlog se crea durante el evento de Sprint Planning. Se compone de los 
elementos seleccionados de la parte superior (lo más prioritario) del Product 
Backlog que se consideran necesarios a realizarse para cumplir el Objetivo del 
Sprint y que el Equipo de Desarrollo cree factible terminar según su velocidad y 
capacidad. 

Para determinar cuántos PBIs incluir en el Sprint Backlog nos basamos en la 
velocidad de los últimos Sprints del Equipo de Desarrollo. 

¿Asignar tareas? 
Los SPIs no se asignan o pre-asignan en Scrum. Hacer esto fomenta que el equipo 
disminuya su responsabilidad compartida sobre el Objetivo del Sprint, ya que cada 
persona se siente más responsable por cumplir sus SPIs asignados (tareas, etc) que 
en contribuir al cumplimiento del Objetivo del Sprint. 

Otra contra que he observado en pre-asignar tareas es que el equipo baja su nivel 
de auto-organización y comunicación para resolver problemas y crear un 
incremento de valor.   

15 
 

Incremento de Producto 
Definición del INCREMENTO DE PRODUCTO 
El Incremento de Producto («Increment» o «Product Increment» en inglés) es la 
suma de todos los ítems del Product Backlog (PBIs) completados durante un Sprint 
y el valor de los incrementos de todos los Sprints pasados. Es uno de los 3 artefactos 
de Scrum y se presenta en cada Sprint Review. 

El Incremento y el EMPIRISMO 
Hay veces que puede ser complicado comprobar si el equipo ha creado valor en 
cada Sprint. No obstante, el Product Owner quiere asegurarse de que el producto 
aumente su valor en CADA Sprint. 

El Product Owner desea crear un producto valioso de la forma más adecuada. El 
mercado tiene distintas necesidades y siempre existe la posibilidad de un 
desequilibrio entre ellas y los objetivos del Product Owner. Por lo tanto, el Product 
Owner debe corroborar regularmente que las cosas que se desarrollaron estén en 
buen camino para crear el valor que imaginó. 

Haciendo uso de Scrum como marco de trabajo empírico, debemos buscar que 
nuestro Incremento nos permita obtener información nueva y relevante sobre el 
mercado y el contexto para poder adaptarnos rápidamente. Es por esto que 
debemos prestar atención al momento de inspeccionar este artefacto, qué 
hipótesis de negocio estamos validando y qué aprendimos del producto. 

Equipos multidisciplinarios y multifuncionales 

Las partes interesadas esperan que el Equipo de Desarrollo entregue algo concreto 
al finalizar cada Sprint, algo que les aporte valor a ellos. Un Equipo de Desarrollo de 
especialistas de varios silos organizativos, o incluso varios equipos de desarrollo que 
trabajan juntos, puede creer que tienen un producto real cuando estos 
especialistas completan su trabajo. Pero, debido a la falta de una perspectiva de 
equipo compartida, es posible que no hayan producido nada más que 
componentes aislados. Todo el producto es más valioso que la suma de estos 
componentes, y el valor real proviene de la integración de estos componentes en 

16 
 

un todo coherente. Es improbable que al mercado le importe cómo el equipo 

particionó el producto para su conveniencia de desarrollo. 

Para entregar el Incremento del producto, el Equipo de Desarrollo debe ser 

multifuncional, es decir, que cuente con todas las habilidades necesarias para 
entregar un incremento de valor al finalizar cada Sprint. 

Desde mi punto de vista creo que este es uno de los mayores desafíos que vengo 
observando en distintas organizaciones que intentan adoptar Scrum, dado que 
suelen existir incentivos hacia las personas y equipos en especializarse en un área o 
tecnología lo cual dificulta que un equipo solo pueda crear un Incremento de 
Producto completo. 

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana 

y continua de software con valor. - Principio del Manifiesto Ágil 

El incremento debe ser un paso hacia la visión del producto o algún objetivo que 
responde a esa visión. En este sentido es muy útil tener bien presente el Objetivo 
del Sprint a la hora de construir cada Incremento. 

Incremento TERMINADO 
Al final del Sprint, el nuevo Incremento debe estar Terminado, lo que significa que 
debe estar en condiciones de uso y cumplir con la «Definition of Done» del Equipo 
Scrum. El Incremento debe estar en condiciones de uso, independientemente de si 
el Product Owner decide liberarlo. 

   

17 
 

El Sprint 
¿Qué significa SPRINT en Scrum? 
El Sprint es uno de los cinco eventos de Scrum y es el que contiene a los otros 
cuatro (Planning, Daily, Review y Retrospectiva). Durante este evento se construye 
un Incremento de Producto que es potencialmente entregable a los interesados 
finales. Según la guía Scrum, es el corazón del marco Scrum. 

¿Cuál es la DURACIÓN? 
Los Sprints tienen una duración de tiempo de máximo un mes calendario. 
Debemos considerar lograr un equilibrio entre lo suficientemente largo como para 
poder producir un Incremento de Producto de valor y lo más corto posible como 
para que el equipo Scrum obtenga feedback rápidamente. 

Restricciones de este evento 

El Sprint tiene un intervalo fijo. No se realizan cambios que pongan en peligro el 
Objetivo del Sprint. Al igual que los proyectos, cada Sprint tiene un objetivo 
determinado y un plan flexible que guiará al Equipo de Desarrollo a crear el 
Incremento. 

¿Quién puede cancelar un Sprint? 

El único que puede cancelarlo es el Product Owner. 

¿Cuándo se puede cancelar un Sprint? 

Debe cancelarse únicamente cuando las circunstancias hagan que ya no tenga 
sentido seguir y por ende el Objetivo del Sprint carezca de sentido. Algunas de 
estas situaciones podrían ser: 

● Requerimientos emergentes o cambios bruscos en el mercado. 

● Problemas técnicos. 
● Pérdida de personas o capacidades críticas. 

Las cancelaciones de los Sprints son muy poco frecuentes.   

18 
 

Sprint Planning 
Definición de Sprint Planning en Scrum 
El SPRINT PLANNING (o planificación del Sprint) es uno de los cinco eventos de 
Scrum y es el primero que haremos al comenzar cada Sprint. 

En esta reunión vamos a planificar QUÉ es lo que vamos a hacer durante el Sprint y 
CÓMO lo vamos a hacer. 

¿Cuál es la duración del Sprint Planning? 

El Sprint Planning tiene un timebox de hasta ocho horas para un Sprint de un mes. 
Si tenemos Sprints más acotados, la duración de esta ceremonia será 
adecuadamente más corta. 

¿Cuál es el OBJETIVO del Sprint Planning? 

El objetivo es crear un Sprint Goal y un Sprint Backlog que incluye todos los 
elementos del Product Backlog requeridos para alcanzar el Sprint Goal acordado 
por todo el Equipo Scrum. 

¿Cómo medimos el éxito de este evento? 

Al finalizar este evento, el Equipo de Desarrollo debe ser capaz de exponer cómo 
piensan alcanzar el Objetivo del Sprint. Si lo pueden expresar con claridad, 
tendremos una buena señal de que han debatido con cierta profundidad todos los 
ítems seleccionados y lo comprenden. Esto amplía la probabilidad que tienen de 
cumplir con sus estimaciones. 

¿Quiénes participan en el Sprint Planning? 

Durante la planificación interviene todo el Equipo Scrum, es decir, el Product 
Owner, el Scrum Master y el Equipo de Desarrollo. 

El Scrum Master se debe asegurar de que este evento ocurra y se cumpla su 
objetivo. También actuará como facilitador para evitar salirse del timebox asignado, 
o evitar que ciertas personas acaparen todas las conversaciones y decisiones. 

19 
 

¿Cuáles son las 2 etapas del Sprint Planning? 

La estructura de la reunión está dividida de manera tal que conteste los siguientes 
dos interrogantes: 

1. ¿​QUÉ​ podemos entregar para lograr un nuevo Incremento de Producto 

durante este Sprint? 
2. ¿​CÓMO​ lo vamos a conseguir? 

Sprint Planning 1 

El primer asunto: ¿QUÉ PODEMOS HACER en esta iteración? 

Para responder a ello, todo el Equipo Scrum analizará el Product Backlog, la 
performance o velocidad del Equipo de Desarrollo de los últimos Sprints y la 
capacidad proyectada para este Sprint. 

La cantidad de ítems del Product Backlog a tomar depende solamente del Equipo 
de Desarrollo. 

Durante esta reunión el Product Owner debate con todo el equipo cuál es el 
Objetivo del Sprint a alcanzar. Explica y se asegura de su correcto entendimiento, 
de todos los detalles de los ítems del Product Backlog que deberían completarse 
para cumplir dicho objetivo. 

Establecer el Sprint Goal 

Luego de esta conversación y el análisis que han hecho, el Equipo Scrum 

COMPLETO acuerda un Objetivo de Sprint. Este objetivo servirá como norte para el 
Equipo de Desarrollo, marcando el propósito de todo lo que estarán construyendo y 
estará visible durante todo el Sprint. 

¿Qué es exactamente el Sprint Goal? 

El Sprint Goal (u Objetivo del Sprint) es una meta establecida para el Sprint por 
todo el Equipo Scrum que puede cumplirse a través de la implementación de PBIs 
(ítems del Product Backlog). Brinda una referencia para el Equipo de Desarrollo 
sobre el propósito de por qué crean el incremento que crean. También ayuda a 
aumentar la unión del equipo y fomenta la colaboración de sus miembros a través 
de trabajar enfocados y no en propuestas o proyectos separados. 

20 
 

Sprint Planning 2 

El segundo asunto: ¿CÓMO LO VAMOS A CONSEGUIR? 

Una vez que se ha establecido el objetivo y seleccionado los PBIs para el Sprint, el 
Equipo de Desarrollo se reúne para decidir y planificar cómo construirán estas 
funcionalidades para llegar a un Incremento de Producto terminado durante el 
Sprint. 

El secreto para salir adelante es comenzar. El secreto para comenzar es dividir 

tus complejas tareas abrumadoras en pequeñas tareas manejables, y luego 
empezar con la primera. - Mark Twain 

Dividir en tareas 

Para construir este plan, el Equipo de Desarrollo toma los PBIs seleccionados y los 
empieza a descomponer en partes más pequeñas a las que llamaremos tareas. Las 
tareas son todas las actividades técnicas que tienen que completarse para que un 
PBI cumpla con el Definition of Done (DoD). Al dividir los ítems en tareas se 
recomienda considerar que una tarea debe poder completarse en un día de 
trabajo. 

Si al momento de dividir los PBIs en tareas, el Equipo de Desarrollo encuentra que 

no es posible terminarlos durante el Sprint, pueden llamar al Product Owner para 
re-negociar el alcance. 

De la misma manera, si lo consideran necesario, pueden llamar a consultores 

técnicos o personas con mucho conocimiento en un dominio específico para que 
los ayuden a clarificar ciertos temas y poder establecer un mejor plan. 

Al conjunto de PBIs seleccionados para el Sprint y todas las tareas que los 
componen se lo denomina Sprint Backlog. 

Cabe destacar que durante esta etapa no es necesario tener planificado hasta el 
último detalle, ya que durante el Sprint probablemente el contexto haga que las 
cosas vayan cambiando y será tiempo desperdiciado. Lo que buscamos más bien es 
tener listo el plan para los primeros días del Sprint y tener una noción de si vamos a 
llegar a completarlo.   

21 
 

Daily Scrum 
Definición del DAILY SCRUM 
El Daily Scrum (o Scrum diario) es uno de los 5 eventos de Scrum con un bloque de 
tiempo de 15 minutos para que el Equipo de Desarrollo se sincronice. Esta reunión 
diaria se realiza a la misma hora y en el mismo lugar para reducir la complejidad. 
Aquí se busca la transparencia y la inspección de lo realizado para tener una 
oportunidad de adaptación para el día siguiente. 

¿Cuál es el OBJETIVO de la DAILY SCRUM? 

El objetivo de la Daily Scrum es lograr que el Equipo de Desarrollo se sincronice. 
Para ello se planea el trabajo de las siguientes 24 horas. 

Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo 

avanzado desde el último Daily Scrum Meeting y haciendo una proyección del 
trabajo restante del Sprint. 

El Equipo de Desarrollo usa el Daily Scrum para evaluar su progreso hacia el Sprint 
Goal y para evaluar qué tendencia sigue este progreso hacia la finalización del 
trabajo del Sprint en curso. 

¿Quién debe asistir al Daily Scrum? 

La Daily Scrum es una ceremonia interna del Equipo de Desarrollo. Si otras 
personas están presentes, el Scrum Master se asegura de que no interrumpan la 
reunión. 

Las personas ajenas al Equipo de Desarrollo pueden asistir a esta reunión diaria de 
sincronización por invitación del Equipo de Desarrollo . El Equipo de Desarrollo 
puede desear considerar que hay un espíritu de transparencia en Scrum. Pero, por 
otro lado, los extraños pueden influir en la reunión por su propia presencia. En 
cualquier caso, solo el Equipo de Desarrollo participa activamente en la reunión. 
Esto se aplica tanto al Product Owner como a cualquier otra persona que no sea 
miembro del Equipo de Desarrollo. 

22 
 

Daily Scrum 3 preguntas 

Una técnica popular es que cada persona del Equipo de Desarrollo conteste las 
siguientes 3 preguntas en 2 a 3 minutos por integrante, a modo de agenda para 
optimizar la eficiencia del tiempo: 

● ¿Qué hice ayer para ayudar a lograr el Sprint Goal (Objetivo del Sprint)? 
● ¿Qué voy a hacer hoy para ayudar a lograr el Sprint Goal? 
● ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo 
logremos el Sprint Goal? 

Cabe destacar que esas 3 preguntas son solo un ejemplo de cómo llevar a cabo 
este evento. El Equipo de Desarrollo es el encargado de establecer la estructura de 
la reunión y esta se puede conducir de diferentes maneras siempre y cuando se 
enfoque en el progreso hacia el Sprint Goal. 

El rol del Scrum Master en la Daily Scrum 

El Scrum Master como facilitador se asegura de que el Equipo de Desarrollo tenga 
el evento pero es el Equipo de Desarrollo el responsable de dirigir el Daily Scrum. El 
Scrum Master enseña al Equipo de Desarrollo a mantener el Daily Scrum meeting 
en los límites del bloque de tiempo de 15 minutos. 

BENEFICIOS de la Daily Scrum 

El Scrum Daily meeting optimiza las posibilidades de que el Equipo de Desarrollo 
cumpla con el Sprint Goal. 

Reduce el tiempo perdido porque el equipo hace que los impedimentos sean 
visibles diariamente. 

Ayuda a encontrar oportunidades de coordinación porque todos saben en qué 

están trabajando los demás. 

Promueve el intercambio de conocimientos y la identificación de lagunas de 

conocimiento. 

Fortalece la cultura del Equipo de Desarrollo a través de rituales compartidos y la 

participación activa. 

Ayuda a aumentar la productividad del equipo ganando eficiencia en el proceso.   

23 
 

Sprint Review 
Definición y OBJETIVO del SPRINT REVIEW 
El SPRINT REVIEW (o Revisión del Sprint) es uno de los cinco eventos de Scrum y se 
realiza al final del Sprint. Durante esta ceremonia se revisa el Incremento de 
Producto, es decir, lo que se realizó durante el Sprint y se analizan los cambios que 
tuvo el Product Backlog. 

El principal objetivo es obtener feedback de los Stakeholders para inspeccionar y 

evaluar el producto a fin de ajustar el Product Backlog. 

¿Cuál es la DURACIÓN del Sprint Review? 

El SPRINT REVIEW tiene un timebox de HASTA cuatro horas para un Sprint de un 
mes. 

Si tenemos Sprints más cortos, la duración de esta ceremonia será adecuadamente 

más corta. 

¿Quiénes participan en el Sprint Review? 

A lo largo de la REVISIÓN DEL SPRINT participa todo el Equipo Scrum, es decir, el 
Product Owner, el Scrum Master y el Equipo de Desarrollo y los Stakeholders (los 
interesados clave invitados por el Product Owner). 

El Scrum Master garantiza que el evento se realice y que los participantes 

comprendan su finalidad. También ejercerá su rol como facilitador, ayudando a 
mantener el evento dentro del bloque de tiempo. 

Actividades típicas de este evento 

El Product Owner expone los elementos del Product Backlog que se han 
“Terminado” (pasaron el DoD) y los que no. 

El Equipo de Desarrollo realiza una exposición del Incremento de Producto, 

comenta qué problemas surgieron y de qué manera los afrontaron. 

24 
 

El Product Owner habla acerca del Product Backlog en su estado actual y proyecta 
futuros objetivos y fechas de entrega basadas en esta nueva información. 

TODOS los participantes debaten en base al análisis de cómo está el mercado y el 
uso potencial del producto, sobre qué hacer a continuación. De este modo la Sprint 
Review proporciona información de entrada valiosa para el próximo evento: la 
Sprint Planning. 

Se revisa el roadmap de producto, los cambios en el presupuesto y las capacidades 

de el/los equipo/s. 

Salida/output del evento 

El resultado de la Sprint Review es un Product Backlog revisado, que define los 
elementos del Product Backlog posibles para el siguiente Sprint. Eventualmente 
será necesario que el Product Backlog reciba un ajuste general para enfocarse en 
nuevas oportunidades.   

25 
 

Retrospectiva 
¿Qué es una retrospectiva? 
Una retrospectiva es una reunión en la cual reflexionamos sobre la manera en la 
que trabajamos en un periodo de tiempo. Es una oportunidad para capitalizar 
aprendizajes y definir acciones de mejora a futuro. 

Una reunión especial donde el equipo participa después de completar un 

incremento de trabajo para inspeccionar y adaptar sus métodos y trabajo en 
equipo. Las retrospectivas permiten el aprendizaje de todo el equipo, actúan 
catalizadores para el cambio y generan acción. - Agile Retrospectives, Making 
Good Teams Great (2006) 

Entonces en una retrospectiva vamos a tener: reflexión, inspección, aprendizaje y 

de plan acción. 

Retrospectiva en Scrum 
En Scrum la retrospectiva tiene lugar al final del Sprint, después de la Revisión de 
Sprint y antes de la siguiente Planificación de Sprint. Se trata de una reunión de, 
como máximo, tres horas para Sprints de un mes. En la práctica si trabajamos con 
Sprints de 2 semanas, la duración será a lo sumo de 1 hora y media. 

¿Cuál es el objetivo de la retrospectiva en Scrum?.  

Según la Guía Scrum Oficial (2017) el propósito de la Retrospectiva de Sprint es: 

● 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; y, 
● Crear un plan para implementar las mejoras a la forma en la que el Equipo 
Scrum desempeña su trabajo. 

26 
 

¿Quiénes participan? 
Participa el equipo Scrum completo. En cuanto a personas externas generalmente 
no es conveniente que participen, ya sea personas de otros equipos, líderes, 
gerentes, etc. ya que puede afectar el espacio seguro que buscamos generar. 

Etapas de una retrospectiva 

1) Preparar el escenario: revisamos el objetivo de la reunión y cómo está cada 
persona para comenzar con la retrospectiva. Conocer cómo llega cada uno nos va a 
dar mucha información para entender cómo se desenvuelve luego en la reunión. El 
estado de ánimo y la forma en que llegan las personas nos va a dar un indicio de 
qué tipo de retrospectiva va a necesitar el equipo en ese momento. 

2) Recolectar Datos: recopilamos toda la información significativa del Sprint y la 

compartimos entre todos. Es importante en esta etapa destacar hitos o eventos 
importantes del Sprint (Ej: fuerte discusión entre 2 personas, error en un servidor 
productivo, migración a una nueva tecnología, etc.). El objetivo es lograr una visión 
compartida. 

3) Generar descubrimientos («insights»): buscamos lograr un entendimiento del por 

qué de cada evento significativo sucedido en el Sprint, reflexionamos sobre la 
causa raíz de los mismos previo a pensar una solución. En esta etapa es donde más 
vemos el rol de coach del Scrum Master (descripto debajo), mediante la indagación 
buscará generar puntos de vista diferentes a los que tenía el equipo hasta ese 
momento. 

4) Decidir qué hacer: vamos a tener una lista de temas, problemáticas y 

experimentos potenciales. Es el momento de decidir qué hacer con eso. Nos 
tenemos que enfocar en los ítems que creemos más prioritarios y en base a eso 
definir accionables que podamos ejecutar en el próximo Sprint. La idea es no 
enfocarse en más de 2 o 3 items como mucho, los equipos que definen muchos 
accionables rara vez los realizan. Algo útil en esta etapa es sumar esos accionables 
como ítems del Product Backlog para tomarlos el próximo Sprint. También suma 
acordar quién o quienes se llevan cada tema. 

5) Cerrar la retrospectiva: Repasamos lo que fue la retrospectiva, revisamos 

accionables y aprendizajes, conversamos cómo podemos mejorar las próximas 
retrospectivas. 

27