SCRUM

Tabla de contenidos

 Definición de Scrum
 Scrum: gestión eficaz de desarrollo de producto
 Los valores de Scrum
o Transparencia
o Inspección
o Adaptación
 Scrum basado en el trabajo en equipo
 El equipo Scrum
o Product Owner
o Scrum Master
o Equipo de Desarrollo
o Stakeholders
 Eventos en Scrum
o Sprint Planning o Planificación del Scrum
o Sprint o Iteración
o Daily Scrum Meeting
o Sprint Review o Revisión del Sprint
o Sprint Retrospective
 Los Artefactos en Scrum (Scrum Artifacts)
o Pila del Producto (Product Backlog)
o Pila del Sprint (Sprint Backlog)
o Incremento (Increment)

Definición de Scrum

Scrum es un marco de trabajo o proceso en el que se aplican un conjunto

de buenas prácticas para facilitar el trabajo colaborativo entre equipos
ágiles y así obtener los mejores resultados en el desarrollo de productos
añadiéndoles un incremento de valor en cada entrega. Esta agilidad permite
el lanzamiento al mercado del producto o servicio rápidamente y empezar a
obtener ventas y beneficios.

Scrum es un marco de trabajo o framework mayormente usado por los

equipos de desarrollo, aunque su filosofía y buenas prácticas pueden
aplicarse a cualquier otro departamento que necesite un trabajo en equipo.

El objetivo de scrum es maximizar el retorno de la inversión para la

empresa (ROI).
DoneTonic es un software Scrum pensado para que los equipos ágiles
consigan aportar este incremento de valor en las entregas gracias a facilitar
la colaboración entre los miembros de los equipos ágiles y la comunicación
entre todos los miembros del equipo Scrum.

Scrum: gestión eficaz de desarrollo de producto

Dentro del marco de trabajo Scrum se implementan Sprints en los cuales

cada aspecto del proyecto se planifica previamente. Una vez que una parte
del proyecto se completa, se lleva a cabo una revisión del trabajo
previamente validado. Este análisis permite al equipo identificar posibles
problemas, determinar los recursos necesarios y, con estos datos, planificar
de manera eficiente los próximos Sprints. De esta forma, Scrum facilita la
mejora continua y la optimización del proceso de desarrollo en cada
iteración.

Scrum hace visible la eficacia relativa de la gestión actual, el entorno y las

reglas de trabajo de modo que se puedan realizar mejoras. El framework
Scrum es capaz de detectar cuando un cliente no recibe lo pactado,
cuando las entregas de cada Sprint se alargan en el tiempo, si los costes se
disparan, y todo tipo de ineficacias que ralenticen la entrega y calidad del
producto.

Con Scrum es posible controlar y poner remedio a posibles desviaciones

que se produzcan durante el desarrollo de un proyecto.

Los valores de Scrum

Son 3 los elementos que no se pueden dejar de lado cuando se trabaja con
metodología Scrum:

Transparencia

El proceso y el trabajo deben ser visibles tanto para el equipo que

desarrolla el proyecto como para quienes lo van a recibir.

Así se consigue que haya un entendimiento común y una visión global.

Inspección
El progreso del proyecto debe inspeccionarse con frecuencia y con
diligencia para detectar los problemas potencialmente indeseables.

La inspección permite la adaptación.

Adaptación

Cuando surge un cambio en el desarrollo del proyecto, el equipo debe

adaptarse para conseguir el objetivo del Sprint.

Gracias a esta adaptación se consigue el éxito de proyectos complejos ya

que es en estos donde se producen requisitos más cambiantes.

Scrum basado en el trabajo en equipo

Scrum se basa en la inteligencia colectiva de las personas que lo utilizan:

en lugar de proporcionar a las personas instrucciones detalladas, las
buenas prácticas de Scrum guían sus relaciones e interacciones,
consiguiendo así un trabajo colaborativo del equipo para conseguir el mejor
resultado posible de proyectos.

Esta metodología reconoce y tiene en cuenta que el equipo no lo sabe todo

al inicio del proyecto y que este evolucionará a través de la experiencia.
Scrum está pensado para ayudar a los equipos a adaptarse de forma
natural a las condiciones cambiantes y a los nuevos requisitos de los
clientes.

Tiene presentes aspectos como:

 Adaptación de cambios y de nuevos requisitos durante el desarrollo

