INNOVACIÓN DE PROCESOS Y DISEÑOS DE PROYECTOS

MÓDULO 1

Lectura 1

INTRODUCCIÓN A LOS MÉTODOS ÁGILES Y LA FILOSOFÍA LEAN

Introducción

Mundo VUCA → descripción militar, siglas ingles (volátil, incierto, complejo y ambiguo). Desafíos empresariales:
organización ágil, adaptación rápida (sobrevivir). Surgen metodologías ágiles, desarrollo de software para adaptarse a
cada área. Velocidad – nueva forma de organizar y realizar las tareas.

Nacimiento de Agile

Metodologías ágiles, respuestas a problemas históricos, en el desarrollo de proyectos. La incertidumbre, desafíos y más
control de proceso, planificando, estimando y diseñando cada paso.

Desarrollo de software 1998 “crisis del software”, solución: diferentes técnicas y herramientas para asegurar la
construcción de productos de calidad, dentro de plazos y costes prefijados. Incrementar el control: requisitos detallados
(primer momento), técnicas para valorar la complejidad de trabajo y estimar el esfuerzo con herramientas que controlan
procesos y miden calidad. La aproximación falla.

“1986, Takeuchi y Nonaka describieron una forma de trabajo, el equipo transversal aborda distintas fases de la misma
forma que los jugadores de rugby afrontan un melé (scrum): empujando con decisión y al unísono”.

La idea se traslada al software y en 1955, los artículos describen aproximaciones para abordar proyectos Scrum. Se
define nueva forma de desarrollar software → programación extrema o XP (eXtreme Programming). Renuncia a los
requisitos preestablecidos y estables, convive con la incertidumbre y cambio.

XP – los requisitos pueden variar y el proceso se adapta a trabajar con la variabilidad, no rechaza cambio, los considera
como natural y saludable. “Capaces de trabajar con un entorno cambiante e incierto, mejor forma de adaptarse a las
formidables revoluciones tecnológicas, definidas por velocidad y cambios constantes y radicales”

Manifiesto Ágil

Referentes del desarrollo de software → 2001 – Manifiesto Ágil. Forma ágil de construir proyectos:

1. Valorar a individuos y sus iteraciones frente a procesos y herramientas: personas, dar toda la importancia y
poner en primer plano. Debe trabajarse igual con ayuda de procesos.
2. Valorar más el software que funciona que la documentación exhaustiva: documentar el trabajo y propio objeto
del proyecto, el producto. La propuesta es documentar solo lo imprescindible y de forma incremental, en
paralelo a la construcción del producto.

1
 3. Valorar más la colaboración con el cliente que la negociación de un contrato: forma más productiva, establecer
un marco de confianza y colaboración con quien nos lo encarga. También deben establecer bases formales de
entendimiento.
4. Valorar más la respuesta al cambio que el seguimiento de un plan: apreciar la incertidumbre como un
componente básico del trabajo, adaptación y flexibilidad (virtudes y no amenazas). Debe haber un plan igual.

Buscar orientación al cliente y al producto; flexibilidad; relevancia a las personas y comunicación; colaboración;
velocidad; autoorganización; calidad; simplicidad; y mejora continua.

Mentalidad ágil

Cambio de paradigma: partir de un presupuesto y fechas de entrega, trabajar para implementar la funcionalidad más
valiosa para el cliente en cada momento. El alcance será flexible. Para ser competitivos, hay que adaptar el producto a
medida que se va construyendo.

Los métodos ágiles sugieren formas de construir un producto que acepten esos cambios. Los métodos ágiles ofrecen
reglas generativas, favorecen a que se creen reglas nuevas en el caso de que fueran necesarias. Adoptan nuevas
prácticas útiles para el equipo y producto.

INTRODUCCIÓN A LOS MÉTODOS ÁGILES

Kanban
Kanban, palabra de origen japonés “tarjetas visuales”. Mostrar permanentemente y de forma visual el estado del
proyecto a todos los implicados. Método útil para gestionar los productos cuyos requisitos cambian constantemente
(nuevas necesidades o su prioridad varía). También es útil en casos complicados para planificar el trabajo. Apps: Trello o
Asana.

Pasos para trabajar con Kanban:

1. Visualizar el flujo de todo el trabajo: panel organizado en columnas, representado todo el flujo del trabajo que
hay que realizar en el proyecto (principio hasta final). Cada actividad se representa por una tarjeta (Kanban).
2. Dividir las columnas en los posibles estados de las tareas: dependiendo de la tarea y su complejidad, se puede
usar la cantidad de columnas necesaria para los distintos pasos del proceso. Cada actividad avanza de izquierda
a derecha por estas columnas.
3. Dividir el trabajo en ítems pequeños: cada actividad
debe escribirse en una tarjeta y colocarse en una de
las columnas del proceso. Dividir los ítems de forma
que la carga de trabajo sea similar entre unos y otros.
4. Limitar el trabajo en curso: Claves para que la
metodología Kanban funcione. Poner un límite al
número de ítems permitidos en cada columna para
evitar colapsos, cuellos de botella y eliminar los
impedimentos que surjan y que impidan trabajar con
un ritmo sostenido.

