1 Gestión técnica de proyectos

Índice
1.1 Herramientas para optimizar la gestión de proyectos (software)
1.2 Gestión Ágil con SCRUM y Kanban
1.3 Gestión de multiproyectos
1.4 Design thinking
 Herramientas para optimizar la gestión de
1.1 proyectos (software)
Introducción a las metodologías ágiles
https://vimeo.com/323790959/dfea2f688f
Del desarrollo en cascada
al desarrollo ágil
Metodología predictiva:
el desarrollo en cascada.
Este método sigue fases estrictas que se adhieren
a un plan previamente diseñado con
requerimientos inamovibles al principio del
proyecto. Los directores de proyecto emplean
mucho tiempo negociando hitos, funcionalidades,
recursos, etc. trabajando con la duración de las
fases de planificación de un proyecto.
En este vídeo se
estudia el uso del
desarrollo en cascada
para empresas que
crean productos
innovadores (Startups).

https://youtu.be/jgsWdqMcMIo
Los clientes exponen todos sus requisitos antes de comenzar
el largo proceso de desarrollo incluido en el proyecto. El
director de proyecto traza todos los movimientos del proyecto
mediante la gestión de las entregas.
Si todo va bien, el proyecto produce un
lanzamiento en el tiempo y presupuesto
acordados.
No obstante, existen grandes inconvenientes asociados a la
gestión de proyectos utilizando metodologías predictivas:
No son capaces
de responder a
los cambios.
La entrega de un
producto funcional toma
mucho tiempo.
Teniendo en cuenta la naturaleza de la tecnología, es posible que un
lanzamiento de producto a seis meses vista, sobre requisitos fijos, no se
corresponda con las necesidades de los clientes.
Por lo tanto, fruto de la frustración de las
empresas de desarrollo de software con
estas metodologías fijas, surge la historia del
desarrollo ágil, que se diseña para acomodar
mejor los cambios y la necesidad de
desarrollar más rápido los productos.
Javier Garzás
explica el uso de
metodologías
ágiles en el
desarrollo de
software.

https://www.youtube.com/watch?v=L9qlrgKWqfI
 El director de proyecto trata de:
Facilitar el trabajo del equipo de desarrollo.

Eliminar los cuellos de botella.

Ayuda al equipo a mantenerse centrado en
entregar iteraciones con cierta regularidad.

Los proyectos de desarrollo ágil incluyen menos hitos, pero más

horas, selección de funcionalidades, priorización y reuniones.
Al contrario que en el modelo en cascada, el equipo de desarrollo decide en
última instancia, al principio de cada sprint o iteración, lo que se puede
conseguir en el tiempo asignado y produce una serie de funcionalidades,
entregando un producto que puede ser instalado en un ambiente de
producción al final de un sprint.
Dado que la mayoría de los métodos de desarrollo de software son flexibles, la
mayoría dan lugar a la gestión a medida, es decir, que los productos pueden
adaptar el flujo para alcanzar las necesidades del producto.
 En este artículo se describe como empresas tales como Honda, Canon y Fuji-Xerox
producen resultados de clase mundial usando un enfoque escalable basado en
equipos para llevar a cabo un desarrollo del producto “todo en uno”.
Además, resalta la importancia de equipos empoderados y
autoorganizados junto al rol del directivo, en el proceso de desarrollo. Si
bien el texto no acuña el término Scrum, sí junta la mayoría de los
conceptos que se recogen en esta metodología.

Haz clic aquí y podrás leer el artículo original (en inglés).

Aunque la mayoría de las veces se utiliza Scrum para desarrollar
productos de software, sus valores y principios pueden ser
utilizados para desarrollar diferentes productos o para organizar el
flujo de varios tipos de trabajo.
Introducción al Manifiesto Ágil
Dicho documento expone que estamos descubriendo
formas mejores de desarrollar software, tanto por nuestra
propia experiencia, como ayudando a terceros.
A través de este trabajo
hemos aprendido a valorar: Haz clic sobre la imagen para ir
Individuos e interacciones sobre procesos y al enlace del documento .
herramientas. http://agilemanifesto.org/iso/es/manifesto.html

Software funcionando sobre documentación extensiva.

Colaboración con el cliente sobre negociación
contractual.
Respuesta ante el cambio sobre seguir un
plan.
Esto es, aunque valoramos los elementos de
la derecha, valoramos más los de la
izquierda.“
Valores del Manifiesto Ágil
El Manifiesto Ágil está compuesto de cuatro valores
fundamentales y doce principios de soporte que guían
el enfoque ágil.
Cada una de las metodologías ágiles disponibles en el mercado aplican de
diferentes maneras los cuatro valores, pero todas ellas se apoyan en ellos
para guiar el desarrollo y entrega de software funcional de alta calidad.
 4
Vamos a
analizarlos
a fondo.
valores:
Individuos e interacciones sobre procesos y herramientas.
Software funcional sobre documentación extensiva.

Colaboración con el cliente sobre negociación contractual.

Respuesta ante el cambio sobre seguir un plan.
Valor 1
Individuos e interacciones
sobre procesos y herramientas.
Es un valor fácil de entender, ya que, obviamente, son
las personas las que entienden las necesidades del
negocio y dirigen el proceso de desarrollo.
Si el proceso o las herramientas guían el proceso de desarrollo,
el equipo es menos adaptable a cambios y menos proclive a
satisfacer las necesidades del cliente.

Vamos a comentar la comunicación como ejemplo.

Haz clic sobre el icono del altavoz.
Valor 2
Software funcional
sobre documentación extensiva.
El Agile no elimina la documentación, pero sí que la encarrila de
manera que le da al desarrollador lo que necesita para hacer el
trabajo sin atascarse en pequeños detalles.
El Agile documenta los requisitos como historias de
usuario, las cuales son suficientes para que el
desarrollador comience la tarea de elaborar una
nueva función.
Para el desarrollo ágil la documentación
es importante, pero lo es mucho más un
software funcional.
Valor 3
Colaboración con el cliente
sobre negociación contractual.
El manifiesto ágil incorpora al cliente como agente
implicado en el desarrollo y que colabora durante
este proceso, convirtiéndose casi en un
desarrollador más.
Esto hace mucho más fácil que el desarrollo acabe
satisfaciendo las necesidades del cliente. Los métodos ágiles
pueden incluir al cliente en demos periódicas, pero un proyecto
puede incluso incluir al cliente como parte del equipo asistiendo
a todas las reuniones. De esta manera se asegura que el
producto satisface de manera consistente las necesidades del
cliente.
Valor 4
Respuesta ante el cambio
sobre seguir un plan.
En el entorno ágil, la naturaleza corta de
una iteración significa que las prioridades
pueden cambiar entre iteraciones y
nuevas características que se puedan
añadir en la siguiente iteración. En este
sentido, la postura del enfoque ágil es que
los cambios siempre mejoran un proyecto
y añaden valor.
Los principios del desarrollo ágil
Describir una cultura en la cual el cambio es bienvenido y el cliente
es el centro de todo trabajo. Además, demuestra que la auténtica
intención del movimiento es llevar al desarrollo a alinearse con las
necesidades del negocio.
Los doce principios del Manifiesto Ágil incluyen:
01 Asegurar la satisfacción del cliente mediante la entrega
temprana y continua de software.
Los clientes están más contentos cuando reciben software que funciona en intervalos
regulares, en lugar de tener que esperar largos tramos entre lanzamientos.

02 Incluir los requisitos cambiantes a lo largo del proceso de desarrollo.

Es la capacidad de evitar retrasos en la entrega cuando un requisito o característica cambia.

03 Entregas frecuentes de software en funcionamiento.

El equipo trabaja con iteraciones sprint en software para asegurarse que

entrega regularmente software que funciona.
04 Un software funcionando es la métrica
fundamental del éxito.
Se toman las mejores decisiones cuando el negocio y el equipo
técnico están en sintonía.

05 Apoya, confía y motiva a las personas involucradas.

Los equipos motivados son más proclives a rendir al máximo que los
equipos desmotivados.

06 Habilita las interacciones cara a cara.

La comunicación es más exitosa cuando los equipos están en la misma sede física.
07 Colaboración entre los interesados y los desarrolladores a lo
largo del proyecto.
Entregar software funcional al cliente la mejor manera de medir el progreso.

08 Procesos ágiles para sustentar un ritmo de desarrollo

constante.
Los equipos establecen una velocidad repetible imposible de mantener, a la
cual pueden entregar software en funcionamiento y que pueden repetir con
cada lanzamiento.

09 La atención a los detalles técnicos y al diseño mejora la

agilidad.
Las habilidades adecuadas y el buen diseño aseguran que el equipo pueda
mantener el ritmo, pueda constantemente mejorar el producto y adaptar los
cambios necesarios.
10 Simplicidad.

Desarrolla solo lo suficiente para realizar el trabajo en cada momento.

11 Los equipos auto-organizados producen grandes

arquitecturas, requisitos y diseños.
Hablamos de equipos cuyos miembros están capacitados, motivados, son
capaces de tomar decisiones, se comunican regularmente con otros
miembros del equipo, comparten ideas y entregan productos de calidad.

12 Reflexionar habitualmente sobre cómo ser más efectivo.

La auto mejora, la mejora de procesos y la mejora de capacidades y técnicas

ayuda a los miembros del equipo a trabajar más eficientemente.
Scrum. Origen e introducción
https://vimeo.com/325660132/b1d312513b
Metodología SCRUM
Scrum es un enfoque ágil para
desarrollar productos y servicios
innovadores.
Pero no hablamos de una metodología cualquiera, ya que
supone una gran innovación con respecto a otras
metodologías de gestión de proyectos.
Funcionalidad
Funcionalidad
A B

El primer elemento será una lista

priorizada de las características y
Funcionalidad otras capacidades necesitadas para
C
desarrollar un producto exitoso.
Con esta lista siempre podemos empezar a trabajar
en los ítems de más alta prioridad, más importantes.
Como mostramos en la siguiente figura que se
Funcionalidad llama “product backlog”.
D
Planificación de iteraciones
Funcionalid
Funcionalidad ad B

Revisión de iteraciones
A

Funcionalid Funcionalid
ad D ad C

Iteración (entre una semana y un mes)

Cuando los recursos se van acabando, como por
ejemplo el tiempo, cualquier trabajo que se haya
realizado hasta entonces pertenecerá a la categoría de
alta prioridad y en cualquier caso será el trabajo de
baja prioridad el que no se haya completado todavía.
El trabajo se realiza en iteraciones cortas y
temporalizadas cuya duración normalmente varía
entre una semana y un mes. Durante cada iteración un
equipo multifuncional y autoorganizado hace todo el
trabajo requerido (diseñar, construir y testear) para
producir características completas y funcionales que
se pueden poner en fase de producción.
Normalmente, la cantidad de trabajo que se coloca en el product backlog es
mucho mayor de lo que se puede completar en una iteración de corta duración,
por lo tanto, al principio de cada iteración se planifica qué subconjunto de alta prioridad está incluida
en el próximo sprint.
En la figura anterior, el equipo ha acordado que puede crear las características A, B, C y D.
Al acabar cada iteración, el equipo revisa las funcionalidades completas con los interesados en el
proyecto, como por ejemplo los clientes, para obtener su feedback. Basados en el feedback, el
propietario del producto y el equipo pueden alterar lo que quieren hacer a continuación y cómo el
equipo planea hacer ese trabajo.
Por ejemplo, si el cliente observa que existe una funcionalidad que no se ha incluido, pero que debería
incluirse, el equipo simplemente tiene que crear un nuevo ítem representando esa funcionalidad e
insertarlo en el product backlog en el orden correcto para trabajarlo en futuras iteraciones.
Al final de cada iteración el equipo debe tener un producto potencialmente
lanzable o, en su defecto, un incremento sobre el producto anterior.
En algunos casos puede producirse ya un producto que se pueda lanzar de manera definitiva.
Cuando finaliza una iteración, el proceso completo comienza de nuevo con la planificación de la siguiente
iteración.
Vídeo: así
trabajan Scrum y
Agile en BBVA.
https://youtu.be/9t0eJM-2zaQ
Pero ¿qué es SCRUM?
¿Por qué un enfoque ágil como Scrum será
bueno para perseguir tus objetivos?

Motivos agregados

¡Vamos a verlos!
01 El enfoque actual de desarrollo en cascada no
está funcionando, por diferentes razones:
Las entregas se realizan con retraso.
La tasa de proyectos fallidos es demasiado elevada.
La calidad de los productos no es adecuada.
El retorno sobre la inversión no es suficiente.
La moral de los empleados es baja.
La productividad es baja.
No hay responsables por los resultados.
Hay demasiado personal y es difícil de
gestionar.
02 Todo lo que rodea al desarrollo del producto es incierto
y no se sabe lo que funcionará y lo que no.

03 sabe lo que querrán y aceptarán los clientes.

El producto es extremadamente innovador y no se

04 lanzando
Se quiere tener una ventaja competitiva sobre la competencia
lo más rápido posible y para ello es necesario desnudar la
idea original e ir vistiéndola en lanzamientos progresivos.

05 La empresa necesita cohesionar equipos

multidisciplinares.

06 Es necesario que la información fluya

constantemente en la empresa.
Es verdad que muchos siguen pensando que es mejor el desarrollo en cascada pues permite
lanzar un producto muy completo y se evita el riesgo de "quedar mal" ante los clientes. Pero la
realidad es distinta, especialmente con el auge del producto digital.

De una manera muy extrema el fundador de LinkedIn, lo

expone de la siguiente manera:
"Si no te avergüenzas de la primera versión de tu
producto, lo has lanzado demasiado tarde“.
Reid Hoffman.
Y, efectivamente, la experiencia de las empresas que se han
tomado en serio esta filosofía y han aplicado los principios
Scrum han experimentado los siguientes beneficios:
Los clientes están
encantados.
Se mejora el retorno de la
inversión.
Los costes se ven
reducidos.
Los resultados llegan
rápido.
Aumenta la confianza para tener éxito en entornos
complejos.
Los trabajadores disfrutan más de su
trabajo.
Vale, muy bien, pero ¿cuándo hay
que implementar un SCRUM?
Es necesario que analices tu propia situación para
poder escoger lo que más le convenga a tu Desorden
organización y, para ello, te proponemos un enfoque
llamado Enfoque Cynefin, que muestra las cuatro
situaciones en las que, como organizaciones o
personas, podemos encontrarnos.
 B
A
A B

Dominio simple
En el dominio simple se trata de detectar-categorizar-responder.
Tu dominio es simple si:
Respondes a hechos categorizados con prácticas ya establecidas.
Tu entorno es estable y probablemente no cambiará.
Las relaciones causa-efecto son muy claras para todos los miembros de la organización y el
entorno.
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por último, realizar
la adaptación.
Aunque se pueden solucionar estos problemas usando
Scrum, un enfoque más práctico y sencillo sería establecer
procesos fijos y basar la gestión en ellos.
 B
B A
A

Dominio caótico A
B
B

En este dominio debes actuar-detectar-responder.

En este dominio:
Actúas de inmediato y, luego, detectas si la situación se ha estabilizado. Una
vez esto ocurre te adaptas para tratar de mover tu dominio hacia "complejo".
Tienes muchas decisiones que tomar y no tienes tiempo para pensar.
Necesitas actuar de inmediato para restablecer el orden.
Buscas algo que funcione en lugar de una respuesta correcta.
No existen relaciones claras causa-efecto.
Nadie tiene nada seguro.

Lamentamos decirte que en este caso Scrum no te va a ayudar demasiado.

Aunque sea un enfoque ágil, en Scrum necesitas pararte a pensar
frecuentemente, para priorizar, decidir, reordenar, analizar resultados, etc. No
hay lugar para tanto trabajo en equipo en este dominio, sino que alguien tiene
que apagar el fuego como sea.
 B
A

Dominio complejo
B
B

A
Su máxima es sondear-detectar-responder.
Sabes si te encuentras este dominio si te encuentras con lo siguiente:
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por
último, realizar la adaptación.
Necesitas ser creativo e innovador.
Tienes que crear modos de experimentación a prueba de fracasos para descubrir
patrones.
Necesitas altos niveles de interacción y comunicación.
Tienes que esperar a fases posteriores a los lanzamientos para saber cualquier resultado.
Más cosas impredecibles que predecibles.

El scrum es una metodología idónea para estos entornos, por su facilidad de

implementar principios de exploración, inspección y adaptación.
 A B

Dominio complicado
A
B

Se lidia con problemas complicados, B

basándose en detectar-analizar-responder.
Estás en el dominio complicado si cumples con lo siguiente:
Más cosas impredecibles que predecibles.
Exploras y analizas la situación, investigas varias opciones y respondes según
una serie de buenas prácticas ya existentes.
Recurres a expertos para aumentar el conocimiento sobre los problemas.
Recurres a métricas para controlar las acciones.
Existe un abanico de respuestas correctas a tus problemas.
Los efectos son relacionables a las causas, pero no se visualizan de inmediato.
Tu entorno es más predecible que impredecible.
Aunque puedes usar Scrum para este dominio, no es necesariamente la
mejor solución, ya que hablamos de utilizar soluciones conocidas,
metodologías como Six Sigma serían más adecuadas en este caso.
Desorden
Sin duda, el lugar más peligroso en el que puedes hallarte. No sabes en qué
dominio estás y, por lo tanto, tampoco tienes claro cómo actuar ni qué
secuencias seguir. Tienes que salir de él cuanto antes y la manera de hacerlo
es desglosar tu situación actual en partes y llevarlas a sus dominios
correspondientes para tener una referencia de cómo gestionarlas. Aquí el
Scrum no te ayudará en nada.
 ¿cuándo hay
Vale, muy bien, pero
que implementar un SCRUM?
Es necesario que analices tu propia situación para
poder escoger lo que más le convenga a tu Desorden
organización y, para ello, te proponemos un enfoque
llamado Enfoque Cynefin, que muestra las cuatro
situaciones en las que, como organizaciones o
personas, podemos encontrarnos.
Fundamentos de Scrum
Como estamos diciendo, Scrum es un marco de trabajo en
el cual las personas pueden enfrentarse a cuestiones
complejas y problemas de complejidad adaptativa
mientras consiguen lanzar productos de manera
productiva y creativa con el mayor valor añadido posible.

El Scrum es
Ligero
Fácil de entender

Difícil de dominar plenamente

1. El desarrollo incremental de los requisitos del proyecto en
bloques temporales o iteraciones, cortos y fijos (de un mes
natural y hasta de dos semanas, si así se necesita).
Esta descomposición en miniproyectos o
iteraciones se realiza con el fin de poder ir
mostrando al cliente los beneficios del proyecto
de una forma incremental. Para ello, cada
requisito debe completarse en una única
iteración, añadiendo nuevos objetivos/requisitos o
mejorando los que ya fueron completados.
Un aspecto fundamental para guiar el desarrollo
iterativo e incremental es la priorización de los
objetivos/requisitos en función del valor que
aportan al cliente.
2. Priorización de los requisitos en función del valor que
aporta al cliente y coste de desarrollo en cada iteración.
Como resultado de esta repriorización se
actualizará la lista de requisitos anteriormente
priorizada, llegando incluso a un punto en el que
no sea necesario desarrollar los requisitos
restantes porque el retorno de inversión (ROI)
que tengan no sea suficiente.
3. El control empírico del proyecto.
Como ya hemos comentado, al final de cada
iteración se le enseñará al cliente el resultado de
la misma para que se puedan tomar decisiones
en función de lo que observa y del contexto del
momento. Con ello, el equipo se sincronizará
diariamente y realizará las adaptaciones
necesarias.
4. La potenciación del equipo.
El equipo se compromete a entregar unos
requisitos y, para ello, se le otorga la autoridad
necesaria para organizar su trabajo.
5. La sistematización de la colaboración y la comunicación tanto
entre el equipo como con el cliente.
6. El timeboxing de las actividades del proyecto para ayudar a la
toma de decisiones y conseguir resultados.
La técnica del timebox 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.
Scrum no es un proceso o una técnica para construir productos.
En vez de eso, es un marco de trabajo en el que puedes emplear
varios procesos y técnicas.
Con Scrum dejamos clara, la relativa eficacia de la gestión de productos y de las
prácticas de desarrollo de manera que, estas, puedan mejorarse.

Equipos Scrum y roles asociados a estos

Eventos

Elementos o artefactos
Reglas Sirven para agrupar los eventos, roles y elementos, gestionando
y regulando las interacciones que tienen lugar entre estos.

Cada componente dentro del marco de trabajo sirve a un propósito

específico y es esencial para el uso y éxito de Scrum.
Elementos o artefactos

Eventos

Equipos Scrum
La teoría de Scrum
Scrum se fundamenta como una teoría de control empírico.

Fundamentalmente tres pilares sostienen toda

implementación de control de procesos empíricos:

01 Transparencia

02 Inspección
03 Adaptación
Transparencia
Los aspectos significativos de cada proceso deben ser visibles
para los responsables del resultado del mismo.
La transparencia requiere que esos aspectos
sean definidos elaborando estándares comunes,
de manera que los observadores tengan un
entendimiento común de lo que se está viendo
en cada momento.
Por ejemplo, todos los participantes deben
compartir un lenguaje común de referencia y
aquellos que se encarguen de realizar el trabajo
deben tener una definición común de lo que se
considera trabajo realizado.
Inspección
Los usuarios de Scrum deben frecuentemente inspeccionar los
elementos y progresar hacia el objetivo de la interacción para
detectar aquellas variaciones que ocurran.
Eso sí, la inspección no debe ser tan frecuente
como para que entorpezca el trabajo. Cuando
más beneficiosas son las inspecciones es
cuando son realizadas por inspectores
cualificados en el punto de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos del proceso se están desviando fuera
de los límites aceptables y que el producto resultante sería, por tanto, inaceptable, este
proceso o el material que esté siendo procesado debe ser ajustado. Cualquier ajuste
debe realizarse lo antes posible para minimizar estas desviaciones no deseadas.
En Scrum hablamos de cuatro eventos formales para la inspección y la
adaptación.
Estos serían los ya mencionados:
Valores de Scrum
Todo trabajo realizado en el marco de Scrum necesita
una serie de valores que servirán como fundamento para
los procesos e iteraciones. El equipo, mediante la
aceptación de tales valores, las hace todavía más
fundamentales para su salud y éxito.

Los valores de Scrum son cinco que enumeramos y

explicamos brevemente a continuación.
Concentración
En Scrum debemos concentrarnos en pocas cosas a la vez,
trabajar bien en equipo y producir un trabajo de excelencia.
Se entregan, por lo tanto, más rápido productos con más
valor.

Valentía
Al trabajar juntos como equipo los miembros se sienten
apoyados y tienen más recursos a su disposición. Esto da
a los equipos mayor valentía para aceptar mayores retos.

Franqueza
En Scrum los miembros del equipo le cuentan a los otros
miembros cómo les va, qué obstáculos encuentran y qué
tipo de preocupaciones tienen acerca del desarrollo.
Compromiso
El compromiso con el éxito en Scrum es enorme dado
que con estas metodologías se tiene un gran control
sobre el propio destino de la empresa y del equipo.