de un proyecto
 La colaboración con el cliente
 Continuo desarrollo adaptándose a los nuevos requisitos y
solucionando posibles inconvenientes aparecidos durante la
continuidad del proyecto

El equipo Scrum

Los Equipos de Scrum son multifuncionales: cada uno es responsable de

sus tareas y de cumplir con sus plazos de tiempo, de esta manera, el
proyecto se desarrolla exitosamente sin la supervisión de otros miembros
de la organización.

Scrum define 3 roles muy significativos dentro de su metodología.

Product Owner

Es el propietario del producto y es el responsable de maximizar el valor del

producto desarrollado por el equipo de desarrollo y es, a la vez, el
representante del cliente dentro de este equipo multi-disciplinar. Cada
equipo Scrum cuenta únicamente con un único Product Owner quien a su
vez, puede ser parte del equipo de desarrollo.
El Product Owner es el responsable final de la gestión de la cartera de
productos o Product Backlog y con DoneTonic, su gestión es muy sencilla.
Dentro del software existen múltiples funcionalidades pensadas para hacer
más fácil la priorización de los PBI o Historias de Usuario.

Conoce aquí las funcionalidades incluídas en el Product Backlog de

DoneTonic.

Scrum Master

Es el encargado de supervisar que las técnicas Scrum son entendidas y

aplicadas en la empresa.

No se debe confundir con el Product Owner, ya que este tiene una

perspectiva más de negocio mientras que el Scrum Master tiene como
función encargarse que todo el equipo entienda qué es Scrum y lo aplique
de manera correcta.

Equipo de Desarrollo

El Equipo de Desarrollo o Development Team es un equipo multifuncional

auto-organizado y es el encargado de definir las tareas.

El Equipo de Desarrollo se compone de profesionales que realizan el

trabajo de entregar un Incremento de producto «Terminado» (Done). Sólo
los miembros del Equipo de Desarrollo participan en la creación del
Incremento.

Es el personal indispensable para que salga un producto, sin ellos, poco

importa contar con los mejores Product Owner o Scrum Master ya que es el
equipo quien desarrollará, en última instancia, el producto.

Stakeholders

Se conoce como Stakeholders a aquel grupo de personas que influyen en

la empresa, podrían ser: los empleados, los proveedores o los accionistas.
Una traducción al español podría ser «partes interesadas».

Los Stakeholders son ese grupo de personas afectadas por las decisiones
que se toman en una empresa. No podrían considerarse como un rol propio
dentro de la metodología Scrum, pero sí tienen ofrecen un feedback
continuo de los productos de la empresa, por eso se les permite participar
en el Sprint Review.

Una de las funciones del Product Owner es canalizar los deseos y

necesidades de los Stakeholders a través del Product Backlog.

Eventos en Scrum

Los eventos en Scrum son eventos o reuniones específicas en los que

participa el equipo Scrum y tienen como objetivo facilitar la planificación, el
seguimiento y la adaptación del equipo durante el desarrollo del proyecto.
Están diseñados para fomentar la colaboración y la transparencia.
Los cinco eventos Scrum son los siguientes:

Sprint Planning o Planificación del Scrum

Es el evento que inicia cada Sprint y el objetivo es decidir qué se va a

desarrollar durante el sprint y cómo se llevará a cabo. Participa todo el
equipo Scrum.

El equipo selecciona los elementos del Product Backlog, llamados PBI o

Historias de Usuario, que se compromete a completar durante el Sprint y
crea el Sprint Goal u objetivo del Sprint.

Se deberán plantear las siguientes cuestiones:

 ¿Qué aporta este Sprint? El Product Owner propone como el

producto puede incrementar su valor y su objetivo se debe definir
antes de que finalice la planificación del Sprint. En base a este
objetivo, se definirán unas tareas u otras que se añadirán a los PBI
seleccionados.
 ¿Cómo se va a abordar? El equipo de desarrollo definirá las tareas
añadidas en una lista de producto que se van a necesitar para
completar el objetivo del Sprint.
 ¿Cómo se realizará? Para cada tarea de esa lista de producto el
equipo de desarrollo planificará el trabajo necesario.

Sprint o Iteración