Lean software development

2
Adaptación del mundo de la fabricación industrial, tres objetivos principales: reducir el tiempo de entrega de un
producto, reducir su precio y reducir el número de defectos (mejorando calidad).

Se basa en una serie de siete principios, enumerados con distintas variantes para conseguir los objetivos deseados:

• Eliminar desperdicio: No le aporta beneficio al cliente y no directamente valioso para él debe ser eliminado. Si el
cliente no lo necesita o no es lo que quiere en este momento, directamente no debe hacerse.
• Optimizar el todo: Pensar desde un punto de vista global y orientado a largo plazo.
• Calidad integrada: Producto construirse con una calidad óptima desde el primer momento.
• Aprender constantemente: Creación como un experimento, acepta el cambio con normalidad. Ir aprendiendo y
entendiendo lo que se necesita a medida que se construye.
• Reaccionar rápido: Implementar rápidamente y con calidad las soluciones que el cliente necesita y que le
interesan en ese momento para, posteriormente, ir adaptando de forma rápida el producto a medida que se
vayan detectando nuevas necesidades.
• Mejora continua: Mejora centrarse en las personas y los procesos para construir un producto y no en mejorar
exclusiva y directamente el producto en sí.
• Cuidar al equipo de trabajo: un equipo de trabajo motivado, varias formas: proporcionando cierto grado de
autonomía para poder tomar decisiones con sentido; ofreciendo la posibilidad de aprender y mejorar de manera
permanente; y haciendo que sientan que su trabajo es valioso en todo momento.

Programación eXtrema o eXtreme Programming

XP → método ágil para el desarrollo de software y útil para abordar proyectos con requisitos vagos o cambiantes.
Funcional si se aplica a equipos de desarrollo medianos o pequeños. Desarrolla el código de forma que su diseño,
arquitectura y codificación permitan incorporar modificaciones y añadir una funcionalidad nueva sin demasiado impacto
en la calidad. XP es un método orientado hacia las personas, creando el producto como a los clientes y usuarios finales.

• Desarrollando con XP, se obtienen rápidamente resultados. Trabajar con pequeñas iteraciones, obtener con
frecuencia comentarios del cliente, resultado que el producto final cubra ampliamente expectativas y
necesidades.
• Las pruebas son la base de la construcción. Los desarrolladores escriban las pruebas a medida que van
construyendo el código. Las pruebas automáticas son constantes para poder detectar los fallos rápidamente.
• Antes de cada iteración se planifica el trabajo que va a realizarse y se realizan de forma simultánea el análisis, el
desarrollo, el diseño y las pruebas del código.

Lean Startup

Útil para definir productos y modelos de negocio, es aplicado por nuevas empresas en proceso de formación (startups)
como en departamentos de empresas ya consolidadas que definen nuevos productos y servicios.

• Lean Startup es complementario a otros métodos, pero no es excluyente. Seleccionar en cada momento la
mejor forma de trabajo para cada etapa o propósito. Puede definirse un producto con Lean Startup,
implementarse usando Scrum y gestionar su soporte con Kanban. Es más importante seleccionar la herramienta
adecuada en cada caso.

3
Conceptos importantes del método Lean Startup:

• Producto mínimo viable o MVP (minimum viable product): Definición del producto en el que se está trabajando
(o producto en sí) al final de una iteración. Capaz de validar hipótesis planteadas como objetivo a través de unas
métricas. MVP incluir capacidades y funciones básicas del producto, las de mayor valor posible al cliente,
dejando de lado elementos superfluos.
• Ciclo crear-medir-aprender: Se basa en iteraciones y un avance progresivo hacia el objetivo final. El ciclo de
trabajo se basa en tres etapas: crear el producto a partir de las ideas; ponerlo en el mercado y medir su
comportamiento; extraer información y aprender más para aplicarlo en la siguiente iteración.
• Métricas: Medir resultados y extraer información. Scrum o Kanban se mide el proceso, en Lean Startup se pide
el producto, o su comportamiento en el mercado. La creación de métricas adaptadas a cada circunstancia.
• Pivotar: En cada iteración se plantean unas hipótesis que se trasladan al producto y cuyo resultado se evalúa por
medio de las métricas para comprobar la validez de las asunciones iniciales. Si las hipótesis se ven refrendadas,
se persevera, pero, si deben cambiarse, se considera un cambio de rumbo, pivotando en una nueva dirección.

Scrum

Marco de trabajo que puede dar soporte a la innovación, basándose en equipos autogestionados. Con Scrum se pueden
obtener resultados con calidad en iteraciones cortas (entre una y cuatro semanas) → sprints. Scrum es el método ágil
más aplicado y con más elementos aplicables… Scrum (o melé en castellano). Necesidad de que se modifique la manera
de trabajar entre los equipos de desarrollo (coordinado, colaborativo y reactivo).