Respeto
A medida que se trabaja juntos, compartiendo éxitos y
fracasos, las personas terminan por respetarse unos a otros y
se ayudan unos a otros a ser merecedores de respeto.
Metodología SCRUM
Scrum es un enfoque ágil para
desarrollar productos y servicios
innovadores.
Pero no hablamos de una metodología cualquiera, ya que
supone una gran innovación con respecto a otras
metodologías de gestión de proyectos.
Funcionalidad
Funcionalidad
A B

El primer elemento será una lista

priorizada de las características y
Funcionalidad C otras capacidades necesitadas para
desarrollar un producto exitoso.
Con esta lista siempre podemos empezar a trabajar
en los ítems de más alta prioridad, más importantes.
Como mostramos en la siguiente figura que se
Funcionalidad D llama “product backlog”.
Planificación de iteraciones
Funcionalidad B
Funcionalidad A

Revisión de iteraciones
Funcionalidad D Funcionalidad C

Iteración (entre una semana y un mes)

Cuando los recursos se van acabando, como por
ejemplo el tiempo, cualquier trabajo que se haya
realizado hasta entonces pertenecerá a la categoría de
alta prioridad y en cualquier caso será el trabajo de
baja prioridad el que no se haya completado todavía.
El trabajo se realiza en iteraciones cortas y
temporalizadas cuya duración normalmente varía
entre una semana y un mes. Durante cada iteración
un equipo multifuncional y autoorganizado hace
todo el trabajo requerido (diseñar, construir y testear)
para producir características completas y funcionales
que se pueden poner en fase de producción.
 Normalmente, la cantidad de trabajo que se coloca en el product backlog es
mucho mayor de lo que se puede completar en una iteración de corta duración,
por lo tanto, al principio de cada iteración se planifica qué subconjunto de alta prioridad está incluida
en el próximo sprint.
En la figura anterior, el equipo ha acordado que puede crear las características A, B, C y D.
Al acabar cada iteración, el equipo revisa las funcionalidades completas con los interesados en
el proyecto, como por ejemplo los clientes, para obtener su feedback. Basados en el feedback,
el propietario del producto y el equipo pueden alterar lo que quieren hacer a continuación y cómo el
equipo planea hacer ese trabajo.
Por ejemplo, si el cliente observa que existe una funcionalidad que no se ha incluido, pero que debería
incluirse, el equipo simplemente tiene que crear un nuevo ítem representando esa funcionalidad e
insertarlo en el product backlog en el orden correcto para trabajarlo en futuras iteraciones.

Al final de cada iteración el equipo debe tener un producto potencialmente

lanzable o, en su defecto, un incremento sobre el producto anterior.
En algunos casos puede producirse ya un producto que se pueda lanzar de manera definitiva.
Cuando finaliza una iteración, el proceso completo comienza de nuevo con la planificación de la
siguiente iteración.
Vídeo: así
trabajan Scrum
y Agile en BBVA.
https://youtu.be/9t0eJM-2zaQ
Pero ¿qué es SCRUM?
¿Por qué un enfoque ágil como Scrum será
bueno para perseguir tus objetivos?

Motivos agregados

¡Vamos a verlos!
01 El enfoque actual de desarrollo en cascada no
está funcionando, por diferentes razones:
Las entregas se realizan con retraso.
La tasa de proyectos fallidos es demasiado elevada.
La calidad de los productos no es adecuada.
El retorno sobre la inversión no es suficiente.
La moral de los empleados es baja.
La productividad es baja.
No hay responsables por los resultados.
Hay demasiado personal y es difícil de
gestionar.
02 Todo lo que rodea al desarrollo del producto es incierto
y no se sabe lo que funcionará y lo que no.

03 sabe lo que querrán y aceptarán los clientes.

El producto es extremadamente innovador y no se

04 lanzando
Se quiere tener una ventaja competitiva sobre la competencia
lo más rápido posible y para ello es necesario desnudar la
idea original e ir vistiéndola en lanzamientos progresivos.

05 La empresa necesita cohesionar equipos

multidisciplinares.

06 Es necesario que la información fluya

constantemente en la empresa.
Es verdad que muchos siguen pensando que es mejor el desarrollo en cascada pues permite
lanzar un producto muy completo y se evita el riesgo de "quedar mal" ante los clientes. Pero la
realidad es distinta, especialmente con el auge del producto digital.

De una manera muy extrema el fundador de LinkedIn, lo

expone de la siguiente manera:
"Si no te avergüenzas de la primera versión de tu
producto, lo has lanzado demasiado tarde“.
Reid Hoffman.
Y, efectivamente, la experiencia de las empresas que se han
tomado en serio esta filosofía y han aplicado los principios
Scrum han experimentado los siguientes beneficios:
Los clientes están
encantados.
Se mejora el retorno de la
inversión.
Los costes se ven
reducidos.
Los resultados llegan
rápido.
Aumenta la confianza para tener éxito en entornos
complejos.
Los trabajadores disfrutan más de su
trabajo.
Vale, muy bien, pero ¿cuándo hay
que implementar un SCRUM?
Es necesario que analices tu propia situación para
poder escoger lo que más le convenga a tu Desorden
organización y, para ello, te proponemos un enfoque
llamado Enfoque Cynefin, que muestra las cuatro
situaciones en las que, como organizaciones o
personas, podemos encontrarnos.
 B
A
A B

Dominio simple
En el dominio simple se trata de detectar-categorizar-responder.
Tu dominio es simple si:
Respondes a hechos categorizados con prácticas ya establecidas.
Tu entorno es estable y probablemente no cambiará.
Las relaciones causa-efecto son muy claras para todos los miembros de la organización y el
entorno.
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por último, realizar
la adaptación.
Aunque se pueden solucionar estos problemas usando
Scrum, un enfoque más práctico y sencillo sería establecer
procesos fijos y basar la gestión en ellos.
 B
B A
A

Dominio caótico A
B
B

En este dominio debes actuar-detectar-responder.

En este dominio:
Actúas de inmediato y, luego, detectas si la situación se ha estabilizado. Una
vez esto ocurre te adaptas para tratar de mover tu dominio hacia "complejo".
Tienes muchas decisiones que tomar y no tienes tiempo para pensar.
Necesitas actuar de inmediato para restablecer el orden.
Buscas algo que funcione en lugar de una respuesta correcta.
No existen relaciones claras causa-efecto.
Nadie tiene nada seguro.

Lamentamos decirte que en este caso Scrum no te va a ayudar demasiado.

Aunque sea un enfoque ágil, en Scrum necesitas pararte a pensar
frecuentemente, para priorizar, decidir, reordenar, analizar resultados, etc. No
hay lugar para tanto trabajo en equipo en este dominio, sino que alguien tiene
que apagar el fuego como sea.
 B
A

Dominio complejo
B
B

A
Su máxima es sondear-detectar-responder.
Sabes si te encuentras este dominio si te encuentras con lo siguiente:
Tienes que explorar para aprender sobre un problema, luego inspeccionar y, por
último, realizar la adaptación.
Necesitas ser creativo e innovador.
Tienes que crear modos de experimentación a prueba de fracasos para descubrir
patrones.
Necesitas altos niveles de interacción y comunicación.
Tienes que esperar a fases posteriores a los lanzamientos para saber cualquier resultado.
Más cosas impredecibles que predecibles.

El scrum es una metodología idónea para estos entornos, por su facilidad de

implementar principios de exploración, inspección y adaptación.
 A B

Dominio complicado
A
B

Se lidia con problemas complicados, B

basándose en detectar-analizar-responder.
Estás en el dominio complicado si cumples con lo siguiente:
Más cosas impredecibles que predecibles.
Exploras y analizas la situación, investigas varias opciones y respondes según
una serie de buenas prácticas ya existentes.
Recurres a expertos para aumentar el conocimiento sobre los problemas.
Recurres a métricas para controlar las acciones.
Existe un abanico de respuestas correctas a tus problemas.
Los efectos son relacionables a las causas, pero no se visualizan de inmediato.
Tu entorno es más predecible que impredecible.
Aunque puedes usar Scrum para este dominio, no es necesariamente la
mejor solución, ya que hablamos de utilizar soluciones conocidas,
metodologías como Six Sigma serían más adecuadas en este caso.
Desorden
Sin duda, el lugar más peligroso en el que puedes hallarte. No sabes en qué
dominio estás y, por lo tanto, tampoco tienes claro cómo actuar ni qué
secuencias seguir. Tienes que salir de él cuanto antes y la manera de hacerlo
es desglosar tu situación actual en partes y llevarlas a sus dominios
correspondientes para tener una referencia de cómo gestionarlas. Aquí el
Scrum no te ayudará en nada.
 ¿cuándo hay
Vale, muy bien, pero
que implementar un SCRUM?
Es necesario que analices tu propia situación para
poder escoger lo que más le convenga a tu Desorden
organización y, para ello, te proponemos un enfoque
llamado Enfoque Cynefin, que muestra las cuatro
situaciones en las que, como organizaciones o
personas, podemos encontrarnos.
Fundamentos de Scrum
Como estamos diciendo, Scrum es un marco de trabajo en
el cual las personas pueden enfrentarse a cuestiones
complejas y problemas de complejidad adaptativa
mientras consiguen lanzar productos de manera
productiva y creativa con el mayor valor añadido posible.

El Scrum es
Ligero
Fácil de entender

Difícil de dominar plenamente

1. El desarrollo incremental de los requisitos del proyecto en
bloques temporales o iteraciones, cortos y fijos (de un mes
natural y hasta de dos semanas, si así se necesita).
Esta descomposición en miniproyectos o
iteraciones se realiza con el fin de poder ir
mostrando al cliente los beneficios del proyecto
de una forma incremental. Para ello, cada
requisito debe completarse en una única
iteración, añadiendo nuevos objetivos/requisitos o
mejorando los que ya fueron completados.
Un aspecto fundamental para guiar el desarrollo
iterativo e incremental es la priorización de los
objetivos/requisitos en función del valor que
aportan al cliente.
2. Priorización de los requisitos en función del valor que
aporta al cliente y coste de desarrollo en cada iteración.
Como resultado de esta repriorización se
actualizará la lista de requisitos anteriormente
priorizada, llegando incluso a un punto en el que
no sea necesario desarrollar los requisitos
restantes porque el retorno de inversión (ROI)
que tengan no sea suficiente.
3. El control empírico del proyecto.
Como ya hemos comentado, al final de cada
iteración se le enseñará al cliente el resultado de
la misma para que se puedan tomar decisiones
en función de lo que observa y del contexto del
momento. Con ello, el equipo se sincronizará
diariamente y realizará las adaptaciones
necesarias.
4. La potenciación del equipo.
El equipo se compromete a entregar unos
requisitos y, para ello, se le otorga la autoridad
necesaria para organizar su trabajo.
5. La sistematización de la colaboración y la comunicación tanto
entre el equipo como con el cliente.
6. El timeboxing de las actividades del proyecto para ayudar a la
toma de decisiones y conseguir resultados.
La técnica del timebox 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.
Scrum no es un proceso o una técnica para construir productos.
En vez de eso, es un marco de trabajo en el que puedes emplear
varios procesos y técnicas.
Con Scrum dejamos clara, la relativa eficacia de la gestión de productos y de las
prácticas de desarrollo de manera que, estas, puedan mejorarse.

Equipos Scrum y roles asociados a estos

Eventos

Elementos o artefactos
Reglas Sirven para agrupar los eventos, roles y elementos, gestionando
y regulando las interacciones que tienen lugar entre estos.

Cada componente dentro del marco de trabajo sirve a un propósito

específico y es esencial para el uso y éxito de Scrum.
Elementos o artefactos

Eventos

Equipos Scrum
La teoría de Scrum
Scrum se fundamenta como una teoría de control empírico.

Fundamentalmente tres pilares sostienen toda

implementación de control de procesos empíricos:

01 Transparencia

02 Inspección
03 Adaptación
Transparencia
Los aspectos significativos de cada proceso deben ser visibles
para los responsables del resultado del mismo.
La transparencia requiere que esos aspectos
sean definidos elaborando estándares comunes,
de manera que los observadores tengan un
entendimiento común de lo que se está viendo
en cada momento.
Por ejemplo, todos los participantes deben
compartir un lenguaje común de referencia y
aquellos que se encarguen de realizar el trabajo
deben tener una definición común de lo que se
considera trabajo realizado.
Inspección
Los usuarios de Scrum deben frecuentemente inspeccionar los
elementos y progresar hacia el objetivo de la interacción para
detectar aquellas variaciones que ocurran.
Eso sí, la inspección no debe ser tan frecuente
como para que entorpezca el trabajo. Cuando
más beneficiosas son las inspecciones es
cuando son realizadas por inspectores
cualificados en el punto de trabajo.
Adaptación
Si un inspector determina que uno o más aspectos del proceso se están desviando fuera
de los límites aceptables y que el producto resultante sería, por tanto, inaceptable, este
proceso o el material que esté siendo procesado debe ser ajustado. Cualquier ajuste
debe realizarse lo antes posible para minimizar estas desviaciones no deseadas.
En Scrum hablamos de cuatro eventos formales para la inspección y la
adaptación.
Estos serían los ya mencionados:
Valores de Scrum
Todo trabajo realizado en el marco de Scrum necesita
una serie de valores que servirán como fundamento para
los procesos e iteraciones. El equipo, mediante la
aceptación de tales valores, las hace todavía más
fundamentales para su salud y éxito.

Los valores de Scrum son cinco que enumeramos y

explicamos brevemente a continuación.
Concentración
En Scrum debemos concentrarnos en pocas cosas a la vez,
trabajar bien en equipo y producir un trabajo de excelencia.
Se entregan, por lo tanto, más rápido productos con más
valor.

Valentía
Al trabajar juntos como equipo los miembros se sienten
apoyados y tienen más recursos a su disposición. Esto da
a los equipos mayor valentía para aceptar mayores retos.

Franqueza
En Scrum los miembros del equipo le cuentan a los otros
miembros cómo les va, qué obstáculos encuentran y qué
tipo de preocupaciones tienen acerca del desarrollo.
Compromiso
El compromiso con el éxito en Scrum es enorme dado
que con estas metodologías se tiene un gran control
sobre el propio destino de la empresa y del equipo.

Respeto
A medida que se trabaja juntos, compartiendo éxitos y
fracasos, las personas terminan por respetarse unos a otros y
se ayudan unos a otros a ser merecedores de respeto.
1.2 Gestión Ágil con SCRUM y Kanban
Introducción a los artefactos de SCRUM
https://vimeo.com/326630255/0c0b36f4e4
Volvemos a incidir en el aspecto
general del marco de trabajo de
Scrum, recordándote la gráfica ya
vista anteriormente.
Elementos o artefactos

Eventos

Equipos Scrum
Podemos decir que en Scrum, el
sprint es el esqueleto que sostiene
todo junto. Es por eso que se ve
representado por una flecha ya
que abarca todo el proceso.
 Ítems de alta
Todo comienza con la visión de prioridad

Grooming
lo que el product owner o dueño
de producto quiere crear.
Como este cubo puede ser bastante grande,
lo primero que se hace es una actividad
de refinado o grooming (en la cual se
desglosa y prioriza una serie de Ítems de baja
características y funcionalidades) que da
lugar a un product backlog. prioridad
Haz clic sobre cada uno de los elementos mencionados.
Durante la ejecución del sprint se realizan las actividades necesarias para
desarrollar las funcionalidades seleccionadas mediante la ejecución de las
diferentes tareas detalladas en el sprint backlog. También, durante esta
parte del proceso se llevan a cabo reuniones diarias de inspección y
adaptación o inspect-adapt, con las que se monitoriza el progreso, si hay
problemas que impiden, qué se está haciendo para progresar en el
proyecto, etc.
Al concluir la ejecución se elabora un incremento sobre el producto
potencialmente lanzable que será sujeto a dos revisiones de
inspección y adaptación: revisión del sprint y retrospectiva del sprint.

El equipo Scrum inspecciona el propio proceso Scrum

empleado.
Al concluir un número apropiado de sprints, la visión del dueño de
producto se hará realidad y el producto podrá ser lanzado.
 Los stakeholders y el equipo Scrum inspeccionan el
producto que está siendo construido.

Al principio de cada sprint, el equipo coge un bloque del product backlog y lo descompone para
ver si lo puede ejecutar en un sprint. Si no puede, lo descompone en las unidades que pueda
abarcar, prioriza y el resto lo deja como PBI para otro sprint.
Al concluir la planificación del sprint, el equipo alcanza un compromiso (antiguamente
llamado pronóstico) para entregar lo que se incluye en el sprint.
Los elementos o
artefactos de Scrum
representan trabajo o
valor para dotar de
transparencia y
oportunidades de
inspección y adaptación.

Estos elementos definidos por

Scrum están específicamente
diseñados para maximizar esa
transparencia de información
clave, de manera que todos los
involucrados en el proyecto,
tienen el mismo nivel de
entendimiento de cada
elemento. Product
backlog
Sprint backlog
Product backlog
En el entorno Scrum, siempre vamos a realizar
primeramente el trabajo que añade más valor.

“El 80% del valor

A fin de cuentas, tal
y como explican
los maestros en el
desarrollo de
de un producto lo añaden el
software. 20% de sus funcionalidades”
En los product backlog del desarrollo de un producto nuevo, los ítems
generalmente se priorizan conforme a la visión que tiene el product owner.
En el caso del desarrollo de un producto existente, el product backlog puede
incluir también, nuevas funcionalidades o cambios en funcionalidades
existentes.
El product backlog enumera todas las funcionalidades,
características, requisitos, funciones, mejoras y arreglos
que constituyen los cambios a realizar en el producto en
futuros lanzamientos.
Los ítems dentro del product backlog tienen una serie de atributos que
describen estimación de tiempo realizado y valor añadido.
 PRODUCT OWNER
Propietario del producto
Es el responsable de determinar y
gestionar la secuencia del trabajo,
contando con el input del resto del
equipo de Scrum y de los
interesados en el proyecto. El
product owner vierte toda esta
información en el product backlog.
Normalmente el
product owner Internos
trabaja con de la empresa
stakeholders
(interesados o Propietario
afectados) en el del producto o
proyecto para Product owner
incluir nuevos Externos
ítems en el Clientes/usuarios
product backlog.
 Ítems de alta
prioridad
A continuación, se asegura que estos
ítems estén incluidos en el orden
correcto, usando factores como el
valor, el coste, el conocimiento
requerido o el riesgo involucrado.
Ítems de baja
prioridad
 La actividad de crear y refinar
refinado o los ítems del product backlog
grooming realizando estimaciones y
asignándoles prioridades.

Un product backlog nunca está completo.

En su desarrollo temprano solo se incluyen los requisitos que se conocen
inicialmente y los que mejor se comprenden. Por lo tanto, podemos decir
que el product backlog evoluciona a medida que el producto y el
entorno en el que será usado también lo hacen.

El product backlog es dinámico y cambia constantemente.

Para identificar qué necesita el producto para ser apropiado, competitivo y útil.
Durante todo el tiempo que exista el producto, también hará el product backlog.
A medida que el producto es usado, este gana valor y el
mercado nos da feedback.
Es entonces, cuando el product backlog se convierte en una lista mayor y
más exhaustiva. Los requisitos, nunca paran de cambiar, con lo que podemos
decir que el product backlog es un elemento vivo. En general existen muchos
factores que pueden provocar cambios en el product backlog, como por ejemplo,
cambios en los requisitos del negocio, necesidades del negocio, condiciones de
mercado o cambios en la tecnología.
Muchos equipos Scrum, a menudo, trabajan juntos en el mismo producto. Se usa
un product backlog para describir el trabajo que se ha de realizar en el producto.
Es en ese momento, en el que un atributo de product backlog que agrupe varios
ítems, puede ser empleado.
Ítems del
Product backlog
La mayoría de los PBI son funcionalidades que
tendrán un valor tangible para el cliente, las
cuales con frecuencia provienen de las user
stories o historias de usuario que detallan cómo la
funcionalidad añade valor al cliente.
 +
+ +
Los PBI pueden adoptar diferentes naturalezas. +

Haz clic sobre cada tipo de PBI para ver su definición y un ejemplo. +
+

+
Que el representante del servicio al cliente pueda

+
Funcionalidad Característica del producto que crear un ticket con una incidencia para registrar y+
añade valor para el cliente. + la petición de soporte técnico de un cliente.
gestionar

Desarrollo que modifica una Que el representante de servicio al cliente quiera que
Cambio funcionalidad para ayudarle a ahora pueda clasificar las incidencias de soporte por
añadir más valor. apellido del cliente en lugar de por número de ticket.

Petición de arreglo de un Arreglar que los nombres con tildes o

Defecto defecto del producto. eñes muestren caracteres extraños.

Mejora técnica Trata de realizar una mejora Cambiar a la última versión del software
empleado para gestionar la base de datos.
necesaria en un producto existente.

Adquisición de Acción destinada a obtener +

Crear un prototipo con dos arquitecturas diferentes
conocimiento para mejorar el + determinar
para realizar tres tests y, posteriormente,
conocimiento cuál sería el mejor enfoque para el producto.
desarrollo. +
+
+
¿Cómo es un buen
product backlog?
Fundamentalmente, hablamos de cuatro
características fundamentales que debe tener un
product backlog. Provienen de un sistema acuñado
en 2010 como DEEP (profundo en inglés) por los
expertos Roman Pichler y Mike Cohn y que en
realidad es un acrónimo de los siguientes términos:

D etallado E
mergente E
stimado riorizado
Como estamos diciendo durante todo el contenido, el Scrum está orientado a
minimizar todos los esfuerzos y, conocer de antemano detalles sobre un sprint que se
va a realizar dentro de bastante tiempo no es, precisamente, optimizar el esfuerzo.

Los diferentes ítems del product backlog solamente se van desglosando

en detalles a medida que avanzan en la lista de prioridades.
Los PBI en los que se va a trabajar a corto plazo, deben estar bien detallados y tener un
tamaño pequeño, ya que de esta manera se podrán conocer muchos más detalles acerca de
cuánto tiempo tomarán, cuánto valor añadirán, etc.
Para el resto de PBI no es tan importante conocer muchos detalles, ya
que no se va a trabajar en ellos a corto plazo. Es más, el refinamiento
(convertir PBI grandes en pequeños, lo veremos a continuación
como grooming) debe realizarse a medida que ítems más gruesos
vayan avanzando en la lista de prioridades.
D
etallado E
mergente E
stimado riorizado

P
Detallado apropiadamente
Los PBI en los que se va a trabajar próximamente deben tener un tamaño reducido y
contener mucho detalle para saber exactamente lo que hay que hacer y cuánto se va a
tardar. Los PBI más grandes en los que no vayas a trabajar durante un tiempo deben
permanecer más abajo en la lista de prioridades.