Normalmente son eventos que tiene una duración de unas dos semanas,
algunas veces hasta cuatro, de esta manera el proyecto no pierde
coherencia ni se disipa en el tiempo, ya que los Sprints largos pueden hacer
que se pierda feedback con el cliente.

Durante este tiempo, el equipo lleva a cabo el desarrollo, las pruebas y

cualquier otra actividad necesaria para alcanzar el Sprint Goal, debe
cumplir con las tareas que se han ido añadiendo en los PBI del Sprint
Planning para alcanzar los objetivos.

Daily Scrum Meeting

El Daily Scrum Meeting se realiza diariamente, es una reunión de unos 15

min de duración en la que participa el Equipo de Desarrollo y el Scrum
Master y se aconseja que se realice siempre a la misma hora y en el mismo
lugar para reducir complejidad.

Estas reuniones tienen como objetivo mejorar las comunicaciones,

identificar inconvenientes e impedimentos y promueven las decisiones
rápidas. Se aprovechan para conseguir la adaptación de las tareas en caso
de que haya cambios dentro del Sprint.

Sprint Review o Revisión del Sprint

El Sprint Review se realiza al finalizar cada Sprint y sirve para mostrarle al

cliente el resultado de los trabajos desarrollados en el Sprint.
Asisten tanto el Product Owner como el cliente y el equipo de desarrollo
y se revisan los elementos terminados y se obtiene retroalimentación para
futuras mejoras.

Sprint Retrospective

Después de la Sprint Review, el equipo se reúne para analizar el Sprint

recién finalizado. En la retrospectiva, se identifican y discuten qué salió
bien, qué se puede mejorar y se planifican acciones para el siguiente Sprint.

En el siguiente artículo te explicamos la diferencia entre Sprint Review y

Sprint Retrospective.

Los Artefactos en Scrum (Scrum Artifacts)

Los artefactos de Scrum están pensados para maximizar la transparencia

de la información para que todos los miembros del equipo Scrum tengan el
mismo entendimiento del artefacto.

Pila del Producto (Product Backlog)

El Product Backlog o Pila del Producto consiste en una lista ordenada de

todo lo necesario en el producto, a su vez, es la única fuente de requisitos
para cualquier cambio que deba realizarse en el producto.

Esta Pila nunca está completa, es dinámica y evoluciona a medida que el

producto y su entorno lo hacen siempre para identificar lo que el producto
necesita para ser adecuado, competitivo y útil. Mientras el producto
exista, el Product Backlog siempre existirá.

Los atributos del Product Backlog son: la descripción, el orden, la

estimación y el valor.

Pila del Sprint (Sprint Backlog)

El Sprint Backlog o Pila del Sprint es el conjunto de elementos del Product

Backlog seleccionados para el Sprint.

Hace visible todo el trabajo que el Equipo de Desarrollo identifica como

necesario para alcanzar el Sprint Goal (Objetivo del Sprint).

Cuando se requiere un nuevo trabajo, el Equipo de Desarrollo lo añade

al Sprint Backlog y a medida que el trabajo se ejecuta se va actualizando
la estimación de trabajo restante.

Incremento (Increment)

Finalmente, el Incremento o Increment es la suma de todos los elementos

del Product Backlog que se han completado durante un Sprint más el valor
de los incrementos de todos los Sprints anteriores.

Cuando acaba un Sprint el nuevo Incremento debe estar «Terminado»

según la Definición del Equipo Scrum de «Terminado».
Puedes saber más sobre Scrum en [Link]

DIFERENCIAS ENTRE SCRUM Y KANBAN

Tabla de contenidos
¿Qué es Kanban?
 ¿Qué es Scrum?
 10 diferencias entre Scrum y Kanban
 ¿Scrum o Kanban? ¿Cuál usar?

¿Conoces las diferencias ente Scrum y Kanban? ¿Sabrías detectar qué

metodología necesitas en implementar en tu empresa?

En el siguiente artículo se van a presentar las diferencias entre Scrum y

Kanban, pero antes, es necesario conocer ambas y así entender que no
son excluyentes entre ellas.

¿Qué es Kanban?

El método Kanban forma parte de las conocidas como metodologías

ágiles y tiene como objetivo gestionar de manera general cómo se van
completando las tareas.

Tiene su origen en la empresa Toyota, en Japón, donde se aplicaba a los