Principios:

• Inspección y adaptación: Trabaja en iteraciones (sprints), duración de entre 1 y 4 semanas. Cada iteración
termina con un producto entregable. Al finalizar cada iteración, este producto se muestra al cliente para que
opine sobre él. El equipo se reúne para analizar la manera de trabajo. Uniendo los dos puntos de vista, el qué se
ha hecho y el cómo se está construyendo, aprender con la experiencia y mejorar iteración tras iteración.
• Autoorganización y colaboración: Equipo se gestiona y organiza a sí mismo. Nivel de libertad, asumir
responsabilidad y un gran nivel de compromiso. Autoorganización funcionará con alta colaboración y espíritu de
equipo. Los líderes y clientes colaborarán igualmente con el equipo de desarrollo en todo momento, facilitando
su trabajo, resolviendo dudas y eliminando posibles impedimentos.
• Priorización: No perder tiempo y dinero en algo que no interesa inmediatamente para el producto. Tener
requisitos perfectamente priorizados y que reflejen el valor del negocio.
• Mantener un latido: Mantener un ritmo que dirija el desarrollo. Este latido marcará la pauta del trabajo y
ayudará a los equipos a optimizar su trabajo. El tener un ritmo fijo de trabajo, el día a día como en las
iteraciones o sprints, permite que el equipo sea predecible, aprenderá a estimar la cantidad de trabajo a la que
puede comprometerse. Ayuda a centrarse en crear el producto, tener fechas clave de iteración estables.
Mantener este latido permite convocar con mucho adelanto reuniones como la sprint review para que los
asistentes puedan organizar sus agendas con suficiente antelación y no faltar a la cita.

Una de las principales características de Scrum es que en cada iteración todas las etapas de la creación de un producto
se solapan, en cada sprint se realiza la planificación, análisis, creación y comprobación de lo que se va a entregar al final.

Lectura 2
4
INTRODUCCIÓN Y FRAMEWORK DE SCRUM

Introducción
Ágil, cambiante, volátil, vanidoso, complejo (mundo actual). Nuevos marcos de trabajo, formas operativas y estratégicas
de reversionar los procesos y proyectos. El ingeniero en I+D (gestor de novedad), atento a los nuevos marcos de trabajo
o framework, para ejecutar diversas formas de llevar a cabo objetivos empresariales.

Versión esquemática de Scrum

El ciclo de Scrum

• Comienza con sprint 0, el rol fundamental lo tiene el PO o product owner. Actúa como conexión entre el cliente
y el equipo y, partiendo de las necesidades del proyecto, se encarga de armar las bases para todo el desarrollo.
• El product owner debe crear el equipo; identificar recursos necesarios; fijar requisitos y plazos; traducir las
necesidades del cliente en requisitos; y elaborar un diseño preliminar formal. El resultado es un backlog o
repositorio del proyecto, incluye requisitos expresados en forma de temas, épicas e historias de usuario. El
contenido del backlog se ordena de acuerdo con las prioridades.
• El trabajo posterior se divide en iteraciones o sprints, que, se agrupan en una o varias releases o entregas de
acuerdo con la longitud del proyecto, las necesidades del cliente y naturaleza del trabajo. Cada una de esas
iteraciones o sprints arranca con el planning, el PO prioriza todas las historias de usuario y añade criterios de
aceptación para determinar cuándo se han cumplido.
• Ayuda del Scrum Master o SM (facilitador del trabajo, intermediario entre el PO y equipo y vigilante del
cumplimento de los principios de Scrum). El equipo de trabajo valora el esfuerzo para realizarlas y selecciona
(priorización fijada), las realizan en transcurso del sprint de acuerdo con la capacidad de trabajo del equipo.
• Segunda etapa, planificación, el equipo traduce las historias al lenguaje del proyecto y las subdivide en unidades
menores o tareas. Se construye el sprint backlog o repositorio de trabajos que se realizarán durante la iteración.
A lo largo del sprint se va realizando el trabajo y el equipo va exponiendo sus avances en la daily meeting (Scrum
diario o reunión diaria). Foro interno (compuesto por el equipo y SM) cada participante comenta los avances
realizados, trabajo futuro e impedimentos. Impedimentos se guardan en un impediment backlog y el SM vigila.
• El final del sprint lo señala la review meeting o reunión de revisión de resultados, el equipo, con el SM, expone
los trabajos realizados y resultados alcanzados al PO y resto de personas interesadas, para que acepten o no y
recoger comentarios y sugerencias a aplicar en la próxima iteración.

5
 • Finalmente, en reunión de retrospectiva, equipo y Scrum master revisan el proceso e identifican, aspectos
positivos (cuidar y mantener) y puntos de mejora a resolver dentro del proceso de mejora continua que supone
Scrum. El proceso queda documentado y seguimiento de capacidad del equipo o su velocidad como medida útil
para el incremento de la productividad.