Emergente
Mientras haya un producto que esté siendo desarrollado o mantenido, el product
backlog nunca está completo ni parado, sino que se actualiza constantemente
basándonos en un flujo de información de valor que no cesa. Por poner un ejemplo, los
clientes pueden cambiar de opinión acerca de lo que quieren, la competencia puede adoptar
estrategias no esperadas, etc. Precisamente el product backlog tiene como finalidad capacitar
al equipo para adaptarse a estas circunstancias.
Estimado
Cada PBI debe tener una estimación de tamaño equivalente al esfuerzo necesitado para
desarrollarlo. Es el product owner quien usa estas estimaciones como uno de los factores a
tener en cuenta en la priorización de cada PBI.
Las estimaciones de PBI se realizan en días o en puntos de historia. Las estimaciones
deben ser razonablemente exactas, pero no perfectas.
En el caso de los grandes PBI en la base del product backlog, no siempre es posible realizar una
estimación numérica, con lo que en ocasiones se les otorga tamaños como si fueran una
camiseta (L, XL, XXL, etc.). Posteriormente, según se acerque su momento, se irán desglosando
estos PBI y se realizarán estimaciones más cercanas a la realidad.

Priorizado
Solamente será necesario priorizar los PBI pertenecientes a sprints cercanos en el tiempo,
ya que aunque el product backlog sea precisamente una lista priorizada de ítems, va contra la
filosofía Scrum el realizar una priorización exacta desde un principio.
 Grooming
Para un buen product El grooming es, por definición, un conjunto
backlog consistente con de tres actividades principales:
los principios DEEP, debes
gestionar, organizar y Crear y refinar (añadir detalles) a los PBI
administrar de manera
Estimar el tamaño de los PBI
proactiva los PBI.
Priorizar los PBI
 PBI Tamaño
Haz clic sobre En el momento adecuado,
cada concepto 3 Estimar tendrás que estimar cada
marcado en rosa. PBI para determinar el
orden en tu backlog y para
ayudarte a decidir si es
necesario o no más trabajo
Claro que, si Repriorizar de refinamiento.
las prioridades
ítems
cambian, Inserta Además, a medida que
reordenarás tu r ítem consigas obtener más
backlog. información, crearás
nuevos PBI que insertarás
en el product backlog en
originalmente el orden pertinente.
grande
Ítem

Refinar Por último, cuando se

ítems acerque el turno de un
PBI más grande, lo
refinarás para
Eliminar convertirlo en un
conjunto de PBI más
ítem pequeños y estimables.
¿Quién hace
el grooming?
En realidad se trata de un esfuerzo conjunto y colaborativo que realizarás
con tu equipo, pero que siempre será liderado por el product owner que
es el responsable final de los lanzamientos.
Además del equipo, en este trabajo contarás con la ayuda del Scrum master, del equipo de
desarrollo (tendrá una dedicación de un 10% de su tiempo) y de los interesados en el
proyecto o stakeholders (consumidores, usuarios, propietarios del negocio, etc.).
¿Cuándo se Al inicio de la creación del product backlog siempre tiene que haber grooming, como es
obvio, para sentar unas prioridades iniciales y sentar las bases de los primeros sprints.

hace hace el Durante el desarrollo de producto, el product owner se reúne con los stakeholders

grooming? (interesados tanto internos como externos de la empresa) para realizar actividades
de grooming con la frecuencia que estimen conveniente.

No existe una regla Mientras trabaja con el equipo de desarrollo, el product owner puede mantener talleres
fija acerca de de grooming, bien semanalmente o bien una vez por sprint. Esto garantiza que el
grooming ocurre de manera regular y monitorizar el tiempo invertido en esta actividad.
cuándo, ni cuántas
veces durante el A veces, los equipos prefieren reunirse varias veces para refinar
proyecto se debe durante el sprint, en lugar de seleccionar un tiempo predeterminado.
realizar esta
actividad. No Aun cuando existen talleres fijados para realizar grooming, la mayoría de los equipos
obstante, te realizan esta actividad de manera natural como parte de la revisión del sprint.
planteamos algunas
posibilidades. No siempre tienen que estar todos los miembros del equipo para
hacer grooming, sino los necesarios en cada momento.
 Algo antes de empezar y
luego cuando se necesite.

Después
Talleres durante del daily .
el sprint.

Durante la revisión
del sprint.
Como muestra,
Steve Jobs te
cuenta en este
vídeo cómo lo
hacían en
Apple.

https://youtu.be/NO7QFnGK3qs
Cuando el ítem
está “preparado”
El resultado de refinar los ítems del backlog de producto es
una serie de ítems en las posiciones más altas que están

Grooming
listos para entrar en sprint. Y tienen que estar preparados
porque, solo de esa manera, el equipo de desarrollo
puede comprometerse y completarlo al final del sprint.

Muchos equipos Scrum formalizan el estado de preparación

acordando lo que significa exactamente preparado. Tanto la
definición de preparado como la definición de terminado son,
en realidad, listas de comprobación que muestran el trabajo
que debe ser completado antes de la entrada en cada fase.

Product
Backlog
Definición de Haz

“preparado”
clic
aquí

Está claro el valor que aporta el ítem en términos de negocio.

El equipo de desarrollo entiende, de manera suficiente, los detalles del ítem como
para decidir razonablemente si lo puede completar.

Las dependencias entre ítems están identificadas y no existen dependencias externas

que puedan impedir el desarrollo del PBI.

El equipo tiene la capacidad necesaria para desarrollar el PBI.

El PBI se ha estimado y es lo suficientemente pequeño para ser completado

cómodamente en un sprint.

Los criterios para validar o no el ítem están claros y son testeables.

El equipo Scrum entiende cómo presentar el PBI en la revisión del sprint.

 Obligatorio tener: se trata de ítems que debes tener
listos y funcionales sí o sí para el lanzamiento o de lo
contrario no habrá producto que lanzar.

Flujo de lanzamientos
Estaría bien: se trata de funcionalidades que te
gustaría incluir en el siguiente lanzamiento, pero que en
Se trata de un conceptocaso de escasez
importante de recursos
que va a guiar (dinero,Atiempo,
nuestros esfuerzos. etc.)
medida que
podrásirás
trabajes en tu product backlog prescindir
refinando y de ellas y, aun
desglosando así,
nuevos tener un producto.
PBI.

¡Vamos a verlo detenidamente

No tendrá: haz clic sobre
son funcionalidades lavas
que no página!
a incluir en el
siguiente lanzamiento porque son las menos prioritarias y
las que menos valor añaden para el cliente.
Product
Backlog
 Sprint backlog
Subconjunto de objetivos/requisitos del Product
backlog seleccionados para el sprint del momento y
su plan de tareas de desarrollo. El equipo lo elabora en
la reunión de planificación del sprint (Sprint planning).
Por lo tanto, el sprint backlog es una planificación táctica del trabajo
a realizar en el sprint actual.
Esta lista permite ver las tareas donde el equipo está teniendo problemas y
no avanza, con lo que le permite tomar decisiones al respecto.
 Timeboxing
Consiste en asignar una cantidad fija y máxima
de tiempo al desarrollo de una actividad o tarea,
con el objetivo de definir claramente y limitar la
cantidad de tiempo que se dedica a cada una.
Ayuda enormemente a potenciar la motivación de los trabajadores. Les obliga
a ponerse de inmediato con la tarea asignada y centrarse de lleno en ella y el
hecho de saber que una actividad tiene un tiempo limitado y un final ya
determinado ayuda, también, a completar el trabajo de forma mucho más efectiva.
 El Timeboxing se utiliza en Scrum para todos los eventos.
Sprint

Los sprints tienen que tener una fecha fija de inicio y otra de fin y,
generalmente, todos los sprints de un proyecto tienen la misma duración.
Cada sprint comienza justo después de acabar el sprint anterior. Como norma general el sprint
no se interrumpe con cambios que puedan alterar el alcance o el personal de un sprint.
 Timebox tipo de los
Sprint
eventos de Scrum
2 semanas 3 semanas 4 semanas
Duración máxima de la reunión en horas

4 6 8

2 3 4

1,5 2,25 3

15 min. a diario
Planificación del sprint
Para determinar los ítems más
importantes que se tienen que desarrollar
en el siguiente sprint, el product owner
junto al scrum master y el equipo de
desarrollo planifican el sprint.
Objetivo del sprint
A medida que se planifica el sprint,
se decide un objetivo que es lo
que define lo que el siguiente
sprint debe conseguir.
Velocidad sostenible
Con el objetivo del sprint en mente, el equipo de
desarrollo revisa el backlog de producto y determina los
ítems de alta prioridad que el equipo puede conseguir
de manera realista en el siguiente sprint, trabajando a
una velocidad a la que el equipo se encuentre
cómodo durante un periodo extendido de tiempo.
Sprint backlog
El sprint backlog es una recopilación de las
tareas de las que se compone un sprint.
Esto se realiza para ganar confianza sobre el cumplimiento de los
objetivos dentro de plazo y, para ello, se divide el objetivo del sprint
en diferentes tareas, asociándolas al ítem que se está tratando de
desarrollar.
El equipo de desarrollo, una vez vistas las tareas, estima las
horas de esfuerzo requeridas para completar cada tarea.
Just-in-time
Esta filosofía de dividir los ítems en tareas facilita el diseño
"justo a tiempo", en el que las diferentes funcionalidades
se abordan justo cuando son requeridas.
La mayoría de los equipos Scrum que realizan sprints de entre dos
semanas y un mes de duración tratan de realizar la planificación del sprint
en entre 4 y 8 horas. Un sprint de una semana de duración no debería
llevar más de 2 horas de planificación.
Al dividir en tareas, el equipo estima la duración y se van añadiendo,
estas tareas, a medida que el equipo disponga de horas hasta que se
llegue al tope de capacidad del equipo.
Incremento de producto
Un incremento es la suma de todos los ítems del product
backlog completados durante un sprint junto al valor de
los incrementos de los sprints anteriores.
Al finalizar un sprint, el nuevo incremento debe estar "terminado o
hecho", lo que significa que debe estar en condiciones de ser usado,
independientemente de si el product owner decide lanzarlo o no.
Definición de hecho
Definition of Done (DoD)
Cuando un ítem de product backlog se describe NIVEL DE COMPRENSIÓN

MÁXIMO
como terminado, todos los miembros del
equipo deben entender lo que esto significa.

La definición de hecho nos va a permitir tener siempre un

producto “potencialmente entregable y usable” al final de
cada iteración, permitiéndonos con ello, saber en que punto real
del proyecto nos encontramos.
 La Definición de hecho
se acuerda entre

PRODUCT OWNER DEVELOPMENT TEAM

Propietario del producto Equipo de desarrollo

Al principio del proyecto y se puede ir

mejorando durante su desarrollo.
Historias de Usuario o User Stories
Una de las grandes diferencias
entre el Scrum y la gestión de
Metodologías proyectos tradicional es la Scrum
tradicionales manera en la que se recopilan y
gestionan los requerimientos
del proyecto.
 La conversación es una de las armas más
poderosas de Scrum, ya que permite
conocer mejor lo que quieren los clientes, lo
que realmente debemos hacer al llegar a cada
requisito y cada ítem del product backlog.

Los detalles de cada PBI van aumentando a medida

que cada ítem se acerca a su ejecución. Necesitamos
herramientas que nos permitan saber más acerca
de los ítems para saber lo que se debe hacer.

Para esto, lo más común en Scrum es

emplear las user stories o historias
de usuario.
Las historias de usuario son una
manera convenida de expresar el
valor de negocio para muchos
tipos de ítems de product backlog.

Tienen una estructura simple.

Las historias
de usuario se Recogen lo hablado en una conversación.
caracterizan Se pueden escribir con diferente nivel de granularidad.
porque:
Son fáciles de refinar (detallar más) progresivamente.

A pesar de todos sus beneficios, las historias de usuario no son la única manera de
representar un ítem de product backlog. Son un primer enfoque, un referente que sirve
como eje central de toda la otra información relevante y útil para detallar un requisito.
Elementos
de las historias
de usuario

01 Tarjetas

02 Conversaciones

03 Confirmación

Vídeo. Historias de usuario

https://youtu.be/-mbAXwB1q2M

Haz clic sobre cada uno

de los elementos.
 01 Tarjetas Título de user story
Como (tipo de usuario)
La idea que trasciende tras la idea de plasmar historias de usuario en quiero (funcionalidad)
tarjetas es realmente sencilla. Es plasmar un deseo de funcionalidad para (beneficio).
por parte del usuario, es decir, algo que le crea valor.
Las tarjetas no incluyen absolutamente toda la información
necesaria para desarrollar el requisito, sino que, por el contrario,
son intencionalmente pequeñas para que se sea breve en lo que se
quiere conseguir.
Posteriormente, se añade información a esa tarjeta con otras tarjetas Encontrar opiniones
o postit de manera que se consiga desarrollar esa funcionalidad.
de sitios cerca
En definitiva, las usamos para capturar la esencia de lo que se Como usuario común
quiere de manera que se alcance un entendimiento común de quiero encontrar opiniones
para quién es, lo que se solicita y cuál será el valor añadido. imparciales acerca de
restaurantes cerca de un
lugar concreto para decidir
elHaz clicsitio
mejor sobre el altavoz.
para cenar.
 02 Conversaciones
Técnicas de venta de
Las meras conversaciones, las que tienen Aaron Ross
lugar a lo largo del proyecto, pueden ser una
Como responsable de desarrollo
excelente fuente de historias de usuario. de negocio querría integrar un
Pero esto no quiere decir que lo dicho en las conversaciones sistema de automatización de
se convierta en requisito o funcionalidad per se, sino que marketing que sea consistente
pueden dar lugar a anotaciones, diseños o presentaciones con los principios del libro
que susciten el desarrollo de nuevas funcionalidades "Predictable Revenue". Más info,
relacionadas con el proyecto, comúnmente, sugiriendo la ver el capítulo "Lead Generation"
lectura de documentos adicionales que ayuden a comprender del libro, págs. 105-125.
la funcionalidad para una siguiente conversación.
 Subida de archivos
Como administrador de la red
social quiero permitir que los
creativos compartan archivos
03 Confirmación para que la generación de
contenidos gane valor.
Es una parte de la historia de usuario
con la que se sellan las condiciones que
tienen que darse para que esa
funcionalidad se dé por satisfecha.
Suele ocurrir a medida que se van conociendo más Condiciones de
detalles acerca de la funcionalidad y contiene una serie
de especificaciones más detalladas sobre la historia.
satisfacción
Verificar subida para archivos:
.txt y .doc
.jpg, .gif y .png
Verificar un tamaño de carga
máximo de 1GB para archivos .mp4
Verificar que no se suban archivos
protegidos por DRM.
Tamaño
de la historia
Dependiendo de lo que incluya la historia, es decir, de la cantidad de historias en las que se
pueda subdividir, hablaremos de diferentes tamaños de historia. Por ejemplo, la subida de
archivos se correspondería con una historia sencilla que puede arreglarse en un sprint. En otras
ocasiones, nos encontramos con historias de mucho mayor tamaño que deberán ser desglosadas
en historias más pequeñas que quepan en un sprint.
Las historias más grandes se llaman, en el entorno Scrum, como Epic, ya que se podrían
comparar en tamaño como historias épicas como El Señor de los Anillos o El Quijote.
Esta historia habría que desglosarla en
historias más pequeñas, creando sistemas de
llamada a las redes sociales en las que los
usuarios puedan hallarse actualmente,
creación de perfil desde cero, importación de
archivos, fotos y creaciones presentes en otras
redes sociales o en sus dispositivos, etc.
Existen muchos nombres para las historias
de varios tamaños, con lo que no vamos a
detallar mucho más en este sentido.
Simplemente, tener en cuenta que las historias
que no se puedan realizar en sprints diarios
no pueden ser ejecutadas directamente, sino
que deben ser desglosadas.
Sistema de creación
de perfiles
Como fundador de la red social
quiero que, los usuarios, puedan
crear sus perfiles de varias
maneras, incluyendo la
importación de perfiles desde
otras plataformas, para así
abarcar un mayor número de
potenciales usuarios.
Ejemplo de una historia Epic.
El método INVEST para
definir la buena historia
Ya que estamos sentando la base de la definición de los elementos del
product backlog a través de las historias de usuario, es conveniente saber
al menos de momento, qué es lo que hace que una historia valga como
ítem del product backlog.
I
ndependent N
egotiable V
aluable E
stimatable izedS
appropiately
estable

T
Independent (independiente)
Las historias deben ser lo más independientes posibles unas de otras, dado que cuanto más
interdependientes sean de otras, más difícil será la priorización y la estimación. Imagina, si tienes
que mover en vez de una historia cinco en el orden de prioridades porque unas necesitan de otras será
más complicado, ya que debes conseguir estimar la duración de cinco sprints en lugar de uno.

Negotiable (negociable)
Las historias, aunque muchos piensen lo contrario, no son como los requisitos formales de un proyecto
en cascada, inamovibles y a las que se debe ceñir el equipo del proyecto sí o sí. En Scrum las
historias son puntos de referencia para conversaciones en las que se acordarán los diferentes
detalles.

Valuable (valiosa o creadora de valor)

Las historias tienen que representar algo que añada valor para el cliente y/o los
usuarios. Si no aportan valor para ninguno de ellos, ¿para qué tenerla en cuenta?
 Estimatable (estimable)
Las estimaciones facilitan una indicación del tamaño y, por lo tanto, el esfuerzo y
coste de una historia para priorizarla adecuadamente en el product backlog.

Sized appropiately (bien dimensionada)

Como hemos mencionado, el tamaño de las historias tiene que ser adecuado y, a la hora de
abordar un sprint con ellas, suficientemente pequeñas.

Testable (testeable)
Las historias deben tener un sistema de testeo final binario, es decir, apto/no apto.
Esto va muy relacionado con el tamaño de la historia. Si una historia es muy grande,
probablemente no podremos someterla a este tipo de testeo. En el ejemplo que citábamos antes
de la red social, si el sistema reconoce archivos protegidos por DRM, acepta archivos hasta 1 giga,
pero no más y acepta las extensiones detalladas, sería apto y de lo contrario no apto.
 Proceso de planificación del sprint
Un lanzamiento normalmente se compone de varios sprints,
cada uno de los cuales añade valor para el cliente.
Cada sprint comienza con la planificación del sprint.
Momento en el cual, el equipo Scrum se reúne para
acordar una meta del sprint y determinar, a su vez,
qué es lo que el equipo puede entregar durante el
sprint que está por comenzar, esto es, los PBI
específicos que estén alineados con la meta del scrum
y que pueden ser entregados de manera realista.

Planificación de un sprint: entre 4 y 8 horas.

4-8h.
 PRODUCT OWNER
Propietario del producto
Comparte la meta inicial del sprint, presenta un product backlog
priorizado y responde cualquier pregunta que pueda hacer el equipo

¿Quién
acerca de los PBI.

planifica DEVELOPMENT TEAM

Equipo de desarrollo
el sprint? Trabaja entonces para determinar lo que se puede entregar y,
luego, realiza un compromiso realista al concluir la planificación.

SCRUM MASTER
Scrum máster
Observa la actividad de planificación, realizando preguntas
profundas y actúa como facilitador para asegurarse que el resultado
es exitoso. No es el encargado del equipo de desarrollo, no puede
decidir en su nombre el compromiso que se ha de adquirir, pero sí
puede retar el compromiso para asegurarse que es realista y apropiado.
Para hacer la planificación de tus sprint, vas a necesitar una
serie de entradas sobre las que decidirás:

Cuántos sprint

Qué duración tendrán

Cuál será la meta

Qué valor entregarás al final de los mismos

 Fundamentalmente, las entradas
que necesitas son las siguientes:

Refinado antes del sprint y, en el cual, los

1. Un product elementos por los que comienza la lista cumplen
con la definición de "preparado". Tienen que tener
backlog unos criterios de aceptación bien definidos y que estén
estimados, medidos y priorizados correctamente.

2. Meta de El product owner debe tener una idea bastante clara

de lo que el equipo entregará al finalizar el sprint.

lanzamiento Conocerlo ayuda al equipo a priorizar y evita que el

equipo se comprometa a más de lo que puede entregar.
 3. Velocidad
Debes conocer la velocidad a la que puede
rendir el equipo, es decir, un histórico de

del equipo
cuánto trabajo puede completar en un
sprint de duración determinada.

Existen siempre una serie de limitaciones a nivel de

4. Limitaciones negocio o a nivel técnico que pueden afectar

materialmente el valor que el equipo puede
entregar. Averigua cuáles son y cuál es su impacto.

5. Capacidad Para planificar el sprint, debes saber cuántas y

qué personas hay en el equipo, qué habilidades

del equipo tiene cada miembro y la disponibilidad de cada

individuo para el sprint que se avecina.
Que el dueño de producto sepa lo que quiere no implica que el equipo de
desarrollo sea capaz de entregarlo durante ese sprint.
Un compromiso realista solamente se consigue mediante
colaboración (y, a veces, negociación) entre el dueño del
producto y los miembros del equipo de desarrollo.
Los participantes en la planificación tienen que tener la oportunidad de
revisar y debatir sobre alternativas que puedan generar valor, además de
decidir lo que es práctico y lo que no, basado en la capacidad, velocidad y
limitaciones existentes.
 Planificación en dos partes
Una de las maneras en las que puedes abordar la
planificación del sprint es separarlo en dos partes.

Parte 1. ¿Qué? Parte 2. ¿Cómo?

En esta fase el equipo de desarrollo define
su capacidad para completar trabajo y con
estos datos pronostica los PBI que cree que
puede entregar al final del sprint.
Si el equipo cree que puede realizar 40 puntos
historia en un sprint, seleccionará PBIs que
sumen 40 puntos de historia.
En esta parte el equipo crea un plan para ganar
confianza en su capacidad de completar los PBI
pronosticados en la primera parte.
La práctica más extendida es desglosar los PBI en
una serie de tareas y luego estimar (en horas) el
esfuerzo requerido para completar cada tarea. Es
entonces cuando el equipo compara la estimación de
estas horas con respecto a su capacidad en términos
de horas para ver si su compromiso inicial era realista.
 Parte 1. ¿Qué? Parte 2. ¿Cómo?
Inicio Determinar Sí ¿Con Sí
capacidad ¿Nos podemos
comprometer? capacidad?

Pronosticar Estudiar Sellar

PBI hasta máxima si el pronóstico No No compromiso
capacidad es razonable

Refinar
objetivo Ajustar
del sprint Pronóstico
Determinar la capacidad
y velocidad del equipo
Como acabas de ver, determinar la capacidad del equipo es el primer paso de
planificación del sprint. Es por esto que debes hacerlo muy bien.

Conocer la capacidad del equipo es lo que guía al mismo para

determinar lo que puede entregar.

¡Vamos a comenzar por un supuesto!

 Si un equipo va a realizar un sprint de dos semanas (10
días), lo primero que debes asumir es que no tendrá 10
días completos para dedicar a la ejecución del sprint.

Sabemos, por ejemplo, que de las 2 semanas:

Un día (8 horas) el equipo va a estar planificando, revisando y haciendo la retrospectiva.

El equipo debe reservar un 10% del tiempo para ayudar en las tareas de grooming del product backlog.