procesos de fabricación de los coches de la marca, y con el tiempo se
convirtió en un método utilizado por los desarrolladores de software.

Básicamente consiste en representar, en un tablero de Kanban, los

elementos de trabajo lo que permite a los miembros del equipo ver el
estado de la tarea de cada uno de ellos.

Dicho de otra manera, Kanban es un método visual utilizado para controlar

las tareas de los desarrolladores a través de su división por fases, hasta su
finalización.

¿Qué es Scrum?

Scrum es una metodología de trabajo, o framework usada por los equipos

de desarrollo de software.

Se trabaja basándose en una serie de sprints en los que se define que

tareas se deben realizar por parte de los miembros de un equipo de trabajo
durante un tiempo determinado, no recomendable más largo de 4 semanas.
En el artículo «Qué es Scrum » desarrollamos este concepto de manera
mucho más amplia.

Estas dos definiciones nos llevan a, de momento, una primera conclusión:

La metodología Kanban y la metodología Scrum no son lo mismo, pero,
ahora veremos, como tampoco son excluyentes entre ellas.

10 diferencias entre Scrum y Kanban

Ahora que ya conocemos los dos conceptos, vamos a cuáles son las
diferencias entre Scrum y Kanban.

1. Scrum es un marco de trabajo o framework pensado para maximizar

el valor entregado en el desarrollo de un producto complejo. En
cambio, Kanban está diseñado para optimizar el flujo de trabajo.
2. En Scrum existen los roles, como Scrum Master , Product Owner,
mientras que en Kanban no existe ningún tipo de rol.
3. En Scrum se trabaja en base a un sprint, una interacción de tiempo,
mientras que en Kanban hay un trabajo continuo.
4. En la metodología Scrum no se presentan cambios en el proyecto
durante el desarrollo del sprint, al contrario, en Kanban se pueden
producir cambios en cualquier momento.
5. En Scrum se necesita un Sprint backlog que priorice las tareas a
llevar a cabo en cada sprint por parte del Product Owner , mientras
que en Kanban las tareas las indica directamente el cliente, con lo
cual no hay ninguna priorización.
6. En la metodología Scrum, los sprint tienen que tener una lista de
tareas a realizar en ese período de tiempo, en cambio en Kanban, el
ritmo de trabajo es continuo y cada nueva petición del cliente será
una nueva tarjeta en el tablero.
7. Los tableros también presentan diferencias: en Scrum, se crea un
tablero nuevo para cada sprint, mientras que en Kanban, estos
tableros no tienen fecha de inicio ni de fin.
8. Además, en los tableros Scrum se realiza un seguimiento del trabajo
a medida que se avanza por las diferentes etapas, en cambio en
el tablero Kanban, las columnas se pueden organizar de diferentes
maneras. Las columnas del tablero Scrum indican que tarea se
realiza en cada momento, que se ha realizado y que está pendiente
mientras que las columnas del tablero Kanban no tienen porque
representar el estado del trabajo, tan sólo el trabajo en sí.
9. Al trabajar con la metodología Scrum, se debe realizar una reunión
diaria, el Daily Sprint para conocer diariamente el estado del
desarrollo y tener una visión global de las tareas acabadas y
pendientes de todo el equipo de desarrollo, en cambio,
en Kanban no existen esas reuniones.
[Link] equipos de trabajo también pueden ser diferentes: en Scrum se
exige equipos multidisciplinares, mientras que en Kanban los equipos
pueden estar formados por especialistas.

¿Scrum o Kanban? ¿Cuál usar?

Cómo se ha visto hasta ahora, sí que existen diferencias entre Scrum y

Kanban, aunque no son muy significativas, el objetivo de ambas es
conseguir un desarrollo eficaz del producto. No tienen porqué ser
metodologías excluyentes, así, si un equipo se siente cómodo con la
metodología Scrum, se puede usar un tablero Kanban para mantener al
equipo organizado.

Lo destacable es tener un marco y una herramienta que sirva para el

desarrollo, e independientemente la metodología que se use, contar con un
sistema de gestión flexible.

Kanban, la herramienta más eficaz de organización

japonesa para las empresas

¿Sabes cómo organizar un equipo de trabajo? ¿Realizas a tiempo todas las

tareas importantes?

Dividir el trabajo y organizar los diferentes equipos humanos no es fá[Link]