Los valores de Scrum

➢ Mejora continua: miembros de un equipo Scrum identifican continuamente puntos de mejora y hacer lo posible
por aplicarlos para realizar su trabajo de forma más productiva y con mayor calidad.
➢ Calidad: Componente básico e innegociable, sacrificar calidad frente a cualquier otro aspecto (plazos o costes)
compromete el proceso y sus resultados.
➢ Time-boxing: Reunión de una hora solo va a durar una hora, que no se van a permitir divagaciones innecesarias
y que solo se van a considerar los temas relacionados con el asunto que se trata.
➢ Responsabilidad: Organización muy jerarquizada, la responsabilidad se acumula a medida que se asciende en la
organización. En Scrum, la responsabilidad es compartida y afecta a todos por igual.
➢ Multidisciplinar: En Scrum se espera que cada uno pueda ser autónomo y realizar todos los trabajos precisos sin
contar con contribuciones externas.
➢ Flexibilidad: Scrum reconoce la realidad y abraza el cambio, se define en torno a la idea de que los requisitos
pueden cambiar.
➢ Ritmo (latido): Scrum favorece que el equipo trabaje a un ritmo determinado. El objetivo es ofrecer
estimaciones de alcance y fechas a sus clientes lo más certeras posibles.
➢ Compromiso: Scrum exige un alto compromiso de todos los participantes en el proyecto.
➢ Simplicidad: Scrum prefiere las soluciones simples a las complejas, facilitará la labor.
➢ Respeto: Respeto mutuo entre los participantes garantiza las relaciones necesarias para el éxito de un proyecto.
➢ Coraje: Avanzar sin esperar órdenes, especialmente cuando el camino no está completamente claro.
➢ Foco: Scrum no permite distracciones. El proyecto es la actividad más importante del equipo y todos los demás
implicados, y debe mantenerse la atención concentrada en él.
➢ Predictibilidad: El equipo debe adoptar un ritmo determinado, trabajar de forma ordenada y disciplinada, y todo
con el objetivo de acabar siendo predecibles.
➢ Personas: Los métodos ágiles se centran más en las personas que en los procesos.

Lectura 3

EL EQUIPO SCRUM

Introducción
Conocer los roles, funciones e incumbencias del equipo Scrum para liderar con éxito la gestión del proyecto empresarial.
El ingeniero en I+D puede ir ocupando distintos roles conforme lo delimite él o el responsable general del área.

Los roles Scrum

6
Product Owner

• Forma parte del cliente y actúa como intermediario entre este y el equipo. Capaz de hablar el lenguaje de
negocios o de los requisitos del cliente y estar familiarizado con los métodos y conceptos empleados por el
equipo.
• Transmitir al equipo los requisitos y reacciones del cliente, actuando como él cuando surjan dudas y cuestiones
sobre el producto que se está construyendo. El product owner debe estar siempre disponible para el equipo.
• PO, representante del cliente ante el equipo, enfocado prioritariamente aspectos de negocio. Responsable del
éxito o fracaso del producto y rentabilidad de procesos técnicos. Encargado de transmitir la visión de producto al
equipo.
• Contenido y desarrollo del trabajo, el PO tiene varias responsabilidades. Fija las fechas clave de las distintas
entregas y quien debe priorizar los distintos requisitos. Ejercer control manteniendo al día el product backlog.
Los elementos contenidos en este (temas, épicas e historias) estarán correctamente descritos, con unas
condiciones de aceptación comprensibles y debidamente priorizadas.
• Para poblar este backlog, el PO debe mantener un contacto continuo con el conjunto de los stakeholders,
comprender sus necesidades y traducir sus requisitos en elementos del backlog, en lenguaje del equipo de
trabajo.
• El PO es quien acepta o rechaza las entregas del equipo por medio de las revisiones del trabajo realizado en cada
sprint y entrega. Mantiene una relación estrecha con el Scrum Master y asiste al menos a dos reuniones dentro
del ciclo de trabajo de cada sprint: review y planning.
- PO actuará en representación del cliente cuando este no pueda asistir y examinará el trabajo del equipo
para darlo por válido o no. El trabajo realizado se revisa de acuerdo con los criterios de aceptación
expresados en la descripción de cada historia, o por medio de una explicación, o examinando el producto o
demostrándolo.
• En la planificación o planning, el PO habrá incluido y priorizado las distintas historias en el backlog, dar todas las
explicaciones y aclaraciones que precise el equipo, fijar criterios claros de aceptación del trabajo. El PO es un
intermediario entre el mundo del negocio y equipo de trabajo, debe conocer los condicionantes de los dos.
Tiene capacidad de decisión definiendo y aceptando el trabajo como delimitando el entorno de desarrollo.

7
El Scrum master

Álvarez García, Gómez Lasa, Heras del Dedo (2018) indican:

• Scrum Master, es “facilitador”. Busca mejorar la productividad del equipo, aislandolo de interferencias externas,
eliminando impedimentos y procurando que fluya la comunicación y colaboración. Debe introducir y fomentar
las prácticas Agile.
• Como facilitador, trabaja muy cerca del product owner, pero cerca del equipo, protege de interferencias
externas, forma en técnicas Scrum, orienta y vela por alcanzar la máxima calidad y productividad.
• El SM supervisa el backlog, asegurándose de que las historias estén correctamente descritas, priorizadas y
estimadas. Es el verdadero supervisor de todo el proceso, ayuda al equipo a evaluar el resultado del trabajo,
analiza la velocidad del equipo, vela por calidad y sigue de cerca el proceso (principal objetivo).
• Intermediario entre el mundo exterior (PO, otros equipos) y el equipo de trabajo. Esta tarea forma parte de su
misión de fomentar la productividad protegiendo al equipo de interferencias externas.
• El SM se encarga de fomentar las buenas prácticas, formación y aplicación de nuevas herramientas. Su objetivo
último es hacerse prescindible y permitir que un equipo suficientemente maduro y entrenado sea capaz de
autorganizarse y funcionar sin la figura del SM.
• Síntesis, lista de los seis atributos principales que selecciona Mike Cohn:
- Responsable: SM responsable de que el equipo aplique correctamente Scrum, sin la coerción que implica
una autoridad formal. SM director de orquesta.
- Humilde: No debe restar protagonismo a los miembros del equipo. No debe destacar ni distinguirse.
Convence por medio del ejemplo y la inspiración.
- Colaborador: Se basa en la colaboración, fomentando la colaboración y buscando la forma de frenar las
actitudes contrarias y egoístas.
- Comprometido: Actitud comprometida con el proyecto, sus fines y la forma de llevarlo a cabo.
- Influyente: Convencer por medio del ejemplo y recurrir a su capacidad para persuadir a otros. Dotarse de
unas armas más políticas que metodológicas, técnicas o científicas.
- Entendido: Forma de influir en otros es desplegando un conocimiento erudito, tanto de Scrum y aspectos
metodológicos como del campo de aplicación en el que se esté desarrollando el trabajo.

El equipo
• Componentes del equipo de trabajo. No tienen un rol específico asignado, sin ellos es imposible llevar a buen
puerto el trabajo, proyecto o actividad en el que se estén aplicando los principios de Scrum.
• Forma tradicional de desarrollar cualquier trabajo se basa en la jerarquía, autoridad formal y estructuración. El
equipo en Scrum se autoorganiza, tiene responsabilidad final del éxito del trabajo y capaz de asumir cualquier
actividad dentro de las necesarias para desarrollar el proyecto.
• Imponen ciertos límites al equipo. Ej. tamaño: límite máximo de 10 a 12 personas a partir del cual debe
sopesarse la división y paso a una versión extendida de Scrum (o Scrum of Scrums). Los miembros del equipo,
elevado grado de compromiso, establecer un acuerdo entre las demandas del product owner y ofrecer el equipo
al final de cada sprint.
• Equipo en Scrum, capaz de autoorganizarse. Un jefe de proyecto asigna a cada persona tareas concretas y fijas.
El equipo Scrum deberá contar con personas capaces de asumir cualquier actividad (perfiles especializados para
ciertas partes del proyecto).

8
 • Ayuda del Scrum Master, equipo capaz de seguir la evolución productividad y mejorarla. Ayuda del SM, los
miembros del equipo deben entrar en un proceso continuo de mejora conocimientos y habilidades, como la
aplicación de mejores prácticas.
• Compromiso – necesidad de dedicación continuada y exclusiva de miembros del equipo al trabajo, salvo que sea
preciso contar puntualmente con perfiles muy especializados.

El cliente y los stakeholders

• Stakeholders: personas y organizaciones que tienen algún interés en el trabajo o proyecto que se va a realizar.
Se habla del “cliente”: conjunto de interesados en llevar a buen término el proyecto.
• Scrum: necesidad que plantear al equipo y quien cuenta con los recursos —económicos— para construir la
solución. Dueño de los requisitos y de los recursos.
• Los stakeholders y proceso scrum, conozcan y estén familiarizados con su terminología y forma de operar. Se
ofrece al cliente una nueva forma de trabajar, no es necesario tener perfectamente cerrados y delimitados los
requisitos y con la que podrá ir revisando resultados parciales a intervalos regulares.
• Cliente en Scrum - dos tareas: proporcionar requisitos y validar resultados. Definir el producto que se quiere
construir y examinar cuidadosamente los resultados intermedios (y finales) que ofrezca el equipo para dar sus
comentarios, correcciones y sugerencias, su feedback.

Lectura 4
ARTEFACTOS Y EVENTOS DE SCRUM

Introducción

Reuniones, gestión del tiempo, revisiones, reflexiones de equipo, detalle de producto → artefactos y eventos Scrum. El
ingeniero en I+D tiene que manejar las distinciones que hacen a cada uno, sabiendo transferir el conocimiento oportuno
para cada evento y artefacto Scrum