Dedicar tiempo a otras tareas fuera del sprint, tales como mantener productos actuales o trabajar en otros proyectos.

Los miembros de los equipos necesitan un tiempo al día para ser buenos
compañeros: ir a reuniones, responder emails, ser interrumpidos, etc.

Otras consideraciones como horas necesitadas por miembros del equipo para asuntos personales deben tenerse en cuenta.

Y, por último, un "colchón" de tiempo para prever por si las cosas no salen según lo planeado es necesario.
Capacidad
total del sprint
La cantidad restante de todo esto Capacidad
es la capacidad que realmente
Para trabajar sobre los items del
tendrá el equipo para trabajar en
product backlog durante el sprint.
los PBI incluidos en el sprint.

Colchón
Otros compromisos
No relacionados con el sprint: soporte,
mantenimento y otros proyectos.

Tiempo libre personal

Actividades de apoyo al sprint
Planificación, retrospección, etc.
 Conocer estos datos para todos los
miembros del equipo es fundamental,
para que sepas la cantidad de horas
de trabajo disponibles de tu personal.

Puedes, por tanto, en este sentido saber cuánto tiempo te llevarán las tareas que
incluyas en un sprint porque podrás incluir una serie de tareas que sumen la
cantidad de horas que tiene disponible tu equipo.
Esto es lo que se llama cálculo de la capacidad del equipo en horas de
esfuerzo.
Medir la capacidad en
puntos historia o story points
Los puntos historia son una unidad de medida
para estimar el esfuerzo necesario para
implementar un PBI.
Al realizar estimaciones con puntos historia, se asigna a
cada PBI un valor numérico. Los valores en sí no son lo más
relevante, sino la relación entre los diferentes valores
asignados a los diferentes PBI, es decir, su relatividad. Que
decidas otorgar valores de 1, 2 o 3 es lo mismo que si asignas
valores de 100, 200 o 300.
Lo realmente importante que tienes que saber acerca
de los puntos historia es qué variables incluyes en el
cálculo de los mismos.
Concretamente son 3.
1. Cantidad de trabajo a realizar
2. Complejidad
3. Riesgo o incertidumbre
 1. Cantidad de trabajo a realizar

Si hay más que hacer para desarrollar un ítem que otro, con seguridad la
puntuación será más alta. Eso sí, como vamos a ver a continuación, la
diferencia de cantidad de trabajo no va a multiplicar directamente, sino que se
verá afectada por la complejidad.

Imagina que tienes que desarrollar dos webs:

◉ En una de ellas tienes que introducir un campo y una etiqueta en la que se pide que el usuario
introduzca un nombre.
◉ En la segunda página, existen cien campos que también deben ser rellenados con texto sencillo.
Esta web, obviamente, recibirá más puntos de historia porque contiene más trabajo, pero
probablemente no tendrá cien veces más puntos, ya que simplemente se trata de meter más
campos.
Como mucho, será dos, tres o diez veces más esfuerzo en el segundo caso que en el primero.
 2. Complejidad
Seguimos con el ejemplo de las webs. Tenemos por un lado el
desarrollo de una web con cien campos triviales que no tienen
interacción entre ellos.
Se trata nada más que de colocar más campos.

Ahora tienes también una web con cien campos de diferente naturaleza:
Algunos incluyen widgets de calendario, otras son celdas preformateadas para introducir DNI o número de
teléfono. Además, la web exige que existan interacciones entre los campos.
Si por ejemplo, el usuario dice ser de nacionalidad extranjera el campo DNI le pedirá una letra, siete números
y otra letra, mientras que si es español le pedirá ocho números y una letra.
Existen, obviamente, en este caso muchas más probabilidades de que el programador se equivoque y tenga
que retroceder a corregirlo.
Esta complejidad extra debe ser reflejada.
3. Riesgo e incertidumbre
El riesgo y la incertidumbre que afectan a
cada PBI deben ser incluidos a la hora de
realizar las estimaciones de puntos historia.

Por ponerlo de la manera más sencilla, si un

equipo debe desarrollar un PBI, pero el cliente no
tiene muy claro lo que necesita, es una
incertidumbre que se debe reflejar en la
estimación porque existen más probabilidades
que el cliente pida que se vuelva atrás a
corregirlo para dejarlo a su gusto.
Considerando todos los factores, se asignan
puntos de historia que al final tratan de descubrir
la distancia que debe recorrer un equipo para
desarrollar una funcionalidad.
Es una unidad abstracta que, es más ventajosa que
estimar la duración en tiempo, porque pone menos
presión en los equipos. Obviamente, los puntos
historia se acaban traduciendo en tiempo como
veremos a continuación.
La manera de calcular los puntos historia se
realiza juntando al equipo de desarrollo jugando
a un juego que se llama Poker Planning, que
veremos más adelante.
La velocidad de un equipo Scrum se
mide en la cantidad de puntos que son
capaces de cubrir en un sprint de
duración determinada.
Pero esto se ve afectado por la capacidad del
equipo en cada momento.
Es decir, si un equipo típicamente es capaz de
cubrir 40 puntos historia en dos semanas, pero
tiene que afrontar un sprint en la última semana de
diciembre y la primera de enero, la capacidad será
menor al haber días festivos en medio y, por lo
tanto, la velocidad para ese periodo concreto
también será menor.
Estimación de
Planning Poker
Recordemos, el producto backlog es una lista priorizada de
requisitos y estimada de historias de usuario. Hasta ahora
solo tenemos historias y ahora falta estimarlas y priorizarlas.

El Planning Poker es una técnica de estimación ágil. La

estimación ágil sirve para calcular (aunque sea de forma
aproximada) los tiempos, requerimientos y demás que
necesitaremos para el desarrollo de un proyecto, lo cual nos
ayudará a tomar mejores decisiones al montar y organizar la
pila de producto y la planificación de los sprints.

El objetivo del Planning Poker es obtener una medida de

tamaño relativo de todas las historias respecto a sí mismas.
La técnica del Planning Poker consiste en una especie de
juego, mediante la utilización de una baraja de Poker
modificada, por la cual, todo el equipo se reúne y van
haciendo rondas de estimación con ayuda de las cartas.
Todos los miembros del equipo se reúnen, cada uno con
una baraja, a cuyas cartas se asignan una serie de valores
(es recomendable quedarnos solo con las cartas inferiores
de la baraja).
A estas cartas se les dan los siguientes valores: 0, ½, 1, 2,
3, 5, “?” e “infinito”. Donde “0” quiere decir que el elemento
ya está hecho o no requiere esfuerzo, “?” quiere decir que
no disponemos de información suficiente para estimar el
elemento e “infinito” que es demasiado grande y habría que
separarla para poder hacer la estimación.
Dependiendo del tipo de tareas que se vayan a tratar en la
estimación, los valores podrán corresponder a días
ideales o semanas ideales, donde ideal quiere decir, ese
tiempo de trabajo llevado a cabo por una persona de forma
óptima sin ninguna distracción.
Pero lo más importante es que todos los que estén
participando en la misma estimación compartan las
mismas medidas, si no será inútil.
La técnica funciona
de la siguiente manera:
Todo el Equipo de Desarrollo se junta para realizar la
estimación, teniendo todos el mismo nivel de información
al respecto.
El Scrum Master y el Product Owner no participan
en la estimación, pero pueden resolver dudas.

Una vez reunido todo el equipo, se van planteando las

distintas tareas a realizar y cada miembro del equipo da
su estimación con su baraja.
Lo normal es encontrar rápidamente un consenso en
cuanto a la estimación, pero si no fuera así entonces se
abre una discusión, lo más breve posible hasta que el
equipo logra el buscado consenso.
De esta manera, al finalizar la sesión, la estimación habrá
sido consensuada y validada por todo el equipo de
desarrollo que deberá cumplirla después, lo cual evita
gran cantidad de problemas y malentendidos.
 Seleccionar los PBI
El paso final de la planificación del
sprint es el compromiso. Y, a lo que
se debe comprometer, es a incluir
Product Backlog items a desarrollar.
Puedes enfocar esto de varias maneras:

Si el equipo tiene una meta de sprint clara, puede optar

Product por escoger ítems que contribuyan a alcanzar esa meta.
backlog
Si por el contrario esta meta no existe, lo adecuado es comenzar
por los ítems en la parte de arriba del product backlog.

Si el siguiente ítem a abordar supera la capacidad

del equipo en ese momento, se escogería el siguiente
ítem que sí cupiese dentro de esta capacidad.
 La regla de oro de la
selección de PBI es no
comenzar lo que no se
puede acabar.

Si no vas a poder completar con un sprint el

siguiente ítem, puedes o desglosarlo en dos
nuevos ítems o como decimos escoger un
ítem que sí puedas abordar. Con todo esto,
es fundamental tener una buena
Product definición de "preparado".
backlog No caigas en la trampa de pensar que
puedes acabar en otro sprint lo que no
acabes en este, pues romperías una de
las reglas básicas de Scrum: tener un
incremento al final de cada sprint.
 La meta del sprint define y resume el valor de
Refinar el negocio de un sprint. El dueño de producto debe
objetivo del comenzar la planificación con un objetivo inicial.
sprint y Pero durante la planificación puede cambiar este objetivo
compromiso cuando el equipo defina a lo que de manera realista se puede
comprometer.
 Ejecución del sprint
La ejecución del sprint es el trabajo que el equipo Scrum
realiza para alcanzar el objetivo del sprint. Comienza cuando
acaba la planificación del sprint y termina en la revisión del sprint.
En realidad, se trata de un mini proyecto, ya que incluye todo
el trabajo necesario para entregar un incremento sobre el
producto potencialmente lanzable.
De todo el sprint la mayoría del tiempo lo ocupa la ejecución.

Se hará Descripción del proceso

hincapié Planificación de la ejecución
en 4
elementos Trabajo a realizar
clave.
Herramientas de comunicación

Haz clic sobre cada uno de los elementos para tener más información.
 Descripción del proceso
Haz clic sobre cada una de las partes del
proceso para tener una breve descripción.

Entradas Ejecución del sprint Salidas

Las entradas a la ejecución
del sprint son el objetivo del
sprint y el sprint backlog
que se han generado
durante la planificación del
sprint.
La ejecución del sprint contiene
planificación, gestión, realización
de trabajo y comunicación, para
producir estas funcionalidades
testadas y funcionales.
Gestión Realización
Planificación Comunicación
La salida de la
ejecución del sprint es
un incremento sobre el
producto
potencialmente lanzable
o entregable, es decir
una serie de PBI
terminados (de acuerdo
con la definición
establecida).
 Planificación de la ejecución

Durante la planificación de la ejecución del sprint el equipo

produce un plan para cómo conseguir el objetivo del sprint.
En la mayoría de los equipos, esto adopta la forma de sprint backlog, que
normalmente enumera una serie de PBI (Product Backlog Items) con las tareas
asociadas a estos, junto con una estimación de duración en horas de esfuerzo.

En la gestión tradicional de proyectos se realizaría una planificación al detalle de todas estas

tareas a realizar, probablemente empleando herramientas como diagramas de Gantt o similar,
Pero la realidad sobre la que trabaja Scrum asume que esto es ineficiente por varias razones:

Es poco probable que un equipo de entre 5 y 9 personas necesite una

herramienta tan complicada para saber quién y cuándo debe realizar los trabajos.

El horizonte temporal de un sprint es mucho más corto que el de un proyecto.

El diagrama de Gantt, como la mayoría de las previsiones, sería inexacta en cuanto el

sprint arrancase, ya que el aprendizaje viene siempre de construir y testear elementos.
 Planificación de la ejecución

No estamos diciendo que no tenga que tener lugar cierta planificación.

Por ejemplo, si una funcionalidad que se está creando durante un sprint tiene que ser sometida a
un test de stress durante dos días, sería adecuado que el equipo secuenciase el trabajo de
manera que este test comience al menos dos días antes de que acabe la ejecución del sprint.

Pero es realmente durante la ejecución del sprint cuando tendrá lugar la

mayor parte de la planificación de la ejecución, ya que será la experiencia
la que diga dónde y qué se debe modificar para optimizar el proceso.
Trabajo a realizar

Gestionar el flujo
de trabajo durante Sabes las tareas que tienes que realizar con el sprint
backlog, pero esto no basta, debes saber qué trabajo
la ejecución del se va a comenzar, cuándo se va a comenzar, cómo
sprint es crucial organizar el trabajo y quién lo va a hacer.
para su éxito.
 Trabajo a realizar

Qué trabajo se va a comenzar.

No te sorprenderemos si te decimos que no todos los PBI se empiezan a la vez. En un momento dado tu
equipo debe determinar qué PBI se va a trabajar a continuación.
La manera más fácil de determinar el siguiente PBI es trabajar sobre las prioridades establecidas por el
product owner en el product backlog.
Por lo menos, esto tiene la ventaja (bastante obvia) de que cualquier ítem que pueda no completarse durante
el sprint será de menor prioridad que aquellos que sí se completan.
Eso sí, no siempre podrás seguir este método porque habrá momentos en los que las capacidades disponibles
no serán suficientes para abordar el siguiente PBI, con lo que deberás optar por el siguiente ítem en el product
backlog en orden de prioridades que sí encaje con la capacidad disponible.
 Trabajo a realizar

Cómo organizar las tareas.

Una vez tu equipo de desarrollo comience a trabajar en un PBI debe, también, definir cómo se va a
realizar el trabajo sobre las tareas que lo componen. Tradicionalmente, se decidía una secuencia y se
asignaban las tareas en función a esta, decidiendo quién, cómo y qué iba a trabajar en cada momento.
Pero Scrum nace para retar el pensamiento tradicional y en este caso no cabe excepción.
En lugar de lo mencionado, el pensamiento se centra en la entrega de valor y los miembros del
equipo organizan de manera "oportunista" las tareas y quién trabajará en ellas.
Al hacer esto, minimizarás la cantidad de trabajo que queda en espera y se reduce el tamaño y
frecuencia de las "entregas" de trabajo entre compañeros.
Herramientas de comunicación

Uno de los beneficios de trabajar con fragmentos pequeños de tiempo y

con equipos reducidos es que no vas a necesitar herramientas
sofisticadas ni complejas para generar gráficas e informes para
comunicar el progreso al equipo.

En Scrum se 01 Pizarras de tareas

usan
fundamental
mente tres 02 Gráfico de trabajo pendiente
herramientas
03 Burn-up chart
En realidad, se trata de un mini proyecto, ya que incluye todo
el trabajo necesario para entregar un incremento sobre el
producto potencialmente lanzable.
De todo el sprint la mayoría del tiempo lo ocupa la ejecución.

Se hará Descripción del proceso

hincapié Planificación de la ejecución
en 4
elementos Trabajo a realizar
clave.
Herramientas de comunicación
 Herramientas de comunicación
Uno de los beneficios de trabajar con fragmentos pequeños
de tiempo y con equipos reducidos es que no vas a necesitar
herramientas sofisticadas ni complejas para generar gráficas e
informes para comunicar el progreso al equipo.

En este sentido, en 01 Pizarra de tareas

Scrum se usan
fundamentalmente 02 Gráfico de trabajo pendiente o Burn down
3 herramientas: 03 Gráfico Burn up
Pizarra de tareas
La pizarra de tareas es una manera simple, pero potente de
comunicar el progreso en los sprints de un vistazo. Formalmente,
muestra el estado evolutivo del sprint backlog a lo largo del
tiempo.

PBIs Pendiente En curso Hecho

to do In progress Done
 PBIs - En esta pizarra se muestran las tareas de cada Product Backlog Item en el que se
va a trabajar en el sprint bajo las categorías de "pendiente", "en curso" y "hecho".

PENDIENTE/TO DO - Todas las tareas comienzan en la columna de "pendiente" y se van

moviendo hacia la derecha.

EN CURSO/IN PROGRESS - Cuando una tarea se encuentra en la columna de

"en curso", se entiende que es una tarea en la cual se está trabajando.

HECHO/DONE - Cuando está completada, se mueve a la columna de "hecho“.

Puedes optar por hacer tu pizarra de tareas de
manera física o digital.
En cuanto a la manera física, si haces clic sobre a
imagen puedes acceder a una explicación de
cómo hacer una pizarra de tareas, con unas
consideraciones muy interesantes sobre el uso y
confección de la propia herramienta.
https://proyectosagiles.org/2010/09/26/ejem
plo-tablero-pizarra-tareas-scrum-taskboard/

Por otro lado, la gestión digital es una opción muy

interesante si trabajas con equipos distantes
geográficamente o ubicados en espacios
distintos. Nosotros optamos por la herramienta
Trello, un software SaaS de gestión de proyectos
cuyo uso es parcialmente gratuito. Puedes acceder
a la herramienta haciendo clic sobre la imagen.

https://trello.com/
 Gráfico de trabajo
pendiente
o Burn down
El gráfico Burn down nos muestra la velocidad a lo largo del
tiempo a la que se está completando los objetivos/requisitos.
De esta manera podremos saber si el equipo podrá acabar el
trabajo en el tiempo estimado.
Podemos
utilizar 2 tipos
de gráficos de
trabajo Haz
pendiente. clicaquí.
Durante cada día de la ejecución del sprint los miembros del equipo actualizan la
estimación de cuánto esfuerzo queda para completar cada tarea que no ha sido
completada todavía.

Se puede crear una tabla de lanzamiento de datos para

visualizar esta información.

¡Vamos a ver un ejemplo!

Te proponemos
un ejemplo de
un sprint de
quince días que
inicialmente
tiene treinta
tareas (para
simplificar solo
se muestran
algunas de las
tareas y días).
El número de horas que le restan a cada tarea sigue la tendencia general de
mermar durante cada día del sprint, porque se está trabajando en estas tareas y
se están completando. Si una tarea no se ha comenzado todavía (permanece en la
columna de "pendientes") no variará en tiempo de un día para otro durante un
número de días. También conviene señalar que una tarea puede acabar requiriendo
más esfuerzo del inicialmente planteado y si esto pasa se pueden no alterar o,
incluso, aumentar las horas de un día para otro.
Como se ve en el caso de la tarea 7, se pueden añadir tareas a esta herramienta en
cualquier momento del sprint si se descubre que es necesaria durante el transcurso del
sprint. No existe una razón real para evitar añadir una tarea al sprint backlog, pero se
tiene que hacer solo si se descubre una tarea necesaria para llegar al objetivo del sprint,
no como trampa para cambiar el objetivo y alcance del resultado del sprint.
El número
total de horas
de esfuerzo
pendientes
en cada día
del sprint se
puede utilizar
para ilustrar
gráficamente
el trabajo
pendiente.
Y como el total de
horas puede variar
por distintos
motivos e incluso
aumentar de un día
para otro (lo
puedes ver en la
tabla que ya hemos
mostrado), puedes
usar esta gráfica
para analizar las
desviaciones que
existen entre la
progresión deseada
y la real.
 "A TIEMPO", describe la línea según las estimaciones. Recuerda que esto lo puedes
estimar sabiendo las horas de cada tarea en sucesión normal con las capacidad en horas de
esfuerzo que tiene tu equipo.

"Anticipado", describe la progresión en el caso de que avance más rápido de lo

previsto. Es una buena señal hasta cierto punto, pero si se está acabando demasiado
rápido quiere decir que la estimación está siendo demasiado conservadora y que, por lo
tanto, se están dejando de incluir cosas que se podrían haber añadido al sprint.

"Con retraso", que indica que el progreso está siendo peor de lo esperado. Es el peor
de los escenarios posibles, ya que implicaría no llevar a cabo un incremento a tiempo como
resultado del sprint. Puede ser indicador de estimaciones mal realizadas, mala planificación
o pobre previsión de eventualidades.
Tanto el sprint backlog como la gráfica de trabajo pendiente (como indica el
nombre de esta última) solamente muestran el esfuerzo realmente invertido, ya
que en Scrum no existe una razón concreta para capturar los esfuerzos
realizados. De todas maneras, se puede tratar de calcular estas cifras con fines
contables o administrativos.
 Gráfico
Burn up
De manera análoga a la gráfica de trabajo pendiente, en Scrum
usamos el burn up chart como manera alternativa para visualizar el
progreso en un sprint. Realmente representa la cantidad de
trabajo completado hacia la consecución del objetivo del sprint.
En esta gráfica
mediremos el
trabajo
realizado en
puntos
historia, ya que
en realidad se
están midiendo
los PBI
terminados
durante el
sprint.
En la gráfica, tenemos tres líneas. El significado de cada leyenda es:

“El OBJETIVO”, es decir, todos los puntos historia previstos por planificar en el sprint.

COMPLETADO, indica el progreso en puntos historia hasta llegar al objetivo que se

marca en el sprint..

“MAL FLUJO" es un ejemplo de cómo no se llega a producir el valor necesario durante el

sprint.
Esto puede ocurrir por varios motivos:
❖ Se empieza a trabajar sobre muchos PBI a la vez. En Scrum la multitarea no tiene cabida porque
realizar trabajo en paralelo disminuye la velocidad.
❖ El equipo pospone la finalización de trabajos para más tarde en el sprint.
❖ El equipo comienza por PBIs demasiado largos que demoran la adición de valor.
En otras palabras, lo que se mide con esta herramienta es el trabajo con valor para
el negocio que se ha completado durante el sprint. Esta diferencia es importante
porque nos ayuda a discernir entre esfuerzo y valor. A veces, lamentablemente, se
trabaja mucho y con mucha intensidad para no entregar valor y es una práctica que
debemos evitar.
La inspección y adaptación
es una fase clave de la metodología Scrum, porque en todo
momento se está tratando de dar valor a los clientes de la
manera más rápida y eficiente posible.
 Es una reunión que tiene lugar diariamente durante no más de
15 minutos y que generalmente se realiza de pie (para
asegurarse que no se alargue más de la cuenta).

La daily Scrum es un Su finalidad es inspeccionar el Para que sea más

evento de Scrum trabajo desde el último daily fácil, la reunión
que se realiza Scrum y crear un plan para las tendrá lugar
diariamente durante siguientes 24 horas. Esto se siempre en el
la ejecución del realiza inspeccionando el trabajo mismo lugar y a
Sprint. y anticipando lo que se podrá la misma hora.
hacer en el siguiente.

15 min.
 El equipo de desarrollo usa el daily Scrum para
inspeccionar el progreso hacia los objetivos y
para inspeccionar cómo se progresa hacia la
consecución del trabajo que hay en el sprint
backlog. Por tanto, podemos decir que el daily
sprint aumenta las posibilidades de que el equipo
alcance los objetivos.
El scrum master se encarga de que estas
reuniones tengan lugar, pero no participa
activamente en ellas. Es el equipo de desarrollo el
que de manera autoorganizada, coordina y dirige
estas reuniones. Por otra parte, el scrum master
es el que enseña al equipo a mantener estas
reuniones dentro del tiempo limitado de 15
minutos.

15 min.
Beneficios
de hacer
Mejoran la comunicación.
Eliminan la necesidad de
mantener otras reuniones.
Identifican rápidamente
impedimentos para poderlos eliminar.

Dan importancia y promocionan la