planificamos acciones u organizamos tareas dentro de una empresa, no es lo
mismo “pensar en hacerlas” que “ejecutarlas”. Por eso uno de los mejores

métodos de organización, y que recomendamos en el master MBA de Málaga,

es el “tablero Kanban”.

Kanban (“panel” en japonés) es una herramienta muy visual de organización

capaz de conseguir mejorar el flujo de trabajo en equipo, dividiendo las tareas
en fases según se vayan alcanzando los objetivos deseados.

En una empresa, la disciplina, el orden y el rendimiento de todo el equipo, son

necesarios para completar la cadena de producción y poder así cumplir los
objetivos previstos.

Sin embargo, tener un control absoluto de todo el proceso y las tareas

realizadas por los empleados, supone un gran esfuerzo por parte de los
directivos y responsables de los proyectos.

A continuación explicamos qué es el método Kanban, cómo crear tu tablero

fácilmente y por qué deberías aplicarlo en tu empresa.

Índice de Contenido
 Filosofía Kanban. Progreso, evolución y resultados
o Crear un tablero Kanban
o Video recomendado sobre Kanban
Filosofía Kanban. Progreso, evolución y resultados

La metodología Kanban está diseñada para crear un sistema de producción

más eficiente en las empresas.

Muchos experto recomiendan este método para controlar cadenas de

producción, logística y proyectos donde se necesiten coordinar todos los
procesos de producción y desarrollo.

La filosofía Kanban se basa en 3 conceptos fundamentales: el progreso, la

evolución y los resultados eficientes.

Toyota, fue la primera empresa en aplicar con éxito éste sistema en la

fabricación de sus automóviles. Más tarde, Microsoft se hizo eco de sus
ventajas y lo incorporó de una forma más moderna al software.

Crear un tablero Kanban

El método Kanban es el método de organización visual más utilizado en las
empresas. Gracias a su diseño, serás capaz de ver en sólo un vistazo en qué
fase del proyecto te encuentras.

Consiste en dividir el proceso en diferentes fases de producción desde el

momento en que el comienza la acción hasta que se realiza o ejecuta. Así,
podemos dividir nuestro panel en:

1. Pendiente
2. Análisis
3. Desarrollo
4. Pruebas
5. Pre-producción
6. Producción
7. Hecho

El objetivo es que todas nuestras acciones evolucionen desde su fase

“Pendiente” hasta “Hecho” controlando todo el proceso sin que nos olvidemos
de las tareas más importantes o urgentes.

Una buena práctica (que ya ha comenzando a aplicarse en muchas empresas

malagueñas), es compartir una pizarra común por equipos donde incluir
pos-it de colores divididos en tareas organizadas.
Un método de trabajo muy funcional y directo donde además conseguirás
interactuar con el resto de compañeros que forman el equipo.

También existen plantillas en Excel que puedes utilizar para comenzar a

organizar y administrar todos los departamentos de una empresa. Puedes
personalizarla con los colores y tableros necesarios para llevar un control diario
de las tareas pendientes o realizadas por el equipo.

Por otro lado, disponer de tu tablero Kanban en cualquier lugar a través de tu

dispositivo móvil, será muy útil para todos aquellos managers que necesiten
viajar continuamente.

Por eso, están surgiendo plataformas online donde puedes diseñar tu tablero
Kanban, guardarlo en la nube y tenerlo a mano en cualquier momento, estés
donde estés, y sobre todo compartir el mismo documento con el resto del
equipo.

Las ventajas del sistema Kanban son innumerables. Conseguirás aumentar la

flexibilidad de los procesos, controlar las actividades del equipo humano,
priorizar las tareas importantes y sobre todo, evaluar los objetivos conseguidos.

¿Qué es el Sprint Planning?

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, los Developers (desarrolladores) deben 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 los Developers.
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.
El Product Owner se debe asegurar de que los asistentes estén
preparados para discutir los elementos más importantes del Product
Backlog y cómo se relacionan con el Objetivo del Producto.
Adicionalmente cualquier miembro del Equipo Scrum puede invitar a
otros asistentes para brindar asesoramiento.
¿Cuáles son las 3 partes del Sprint Planning?
La estructura de la reunión está dividida de manera tal que aborde los
siguientes temas:
 Tema 1: ¿Por qué es valioso este Sprint?
 Tema 2: ¿Qué se puede hacer en este este Sprint?
 Tema 3: ¿Cómo se realizará el trabajo elegido?