Artefactos

El trabajo se compone de múltiples elementos que deben estar al alcance de todos los participantes del proyecto.
Elementos = artefactos. Los almacenes, repositorios, pilas o backlogs son artefactos (sustentados por herramientas) en
los que se guardan todos los elementos que definen el trabajo. En Scrum se definen al menos tres backlogs, dentro de su
principio de flexibilidad y en función de las necesidades del trabajo, podrían definirse otros.

a) Product backlong o pila de productos

• Lista que contiene todas las entidades que definen el trabajo del proyecto.
• Gestionado por el product owner, refleja la visión del cliente, las entidades que contiene se refieren a los
requisitos: épicas, temas e historias de usuario.
• PO ordena de acuerdo con la prioridad de necesidades del negocio. La unidad de medida son los story points o
puntos de historia, reflejan la medida del esfuerzo asignada por el equipo en el momento de la planificación.

9
• La descripción de cada historia y criterios que definen su cumplimiento es parte crítica de la creación del product
backlog. Su creación es un trabajo en el desarrollo Scrum, es posible añadir y modificar su contenido, a partir de
un conjunto lo más amplio y detallado, describa todos los elementos fundamentales del proyecto.
• Una buena práctica es usarlo para recoger el trabajo futuro y pendiente de realizar, como guardar un rastro de
las actividades completadas

b) Sprint backlong o pila de sprint

• Lista de los trabajos que se van a realizar en una iteración o sprint determinado. Contiene las historias de
usuario y las tareas que el equipo (gestiona este backlog), ha identificado en la planificación de detalle.
• La unidad de referencia es el tiempo, las tareas concretas se pueden estimar con más exactitud. La descripción
es más concreta, desglosando las acciones que deben completarse en cada tarea, y no en forma de requisitos
(historias de usuario).
• El sprint backlog se realiza a partir del product backlog, seleccionando historias en función de la priorización
hecha por el product owner. El equipo estima cada historia, rechaza para que sean divididas aquellas que
exceden una complejidad determinada (número alto de puntos, como 13 o más) y añadiéndolas al backlog hasta
que se alcanza una suma de story points en las historias similar a la velocidad habitual del equipo.
• Cada historia seleccionada se divide en tareas, descritas en el lenguaje del dominio técnico del trabajo,
pequeñas, detalladas y con una estimación de tiempo para su realización. Se asume que cada tarea debe poder
ser realizada por una persona.

c) El impediments backlong o pila de impedimentos

• Repositorio que recoge aquello que impide alcanzar los objetivos del proyecto, incluyendo aquello que pueda
degradar o amenazar la calidad del producto final. Es gestionado por el SM y es actualizado a lo largo del sprint
con todos los impedimentos que se detecten y que se manifiesten en la daily meeting.
• Los impedimentos se priorizan para su resolución de acuerdo con el impacto que tengan en las actividades del
proyecto.

• Los otros artefactos importantes de Scrum son las gráficas. Hay una que representa la evolución del trabajo:
burn-down chart. Se representa en un eje el tiempo “X” (horizontal) e “Y” (vertical) la cantidad de trabajo que se
debe realizar. Esa cantidad de trabajo puede medirse en puntos de historia o como la suma de entidades (tareas
e historias de usuario) a realizar a lo largo del sprint o del conjunto del proyecto (menos habitual).

10
 • Una línea recta marca la evolución ideal del trabajo: se sitúa al principio en el número total de puntos o
entidades que se van a resolver y llega hasta el final del periodo señalando cero o que se ha resuelto
completamente.
• El SM se encarga de actualizar la cantidad de trabajo pendiente. La distancia entre la evolución real y la ideal o
estimada va a ir señalando si el trabajo se está realizando a un ritmo adecuado o si hay algo que corregir en el
proceso. Herramienta básica de consulta diaria

Eventos

Sprint 0

Momento en el que se definirá la misión del trabajo que se va a realizar, las herramientas y el equipo (objetivo final del
trabajo). El sprint 0 – etapa importante y de duración variable, pero no indefinida. Es una inversión que ahorrará
problemas y quebraderos de cabeza futuros.

Tiene muchos objetivos, dos por encima de los demás: definir las condiciones y el contenido del trabajo o alcance.

- Condiciones que van determinar el alcance del proyecto incluyen los recursos (financiación, personas,
herramientas) necesarias para desarrollarlo, como el marco temporal con la distribución y entrega de
resultados. Al final del sprint 0 es claro si el proyecto es viable y si cuenta con medios y apoyo necesarios
para llegar a buen fin.
- Contenido del trabajo, por medio de una primera versión del product backlog, lista de grandes trabajos y
tareas que van a desarrollarse en el transcurso del proyecto.

El producto backlog recoge la visión de requisitos más importantes del proyecto: principales funcionalidades o
resultados, productos generados, definición de la interacción con el usuario si la hay, entre otros. El product owner es el
protagonista de esta etapa, debe conseguir apoyos y recursos necesarios, seleccionar el equipo y Scrum master, acordar
el alcance y las fechas con el cliente y establecer condiciones para un buen fin del proyecto a desarrollar.