toma rápida de decisiones.
Mejoran los conocimientos del
equipo sobre el proyecto.
La reunión diaria o daily standup meeting es una
reunión que tiene lugar de manera muy breve y a
diario.
Los equipos se juntan durante no más de 15 minutos
para explicar su progreso en el sprint y planificar las
actividades del día.
Todos los miembros del equipo Scrum tienen que
asistir a la reunión, pero si por algún motivo algún
miembro no puede acudir la reunión no se cancela.

15 min.
 Las tres preguntas diarias
En la reunión, con el Scrum master como facilitador, cada
miembro del equipo Scrum responde a las siguientes tres
preguntas:

01 ¿Qué completé ayer?

02 ¿Qué completaré hoy?

03 ¿Qué impedimentos u obstáculos me encuentro?

15 min.
 Existirán debates acerca de las diferentes cuestiones que surjan dentro
de estas tres preguntas y conviene que esto ocurra, pero debe suceder
después de la reunión diaria para asegurarse de que esta sea corta.

Al centrarse en las preguntas mencionadas, el equipo tiene una

comprensión clara del estado del trabajo. Ocasionalmente, se tratarán
otras cuestiones, pero esto deberá ser mínimo para mantener la corta
duración de la reunión.

Se recomienda que las primeras dos preguntas sean respondidas de manera

cuantificable, siempre que sea posible, en lugar de dar respuestas largas y
cualitativas. Los miembros del equipo pueden organizar reuniones
adicionales después del daily meeting si estiman que deben abordar
asuntos que necesitan discusión adicional.

15 min.
 Si un programador dice "hoy, terminaré el módulo
de almacenamiento de datos", todos sabrán que
en la reunión del día siguiente dirá si lo ha
acabado o no. Esto tiene el maravilloso efecto de
ayudar al equipo a darse cuenta del significado de
estos compromisos y, sobre todo, que se están
comprometiendo con los compañeros del equipo y no
con algún cliente o vendedor que está lejano en el
horizonte temporal.
Los impedimentos que surjan en la reunión tienen
que ser resueltos por el Scrum master tan pronto
como sea posible.

15 min.
Los impedimentos más típicos son:
Se me ha roto el ___________ y necesito uno nuevo hoy.
Todavía no tengo el software que pedí hace un mes.
Necesito ayuda resolviendo el problema ____________.
Me está costando aprender ______________ y me gustaría
que me emparejaran con alguien en ese campo.
No puedo contactar con el soporte técnico del proveedor.
Nuestro nuevo contratista no puede empezar porque no hay
nadie aquí para firmar el contrato.
El grupo _________ no me concede una reunión que necesito
mantener con ellos.
El subdirector de mi departamento me ha pedido que trabaje
en otra cosa "durante un día o dos".
 En los casos en los que el Scrum master no pueda eliminar los
impedimentos él mismo (esto suele ocurrir cuando se trata de impedimentos
de complejidad técnica elevada) asume la responsabilidad de encontrar la
persona que lo pueda resolver y asegurarse de que lo hace.
La gran mayoría de los equipos comienzan la reunión con un miembro
respondiendo a las tres preguntas, luego otro, etc.
Una alternativa interesante es hablar sobre los diferentes PBI durante la
reunión.
De esta manera cada miembro del equipo puede dar información a sus
compañeros varias veces durante una reunión.

15 min.
 Vídeo. Un daily meeting en Google.

15 min. https://youtu.be/78EDC9oAelY
4.1.1. Reunión diaria (7)

El lugar de
la reunión
Lo ideal es que los equipos se hallen en la
misma localización física. Comúnmente se
llama a esta zona, Habitación de Guerra.
Normalmente, se diseña de manera que los miembros del
equipo se puedan mover libremente, además de trabajar y
comunicarse con facilidad al colocarles cerca unos de otros.
Se provee al equipo de herramientas manuales y poco
tecnológicas para facilitar el flujo de trabajo, la colaboración
y la resolución de problemas. Estas herramientas incluyen
tarjetas, notas autoadhesivas, tableros, etc.
 Esta estancia a menudo es ruidosa debido a las
conversaciones de los equipos, pero lo cierto es que
estas conversaciones contribuyen mucho al progreso
del equipo. Una buena Habitación de Guerra carece
de limitaciones espaciales (cubículos y despachos) y
permite que el equipo se siente junto para que pueda
tener lugar mucha comunicación cara a cara, lo que
hace que se consolide el equipo y haya transparencia.

Los miembros interesados de otros

equipos Scrum también están
invitados a la Habitación de Guerra
para tratar asuntos relevantes.

15 min.
Características de un
buen daily meeting
Tiene lugar por la mañana.

Ayuda a comunicar qué está pasando.

Ayuda a identificar problemas.

Ayuda a enfocar objetivos correctos

y a reforzar el espíritu de equipo.
4.1.1. Reunión diaria (9)
Tiene lugar por la mañana

El daily meeting debe nutrir al equipo de energía y de ganas de comerse el

mundo.

¿Por qué?
Si el propósito del daily meeting es sentar los objetivos del día, no tendría realmente sentido
hacerlo en otro momento, ni siquiera a última hora para cerrar el trabajo del día siguiente porque
el compromiso se diluye de un día para otro.
El daily meeting trata de hacer un compromiso de lo que voy a hacer hoy y de lo que rendiré
cuentas mañana, no de lo que haré mañana y rendiré cuentas al final del día. Parece lo mismo,
pero no lo es.
Ayuda a comunicar qué está pasando

Ya lo hemos dicho, el daily meeting va sobre compartir información y que

el equipo esté al tanto de todo lo que está ocurriendo durante el sprint.
4.1.1. Reunión diaria (10)
Ayuda a resolver y compartir problemas

Respondiendo a la pregunta sobre los impedimentos que se encuentra

cada uno, se hace que los demás miembros del equipo sean conscientes,
se escuchen y empaticen. Pueden, además, conocer problemas que otros
tienen que ellos pueden solucionar. Nadie puede ayudarte a solucionar
problemas que desconoce.
Ayuda a enfocar objetivos y a reforzar el espíritu de equipo

Cuando mejor funciona un equipo es cuando le motiva una causa. Lo

que une a un equipo no es el dinero, no es la jerarquía, sino, perseguir una
meta común.
 Scrum de Scrum
Scrum de Scrum es una técnica que permite escalar el
enfoque Scrum para grandes equipos. La división de el gran
equipo inicial en varios equipos pequeños Scrum, nos
permite, más tarde realizar las reuniones Scrum de Scrum
para una coordinación.
En estas reuniones Scrum de Scrum, acuden uno o
dos integrantes de cada equipo (dos es ideal).
 Revisión del sprint
La revisión del sprint es un evento Scrum que tiene
lugar al final del sprint y que tiene como objetivo
inspeccionar y adaptar el incremento producido.
En esta reunión, el equipo Scrum y los stakeholders colaboran
sobre lo que se ha llevado a cabo en el sprint.
Tomando como punto de partida el trabajo realizado en el sprint y
los cambios realizados durante ese periodo de tiempo sobre el
product backlog, los asistentes a la reunión debaten sobre
nuevas ideas que puedan crear valor. Es una reunión informal
en la cual se presenta el incremento para obtener feedback y
colaboración.
Como máximo, es decir, para sprints de un mes, la reunión
puede durar 4 horas.
2-4h.
El scrum master se asegura de que esta reunión tenga lugar y que
todos los participantes entienden su finalidad. El scrum master también
debe instruir a todos en cómo mantenerse dentro del tiempo estipulado.

El resultado de la revisión del sprint es un product backlog

revisado que define los PBI en los que probablemente se
trabajará durante el siguiente sprint. El product backlog puede
ser ajustado para aprovechar nuevas oportunidades.
Durante la reunión de revisión del sprint se inspecciona y adapta
el resultado del trabajo realizado en el sprint, es decir, el incremento
de producto potencialmente lanzable. Esto ocurre cerca del final de
cada ciclo de sprint, justo después de la ejecución y justo antes de la
retrospectiva.
La revisión del sprint da, a cada participante en la misma, una
oportunidad para estudiar el esfuerzo realizado en el desarrollo de
producto hasta el momento y también la oportunidad de inspeccionar
y adaptar lo que se ha construido hasta el momento.
Revisión del sprint (2)

La revisión del sprint consta de las siguientes características:

Los participantes son el equipo Scrum (Scrum master y equipo de desarrollo) y

los principales stakeholders, invitados por el dueño de producto.

El dueño de producto explica qué PBI se han terminado y qué PBI no se han
terminado.

El equipo de desarrollo explica lo que fue bien durante el sprint, qué problemas
se encontraron y cómo se resolvieron esos problemas.

El equipo de desarrollo presenta lo que está terminado y responde a preguntas

acerca del incremento.
Revisión del sprint (3)

El dueño de producto habla sobre el product backlog en su estado actual y proporciona

fechas estimadas de compleción basados en el progreso realizado hasta la fecha.
El grupo completo colabora en lo que se debe hacer a continuación, de manera
que el sprint review proporcione información valiosa para planificar siguientes sprints.

Se revisa cómo ha podido cambiar el mercado del producto durante el sprint y

cuáles son las cosas más valiosas en las que se pueden trabajar a continuación.

Se revisa la secuencia de trabajo, el presupuesto, las capacidades potenciales y el

mercado para el siguiente lanzamiento.
4.1.2. Revisión del sprint (2)

Participantes
En el sprint review el equipo Scrum consigue valioso
feedback de personas que no están con el equipo
durante la ejecución de manera diaria.
Para estas personas la revisión del sprint es la primera oportunidad que
tienen para ver y hablar sobre el trabajo que se ha producido durante el
sprint. Por lo tanto, la revisión debe ser atendida por todas las partes
interesadas, las cuales pueden venir de muchas fuentes.
 Citamos en la tabla resumen las principales fuentes:

Stakeholders Otros equipos Stakeholders

Equipo Scrum
El dueño de producto, el
Scrum master y el equipo
de desarrollo deben estar
presentes para oír el
mismo feedback y poder
responder cuestiones
sobre el sprint y sobre el
incremento de producto.
There are many variations
operaciones
negocio
internos internos externos
Ventas, marketing, soporte,
Los dueños de la empresa,
jurídico y otros equipos de Clientes externos,
directivos y gerentes deben
desarrollo (tanto Scrum usuarios y socios pueden
ver el progreso de primera
como no Scrum) pueden dar un feedback muy
mano para poder sugerir
querer atender las valioso al equipo Scrum
correcciones. Para el
revisiones de sprint para y otros asistentes.
desarrollo interno de
ofrecer feedback específico
productos, se debe contar
relacionado con sus áreas o
con Goes
Title usuarios
Hereinternos, Title Goes
para Here
sincronizar el Title Goes Here
trabajo
expertos en la materia del
de suvariations
There are many equipo conThere
el equipo
are many variations
desarrollo y dirección de
of passages ofde
lorem of passages of loremScrum. of passages of lorem
la función de
ipsum
available
cuyas necesidades seipsum available ipsum available
está tratando de satisfacer
con ese producto.

01 02 03 04
 4.1.2. Revisión del sprint (4)

Preparación de la reunión
Aunque la reunión de revisión del sprint es informal, el equipo
Scrum debe llevar a cabo cierto grado de preparación.
Para preparar la reunión, el equipo debe:

01 Determinar a quién invitará a la reunión.

La idea es conseguir reunir al conjunto correcto de personas para
poder extraer la mayor cantidad de valor posible del evento. A no ser
que exista una buena razón para omitir a alguien o a algún grupo, se
debe reunir una red amplia y dejar que la gente vote con los pies.
4.1.2. Revisión del sprint (5)

02 Programar la actividad.
La revisión debe ser programada, es decir, se debe saber cuándo, dónde y
cuánto durará la reunión. De todas las reuniones relacionadas con el sprint, la
revisión es la más difícil de programar porque incluye a muchas personas
de fuera del equipo Scrum.

03 Confirmar que el trabajo del sprint está terminado.

Durante la revisión del sprint el equipo solo puede presentar trabajo terminado, es
decir, el que coincida con la definición que se ha hecho de terminado. Esto quiere
decir que antes de la reunión alguien debe haber determinado qué PBI están
terminados o no, porque de otra manera el equipo no sabría qué presentar.
04 Preparar la presentación.
Esto no debería tomar mucho tiempo porque todo el trabajo que el equipo presenta está
terminado. El objetivo es dar transparencia para inspeccionar y adaptar el producto,
no realizar una presentación espectacular que deje a todos boquiabiertos. De hecho, la
mayoría de los equipos normalmente establecen un tope de 30 minutos para preparar la
presentación del producto.

05 Determinar quién hace qué.

El equipo debe decidir qué miembro del equipo Scrum va a ejercer de facilitador en la
reunión. Normalmente es el Scrum master, pero el dueño de producto realizará una
pequeña introducción dando la bienvenida a los stakeholders y dando un breve resumen
previo de los resultados del sprint. Para enseñar el funcionamiento del producto en sí, lo
mejor es que los miembros que han estado desarrollando el producto hagan la
demostración.
 Enfoque
Sprint Product
Entradas Salidas backlog
backlog
refinado
Objetivo de
sprint Plan de
lanzamiento
Incremento s
de producto actualizado

Un enfoque común para llevar a cabo la revisión contiene: un

resumen o sinopsis sobre lo que no se ha conseguido con
respecto al objetivo del sprint, presentar el incremento y
hablar sobre el estado actual del producto para realizar
adaptaciones en la nueva dirección del producto.
¡Vamos a analizar cada una de ellas!
1. Resumen
La revisión de sprint comienza con un miembro del equipo de Scrum
(con frecuencia el dueño de producto) presentando el objetivo de
sprint, los elementos de la cartera de productos asociados con
el objetivo de sprint y una visión general del incremento del
producto al que se llegó durante el sprint.
Esta información proporciona un resumen o una sinopsis de cómo
los resultados del sprint se corresponden con el objetivo del sprint.
Si los resultados no coinciden, el equipo Scrum da las explicaciones
pertinentes. Es importante que la revisión de sprint no se convierta en
una caza de brujas. Si el objetivo no se ha cumplido, todos los
participantes deben abstenerse buscar culpables. El objetivo de la
revisión es describir lo que se ha logrado y luego usar la
información para determinar el mejor curso de acción para
determinar el mejor curso de acción para avanzar.
2. Demostración
La revisión de sprint es frecuentemente mal etiquetada, la
"demostración del sprint" o simplemente "la demo".
Aunque una demostración es muy útil en la revisión de sprint, la
demo no es el objetivo de la revisión de sprint. La demostración
de lo que realmente se ha construido es, simplemente, una manera
muy eficiente para energizar la conversación en torno a algo
concreto. Nada centra la conversación sobre algo como poder ver
su funcionamiento.
Pero, ¿y si no hay nada que enseñar? Si el equipo no ha
conseguido hacer nada y no hay nada que mostrar, la revisión de
sprint probablemente se centrará en por qué no se ha hecho y
cómo el trabajo futuro se verá afectado por la falta de progreso
durante este sprint.
3. Conversión
Enseñar el incremento de producto se convierte en una base
sobre la cual tener una conversación profunda. Se anima a
que los participantes realicen observaciones,
comentarios y debatan sobre el producto y la dirección
del mismo. La revisión del sprint, sin embargo, no es el lugar
para la resolución profunda del problema.
El debate intenso permite a los participantes que no están en
el equipo Scrum hacer preguntas, entender el estado actual del
producto y ayudar a guiar el rumbo.
Al mismo tiempo, los miembros del equipo Scrum aumentan el
conocimiento sobre el lado del negocio y de la comercialización
de su producto obteniendo feedback a raíz del contacto entre el
producto y los clientes o usuarios.
4. Adaptar
Mediante la demostración y la conversación, el equipo debe ser
capaz de realizar preguntas como las siguientes:
¿Les gusta a los stakeholders lo que ven?
¿Quieren ver cambios?
¿Es lo que estamos construyendo una buena idea para el
mercado o para los clientes internos?
¿Estamos pasando por alto alguna funcionalidad importante?
¿Estamos sobre desarrollando o invirtiendo en una
funcionalidad en la que no debemos invertir?
Preguntar y responder a estas preguntas facilita información sobre
cómo adaptar el product backlog y los planes de lanzamiento.
4.1.2. Revisión del sprint (12)

La mayoría de los equipos hacen algo de grooming durante la revisión de sprint. Dado que
todos los participantes aumentan la comprensión sobre el esfuerzo de desarrollo y su rumbo con
frecuencia de estas reuniones se sale con nuevos PBI o con antiguos PBI eliminados o re
priorizados. Esto afectará a cómo trabajará el equipo en el siguiente sprint.
La revisión de sprint también es posible que cambie otros factores pertenecientes al marco
más amplio del proyecto. Basándose en las conclusiones obtenidas de una revisión de sprint el
dueño de producto puede decidir alterar una de las variables claves de la planificación del
lanzamiento: alcance, fecha o presupuesto. Si por ejemplo, se decide dejar de trabajar en una
funcionalidad considerada hasta el momento clave para el producto, se estaría cambiando el
alcance.
 Retrospectiva de sprint
La retrospectiva de sprint es una oportunidad para que el
equipo Scrum pueda inspeccionarse a sí mismo y
pueda crear un plan de mejoras a implementar en el
siguiente sprint.
La retrospectiva de sprint ocurre después de la revisión de sprint
y antes de la siguiente planificación de sprint y debe tener una
duración de entre 3 y 4 horas en el caso de sprints de un mes.
El scrum master debe asegurar que la reunión tenga lugar y que los
participantes entiendan su cometido y les instruye sobre cómo ceñirse
al tiempo estipulado. En esta reunión el Scrum master participa como
un miembro más como responsable del proceso Scrum.

1,5-3h.
El objetivo de la
retrospectiva de sprint es:

Inspeccionar cómo el último sprint ha funcionado en

cuanto a personas, relaciones, procesos y herramientas.

Crea un plan para implementar mejoras sobre cómo

trabaja el equipo Scrum actualmente.

Identifica y ordena los PBI importantes que han ido

bien y las potenciales mejoras a implementar.
Retrospectiva de sprint (2)

El Scrum master anima al equipo a mejorar dentro del marco de trabajo de procesos Scrum,
su proceso de desarrollo y las prácticas que pueden hacer Scrum más efectivo y placentero
para el siguiente sprint.
Durante cada retrospectiva de sprint se planifican modos de mejorar la calidad
del producto adaptando la definición de "terminado" según convenga.

Al final de cada retrospectiva, el equipo Scrum debe haber identificado mejoras para
implementar en el siguiente sprint. Implementar estas mejoras es la adaptación de la
inspección del equipo Scrum en sí mismo.
Aunque las mejoras pueden implementarse en cualquier momento, la
retrospectiva plantea una oportunidad formal para centrarse en la inspección y
la adaptación.
La retrospectiva del sprint da a todo el equipo una
oportunidad para pararse y pensar.
Dentro de este marco los equipos pueden:

Examinar lo que está pasando.

Analizar la manera en que trabajan.

Identificar posibles mejoras.

Hacer planes para implementar estas mejoras.

4.1.3. Retrospectiva de sprint (2)

Cualquier cosa que afecta la manera en la que el equipo crea el

producto está sujeta a escrutinio y debate, incluyendo:

Procesos Comunicación Artefactos

Prácticas Ambiente Herramientas

Otros
 La retrospectiva de Sprint es una de las prácticas más importantes,
pero menos apreciadas, en el marco de trabajo de Scrum:

Se infravalora
Es importante porque los
porque da a los equipos piensan
equipos la que les roba
oportunidad de tiempo de trabajo
adaptarse a sus real, es decir, de
circunstancias desarrollo,
únicas. construcción y
testeo.

La retrospectiva de sprint supone una contribución crucial a la mejora continua que

ofrece la metodología Scrum. Mientras que algunas empresas y metodologías esperan
hasta el final de un largo desarrollo para conducir una retrospectiva, los equipos Scrum
realizan retrospectivas todas y cada una de las veces que finalizan un sprint.
4.1.3. Retrospectiva de sprint (4)

Dado que el equipo Scrum se reúne al final de cada Sprint para inspeccionar y adaptar el
proceso Scrum, puede aplicar lecciones aprendidas desde muy pronto dentro del proceso
de desarrollo y, por lo tanto, alterar de manera significativa el resultado del proyecto.
De manera muy sencilla una retrospectiva de Scrum tiene como
objetivo que los miembros del equipo se reúnan y debatan sobre
cuestiones tales como:
¿Qué ha funcionado bien durante este sprint y,
por lo tanto, continuaremos haciendo?
¿Qué no ha funcionado y vamos a dejar de hacer?

¿Qué deberíamos empezar a hacer o mejorar?

Trabajo previo

Antes de realizar la retrospectiva de sprint se debe realizar

algo de trabajo previo, que para los casos de sprints de corta
duración será también una preparación bastante sencilla.

01 Definir el centro de la retrospectiva

Cada retrospectiva de Sprint debe tener un centro en el

que enfocarse bien definido. Por norma general se trata de
revisar todos los aspectos relevantes del proceso Scrum que
el equipo ha usado durante el sprint que acaba de terminar.
4.1.3. Retrospectiva de sprint (8)

De cualquier modo, hay ocasiones en las que un equipo decide centrarse en lo que
actualmente es crucial para el equipo y donde las mejoras son más necesarias, como
por ejemplo:
Centrarse en cómo mejorar las habilidades del equipo con desarrollo guiado por pruebas.
Centrarse en porque con frecuencia se construye en lo que se cree que el cliente
quiere, pero el cliente cree que no se ha entendido bien sus deseos o que se han pasado
por alto aspectos importantes de los requisitos.
Establecer y comunicar el centro de la reunión antes de la retrospectiva permite que el
equipo Scrum determine tres cosas:
Si es necesario invitar miembros del equipo no relacionados con Scrum.
Seleccionar los ejercicios adecuados.
Preparar la información necesaria para asegurar que la reunión es fluida.
4.1.3. Retrospectiva de sprint (9)

02 Seleccionar los ejercicios

Una vez sabemos el centro de la reunión y quiénes eran sus

participantes podemos determinar qué ejercicios ayudarán a los
participantes a engancharse, pensar, explorar y decidir todos juntos.
Una retrospectiva típica incluye los siguientes ejercicios:
Crear una línea de tiempo con los eventos que han ocurrido en el sprint.
Realizar una tormenta de ideas sobre las percepciones.
Crear grupos y votar sobre las percepciones fruto de la tormenta de ideas.

De cualquier modo existen numerosos ejercicios que puedes aplicar a

tus retrospectivas de sprint. Para más información te recomendamos que
hagas clic en este enlace en el que podrás encontrar muchos de ellos.
4.1.3. Retrospectiva de sprint (10)

03 Recopilar datos objetivos

Dado que la retrospectiva de sprint se realiza de una manera enfocada y

en un corto período de tiempo, cualquier trabajo destinado a recopilar
los datos necesarios debe ser realizado antes de que comience la
retrospectiva.

Los datos objetivos no son opiniones con lo cual debes