Tema 1
El primer tópico: ¿Por qué es valioso este Sprint?

El Product Owner propone cómo el producto podría Incrementar su

valor en el Sprint actual. Luego, todo el Equipo Scrum colabora para
definir el Objetivo del Sprint que comunica por qué el Sprint es valioso
para los stakeholders. El Objetivo del Sprint debe completarse antes
de que termine la Sprint Planning.
Establecer el Sprint Goal
Luego de las conversaciones y el análisis que han hecho, el Equipo
Scrum COMPLETO acuerda un Objetivo de Sprint. Este objetivo
servirá como norte para los Developers, 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 los Developers 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.
Ejemplos de Sprint Goals
Para bajar un poco a tierra, les comparto algunos posibles ejemplos
Sprint Goals:
 Reducir un 20% el tiempo de carga de la página del listado de
“Productos con Descuentos”
 Modificar la forma en que los usuarios se registren para subir la
tasa de conversión por lo menos en un 25%.
 Proveer un mecanismo para que los usuarios puedan dejar su
feedback en cada producto.
Tema 2
El segundo tópico: ¿Qué se puede hacer en este este
Sprint?
Una vez que se ha establecido el Objetivo de Sprint,
los Developers analizarán el Product Backlog, la performance o
velocidad de sus últimos Sprints y la capacidad proyectada para este
Sprint. En base a ello, seleccionarán la cantidad de ítems del Product
Backlog que consideren factible de completar.
Tema 3
El tercer tópico: ¿Cómo se realizará el trabajo elegido?
Una vez que se ha establecido el objetivo y seleccionado los PBIs para
el Sprint, los Developers se reúnen para decidir y
planificar cómo construirán cada elemento del Product Backlog para
llegar a un Incremento de Producto que cumpla con la Definición de
Terminado terminado.
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
Generalmente los Developers toman 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 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.

La forma de descomponer o dividir los PBIs queda a criterio exclusivo

de los Developers. Nadie más les dice cómo convertir los elementos
del Product Backlog en Incrementos de valor.

Si al momento de dividir los PBIs en tareas, los Developers 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.
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.

El objetivo del Sprint, más el conjunto de PBIs seleccionados para

el Sprint más el plan para completarlos denomina Sprint Backlog.
Objetivo de Sprint + PBIs seleccionados + Plan de ejecución =
Sprint Backlog.

RESUMEN GRÁFICO del SPRINT PLANNING:

Patrones y buenas prácticas

La importancia de un buen Sprint Goal
El equipo se compromete a una corta declaración donde se describe
el VALOR que pretenden entregar en el Sprint y esto se convierte en
el foco de todo el trabajo.

El objetivo de un Sprint es entregar VALOR a los stakeholders, pero es

necesario aclarar que seguir una lista de elementos del Sprint
Backlog (como por ejemplo las tareas que dividieron) no
necesariamente da como resultado la creación del MAYOR VALOR
POSIBLE.

Cuando el equipo divide los PBIs en tareas pequeñas e individuales

puede volverse sencillo comenzar a trabajar en ellas de manera
aislada durante el Sprint. Esto disminuye la innovación que deriva de
las distintas perspectivas que pueden aportar los miembros del
Equipo ante un tema y sus interacciones. El trabajo en equipo cae.

Si bien utilizamos el Objetivo del Sprint para encuadrar los PBIs que
seleccionamos, el Objetivo del Sprint es más importante incluso
que la suma de los PBIs individuales. El Sprint Goal crea una
conexión entre los PBIs, ayudando a crear un Incremento de Producto
de gran valor.
Técnicas para armar los Sprint Goals
Una manera de llegar a conseguirlo puede ser aplicar la técnica de los
cinco por qué. Esto se realiza a través de repetir la pregunta de “¿por
qué seleccionamos estos PBIs para este Sprint?” hasta encontrar un
hilo conductor entre todos los PBIs en lugar de tener un objetivo que
sea solamente: “terminar todos los PBIs seleccionados.

Otra orientación es construir nuestro Product Backlog como una lista