Sprints

o El desarrollo se divide en iteraciones, etapas o sprints. Cada una de estas etapas sigue una secuencia muy
precisa de reuniones que tiene como principal cometido garantizar el cumplimiento de los compromisos del
equipo de trabajo y el product owner.

11
 o Decisiones clave del sprint 0 es elegir la duración que inicialmente tendrá cada sprint. Lo más habitual es que
oscile entre 1 y 4 semanas, generalmente 2 o 3. Hay que fijar un calendario de releases o entregas, los
momentos en los que, pasado un número determinado de sprints, se va a ofrecer al cliente o destinatario del
trabajo un resultado parcial antes de completarlo.
o Si el product backlog recoge el conjunto de los trabajos que se van a realizar para alcanzar los requisitos del
cliente, hay un subconjunto, el sprint backlog, que contiene aquellos que se van a llevar a cabo durante la
duración de un sprint determinado. El contenido de este backlog es un compromiso entre necesidades del
cliente expresadas por medio del product owner y la capacidad de producción del equipo de trabajo.
o El alcance del trabajo de cada sprint se define a partir de los objetivos que fije el product owner, la priorización
de las tareas en el product backlog y compromiso del equipo.
o El sprint tiene tres etapas diferenciadas y marcadas por una serie de reuniones: arranca sprint planning (aunque
previamente el PO, con ayuda del SM, haya revisado y priorizado el backlog), se desarrolla en el tiempo que se
haya fijado con reuniones diarias o daily meetings y termina con una reunión de review y otra de retrospectiva.
Hitos del proceso

Sprints planning

• Al comienzo de cada sprint o iteración dedicar tiempo a planificar el trabajo. Antes de la reunión, el PO (apoyo
del SM) revisa el product backlog para asegurarse las historias de usuario (requisitos, lenguaje de negocio, se
divide el conjunto de la actividad) y las incluidas en la próxima iteración, correctamente descritas y priorizadas.
Backlog priorizado → punto de partida para el trabajo de planificación.
• Reunión terminar con unos objetivos claros: lista de historias que se compromete el equipo a realizar, o sprint
backlog; propósito global y claro para el sprint (product owner); compromiso firme del equipo para las historias
que ha seleccionado; estimación que hace el equipo de la entiendan el contenido y alcance de cada una de las
historias.
• El sprint planning se divide a su vez en dos etapas. La primera, con concurso del product owner, revisa cada
historia del product backlog siguiendo el orden de la priorización. El PO las explica, detalla los criterios de
aceptación para validar el trabajo realizado y atiende preguntas, dudas y aclaraciones que plantee el equipo.
• C/u historias de usuario, el equipo hará estimación, para delimitar el alcance del sprint, conocida la velocidad o
capacidad habitual del equipo. La estimación se valorará como esfuerzo necesario para realizar cada historia de
acuerdo con el equipo.
• Técnica → planning poker: cartas marcadas con números para que se asigne una valoración a cada historia. La
valoración parte de lo que cada miembro del equipo vota, usando su criterio y obteniendo el valor final como
una valoración media, compromiso entre todos o cualquier otro criterio establecido de previo acuerdo.
• Elemento importante de cada historia de usuario - criterio de aceptación: define qué es lo que permite
determinar si la historia se ha completado o no. Alcanzado un número suficiente de historias como para ocupar
el trabajo del equipo durante el sprint, se procede a su división en partes más manejables o tareas.
- El equipo de forma autónoma y permitirá desmenuzar cada historia en un conjunto de tareas más
manejables y expresadas en el lenguaje del dominio de trabajo (arquitectura, desarrollo de software,
marketing, etc).
- Incluirá para cada tarea una definición de completitud, definición de hecho o definition of done, la más
concreta y describe los criterios que permitirán determinar (punto de vista técnico) si se han completado o
no.
- El conjunto de historias de usuario y las tareas en las que se dividen conforman el sprint backlog, la
definición del trabajo que se va a desarrollar durante la iteración o sprint
12
Daily meeting o Scrum diario

Mecánica simple y repetitiva: cada miembro del equipo selecciona la siguiente tarea de acuerdo con el resto de los
miembros, siguiendo la priorización del backlog establecida por el PO. Usando herramientas seleccionadas para el
trabajo, marca la tarea para indicar que está en curso, va reflejando su evolución e informa cuando se completa.

• Para evitar que se pierda la sincronización entre el trabajo del equipo, mantener el ritmo y la “tensión” y para
fomentar la comunicación interna, Scrum propone el daily meeting o Scrum diario.
• Reunión diaria en la que participan todos los miembros del equipo y Scrum Master, puede asistir el PO.
• Cada miembro del equipo detallará qué actividades ha realizado, cuáles son las que piensa abordar a
continuación y qué impedimentos hay para continuar su trabajo.