esforzarte en identificar los eventos que han pasado, cuándo han
pasado, los PBI que se han comenzado, pero no se han acabado, la
lectura de los gráficos de progreso, etc.
04 Estructurar la retrospectiva

La duración de la retrospectiva se ve condicionado por factores tales como el número de

personas del equipo, el tiempo que lleva junto el equipo, si existen miembros en otras
localizaciones de la empresa, etc.
El equipo Scrum debe escoger un lugar en el que celebrar la reunión que les
ayude a producir un resultado exitoso. Algunos equipos prefieren realizar las
retrospectivas en donde se halla normalmente el equipo, ya que tienen acceso a
los diferentes gráficos de progreso y eso les da mucha información.
Otros prefieren realizar la reunión en un entorno de menor saturación
emocional en el que el equipo se pueda sentir menos inhibido y más
libre para expresar sus opiniones. De cualquier modo, el lugar de la
reunión no es tan importante como el que los miembros del 1,5-3h.
equipo se sientan seguros y libres para expresarse.
Enfoque
Las entradas para la retrospectiva del sprint incluyen
el foco acordado para la reunión y todos aquellos
ejercicios y materiales que el equipo quiera usar
durante la retrospectiva. Además de esto, la mayoría de
las retrospectivas necesitan, por lo menos, algunos datos
objetivos ya recopilados. Otra entrada es una recopilación
de las percepciones obtenidas en anteriores reuniones de
retrospectiva.
Las salidas de la retrospectiva incluyen un
conjunto de acciones concretas de mejora que
el equipo acuerda implementar para el siguiente
sprint. Otras salidas pueden incluir una recopilación
de percepciones de la presente retrospectiva que el
equipo puede decidir no incluir en el siguiente
sprint, pero si en un futuro cercano. Los miembros
del equipo también deberían salir de la retrospectiva
más cohesionados.
 Aunque existen muchos enfoques para
retrospectiva, la mayoría deben tratar de
responder a las siguientes preguntas:
Qué ha funcionado bien durante este
sprint y, por lo tanto, seguiremos haciendo

Qué no ha funcionado bien y,

por lo tanto, dejaremos de hacer

Qué debemos empezar a hacer o mejorar

4.1.3. Retrospectiva de sprint (14)

Cierre de la
retrospectiva
Una vez que se determinan las acciones de
mejora, los participantes cierran la retrospectiva.
Frecuentemente, se cierra recapitulando qué
acciones ha decidido tomar el equipo, basándose
en lo que han aprendido los participantes. Esto
puede ser algo tan sencillo cómo describir el
compromiso con cada acción y quién va a
trabajar en ello.
Moralmente, el cierre es un
momento excelente para
agradecer a todos por su
trabajo y participación. Cada
participante debe expresar unas
palabras de reconocimiento de
las aportaciones realizadas por
los demás participantes.
Finalmente, es una buena idea
emplear unos minutos pidiendo
al equipo que realicen
sugerencias sobre cómo se
podrían mejorar las futuras
retrospectivas. La retrospectiva
es, después de todo, parte del
marco de trabajo Scrum y, como
tal, debe ser objeto de inspección
y adaptación.
Introducción a equipo SCRUM
https://vimeo.com/326546030/b046a30092
Los roles en la
metodología Scrum
Por las características
de las herramientas y
las diferentes fases
de Scrum podemos
hablar de
roles
del equipo
SCRUM
 Equipo de
desarrollo o
Development
team
Propietario del
producto o Grupo de personas que tiene
Product owner
Scrum
como cometido realizar las
tareas necesarias en las
Este rol es el último
responsable de que todos
que se dividen las historias
de usuarios. La gran
Master
los incrementos añadan diferencia con respecto a los
valor al producto conforme equipos tradicionales es que Es una figura que tiene como
a las necesidades de los tiene que componerse de finalidad asegurarse que se
clientes, usuarios y miembros multidisciplinares y cumplen los preceptos de
stakeholders internos. autoorganizados. la metodología Scrum.
Propietario
del producto o
Product owner
El dueño de producto
es la persona con
más poder y
responsabilidad en
cuanto al liderazgo
del producto.
 Introducción El product owner tiene que estar, constantemente, mirando en
Propietario del dos direcciones, la de su propio equipo scrum, por un lado y, la
producto o de los stakeholders por otro, quienes están formados por:
Product owner
Otras personas de la
Stakeholders empresa como dueños,
internos gerentes, directivos, etc.

Personas ajenas a la empresa, pero

Stakeholders afectadas por el producto en mayor
externos o menor medida como el cliente
(por supuesto), afectados por el uso
del producto, usuarios, etc.
¡Vamos a verlo con una gráfica¡
Equipo
Stakeholders Scrum

Internos Scrum
de la empresa Master

Propietario
del producto o
Product owner
Externos
Clientes/usuarios

Equipo de desarrollo o
Development team
Propietario del
producto o
Product owner

Esto quiere decir que:

El product owner es product manager.

Debe entender las necesidades y prioridades de los stakeholders
internos y de los clientes/usuarios, lo suficiente para actuar como
ellos mismos en las directrices del producto.
 El product owner es en parte analista de
negocio y en parte evaluador.
Debe comunicar al equipo de desarrollo lo que tiene que construir y
Propietario del el orden en el que lo deben hacer. Además, se asegura que los criterios
de aceptación se especifican y los test, para realizar las verificaciones
producto o sobre los criterios, se realizan para comprobar si las funcionalidades están
Product owner completas. El dueño de producto no desarrolla test a nivel de detalles,
pero sí se asegura que los test a alto nivel se escriben de manera que el
equipo pueda saber cuándo y cómo el product owner considerará el
producto completo.

El rol del product owner es un rol a tiempo completo

con responsabilidades muy importantes.
De hecho, como verás a continuación, a primera vista va a parecer difícil que
una sola persona gestione todas las responsabilidades y funciones que te
vamos a mostrar, pero exceptuando algunos casos puntuales el rol de
product owner puede y debe ser ocupado por una sola persona.
Propietario
del producto o
Product owner Responsabilidades
¡Vamos a ver cada Gestión económica
una de ellas! Participar en planificación

Refinar el product backlog o grooming

Definir los criterios de aceptación y verificar que se cumplen

Colaborar con el equipo de desarrollo

Colaborar con los stakeholders

 Responsabilidades Gestión económica

Propietario del
producto o El dueño de producto es el responsable de la toma
Product owner de buenas decisiones económicas de manera
constante a nivel de:
Lanzamiento

Sprint

Product backlog
 Responsabilidades Gestión económica Lanzamiento

De cara al lanzamiento el product owner está

constantemente equilibrando, dentro de lo posible,
Propietario del entre alcance, fecha, presupuesto y calidad a medida
producto o que la información económicamente importante llega
durante el desarrollo de producto.
Product owner Este equilibrio implica que tiene que tomar las mejores decisiones para
alcanzar el mejor punto posible entre cada una de las cuatro áreas.
Ahora bien, dependiendo de la información que vaya llegando, quizás, el
product owner ya no tenga tanta necesidad de alcanzar equilibrios.

¿Deberías asumir el retraso y el coste

adicional a cambio de los ingresos extra?
 Responsabilidades Gestión económica Lanzamiento

Tú, como product owner

Propietario del supervisas esta decisión.
producto o En muchos casos podrías tomar unilateralmente la decisión,
Product owner pero en otros, podrías tomar la determinación de recomendar
una decisión trabajando con otros para asegurar su compromiso
(y en ocasiones aprobación) en ejecutar esta decisión.
También, al final de cada sprint el dueño de producto supervisa la
decisión de financiar o no el siguiente sprint. Si se está progresando
hacia el lanzamiento o el siguiente sprint se justifica económicamente de
alguna otra manera, el sprint se financiará. Si no se está progresando o
la economía no apoya nuevos gastos, el esfuerzo puede cancelarse.
Un dueño de producto satisfecho, también, puede cancelar la
financiación del siguiente sprint si observa que el producto está
listo para lanzarse y gastar dinero adicional en otras
funcionalidades no se justifica.
 Responsabilidades Gestión económica Lanzamiento

Propietario del
producto o
Product owner ¿Qué harías?
Podrías llegar a la lógica conclusión que realizar una entrega
temprana es económicamente más razonable que continuar con el
plan para diez sprints.
Esta flexibilidad para realizar entregas tempranas, solo tienen lugar si
consigues que se trabaje, primeramente, en los valores de alto valor
en la parte alta del product backlog y que en cada sprint, el equipo
está completando el trabajo de acuerdo con una sólida definición de
"terminado".
 Responsabilidades Gestión económica Lanzamiento

Por supuesto, el propietario de producto también

Propietario del debe poner fin a los sprints si las condiciones
producto o fundamentales han cambiado.
Product owner Imagina que estás creando un portal de apuestas específico para
Corea del Sur y todo está saliendo según lo planeado en los
diferentes sprints:

De los quince sprints que tienes que desarrollar, tú y tu equipo

habéis desarrollado perfectamente y a tiempo los primeros diez,
pero en ese momento su gobierno aprueba una ley prohibiendo
los juegos de azar y las apuestas deportivas.
Esto haría que vender el producto fuese ilegal, con lo que llevaría
a la cancelación de los futuros sprints porque el proyecto de
desarrollo dejaría de tener sentido.
 Responsabilidades Gestión económica Sprint

Propietario del
producto o Gestionar la economía de cada sprint consiste en
Product owner asegurarse de que existe un retorno de la inversión
suficiente de cada sprint. Los buenos dueños de producto
emplean el dinero de la empresa como si fuese suyo.
En la mayoría de los casos el product owner conoce el coste del
siguiente sprint, ya que conoce la duración del mismo y el equipo que lo
va a llevar a cabo.
Como dueño de producto, piensa: ¿extendería un talón desde mi
cuenta bancaria equivalente al coste del sprint para obtener las
funcionalidades que se van a desarrollar? Si la respuesta es no,
probablemente tampoco deberías gastarte el dinero de la empresa.
 Responsabilidades Gestión económica Product backlog

El propietario de producto, como ya hemos visto, es

Propietario del el responsable de priorizar en el product backlog.
producto o Cuando cambian las condiciones económicas,
Product owner también lo harán las del product backlog.

Como el ratio entre coste y beneficio

ha cambiado drásticamente, deberías
repriorizar el product backlog con esta
nueva información, normalmente
descendiendo los PBI (producto backlog
ítems) asociados con esta funcionalidad a puestos
más bajos.
 Responsabilidades Participar en la planificación

El dueño de producto es un participante clave en la

planificación de las siguientes áreas:
Propietario del
producto o Portfolio
Trabaja con stakeholders internos (por ejemplo, un comité
de aprobaciones o una junta de gobierno) la posición correcta
Product owner del producto en el portfolio de la empresa para determinar el
principio y el final del desarrollo del producto.

Trabaja con diferentes stakeholders

Producto para crear la visión del producto.

Junto con los stakeholders define el

Lanzamiento contenido del siguiente lanzamiento.

Junto con el equipo de desarrollo, define el objetivo del

sprint y, además, facilita información valiosa para que el
Sprint equipo de desarrollo pueda seleccionar un conjunto de PBI´s
que puedan entregar, de manera realista, al final del sprint.

Haz clic sobre cada una de las áreas

 Responsabilidades Refinar el product backlog o grooming

Propietario del El dueño de producto supervisa el proceso de

grooming, pero NO realiza él, personalmente,
producto o todas las actividades que lo componen.
Product owner
No escribe todos los PBI, ya que le ayudan otros miembros
del equipo. Tampoco realiza las estimaciones, ya que lo hace
el equipo de desarrollo, pero sí que está disponible
durante esta fase para solucionar dudas o preguntas que
pueda tener el equipo.
De todos modos, sí es responsable de que el
grooming ocurra de un modo que fomente un
flujo constante de valor entregado.
 Definir los criterios de aceptación
Responsabilidades
y verificar que se cumplen

El product owner es responsable de definir los criterios

de aceptación de cada PBI (Product Backlog Item.)
Propietario del
producto o Las condiciones de aceptación, como has visto anteriormente, se trata de
Product owner una serie de condiciones con las cuales se cumplen los requisitos
funcionales y no funcionales del PBI y con los cuales el dueño de
producto estaría satisfecho.
También puede escribir los test de aceptación de
manera autónoma o con el asesoramiento de expertos en
cada área y/o miembros del equipo de desarrollo.
En cualquiera de estos casos, el dueño de producto debe asegurarse que
estos criterios y sus tests se definen antes de considerar un PBI en la
reunión de planificación de sprint. Sin ellos, el equipo no tendrá un
entendimiento completo del PBI y no estaría preparado para incluirlo en un
sprint. Por esta razón, muchos equipos Scrum incluyen los criterios de
aceptación como ítem en su lista de comprobación de la definición de
terminado.
 Definir los criterios de aceptación
Responsabilidades
y verificar que se cumplen

Propietario del El dueño de producto es, asimismo, el máximo

producto o responsable de confirmar que los criterios de
Product owner aceptación se cumplan.
De nuevo puede realizar esto él solo o contar con el asesoramiento
de expertos para confirmar que el PBI reúne las condiciones de
satisfacción. El equipo puede ayudar a crear una infraestructura de
testeos que ayude al dueño de producto y a los expertos a evaluar
más eficientemente, pero la última palabra sobre si un PBI cumple
las condiciones, pertenece al product owner.
 Definir los criterios de aceptación
Responsabilidades
y verificar que se cumplen

Propietario del Es también importante que el product owner verifique los

producto o criterios de aceptación durante la ejecución del sprint, en lugar
Product owner de esperar al sprint review.
Realizando los tests a medida que las funcionalidades se van
completando, el dueño de producto identifica fallos y
malentendidos que el equipo puede arreglar antes de llegar a la
revisión.
Y, dado que el equipo está autorizado solamente a presentar
funcionalidades completas en la revisión de sprint, el product
owner tiene que asegurarse de que el equipo conozca qué
funcionalidades cumplen finalmente con la definición de
terminado.
 Responsabilidades Colaborar con el equipo de desarrollo

Colaborar de manera cercana y frecuente con el

Propietario del equipo de desarrollo. El rol del propietario de producto
producto o es un rol de compromiso diario.
Product owner
A tener en cuenta:
Fomentar el feedback.

No confundir el rol del product owner con el del

director de proyecto en el desarrollo en cascada.
 Responsabilidades Colaborar con los stakeholders

Propietario del
producto o
Product owner El dueño de producto es la voz de los stakeholders, tanto
internos como externos. Debe trabajar con ellos de
manera cercana y constante, para guiar al equipo
facilitando información sintetizada y una visión
coherente del desarrollo de producto.
Propietario
del producto o
Product owner Características
¡Vamos a ver cada Habilidades técnicas
una de ellas!
Habilidades interpersonales
Toma de decisiones
Responsabilidad
 Características Habilidades técnicas

El propietario de producto es un visionario que

puede sintetizar la visión de producto y guiar al
Propietario del equipo para lograr esa visión.
producto o Tener una visión no significa que, cada detalle de la visión o el
Product owner camino para lograr la visión, esté perfectamente claro. Un buen
dueño de producto sabe que no todo puede anticiparse y está
dispuesto a realizar adaptaciones cuando el proyecto lo requiere.

Para ser eficaz….

El propietario de producto debe tener conocimientos
adecuados sobre la empresa y el dominio.

Es difícil ser eficaz como product owner si

se es nuevo en el dominio del producto.

No se pueden establecer prioridades entre

las características si no se conoce el tema.
 Características Habilidades interpersonales

Debe ser la "voz del cliente“. Esto requiere tener una buena
relación con los stakeholders.
Propietario del
producto o Buen negociador y ayudar a alcanzar consensos.
Product owner Es el enlace entre los stakeholders y el resto del equipo Scrum,
por lo que es necesario que tenga habilidades
comunicativas.
Un buen comunicador tiene las siguientes habilidades:
❖ Está dispuesto a hablar, incluso, si hacerlo va en contra del status quo.
❖ Confía en sus ideas.
❖ Conoce los temas de los que habla.
❖ Es capaz de comunicarse de una manera simple, concisa y fácil de
entender.
❖ Tiene credibilidad.

El dueño de producto debe ser también un gran motivador.

Características Habilidades interpersonales

Debemos realizar una

parada para ver un
interesante vídeo
sobre qué motiva a
las personas:
https://youtu.be/y5utyIPXu5A
 Características Toma de decisiones

El product owner debe estar

autorizado para tomar decisiones.
Propietario del Un impedimento frecuente para las empresas que se inician en
producto o Scrum es que la persona seleccionada para ser el dueño de producto
no cuenta con poder para tomar decisiones importantes, haciendo
Product owner que esa persona, en realidad, no sea dueña de producto como tal.

El dueño de producto también debe estar dispuesto a

tomar decisiones difíciles equilibrando restricciones
como el alcance, la fecha de lanzamiento y el presupuesto.
Estas decisiones deben hacerse de forma oportuna y no cambiarse sin
una buena razón. Al tomar estas decisiones, el dueño de producto mantiene
el equilibrio adecuado entre las necesidades del negocio y las realidades
técnicas. Aunque el equipo Scrum en su conjunto es responsable cuando los
sistemas acumulan niveles inaceptables de deuda técnica (errores o faltas
en el producto en los que se incurre para acortar los plazos), las decisiones
que toma a este respecto el dueño de producto son un factor significativo.
 Características Responsabilidad

El dueño de producto es responsable por la entrega de buenos

resultados para el negocio.
Propietario del Esta responsabilidad no exime a otros miembros del equipo Scrum de su propia
responsabilidad para obtener un buen retorno de la inversión. Es el que rinde
producto o cuentas de que los recursos se están utilizando de manera sensata y debe aceptar
Product owner la responsabilidad si esto no ocurre. Después de todo, el dueño de producto tiene
muchas oportunidades para cambiar la cartera de productos, reajustar las
prioridades o incluso supervisar la cancelación del desarrollo por completo.

Debe estar comprometido y estar disponible, tanto para los

stakeholders, como para el resto del equipo Scrum.
Ser product owner es un trabajo a tiempo completo, tratar de hacerlo a tiempo
parcial es la mejor manera de fracasar.

Es miembro del equipo Scrum y, por lo tanto, se da cuenta de que

los buenos resultados son imposibles sin los esfuerzos de
colaboración del equipo Scrum al completo.
Trata al equipo de desarrollo y Scrum master con respeto y confía en que son
sus aliados en la entrega de los resultados deseados.
Propietario del
producto o
Product owner Escoger el propietario de producto
Tipo de desarrollo Posible product owner
Representante o cliente del área de negocio que se beneficia
Interno de la solución. En un proyecto de desarrollo de software de
ventas el product owner debería ser alguien de ventas.

Un representante interno de clientes y usuarios. Normalmente es el

Comercial director de producto, desarrollo de negocio o director de proyectos.

Un representante o cliente de la empresa que paga

Subcontratado por la solución y recibe los beneficios del desarrollo.

Por componentes Un product owner con formación técnica.

 Scrum
Master
Si bien el dueño de producto
se centra en la construcción
del producto adecuado y el
equipo de desarrollo
adecuadamente en el
producto, el Scrum master
se centra en ayudar a
todos a entender y abrazar
los valores, principios y
prácticas de Scrum.
Scrum El Scrum master actúa como un entrenador para el
equipo de desarrollo y el dueño de producto.
Master Támbién lidera procesos, ayudando al equipo Scrum
y al resto de la empresa a desarrollar su propio enfoque
Scrum con alto rendimiento y adaptado a la
organización.
Scrum
Master Responsabilidades

¡Vamos a ver Coach Conocedor de la metodología

cada una de
ellas! Líder servicial Realizar preguntas excelentes

Autoridad en procesos Paciencia

Escudo para interferencias Colaboración

Eliminar obstáculos Protección

Agente de cambio Agente de cambio

 Responsabilidades Coach

El Scrum master entrena a un nuevo propietario de producto

Scrum ayudándole a entender y a asumir sus responsabilidades como
product owner.
Master Una vez que el Scrum master ayuda al dueño de producto a establecerse en
su rol, le proporciona asistencia continua en sus actividades.
Podemos decir, por tanto, que fundamentalmente el Scrum
master entrena a ambas partes del equipo Scrum para
eliminar barreras entre ambos lados y habilitar al dueño de
producto a dirigir el desarrollo.
 Responsabilidades Líder servicial

El Scrum master se describe a menudo

como un líder servicial del equipo
Scrum. Incluso cuando actúa como
Scrum entrenador del equipo, el Scrum master
Master es ante todo un sirviente del equipo
Scrum, asegurando que sus
necesidades de mayor prioridad
se están satisfaciendo.

Entonces, ¿qué puedo

hacer hoy por mí?
Entonces, ¿qué puedo hacer
hoy para ayudarte a ti y a
tu equipo a ser más eficaces?
 Responsabilidades Autoridad en procesos

Scrum El Scrum master es la autoridad en cuanto a procesos Scrum

y está capacitado para asegurar que el equipo Scrum se
Master adhiera a los valores, principios y prácticas Scrum junto
con las características específicas del equipo Scrum.
Ayuda continuamente al equipo Scrum a mejorar el uso de la metodología
siempre que sea posible para maximizar el valor del negocio
entregado.
La autoridad que tendría el Scrum master, en este contexto, no es el mismo
tipo de autoridad que la que tendría un gerente funcional o gerente de
proyecto. Por ejemplo, el Scrum master no contrata y despide y no puede
dictar al equipo qué tareas debe hacer o cómo hacerlo. El Scrum master
tampoco es responsable de asegurarse de que el trabajo se hace.
En vez de esto, el Scrum master ayuda al equipo a definir los
procesos que garantizan que el trabajo se hace.
 Responsabilidades Escudo para interferencias

Scrum
Master
Protege al equipo de desarrollo de las interferencias y
distracciones externas para que sus miembros puedan
centrarse en añadir valor de negocio a cada sprint.
La interferencia puede venir de numerosas fuentes: encargados que
quieren reorientar a miembros del equipo durante un sprint, a asuntos que
surgen en otros equipos, etc.
Independientemente de la fuente, el Scrum master actúa
como interceptor (investigación, gestión y arbitraje) para que
el equipo pueda concentrarse en crear valor.
 Responsabilidades Eliminar obstáculos

Scrum También se encarga de eliminar los impedimentos que

Master inhiben la productividad del equipo (solo los que los miembros
no pueden eliminar razonablemente por su cuenta).
Algunas cosas no las podrá arreglar personalmente y deberá coordinarse con
otros departamentos de la empresa para hallar las soluciones a problemas
que potencialmente puedan retrasar el progreso del sprint, disparar el
presupuesto u obstaculizar la entrega de valor por parte del equipo.
 Responsabilidades Agente de cambio

Scrum El Scrum master ayuda a otros a entender la necesidad del

Master cambio, los impactos de Scrum fuera del equipo de Scrum y
los beneficios que puede ayudar a lograr.
También asegura que el cambio cultural ocurre a todos los niveles
organizativos, permitiendo no solo que ese proyecto Scrum tenga éxito, sino
que la metodología Scrum pase a ser parte integrante de la cultura corporativa.
En las grandes empresas, los Scrum masters pueden unirse para
convertirse en una fuerza para el cambio más eficaz.
 Responsabilidades Conocedor de la metodología