de Objetivos de Sprint, y luego todo el Equipo junto trabaja
regularmente en la fabricación de PBIs partiendo de dichos objetivos.
De esta manera, al llegar a una Sprint Planning, es muy fácil
identificar el Objetivo de Sprint asociado a cada PBI.
Buena visibilidad
El Objetivo del Sprint debe ser transparente para todos. Para
colaborar con esto es recomendable que éste se encuentre en un
lugar bien visible y que funcione como un radiador de información.

Al tenerlo bien visible los Developers puede recordarlo fácilmente en

todas sus Daily Scrum de manera que puedan sincronizarse teniendo
en cuenta el objetivo principal para el cual se están sincronizando.
Hacer el refinamiento
El refinamiento, también conocido como PRE PLANNING o Product
Backlog Refinement, ayuda a llegar al Sprint Planning con todos los
elementos del Product Backlog en buenas condiciones.

Tener estos elementos listos significa, por ejemplo, que tengan toda
la información necesaria para ser estimados, que no esten
bloqueados por otros elementos y que no tengan dependencias
externas.

Realizar el refinamiento mejora considerablemente la eficiencia

del Sprint Planning y reduce en gran medida el tiempo de la
reunión.
Prepararse para las interrupciones en el Sprint Planning
Prepararse para las interrupciones ayuda a los equipos a enfrentar
circunstancias imprevistas y les da la oportunidad de cambiar su plan
de trabajo todos los días durante la Daily Scrum sin perder horas
de re-planificación.
Un estudio de la Universidad Carnegie Mellon demuestra que:
 Los equipos que se preparan de antemano para las
interrupciones, las enfrentan un 14 por ciento mejor que los
equipos que no lo hacen.
 Los equipos que se preparan para las interrupciones completan
una tarea de interrupción en un 43 por ciento más rápido
que los que no se preparan.
Es parte de construir la cultura del equipo, el prepararse para cosas
no planificadas. De esta manera ante imprevistos, los equipos pueden
cambiar hacia nuevas formas de proceder para poder avanzar sin
ayuda externa.
Promover trabajar en una cosa a la vez
Uno de los creadores de Scrum añade que además de promover el
foco, el Sprint Goal impulsa el trabajo “Swarming” (o trabajo en
enjambre): ¿Podemos hacer que todos trabajen juntos en una
cosa?
Él relata:
En Silicon Valley en 2007, Palm estaba trabajando en un sistema
operativo web que luego fue adquirido por Hewlett-Packard. Sprint a
Sprint los equipos estaban bien hasta que en un momento parecía
que golpearon una pared luego de un par de Sprints. Los PBI no se
estaban terminando. Los developers se desmotivaron y se fueron a
casa temprano. Me trajeron y conseguí que los Product Owners y
Scrum Masters pasaran una hora entrevistando a los miembros del
equipo sobre por qué estaban desmotivados. Descubrimos que no
entendían la razón por la que estaban trabajando tan duro en
los PBIs de bajo nivel (tareas).

Pasamos una tarde limpiando el Product Backlog para muestre un

vínculo claro entre las Historias de alto nivel y la jerarquía de
descomposición. Tan pronto como los developers entendieron que el
Objetivo del Sprint era mejorar el rendimiento del sistema operativo
web en un 10%, se sintieron motivados para completar las historias
de bajo nivel y la velocidad volvió a la normalidad.

Comprender por qué se implementan los PBI es fundamental para los

developers, especialmente para los developers expertos que
preferirían ir a surfear si no ven la razón de su trabajo.
Jeff Sutherland

Tener un segundo objetivo

Usualmente el Sprint Goal tiene que ver con VALOR en cuanto al
producto. El equipo puede establecer opcionalmente objetivos de
Sprint en términos de objetivos de procesos. Por ejemplo, hacer
pair programming o ser puntuales con el horario de la Daily
Scrum todos los días.
El Sprint Planning ES ÁGIL
Como hemos mencionado, el Sprint Planning produce la versión inicial
del Sprint Backlog. Esto quiere decir que utilizamos este evento para
que los Developers pueda comenzar a trabajar con cierta claridad y
fluidez, pero para nada busca establecer un plan fijo e
inamovible.

Recordemos que Scrum está diseñado para trabajar en contextos

cambiantes, por lo que este plan se irá ajustando todos los días en
el Daily Scrum.
El Daily Scrum es esencialmente un evento de re-planificación.
Hacé la Planning, pero tirá los planes.