SM participa como facilitador: no dirige la reunión ni da paso a cada miembro del grupo, “empuja” y facilita su
desarrollo. Toma nota de los impedimentos que haya para seguir su solución. La daily meeting es una reunión muy
breve, en la que deben dejarse de lado las discusiones detalladas.

Review o revisión

El final de cada sprint o iteración está marcado por una revisión del resultado y de la forma de alcanzarlo.

Revisión o review: reunión con la participación del Scrum master, conjunto del equipo, product owner (equipo
Scrum) y stakeholders (clientes, usuarios y quien tenga interés y pueda aportar valor al producto o proyecto). Se
repasa el trabajo realizado x los resultados obtenidos (programas, documentos, diseños o formato)
• Relevancia de los criterios de aceptación: descripción de resultados esperados y por qué se ha alcanzado o no el
objetivo de cada una de las historias incluidas en el backlog.
- Orden de priorización de las historias incluidas en el sprint backlog, los miembros del equipo van
exponiendo el resultado alcanzado.
- La exposición de resultados debe ser de la forma más gráfica y directa posible, si se puede demostrar el
resultado, se haga antes que enunciado o descrito.
• Vista de los resultados: product owner y conjunto de stakeholders, determinan si se han alcanzado o no los
objetivos propuestos inicialmente y expresados en los criterios de aceptación. Se identifican claramente los
elementos pendientes de completar (abordados en un próximo sprint, salvo que se cambie la prioridad).
- Lista de historias de usuario completadas y pendientes: las primeras sumarán a la hora de calcular la
velocidad real, solo incluye los trabajos completamente realizados.
- Forma de forzar una inclinación hacia completar el trabajo y no arrastrarlo sprint tras sprint sin poder
cerrarlo. Al final de la revisión de los resultados del sprint, el PO decidirá si el objetivo general propuesto
para el sprint se ha alcanzado o no.

Retrospectiva

• Reunión más importante del Scrum: define el espíritu de esta forma de desarrollar proyectos. Si uno de los
principios de Scrum es la mejora continua, la retrospectiva es el medio para analizar la forma en la que se hacen
las cosas y cómo mejorar el conjunto del proceso.
- Requiere la participación activa de todo el equipo, para examinar su funcionamiento y mejorar su trabajo.
Cuenta con el Scrum Master como facilitador y encargado de seguir el cumplimiento de los principios de
Scrum.

13
 - Análisis del proceso, no de requisitos y resultados de negocio, si el PO afecta o se ve afectado, es
conveniente que asista.
• La retrospectiva se centra en analizar la forma de trabajar de manera crítica, destacando los puntos fuertes y
débiles del equipo e identificando formas de mejorar.
- Revisión de la evolución concreta del sprint y sus resultados: qué objetivos tenía y si se han alcanzado, qué
dificultades fueron encontradas, dónde se ha fallado y qué se ha hecho bien y qué aspectos positivos hay
que destacar y conservar.
• Un punto básico de la retrospectiva es la valoración de la velocidad del equipo. El Scrum Master se encarga de
recopilar la estimación previa y contrastar el valor obtenido finalmente.
• Formas de medir velocidad, todas ellas subjetivas, no hay medida objetiva posible (excepto para trabajos
repetitivos, muy definidos y con poca incertidumbre).
- Estimación de complejidad que hacen los miembros del equipo en forma de puntos de historia o story
points.
- La suma de los puntos de todas las historias contempladas inicialmente en el sprint da la velocidad
estimada. Conocer la velocidad realmente alcanzada, solo se cuentan los puntos de aquellas historias que se
han considerado completamente cerradas en la review.
- Los equipos tienden a tener un valor de velocidad estable que facilita la estimación del alcance de cada
sprint. Si se repiten con la misma duración y mismas personas, ese valor tiende a ser predecible.
- La evolución de esa velocidad es un indicador de la mejora o degradación del proceso de desarrollo
realizado por el equipo.
• Cuidar la identificación de los riesgos e impedimentos que amenazan el trabajo para ayudar a su resolución;
como destacar todos los éxitos del trabajo para que sirvan de referencia y ejemplo futuros
• Cada miembro del equipo tiene la oportunidad de expresar su visión crítica sobre qué se está haciendo bien y
mal y de qué manera mejorar la forma de trabajar.
• Técnicas para recoger la visión de los miembros del equipo:
- Recopilación de sugerencias sin orden o una ronda para garantizar que nadie se quede sin dar su punto de
vista. Puede sintetizarse con facilidad en tres categorías (qué se hace bien, qué mal y qué hay que corregir) o
distinguirse en muchas.
- Al final de la retrospectiva debe quedar claro qué puntos de acción concretos hay que abordar para seguir
un proceso continuado de mejora. Esos puntos de acción deben ser asumidos y compartidos por todo el
equipo como parte de su compromiso para mejorar su forma de trabajo y productividad, y su aplicación es
una de las prioridades que deberá seguir el Scrum Master

14