Para entrenar a los demás en procesos Scrum, el Scrum

Scrum master debe conocer la metodología a la perfección.
También debe entender los problemas técnicos que el equipo
Master necesita abordar y las tecnologías que el equipo utilizará para
crear soluciones.
No necesita tener conocimientos tecnológicos como para desarrollar él
mismo el proyecto, pero si tiene conocimiento técnico sobre lo que se va a
hacer en el proyecto es, obviamente, un plus.
Tampoco necesita ser un experto en el ámbito empresarial (esto es tarea
del dueño de producto), pero de nuevo, si lo tiene, es mejor para el proyecto.
 Responsabilidades Realizar preguntas excelentes

Scrum El Scrum master usa sus habilidades como "entrenador" junto a

Master sus conocimientos sobre procesos, tecnología y negocio para
realizar grandes preguntas que ayuden al equipo a idear
nuevos y mejores caminos para entregar valor.
Los grandes Scrum masters nunca responden directamente a una pregunta.
En lugar de ello, responden reflexivamente con su propia pregunta para
profundizar, ayudando a la gente a encontrar sus propias respuestas.
 Responsabilidades Paciencia

Scrum Como los Scrum masters prefieren no dar respuestas necesitan

Master ser pacientes, dando tiempo a los equipos para llegar a las
respuestas adecuadas por su cuenta.
Por lo tanto, a veces debe morderse la lengua y ser paciente, dejando que el
equipo de trabajo dé la solución, haciendo con frecuencia preguntas de
sondeo para ayudar a guiar al equipo.
 Responsabilidades Colaboración

Scrum Debe tener excelentes habilidades de colaboración para

trabajar con el product owner, el equipo de desarrollo y todas las
Master demás partes, incluso aquellas que podrían no estar directamente
involucradas en Scrum.
Por lo tanto, a veces debe morderse la lengua y ser paciente, dejando que el
equipo de trabajo dé la solución, haciendo con frecuencia preguntas de
sondeo para ayudar a guiar al equipo.
 Responsabilidades Protección

Debe ejercer de protector del equipo. Protege al equipo

de impedimentos que vengan de la propia empresa o
Scrum agendas contradictorias.
Master El Scrum master es experto en asegurar la protección del equipo
dentro del contexto superior de la toma de decisiones empresariales
económicamente sólidas, mostrando comprensión, tanto al equipo,
como con las necesidades empresariales. Ayuda al equipo Scrum a
mantener un balance adecuado entre las dos.
También ayuda a los miembros del equipo que empiezan a
alejarse del trabajo del equipo. Cuando las cosas se ponen difíciles,
las personas suelen tender a volver a metodologías anteriores no
ágiles. En este caso, el trabajo de Scrum master implica ayudar al
equipo a solventar las dificultades reforzando los beneficios de Scrum
como metodología a seguir.
 Responsabilidades Transparente

Scrum El scrum master es transparente en todos sus formas de

comunicación. Cuando se trabaja con los miembros del equipo,
Master las agendas ocultas no tienen cabida, lo que se ve y se oye de
Scrum Master debe ser lo que se obtiene. La gente no espera
nada menos de un líder servicial.
El Scrum master también promueve una comunicación transparente fuera del
equipo de Scrum. Sin un acceso transparente a la información, es difícil para
la empresa realizar actividades de inspección y adaptación para lograr los
resultados deseados de usar Scrum.
 Escoger el Scrum máster
La empresa realmente tiene varios posibles
perfiles para incorporar como Scrum master:
Scrum Posible Scrum máster
Master
Directores de proyecto.

Directores de producto (aunque estos normalmente

se designan para roles de product owner).

Perfiles técnicos relacionados con el desarrollo y el testeo.

Directores de
departamento.

En definitiva, siempre que el individuo tenga las

características que hemos mencionado y el deseo de asumir las
responsabilidades, puede ser un Scrum master válido.
Equipo de
desarrollo o
Development
team

Conjunto de personas
más “técnicas” que de
manera conjunta
desarrollan el producto
del proyecto.
Equipo de
desarrollo o
Development
team Responsabilidades
¡Vamos a ver cada Realizar la ejecución del sprint
una de ellas! Inspeccionar y adaptar cada día

Grooming del product backlog

Planificare el sprint

Inspeccionar y adaptar procesos y productos

 Responsabilidades Realizar la ejecución del sprint

Equipo de
desarrollo o
Development Sprint
team Durante la ejecución del sprint los miembros del equipo de
desarrollo realizan el trabajo de diseño, creatividad,
construcción, integración y testeo de los PBI. El equipo de
desarrollo invierte la mayor parte de su tiempo en este
proceso.
 Responsabilidades Inspeccionar y adaptar cada día

Equipo de
desarrollo o Cada miembro del equipo de desarrollo debe participar
Development en las reuniones de daily Scrum, en la cual, los miembros
team de manera colectiva inspeccionan el progreso hacia el
objetivo del sprint y adaptan el plan para el día de trabajo.
Si algunos miembros del equipo no participan, el equipo
puede perderse fragmentos del mapa de desarrollo y esto
puede hacer que no cumplan el objetivo del sprint.
 Responsabilidades Grooming del product backlog

Equipo de
desarrollo o
Development Una porción de cada sprint se emplea en prepararse para
el siguiente sprint. Gran parte de esta preparación implica
team realizar las actividades de grooming. El equipo debe apartar
un 10% de su tiempo para asistir al dueño de producto en
estas actividades.
 Responsabilidades Planificar el sprint

Equipo de
desarrollo o Junto al propietario de producto y el Scrum master, el equipo
Development de desarrollo participa en la planificación del sprint.
team
 Responsabilidades Inspeccionar y adaptar
procesos y productos

Equipo de
desarrollo o Los equipos de desarrollo también participan en las dos
Development
actividades de inspección y adaptación posteriores al sprint:
team revisión y retrospectiva.
Equipo de
desarrollo o
Development
team Características
¡Vamos a ver cada Autoorganizado

una de ellas! Multifuncional

Habilidades en forma de T

Actitud de mosquetero

Comunicación de banda ancha

Comunicación transparente

Tamaño adecuado

Centrado y comprometido

Trabajar a ritmo sostenido

 Características Autoorganizado

Los miembros del equipo se organizan ellos mismos

de la mejor manera para llegar al objetivo del sprint.
La autoorganización es algo que ocurre de abajo a arriba y en la que no
tiene lugar una fuerza dominante externa, es decir, no se impone una
Equipo de organización desde niveles superiores del organigrama.
desarrollo o
Development
team
 Características Multifuncional

Los miembros del equipo deben ser diversos en cuanto a

funcionalidad, es decir, colectivamente deben poseer
un conjunto de habilidades suficientes para hacer el
trabajo encomendado.
Equipo de Además de las habilidades técnicas, cuanto más diferente sea el bagaje
desarrollo o de los miembros entre ellos, más amplias serán las miras del equipo. La
Development diversidad aumenta la cantidad de puntos de vista presentes, al igual que
team incluir personas con diferentes años de experiencia es positivo porque:

Demasiados perfiles senior puede ocasionar turbulencias dado

que todos están acostumbrados a llevar la voz cantante.
La falta de experiencia acumulativa de un equipo formado
por demasiados perfiles junior podría significar un equipo
poco preparado e incapaz de realizar los trabajos.
 Características Habilidades en forma de T

Este es un concepto bastante utilizado en cuanto a los equipos Scrum.

Tener habilidades en forma de T quiere decir que los miembros
del equipo, idealmente, deben poseer conocimiento básico en
Equipo de todas las tareas a realizar en el proyecto, pero conocimiento
desarrollo o profundo en, al menos, una de ellas.
Development De esta manera los miembros se pueden suplir en caso de necesidad y
team todos comprenden el trabajo de los otros.
 Características Actitud de mosquetero

“Uno para todos y todos para uno.”

Esto refuerza que todos los miembros del equipo tienen
colectivamente la responsabilidad de llevar el trabajo a buen puerto.

Equipo de Como equipo tienen éxito y como equipo fracasan.

desarrollo o
Development
team
 Características Comunicación de banda ancha

Los equipos de desarrollo deben comunicarse entre ellos, además

de con el dueño de producto y con el Scrum master. Esto debe
ocurrir como la banda ancha, es decir, intercambiando
información valiosa de manera eficiente, rápida y frecuente
con las mínimas pérdidas por el camino.
Equipo de
desarrollo o Otro de los condicionantes para una comunicación de banda ancha
es la duración de las reuniones. Se debe trabajar para que sean lo
Development
team más cortas posible.
En Scrum las comunicaciones en tiempo real cara a cara tienen
preferencia, pero de cualquier modo cuando esto no es posible, para equipos
remotos existen hoy día herramientas de comunicación telemática excelentes
que permiten una comunicación bastante fluida, como por ejemplo:
 Características Comunicación transparente

Las palabras deben ser claras y los

miembros del equipo honestos.
Además de rápida, la comunicación debe ser transparente.

Equipo de Esto quiere decir que lo que muestre la información debe proporcionar una
información clara de lo que esté ocurriendo, para evitar sorpresas y aumentar
desarrollo o el nivel de confianza entre los miembros del equipo Scrum y los stakeholders.
Development
team
 Características Tamaño adecuado

En Scrum, los equipos de desarrollo ideales son de reducido

tamaño. El consenso general en la disciplina es que el tamaño
ideal es de entre 5 y 9 miembros.
Mike Cohn, expone una serie de razones por las cuales esto es cierto:
Equipo de
desarrollo o Menor tendencia de esforzarse porque "ya lo acabará otro“.
Development
team Más probable que exista interacción constructiva.

Se emplea menos tiempo en coordinar los esfuerzos del equipo.

Nadie queda en segundo plano.

Trabajar en grupos pequeños es más satisfactorio para sus miembros.

No se contrata especialistas en campos minoritarios.

 Características Centrado y comprometido

Los miembros del equipo de desarrollo deben estar centrados y

comprometidos con los objetivos del equipo.
Concentrado quiere decir poniendo toda su atención en el
objetivo del equipo. Esto es más fácil si los miembros trabajan
Equipo de en un solo proyecto de cada vez.
desarrollo o
Development
team
 Características Trabajar a ritmo sostenido

Scrum asegura que se trabaja a ritmo sostenible, realizando la

inspección y adaptación durante la ejecución del sprint, lo cual
quiere decir que los problemas no aparecen a última hora, sino
que se van solucionando a medida que los test revelan
Equipo de errores en el producto.
desarrollo o
Development
team
 Kanban
3.4 Las tresviene de Kanban
reglas del una palabra
de la lengua japonesa que significa algo similar a
(3)
"tarjetas visuales". Este sistema se creó en Toyota como medio para controlar el
avance del trabajo en la línea de producción y es una herramienta de mejora
continua o Kaizen.
Kanban cuenta con tres reglas:

1. Regla #1. Visualizar cómo fluye el trabajo a lo largo del sistema

Algo que tiene en común Kanban con Scrum es la base del desarrollo incremental, es decir, se divide el
trabajo en partes. Kanban utiliza técnicas visuales para ilustrar la situación de cada tarea en el
denominado Muro Kanban. Frecuentemente, se trabaja con una pizarra en la que se definen las fases de
las tareas y se utilizan post its para ir moviendo las tareas de lugar.
En la pizarra se ilustran tantas columnas como estados por los que puede pasar una tarea.
Se realiza esta visualización para que aclarar:
❖ El trabajo a realizar.
❖ En qué está trabajando cada empleado.
❖ Que todos los trabajadores estén involucrados.
❖ Clarificar la prioridad de tareas.
3.4 Las tres reglas del Kanban (4)

2. Regla #2. Limitar la cantidad de trabajo en curso

El trabajo en curso (WIP, por las siglas en inglés de Work In Progress) tiene que estar limitado en el
contexto Kanban, es decir, que debemos conocer el número más alto de tareas realizables en cada fase.
Esto quiere permite controlar los cuellos de botella. Imagina que tienes tres fases antes de terminado:
selección de tareas, desarrollo y prueba. Si no controlas esto es posible que incluyas demasiadas tareas en
desarrollo, con lo que las personas que tienen que realizar los testeos no estarán empleando
eficientemente su tiempo. Si hay un tapón, es preferible mover a personas dedicadas generalmente a
pruebas (de ahí la importancia de las habilidades en forma de T, entre otros factores) a tareas de desarrollo
con el fin de que puedan pasar a la fase de prueba y posteriormente a terminado.
En definitiva, limitar las tareas de cada fase ayuda a terminar más trabajo y a no retrasar las entregas.
 Regla #3. Medir y optimizar el flujo de trabajo en el sistema para poder
3. mejorar continuamente
Debes medir el tiempo que tardas en realizar las tareas. Esto es lo que se conoce en Kanban como "lead
time". Este tiempo cubre lo que se tarda, en horas de trabajo, desde que se realiza la petición hasta que
ocurre la entrega.
Además del lead time, en Kanban se emplea otra métrica: cycle time o tiempo de ciclo. En este sentido
mide el tiempo desde que el trabajo de una tarea comienza hasta que termina.
El lead time mide lo que va a esperar un cliente, es decir, lo que transcurre desde que solicita un trabajo a
la empresa hasta que lo ve terminado, pero el cycle time es la métrica sobre la que la empresa trabaja para
mejorar. Si consigue reducir el cycle time se podrán incorporar los pedidos antes al trabajo en curso y, por
lo tanto, los resultados y el valor entregado al cliente mejorará.
3.5. Gestión evolutiva del cambio con Kanban (2)
Tu empresa es una red de individuos psicológica y socialmente programados para resistirse al
cambio. Kanban reconoce y trabaja este aspecto humano con sus tres principios para la gestión del
cambio:

1. Empieza con lo que haces actualmente

Casi toda la gestión del cambio está basada en modelos del siglo XX. En estos modelos se plantean
cambios radicales sobre todas las maneras en las que se hacen las cosas. Esto, obviamente, provoca
resistencia al cambio porque se está tratando de cambiar la identidad profesional de los individuos.
Por el contrario, Kanban comienza con las funciones y procesos ya presentes en la empresa y lo que
plantea son cambios continuos, incrementales y evolutivos. Es decir, se realizan mejoras mínimas de
manera continua hacia un objetivo de cambio, siendo lo suficientemente sutiles como para no despertar la
resistencia al cambio.
3.5. Gestión evolutiva del cambio con Kanban (3)

2. Persigue la mejora mediante el cambio evolutivo

La empresa tiene que estar de acuerdo con que el cambio continuo, gradual y evolutivo es la manera
correcta para implementar mejoras en el sistema y debe adherirse a esta creencia. Hacer un cambio radical
puede parecer una práctica más eficaz, pero en la práctica son más proclives a fracasar por la resistencia al
cambio y el miedo en la empresa.

3. Respeta el proceso actual

Facilita el cambio futuro: acuerda con los equipos respetar los roles actuales, responsabilidades y cargos.
De esta manera erradicas los temores iniciales. Esto debería provocar en el equipo una mentalidad más
abierta y un apoyo hacia el uso de las mejoras de Kanban.
1.3 Gestión de multiproyectos
Hasta ahora hemos trabajado pensando en el trabajo sobre
un solo proyecto, pero la realidad es que en muchos casos
las empresas manejan varios proyectos
simultáneamente que comparten recursos y, a
esto, se le denomina entorno multiproyecto.
Como veremos, este nuevo entorno conlleva una serie
de dificultades.
El entorno multiproyecto, como decimos, es una
situación en la que dentro de la empresa existen
varios proyectos que comparten recursos y, por lo
tanto, se crea una especie de “competición”
entre los diferentes proyectos para conseguir
usar los recursos en el momento adecuado.
Existe además una interdependencia entre todos estos
proyectos que hace que los acontecimientos o decisiones
que se toman en otro proyecto afecten al resto de
proyectos.
Trabajar en un entorno multiproyecto tiene varias implicaciones:
▪ Esta interacción entre proyectos, además, aumenta los riesgos asociados a cada unos de ellos dado
que un atraso en un proyecto puede colapsar un determinado recurso, generando un efecto dominó
sobre los demás proyectos.
▪ Existen nuevas oportunidades que derivan de este tipo de gestión al crearse sinergias entre
proyectos, como aprovechamiento del conocimiento y valor generado entre proyectos o la posibilidad
de hacer compras conjuntas.
▪ El proceso de planificación es más difícil, ya que los recursos se hacen menos disponibles a medida
que se requieren en otros proyectos.
▪ Se debe cambiar el foco de la empresa para centrarse ahora en un cuadro de mando con métricas y
para el conjunto de proyectos.
▪ Los recursos tendrán que autogestionarse en lugar de estar destinados únicamente a ejecutar las
tareas.
▪ Al aumentar la cantidad de conflictos entre proyectos se vuelve necesaria la
implementación de un sistema de resolución de conflictos más eficiente.
▪ Existen limitaciones adicionales sobre cada proyecto por la injerencia de las
consecuencias de las decisiones tomadas en otros proyectos.
Gestión de multiproyectos
con Cadena Crítica
La metodología de Cadena Crítica fue desarrollada por el
físico israelí Eliyahu M. Goldratt y, en ella, propone una
solución para gestionar operaciones en un entorno multiproyecto.
La idea fundamental es que para gestionar la incertidumbre de
tener varios proyectos es necesario saber cómo compartir los
recursos, no cómo repartirlos. En este sentido se introduce el
concepto de buffer, es decir de compartir el tiempo, basándose
en la Teoría de las Limitaciones.
En esta metodología Goldratt propone a las empresas un enfoque
distinto, en el que se hace más énfasis en la ejecución que en
la planificación. Se propone empezar más tarde para llegar
antes, lo que supone una disrupción con respecto a otras teorías
de gestión de proyectos.
Un GPS para la ejecución
Cuando conducimos, tratamos de llegar a nuestro destino lo antes posible.
Pero esto, ¿de qué depende?
En la mayoría de los casos no estamos hablando de la habilidad del
conductor, ni del coche, sino del tráfico que haya en carretera. En el
entorno de los proyectos, el tráfico, son las tareas o proyectos que estén
abiertos en cada momento. Normalmente, en las empresas se trata de
“saturar” al máximo el uso de cada recurso porque se entiende que así se
mantiene a la gente activa. La realidad es que cuantos más proyectos
existan abiertos más tráfico se encontrará un proyecto nuevo.
Para esto se introduce el concepto de buffer, que no es ni más ni
menos que un amortiguador, es decir, un tiempo añadido a la
planificación inicial que permite que los proyectos se ejecuten en el
plazo establecido.
La cadena crítica y el buffer funcionan como un
navegador que recalcula rutas y prioridades a diario.
A la hora de tomar decisiones, se clasifican las tareas en función de su
importancia. Se pasa de esta manera de ser una empresa que realiza planning
con hitos intermedios, a una con un buffer que se recalcula a diario dependiendo
de la duración restante real de las tareas en curso.
Esto ocurre así porque se considera que el planning con hitos intermedio es como
un plano o instrucciones impresas en papel que ya no servía si se tomaba mal una
desviación.
El buffer, por otro lado, es un mecanismo de
gestión de todo el proyecto que muestra el
impacto de cualquier desviación en todo el
conjunto.
Por tanto, el esfuerzo se basa en crear ideas o
mecanismos que ayuden en la gestión de la
ejecución en lugar de la planificación.
En esta metodología el planning tiene un impacto del 10%, mientras
que el otro 90% se centra en ideas y reglas para gestionar la ejecución.
En realidad, lo único que importa en la ejecución es la duración
restante, no el avance hasta ese momento. Lo que falte por terminar
hoy será diferente mañana y este es el único dato real. Cada persona
involucrada en cada tarea debe decir al acabar cada día lo que le falta
por terminar, lo cual es más fiel a la realidad que cualquier plan. Lo
recomendable es que el amortiguador tenga un tamaño de un
tercio del plazo.
Aquí puedes ver una
planificación.
El eslabón más débil
Goldratt, en su Teoría de las Limitaciones, dice que cualquier
proyecto o empresa es una cadena que rompe siempre por
el eslabón más débil.
La implicación de esto en la práctica es que cualquier mejora aplicada a un
eslabón que no es el más débil no sirve para nada.
Trasladado al entorno multiproyecto, un eslabón débil es un departamento y en el
caso del trabajo intelectual suele tratarse de un problema de capacidad de
resolución de problemas, no de recursos.
Lo más importante es la sincronización entre eslabones y la
relación entre ellos en lugar de cada eslabón, exceptuando
el más débil.
Conflictos y cambios en los recursos
Por muy bien planificado que esté un proyecto,
siempre existen cambios en el alcance, bien
sea por cuestiones internas o por temas
relacionados con el cliente.
Además, fruto de la ejecución del proyecto siempre
aparecen nuevas tareas no previstas, así como
variaciones en las necesidades de recursos y otras
cuestiones.
Cuando hablamos de varios
proyectos, el nivel de complejidad
aumenta, ya que se produce un efecto
cascada sobre los demás proyectos
cuando uno varía. Cualquier desviación puede
producir picos de carga y conflictos. Asimismo, el
compartir recursos puede provocar la existencia
de multitarea negativa, empezando a realizar
actividades y pasando a otras sin terminar las
primeras. Esto hace que sobre la tarea empezada se
consuman los plazos. La respuesta natural suele
ser comenzar antes los proyectos, lo que dispara
los tiempos de ejecución.
Las esperas
Como decimos, al haber unos recursos que se
están utilizando simultáneamente en varios
proyectos, tienen lugar dos distintos tipos de
espera: el recurso que espera a la tarea y la
tarea que está esperando al recurso.
De esta manera, en ocasiones casi la mitad del plazo de un
proyecto se consume entre esperas e interrupciones.
Si se consiguen reducir las esperas se acortarán los
plazos. Existen una serie de esperas que son imposibles de
evitar pero otras se pueden evitar con una mejor
sincronización de los proyectos.
1.4 Design Thinking
¿Qué es Design Thinking?
Rompemos viejos paradigmas
Todo es cambiante y al igual que la manera de
hacer negocios, hoy en día, no es como antes
tampoco será igual en un futuro.
Los negocios ya no son lo que eran, cambiaron, están
cambiando y seguirán haciéndolo, adaptándose a las nuevas
necesidades que surgen día a día como respuesta a otra
mentalidad en la sociedad, así como a los movimientos
tecnológicos y económicos acaecidos recientemente.
Somos mucho más exigentes y
proporcionalmente menos pacientes.
“Las cosas” las queremos en el momento
que tenemos o creemos tener la necesidad.
Las personas adultas tenemos hábitos
adquiridos contrarios al pensamiento
creativo, si no salimos de ellos y nos asomamos
al abismo de las posibilidades abiertas, no
encontraremos nuevas soluciones de las ya
existentes.
Debemos despojarnos de los “hábitos adultos”
y sopesar ideas desde nuevos ángulos, no
quedarnos con la primera, activar el ingenio y seguir
probando, lanzarnos y explorar nuevos puntos de
vista. En otras palabras:

“Debemos escaparnos de la
forma 'normal' de pensar”.
Salir del círculo de confort es
fundamental para encontrar
soluciones, Albert Einstein ya lo
comentó en su día:
“Si buscas resultados
distintos no hagas
siempre lo mismo”.
Volvámonos niños, repliquemos su capacidad
de desechar un juguete para jugar con la caja.
No empezamos el viaje solos, el Design Thinking
será nuestro guía. General Electric,
Procter&Gamble y Philips Electronics son algunas de
las marcas que tienen interiorizada esta herramienta
en sus procesos de trabajo e incorporan este
concepto en las rutinas de fabricación de sus
productos.
“El problema de competir como un
loco es que, incluso si ganas, sigues
siendo un loco.”
Lily Tomlin.
¿Qué es Design Thinking?
El pensamiento en modo crisis debe cambiarse
Una de las propuestas básicas que ofrece el Design Thinking es enfocar los desafíos
desde un nivel sistemático. Cuando una situación complicada nos rodea es fácil que las
decisiones que tomamos sean equivocadas, pero eso también es fruto del modo en que
hemos gestionado los problemas anteriormente, ya que se pautaba como primordial
reaccionar, en vez de actuar proactivamente o estar a la defensiva en vez de a la ofensiva.
Dicha situación afecta a la gestión, ya que se
incita y se trabaja por y para el fomento de la
creatividad, pero queda en un segundo plano
la formación indispensable para la disminución
de los errores y riesgos innecesarios.
De la misma manera que los precursores del movimiento
modernista admitieron la necesidad de nuevas concepciones
de diseño para adaptarse al progreso tecnológico del siglo XX,
debemos nosotros en la actualidad estar receptivos a otros
cambios y, poder así, reconocer cuando surge la
necesidad de crear nuevos conceptos administrativos que
se adapten al siglo XXI.
Crisis
No pretendemos que las cosas cambien, si
siempre hacemos lo mismo. La crisis es la mejor
bendición que puede sucederle a las personas y
países, porque la crisis trae progresos, la
creatividad nace de la angustia como el día de la
noche oscura. Es de la crisis que nacen la inventiva,
los descubrimientos y las grandes estrategias. Quien
supera la crisis se supera a si mismo sin quedar
superado.

Quien atribuye la crisis a sus fracasos y penurias,

violenta su propio talento y respeta más los
problemas que las soluciones, la verdadera crisis
es la crisis de la incompetencia.
El inconveniente de las personas y los países es la
pereza para encontrar las salidas y soluciones. Sin
la crisis no hay desafíos, sin desafíos la vida es
una rutina, una lenta agonía. Sin crisis no hay
méritos. Es en la crisis donde aflora lo mejor de
cada uno, porque sin crisis todo viento es caricia.
Hablar de crisis es promoverla, y callar en la crisis es
exaltar el conformismo. En vez de esto, trabajemos
nuestro talento y nuestras habilidades para
encontrar soluciones, acabemos de una sola vez
con la única crisis amenazadora, que es la tragedia
de no querer luchar por superarla.
La estrategia y la planificación empresarial tratan de deducir nuestro
futuro basándonos siempre en nuestras experiencias pasadas (buenas y
malas), pero solo será posible hacerlo a un máximo de seis meses vista, ya
que lo habitual suele ser tener una actitud lineal opuesta al caos.
Uno de los objetivos de Design Thinking es ayudarnos a valorar y darle sentido a la
conectividad existente entre las personas, los lugares, los objetos, los sucesos y las ideas
tratando de ampliar el plazo de la planificación estratégica, conformando las decisiones de
negocio que deben basarse en oportunidades futuras fomentando la imaginación.
 También puede calificarse como herramienta de gran utilidad
enfocada a fomentar la innovación en las organizaciones de una forma
eficaz y exitosa.
Esto se debe a que, gracias a su aplicación, se generan
importantes beneficios en el diseño de soluciones, permitiendo a
las empresas obtener mejores resultados en su comercialización.
 El Design Thinking se presenta como una metodología para desarrollar
la innovación centrada en las personas, ofreciendo una lente a través de
la cual se pueden observar los retos, detectar necesidades y solucionarlas.
En otras palabras, puede definirse como un enfoque que se sirve de las
sensibilidades del diseñador y su método de resolución de problemas
para satisfacer las necesidades de las personas de una forma que sea
tecnológicamente factible y comercialmente viable.
Los expertos en este tema piensan que la planificación estratégica impulsa
la innovación estratégica es un error por ser un pensamiento anticuado.
Por ejemplo, sus pautas no se basan solo en nuevas ideas o propuestas, sino también en
desbloquear el valor oculto en productos, servicios, tecnologías y bienes ya

DO I T
existentes, reforzando y aportando vigor a un negocio sin reinventarlo necesariamente.

Definir Observar Idear Transformar

Unos de los mayores expertos en Design Thinking, Idris Mootee, explica de la
siguiente manera los cambios y diferencias en los paradigmas de la gestión
acaecidos durante los 2 últimos siglos:

Siglo XX Siglo XXI

Escalada y alcance Velocidad y fluidez
Predictibilidad Agilidad
Límites organizacionales rígidos Límites organizacionales flexibles
Mandar y controlar Captación creativa
Reactiva y adversa al riesgo Intrapreneur
Intención estratégica Beneficios y propósito
Ventaja competitiva Ventaja comparativa
Datos y análisis Síntesis de grandes datos
Definición de Design Thinking
No existe una interpretación única y universal sobre su significado, ya que cada
persona puede percibir de manera distinta el significado según las circunstancias.
Para ver que esto es así, citaremos las definiciones que distintos expertos acertaron a dar,
cabe destacar la distancia temporal entre cada una.
Design Thinking según varios expertos
ROGER MARTIN, autor de “The Design of Business”
Las habilidades del diseño y de los negocios están
convergiendo. Para ser exitosos en el futuro, los ejecutivos
deberán pensar más como diseñadores…más “maestros de la
heurística” que “maestros de los algoritmos”.
Para IDRIS MOOTEE
Búsqueda de un equilibrio mágico entre, los
negocios y el arte, la estructura y el caos, la intuición y
la lógica, el concepto y la ejecución, el espíritu lúdico y
la formalidad y el control y la libertad.
TIM BROWN, fundador de Ideo.com y uno los
“culpables” de la masificación del concepto.
Disciplina “que usa la sensibilidad y métodos de los
diseñadores para hacer coincidir las necesidades de las
personas con lo que es tecnológicamente factible y con lo
que una estrategia viable de negocios puede convertir en
valor para el cliente y en una oportunidad para el mercado”.
HERBERT SIMON
Transformación de las condiciones
existentes en otras preferidas.
 Por tanto, Design Thinking implica solucionar mediante la creatividad
problemas de diseño del producto.
En un sentido más amplio diremos “que usa la sensibilidad y métodos de los diseñadores para
hacer coincidir las necesidades de las personas con lo que es tecnológicamente factible y
con lo que una estrategia viable de negocios puede convertir en valor para el cliente y en una
oportunidad para el mercado”. De esta manera podemos afirmar que desde que el término fue
planteado se le han ido sumando infinidad de acotaciones y matices, pero puliendo la idea nos
quedamos con que:
“El Design Thinking o pensamiento de diseño es una metodología de
resolución de problemas aplicable a cualquier ámbito que requiera un
enfoque creativo”.
Como su nombre indica, se centra en el proceso de diseño, dejando en un
segundo plano el producto final e integra enfoques de diferentes campos
mediante la participación de equipos multidisciplinares que tienen como
objetivo:

Adquirir conocimientos básicos

sobre los usuarios.
Del producto o solución y sobre la situación o el
problema que afrontan. Por lo tanto, pretende
comprender al usuario.

Desarrollar empatía con los usuarios.

Mediante la observación de los mismos. Por lo tanto,
es una metodología basada en observar al usuario.
Generar un usuario tipo.
Para el cual se diseña la solución o producto,
definiendo así el punto de vista a partir del cual se
debe desarrollar el diseño.

Generar tantas ideas como sea posible.

Es necesario idear.

Aprender a partir de las

reacciones de los usuarios al
interactuar con rl prototipo.
Por tanto, es necesario dejar que prueben el
producto mediante los prototipos desarrollados y
recabar información gracias a dicha interacción.

Construir prototipos.
De las ideas más prometedoras.
Design thinking es:
▪ Un medio para resolver problemas complejos.
▪ Un marco donde equilibrar las necesidades y la factibilidad.
▪ Un enfoque a la resolución de problemas que los aborda en el nivel sistemático.
▪ Una cultura que fomenta la exploración y la experimentación.
▪ Un paradigma conceptual para la curiosidad y la investigación.
▪ Un enfoque sobre la resolución colectiva de problemas.
▪ Un proceso fijo y un conjunto de herramientas.
▪ Una manera de superar los retos del diseño mediante la aplicación de la empatía.
▪ No es una palabra de moda que usan los diseñadores para sugerir que pueden hacer algo más que
▪ Tampoco
diseñar. una expresión de moda que venden los directivos como la próxima herramienta de estrategia.
 Es de vital importancia mencionar que el diseño está ligado por haberse inspirado, en
ocasiones, en disciplinas científicas y, más en concreto, por las ciencias naturales.
Cuando el Design Thinking se aplica en el entorno empresarial, ayuda a las personas que
están en él a identificar, comprender y analizar su competencia y entorno operativo.

“Los analfabetos del siglo XXI no serán los que no sepan leer y escribir,
sino quienes no sepan aprender, desaprender y volver a aprender.”
Alvin Toffler.
Principios de Design Thinking
Introducción
La humanidad, gracias a su facilidad para trabajar en cooperación, mostrar
empatía, comunicarse y tener la capacidad de prever y comprender, ha
trabajado de manera óptima.
Como reflejo de esas capacidades surge esta nueva filosofía, de ahí que la cultura, los
principios y procesos provenientes de las praxis mencionadas, sean potencialmente
más empáticas, antropocéntricas y valientes que la gestión empresarial.
Los principios inherentes al Design Thinking han sido influidos por el enfoque
multifuncional y de diversas perspectivas a la hora de resolver los problemas.
Por eso, cobra sentido introducirlo en la empresa con la finalidad de influir en nuestros
valores esenciales y formas de ver el mundo. En este punto, se debe destacar la importancia
de que todo aquel que lo vaya a utilizar o implantar necesita entender, previamente, la necesidad
humana de sentido y conectividad y, luego, actúa en consecuencia.
Uno de los problemas que podemos encontrarnos es que muchos acceden al método como si
fuese algo perfectamente estructurado, ya que “juegas” con procesos fácilmente
predecibles y que pueden repetirse llegando a catalogarlos como algoritmos, pero también
puede incluir enfoques aleatorios para aprovecharse del poder de la intuición.
Por lo anterior y, porque se trata de un concepto relativamente nuevo, hay que adoptarlo con
precaución e integrarlo en las prácticas de gestión tradicionales y, por descontado, no vincularlo
directamente como técnica de marketing o usarlo como excusa, para que las ideas creativas eludan la
crítica basada en un análisis o la lógica empresarial.
Es fundamental que las empresas que lo implanten reconozcan sus
principios clave y lo presenten como instrumento creativo que facilita la
innovación y la transformación.
Los 10 principios del
Design Thinking
01 El Design Thinking está
orientado a la acción.
Propone aplicar un enfoque de “actuar para aprender”
interdisciplinario a la resolución de problemas. Nos permite
tomar en cuenta diversos intereses y capacidades por
medio de experiencias cognoscitivas prácticas, aplicadas
entre los individuos. Buena parte del Design Thinking
consiste en crear diseño.
Supone ensuciarse las manos y experimentar.
02 El Design Thinking está a
gusto con el cambio.
Es disruptivo y provocador por naturaleza porque fomenta
nuevas maneras de abordar los problemas. El
encuadramiento estratégico de problemas complejos y
ambiguos exige un enfoque libre de dogmas organizacionales,
limitaciones codificadas y supuestos caducos.
Una gran parte del proceso de Design Thinking
consiste en salirse de los roles convencionales y
huir de los dogmas existentes, para analizar nuevas
metodologías para resolver problemas.
03 El Design Thinking
es antropocéntrico.
Siempre se centra en las necesidades del
cliente o del usuario final, incluyendo las
inexpresadas, insatisfechas y desconocidas.
Para ello, el Design Thinking emplea diversas
técnicas de investigación basadas en la
observación y la escucha, para informarse
sistemáticamente sobre las necesidades, tareas,
pasos e hitos del proceso de una persona.
04 El Design Thinking
integra la previsión.
La previsión nos abre el futuro y nos invita a explorar las incertidumbres.
Nos anima a sentirnos a gusto trabajando con incógnitas y, espera
de nosotros, que afrontemos una información insuficiente durante el
proceso de descubrir y crear un resultado tangible.
Sin imaginar de forma anticipada y disciplinada el futuro, el
proceso de planificación estratégico no sirve de nada.
05 El Design Thinking es un proceso
constructivo dinámico.
Es interactivo. Exige una definición, redefinición,
representación, evaluación y visualización contantes.
Es una experiencia cognoscitiva constante que surge de la
necesidad de obtener y aplicar nuevas percepciones a los
objetivos cambiantes. Por este motivo, la definición de
prototipos, la creación de artefactos tangibles y compartibles
se convierte en un elemento importante del conjunto de
instrumentos del Design Thinking.
06 El Design Thinking
fomenta la empatía.
Coloca al usuario en el centro de todo.
Fomenta el uso de instrumentos que nos ayuden a
comunicarnos con las personas con objeto de
comprender mejor sus conductas, expectativas,
valores, motivaciones y las necesidades que les
impulsan y que mejorarán sus vidas.
Usamos esta información para desarrollar
nuevos conocimientos por medio del
aprendizaje y la experimentación creativos.
07 El Design Thinking
reduce los riesgos.
Tanto si se trata del desarrollo y el lanzamiento de un nuevo
producto como de un servicio, aprender de los pequeños
fracasos inteligentes, arroja muchos beneficios. Son
cosas que siempre pasarán, pero las prácticas aplicadas del
Design Thinking ayudan a reducir los riesgos al tener en
cuenta todos los factores presentes en el ecosistema de
desarrollo, incluyendo la tecnología, el mercado, la
competencia, los clientes y la cadena de proveedores.
08 El Design Thinking puede
crear significado.
Las presentaciones del PowerPoint y las
hojas de Excel tienen una capacidad
limitada para transmitir visiones o ideas.
Crear significado es la parte más dificultosa del
proceso de diseño, y los instrumentos de
comunicación que se usan en el Design Thinking
(mapas, maquetas, esbozos y relatos) contribuyen a
captar y a expresar la información necesaria
para formar y socializar el significado. Llegar a
este punto requiere su tiempo, y se va forjando por
medio de las múltiples iteraciones y conversaciones.
09 El Design Thinking puede llevar la creatividad
empresarial al siguiente nivel.
Fomenta una cultura que valora los cuestionamientos, inspira la reflexión frecuente mientras
se actúa, celebra la creatividad, acepta la ambigüedad y crea significado visual por medio de
interacciones con visualizaciones, objetos físicos y personas.
Una organización que usa el Design Thinking crea “un proceso de
inspiración” y “sensibilidad” para hacer el contrato emocional que los
empleados tienen con su organización sea tangible.
10 El Design Thinking es la nueva lógica
competitiva de la estrategia empresarial.
El Design Thinking es la práctica más complementaria que se puede
aplicar a la teoría de la estrategia competitiva de Michael Porter. Permite
a las compañías crear nuevos productos, experiencias, procesos y
modelos de negocio que trascienden de lo que meramente
funciona. Los convierte en productos deseables, lo cual, constituye una
ventaja competitiva realmente sostenible por medio de la innovación.
Premisas principales
del Design Thinking
Enfocarse en valores humanos.
Tener empatía por las personas para las cuales estaremos
diseñando. El feedback de estos usuarios es fundamental.

No decirlo. Mostrarlo.
Comunicar visión de una manera significativa e
impactante creando experiencias, siendo ilustrativos y
contando buenas historias.

Colaboración radical.
Juntar en el equipo personas de distinto perfil. La diversidad
permite salir ideas radicales y con puntos de vista diferentes.
Ser consciente del proceso.
Tener claro el proceso de diseño y saber qué métodos
se utilizan en cada fase.

Cultura de prototipos.
Hacer prototipos no es simplemente una manera de validar
las ideas, debe ser una parte integral del proceso de
innovación.

Incita a la acción.
Se trata de hacer. De pasar de pensar a la acción.
 El proceso de
Design Thinking
Empatizar

Definir el
alcance Investigar Sintetizar Idear Prototipar Testear
Lo primordial durante el proceso de diseño es la empatía, ya que así
te centras en mayor medida en las personas y en los usuarios o clientes.

Observar. Miraremos a los usuarios y sus comportamientos

en su contexto. Trataremos de observar sin ser observados.

Involucrarse. Debemos haber generado una conversación

Empatizar para la cual, prepararemos algunas preguntas para que sea
estructurada. Lo importante es siempre preguntarnos por qué.

Mirar y escuchar. Debemos saber combinar la

conversación y el engagement. Debemos pedir que el cliente
nos explique cómo hace algunas cosas y, que además, nos diga lo
que pasa por su mente en los diversos aspectos de su vidas diaria.
Como diseñadores los problemas que tratamos
de resolver no son los nuestros sino los de
otros, debemos por lo tanto adquirir empatía
por lo que ellos son como personas y lo que es
Este modelo se basa en la
importante para ellos. aparición de dos tipos de
productos
para entender a los usuarios dentro bajo el paraguas
del contexto del cual de la misma marca:
El modo empatía es básicamente el trabajo que hacemos

1
se está diseñando así que nos esforzaremos por
Freemium
comprender qué hacen y por qué,Producto básico
sus necesidades (gratis)
físicas
como emocionales, como conciben el mundo y qué es
2
significativo para ellos. PodemosProducto
decir que básico
es una inmersión en un mar de aprendizaje.
con añadidos
esta etapa (de pago)

Esto significa que existe la posibilidad de ofrecer parte del servicio con menos
prestaciones gratis y que el coste sea sufragado por los usuarios premium y
otras fuentes de ingresos.
 Vamos ahora a arrojar claridad y enfoque sobre el espacio de diseño en
el que se definen y redefinen los conceptos. Es crucial la correcta
determinación del desafío del proyecto de diseño basado en lo
aprendido del usuario y su contexto. En esta etapa tratamos de dar
coherencia a la información que se ha reunido hasta ese momento.
Definir El modo definición significa crear una declaración de problema
viable y significativo que será guía para enfocarse de mejor manera
a un usuario en particular. El conocimiento sobre el usuario nace de
procesar y sintetizar la información y enfrentando el problema para
hacer conexiones y descubrir patrones racionales.
Para que el conocimiento
Este sobre
modeloel se
usuario
basaseaenválido
la aparición de dos tipos de
debe cumplir con los siguientes criterios:
productos bajo el paraguas de la misma marca:
Freemium 1
Enmarcar el problema con un enfoque directo.
Producto básico (gratis)
Ser inspirador para el equipo.
2 Producto básico con añadidos (de pago)
Generar criterios para evaluar ideas y contrarrestarlas.

Capturar las mentes

Estoysignifica
corazonesque de laslapersonas
existe estudiadas.
posibilidad de ofrecer parte del servicio con menos
prestaciones gratis y que el coste sea sufragado por los usuarios premium y
otras fuentes de ingresos.
 Ahora es cuando de verdad empezamos a diseñar y a crear ideas,
aprovecháremos los conceptos aprendidos en las fases anteriores para
hacer prototipos y crear soluciones innovadoras. En este momento,
todas las ideas son válidas combinándolo todo: el pensamiento
Idear consciente e inconsciente, pensamientos racionales y la
imaginación. En lugar de tratar de encontrar la mejor solución en esta
fase lo que vamos a tratar es de generar muchas alternativas que den
lugar a posibles solucione.
Generar múltiplesEste
ideasmodelo se basa en la aparición de dos tipos de
permite:
productos bajo el paraguas de la misma marca:
1
Sacar el máximo partido a las distintas visiones de
Freemium
cada equipo de trabajo. Producto básico (gratis)

2 Producto básico con añadidos (de pago)

Aumentar el potencial de innovación.
Descubrir áreas nuevas con potencial de innovación
que no se habíanEsto
considerado hasta
significa que el momento.
existe la posibilidad de ofrecer parte del servicio con menos
prestaciones gratis y que el coste sea sufragado por los usuarios premium y
otras fuentes de ingresos.
 Aunque comúnmente pensemos en los prototipos como objetos físicos
con cierto nivel de sofisticación, un prototipo puede ser un post-it, una
servilleta dibujada o incluso una tira cómica. Simplemente, se trata de
Prototipar que sea algo con lo que poder trabajar y experimentar, tanto el
usuario como el diseñador. Como norma, un prototipo debe ser una
manera rápida y barata con la que obtener aprendizaje mediante
ensayo y error. Se puede entregar entre usuarios y compañeros de
profesión y de equipo para obtener feedback.
 Este modelo se basa en la aparición de dos tipos de
Motivos para construir un prototipo:
productos bajo el paraguas de la misma marca:
1
Para pensar mejor en el problema.
Freemium Producto básico (gratis)
Para comunicar.
2 Producto
Para empezar conversaciones con los básico
usuarios.con añadidos (de pago)
Para cometer errores antes de manera barata.
Esto significa que existe la posibilidad de ofrecer parte del servicio con menos
prestaciones gratis y que el coste sea sufragado por los usuarios premium y
Para evaluar las alternativas.
otras fuentes de ingresos.
Para controlar el proceso de creación de soluciones.
 Este paso consiste en comenzar a testear y obtener
feedback y opiniones emitidos por usuarios y otros
interesados en el producto. Una regla de oro es hacer los
Evaluar prototipos pensando que acertamos y evaluarlos pensando que
nos equivocamos. Con esta etapa tenemos la oportunidad de
refinar y mejorar las soluciones. Lo ideal es evaluar y testear
el producto en el propio contexto del usuario.
 Este modelo se basa en la aparición de dos tipos de
Razones para entrar en labajofase
productos de evaluación:
el paraguas de la misma marca:
1
Aprenderemos más sobre el usuario y seguirá creciendo nuestra
Freemium Producto básico (gratis)
empatía a través de las observaciones.

2 de esta fase y ayuda a mejorar la

Para refinar los prototipos yProducto
los siguientes pasos dentro
las soluciones. Se traslada
básico con información
añadidos (dea pago)

iteración.
Esto significa que existe la posibilidad de ofrecer parte del servicio con menos
En ocasiones, la evaluación
prestacionesrevela
gratis que
y queno
el solo
costenos
seaequivocamos conusuarios
sufragado por los la premium y
solución, sino queotras
ni siquiera
fuenteshemos acertado identificando el problema.
de ingresos.
¡Lo Has llegado al final de la unidad

Para continuar, sal del modo “pantalla completa” y vuelve al

conseguiste! panel principal para realizar las actividades y evaluaciones.