Unidad 03

Unidad didáctica 3
Los documentos y su seguimiento, el

Scaling Scrum y la implementación de
Scrum
IFCD048PO METODOLOGÍA DE GESTIÓN Y DESARROLLO DE PROYECTOS DE SOFTWARE CON SCRUM
Índice
Introducción y objetivos
1. Documentos
1.1. Introducción
1.2. Product Backlog, historias de usuario y la ordenación
1.2.1. Introducción
1.2.2. Las historias de usuario, épicas y temas
1.2.3. Ordenar los elementos del Product Backlog
1.3. Criterios de estimación
1.3.1. Puntos de historia
1.3.2. Método de triangulación
1.3.3. Estimación por afinidad
1.3.4. Reestimar
1.3.5. Planning poker o póker de planificación
1.4. El sprint backlog y la velocidad
1.4.1. Sprint Backlog
1.4.2. La velocidad
1.5. Incrementos, DoD y planificación de entregas
1.5.1. Incrementos
1.5.2. Definición de "Completo" DoD (Definition of Done)
1.5.3. Planificación de las entregas
2. Seguimientos del progreso

2.1. Introducción
2.2. Project Burn-down chart
2.3. Burn-up
2.4. Sprint chart (tablón del sprint)
3. Principales obstáculos y herramientas ágiles

3.1. Identificación de los principales obstáculos
3.1.1. Durante la implantación
3.1.2. En los comienzos
3.2. Consejos para hacer más efectivas las reuniones Scrum
3.2.1. En el Daily Scrum
3.2.2. En el Sprint Planning
3.2.3. En el Sprint Review
3.2.4. En el Sprint Retrospective
3.3. Herramientas ágiles
4. El Scaling Scrum
4.1. Scrum de Scrums (SoS)
4.2. Otras metodologías para escalar Scrum
Resumen

INTRODUCCIÓN Y OBJETIVOS
En Scrum la transparencia es un pilar básico, por lo que el seguimiento sobre el
avance que se realiza sobre la iteración y sobre el propio proyecto está disponible. Es
una información que está al día y es útil para todo el Equipo Scrum y para
stakeholders.
Cuando un equipo trabaja en un proyecto con la metodología Scrum, pero el proyecto

requiere más desarrolladores u otros equipos, ¿podemos seguir utilizando Scrum? La
respuesta es que existen diferentes metodologías para escalar Scrum a nivel de
proyecto o a nivel de organización.
La gestión de los proyectos ágiles puede hacerse con tableros y Excel o utilizando
diferentes herramientas que sirven al equipo para estar sincronizado cuando está
deslocalizado, o para dejar evidencias de la gestión del proyecto o por razones de
auditoría de procesos.
Los objetivos de esta unidad son:
• Conocer la composición de los Product Backlog y cómo se trabajan las

historias de usuario, desde la priorización realizada por el Product Owner hasta
la estimación de esfuerzo por parte del Team.
• Entender qué es el Sprint Backlog y la técnica que el Team utiliza para

seleccionar las historias de usuario que desarrollará durante el Sprint, teniendo
en cuenta unidades de esfuerzo y no de tiempo, así como la velocidad y los
incrementos a entregar.
• Comprender cuáles son los diferentes gráficos utilizados para conocer el grado
de avance del proyecto, el trabajo realizado por el equipo y el tiempo estimado
para la finalización del proyecto. Nos familiarizaremos con el tablón que se
utiliza en el sprint.
• Descubrir las metodologías y herramientas para llevar Scrum a otro nivel, tanto
en escalado como en su ejecución a través de diferentes tips..

1. DOCUMENTOS
1.1. INTRODUCCIÓN
Durante el proyecto tendremos unos documentos, es decir, unos productos o

resultados de las actividades de gestión de dicho proyecto. Esos documentos están
diseñados para aumentar la transparencia de la información relativa a la entrega del
proyecto y propiciar oportunidades para la inspección y adaptación del mismo. A estos
documentos, Scrum les denomina artefactos.
En Scrum hay tres artefactos:
1. El Product Backlog.
2. El Sprint Backlog.
3. Incremento.
Adicionalmente, y para aportar mayor transparencia, hay elementos de seguimiento

del progreso del proyecto, como son:
• Monitorización del progreso del proyecto.

• Monitorización del progreso del sprint.
1.2. PRODUCT BACKLOG, HISTORIAS DE USUARIO Y LA

ORDENACIÓN
1.2.1. INTRODUCCIÓN
Recuerda
El Product Backlog es una lista ordenada de todo lo que podría incluir el

producto final del proyecto. Se puede definir como un listado de las distintas
partes (funcionalidades o características) que podría incluir el producto final
esperado. Es la única fuente de requisitos para cualquier cambio a realizarse
en el producto.
Es imprescindible que todos los elementos que componen el Product Backlog se

escriban en un lenguaje sencillo, y no técnico, que permita que sean comprensibles
por todo el equipo Scrum y stakeholders.

El Product Backlog es dinámico, cambia y mejora continuamente: nunca tiene el

estado de completo. Cada requisito y cada cambio en el proyecto, debe reflejarse en el
Product Backlog.
El Product Owner tiene la responsabilidad de ordenar los elementos del Product

Backlog. Establecerá una serie de factores que le ayudarán a determinar el valor de
cada uno. Todos los factores deben resumirse en un único valor que determina la
importancia de cada elemento y que se muestra junto a este.
Una vez que el Product Owner ha calculado el valor (la importancia) de cada
elemento, el Product Backlog se reordena en función de este valor, de mayor a menor
importancia. Cuanto más arriba se sitúe un elemento, más detallado estará y más
pronto lo entregará el Team.
Cada elemento del Product Backlog incluye una estimación de trabajo. Estas
estimaciones las realiza exclusivamente el Team y se utilizan para determinar el
número de elementos que se llevarse a cabo durante un sprint, en comparación con la
capacidad de trabajo que el equipo pueda desarrollar en un sprint.
El equipo Scrum realiza un refinamiento del Product Backlog que consiste en añadir
detalles, estimaciones y ordenar los elementos del Product Backlog a lo largo de todo
el proyecto. Esta actividad también es conocida como Backlog Grooming.
1.2.2. LAS HISTORIAS DE USUARIO, ÉPICAS Y TEMAS
Los elementos más comunes del Product Backlog son las historias de usuario. Son
pequeñas descripciones de los requerimientos del cliente. Al redactar las historias de
usuario se debe tener en cuenta describir el rol, la funcionalidad y el resultado
esperado en una frase corta. Para su construcción deben seguir el formato:
Como <quién> Quiero <qué> Para <objetivo>.
Ejemplo
Como Vendedor, quiero registrar los productos y cantidades que me

solicita un cliente para crear un pedido de venta.
Las historias de usuario deben ser independientes y de carácter no técnico. Algunas

fuentes sugieren que para su composición es conveniente seguir la pauta marcada por
las siglas INVEST:

- Independent (I), independiente: si los elementos del Product Backlog no son

independientes será imposible ordenarlos en función de su valor para el
negocio.
- Negotiable (N), negociable: los elementos del Product Backlog son también
una herramienta de comunicación y, por lo tanto, deben ser negociables.
- Valuable (V), valorable: cada elemento debe tener un valor de negocio
asignado, y este ser la base para ordenarlos.
- Estimatable (E), estimable: únicamente necesitamos tener estimaciones
fiables de los elementos de la parte superior del Product Backlog. El resto se
irán estimando de manera progresiva mediante el "refinamiento" del Product
Backlog.
- Small (S), pequeño: solo los elementos en la parte superior del Product
Backlog deben ser pequeños y detallados; el resto pueden ser más grandes o
generales.
- Testable (T), verificable: la prueba es siempre parte fundamental de la
definición de "completo".
Las historias de usuario nuevas, por lo general, serán más grandes y menos claras.
Pasado un tiempo, podemos trabajarlas y convertirlas en historias de usuarios más
pequeñas y, por último, aclararlas si fuera necesario.
Historia de usuario "épicas":
Las historias de usuarios que son demasiado grandes se conocen como historias de
usuario épicas. Es normal tener historias de usuario épicas en la parte baja del
Product Backlog. Llegado el momento, deberemos dedicar tiempo a "trabajar" estos
elementos y convertirlos en otros más pequeños e independientes (historias de
usuario).
Temas:
Las historias de usuario tienen que ser independientes. Se denomina tema a una
colección de historias épicas relacionadas para describir un sistema o subsistema en
su totalidad.
Por ejemplo, en un sistema de software para gestión contable, el conjunto de historias

épicas: "Altas, bajas y mantenimiento de clientes", "Facturaciones puntuales y

recurrentes", "Consultas de navegación y acciones de fidelización", "Pedidos",

"Devoluciones" se podrían denominar como el tema de la gestión de clientes.
Por lo general creamos grupos de elementos relacionados que generan "capacidades

de solución".
Comprender los temas es muy útil a la hora de planificar las entregas y asignar valor
de negocio a las historias de usuario individuales.
1.2.3. ORDENAR LOS ELEMENTOS DEL PRODUCT

BACKLOG
El Product Owner tiene la responsabilidad de ordenar los elementos del Product

Backlog. Los criterios habituales están relacionados con los siguientes conceptos:
- Beneficios:
¿Cuáles son los beneficios de la solución? Los beneficios se definen en función
de las estrategias de la organización y no son los mismos para todas. Sin
embargo, los beneficios monetarios son los más comunes.
- Costes:
La cantidad de recursos necesarios para el articulo o, en otras palabras, el
coste del artículo, es también un punto muy importante. Algo puede ser valioso
si es posible desarrollarlo con poco de esfuerzo, pero no si se necesita invertir
una gran cantidad de recursos.
- Riesgos:
Ordenar los elementos del Product Backlog es una de las principales formas de
gestionar los riesgos en un proyecto Scrum.
Nota
En general, el valor del negocio es la ratio beneficio/coste, y es por eso que

debemos tener en cuenta los dos. Hay muchas métricas que son
combinaciones de ambos, tales como: ROI (Retorno de la Inversion, Return On
Investment), VAN (Valor Actual Neto), Período de Recuperación, TIR (Tasa
Interna de Retorno).

Los Product Owners prefieren mantener los cálculos tan simples como sea
posible. Ten en cuenta que cada estimación del valor de negocio es una
estimación aproximada y no se debe perder el tiempo en detalles innecesarios
que no representen cambios significativos.
1.3. CRITERIOS DE ESTIMACIÓN

1.3.1. PUNOS DE HISTORIA
En Scrum no se utiliza la estimación tradicional basada en horas/hombre o

días/hombre. Para la estimación de las historias de usuario no se utilizan unidades
basadas en el tiempo. En su lugar se utilizan unidades de esfuerzo relativo, que
muestran la cantidad de esfuerzo necesario para realizar cualquier historia de usuario
en comparación con una historia de referencia. A esta unidad de referencia se le
denomina puntos de historia.
- Se debe partir de una referencia para determinar los puntos de cada historia.
- Se puede comenzar eligiendo una historia de usuario simple y que sea clara
para todos, que ya haya sido realizada varias veces antes y en la que se
conozca exactamente el esfuerzo requiere.
- Le asignamos 1 punto historia a esta historia de usuario y luego comparamos

el resto de historias con la elegida como referencia.
- Si el equipo de desarrollo cree que una determinada historia requiere cinco

veces el esfuerzo de la historia de referencia, el valor de dicha historia será de
5 puntos de historia.
Las características principales de los puntos de historia son dos:
1. Se basan en el esfuerzo en vez de en el tiempo.

2. Son relativos.
Nota
La historia de referencia no tiene por qué ser una historia real, solo algo lo
suficientemente pequeño, sencillo, claro, y familiar para todo el equipo de
desarrollo.

1.3.2. MÉTODO DE TRIANGULACIÓN
Es un método para realizar las estimaciones. En vez de utilizar una única historia de
usuario como referencia, se emplean múltiples historias de usuario de referencia en
función de su tamaño, y así utilizarlas para estimar cada historia de usuario.
Ejemplo
Puedes tener una historia de referencia de 1 punto y otro de 10 puntos. Cuando

comparas la historia objetivo con la primera referencia (1 punto) y decides que
se necesitan cinco veces el esfuerzo (5 puntos de historia). También debes
compararla con la segunda referencia (10 puntos) y ver si se necesita la mitad
de esfuerzo.
Estas comprobaciones dobles que se emplean para aumentar la fiabilidad de

las estimaciones se conocen como triangulaciones.
Una muy buena práctica para triangular las estimaciones es utilizar una tabla de
triangulaciones con columnas para cada valor y colocar las tarjetas de las historias
de usuario en su correspondiente columna, en función de la estimación asignada.
Logramos una comparación completa entre todas las historias y será mucho más fácil
encontrar cualquier problema de planificación y darle solución.
1.3.3. ESTIMACIÓN POR AFINIDAD
Estimar por afinidad es, a veces, una buena opción. En esta metodología de
estimación, el equipo de desarrollo empieza a clasificar las historias en función del
esfuerzo relativo que requieren cada una de ellas de menor a mayor, o viceversa.
Cuando las historias ya están clasificadas, se agrupan en función valores estimados

(puntos de historia).

1.3.4. REESTIMAR
Las estimaciones que hacemos sobre el esfuerzo relativo requerido para llevar a cabo
una historia de usuario pueden volverse a realizar para resolver algún malentendido o
como consecuencia de nuestro mayor conocimiento del proyecto. Cuanto mayor sea
nuestra experiencia en el proyecto, nuestras estimaciones serán más precisas.
En Scrum solo las historias de usuario que se encuentran en el Product Backlog

pueden ser reestimadas ya que no se reestiman cuando se mueven al Sprint Backlog
o cuando se completan. Si no se completan vuelven al Product Backlog, y entonces
pueden ser reestimadas de nuevo.
1.3.5. PLANNING POKER O PÓKER DE PLANIFICACIÓN
En esta técnica, el Team se reúne y el Product Owner explica la historia de usuario

para asegurarse de que todo el mundo la entiende. A continuación, el equipo puede
discutir el enfoque de desarrollo o cualquier otro aspecto técnico y finalmente se
establece su valor mediante votación.
La clave de esta estimación está en la forma de realizar la votación. Cuando la

votación se realiza secuencial, es decir, si empezamos a emitir votos uno por uno,
cada persona escuchara la opinión de todos los anteriores y su respuesta podría estar
sesgada. Empleando la técnica del póker de planificación evitamos ese sesgo.
El siguiente dibujo muestra una baraja normal de cartas de póker de planificación:

- En el "planning poker" cada miembro del equipo de desarrollo cuenta con una
baraja de cartas, elige una carta que muestra su estimación y la coloca hacia
abajo. Cuando todos estén listos se muestran las cartas al mismo tiempo.
- Si los valores propuestos por todos están en el mismo rango, el promedio de

los valores serán la estimación de la historia.
Si hay una gran diferencia entre los valores propuestos, entenderemos que no
todo el equipo lo comprende de la misma manera. Por lo tanto, se discute y se
vota de nuevo hasta que los valores están en el mismo rango.
- ¿Hay alguna diferencia entre 40 y 41 puntos cuando estamos

estimando? Por supuesto que no. Es por eso que las cartas no tienen
todos los valores. La mejor opción es utilizar la secuencia de
Fibonacci, en la que cada número es la suma de los dos números
anteriores o la secuencia de Fibonacci redondeada.
Secuencia Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,—

Secuencia Fibonacci redondeada: 1, 2, 3, 5, 10,15, 20, 35, 50, 100
- La historia de referencia no tiene por qué ser siempre la más pequeña, por lo
que podemos agregar cartas con el valor 1/2 punto. Incluso algunas historias
pueden ser más pequeñas de 1/2 punto de historia.
- Se puede incluir el valor 0. El valor de la historia cero significa que esta es

demasiado pequeña como para contemplarla como historia de usuario.
- Por otro lado, 100 puntos de historia o cualquier otro número mayor puede no
ser suficiente para algunas de las historias de usuario épicas que se
encuentren en la parte inferior del Product Backlog, por lo que también se
añade una carta con el valor ∞ (infinito), lo que demuestra que la historia es
demasiado grande para ser estimada y tendrá que ser descompuesta en algún
momento.
- No hace falta que las cartas estén en papel. Se pueden utilizar aplicaciones
móviles para el póker de planificación. Estas aplicaciones son solo un conjunto

de cartas electrónicas; tienes que elegir una y mostrar el teléfono móvil a la vez
que todo el mundo, como si se empleara una baraja convencional.
1.4. EL SPRINT BACKLOG Y LA VELOCIDAD

1.4.1. SPRINT BACKLOG
El Sprint Backlog se crea durante el evento de Sprint Planning, que es el primer evento
en un sprint. Durante el evento de Sprint Planning, todo el Equipo Scrum colabora en
la creación del Sprint Backlog, que, como hemos visto anteriormente, consiste en lo
siguiente:
1. Seleccionar el conjunto de elementos o funcionalidades (historias de usuario)

de la parte superior del Product Backlog que se realizarán durante el Sprint en
base a la capacidad y la carga de trabajo estimado del Team o Equipo de
Desarrollo.
2. Definir el objetivo del Sprint, que ayudará a comprender el significado real de
las funcionalidades y a dirigir los esfuerzos del equipo de desarrollo.
3. Crear un plan detallado para la entrega de los productos y la realización del
objetivo del sprint durante el sprint. Este plan detallado se actualizará
continuamente durante el sprint.
Recuerda
Después de la Sprint Planning, los elementos que componen el Sprint Backlog

permanecen inmutables, y el equipo de desarrollo se centrará en entregar un
incremento "completo" siguiendo el plan establecido. No se pueden añadir ni
eliminar historias de usuario en el Sprint Backlog durante el sprint.
Sin embargo, podría ser necesario obtener más información, justificar o aclarar
algunos de los elementos, lo que debe realizarse siempre en presencia del Product
Owner. El plan detallado del sprint, que habitualmente no está completo al final del
evento de Sprint Planning, continuará actualizándose a medida que avanza.

1.4.2. LA VELOCIDAD
Definición
La velocidad, en un proyecto Scrum, es la cantidad de puntos de la historia que

el equipo de desarrollo puede completar durante un sprint. Es un valor que
convierte los puntos de historia, basados en un esfuerzo relativo, en tiempo.
La velocidad se calcula como el promedio del número de puntos de historia

completados en los sprints anteriores. Se pueden excluir del cálculo los primeros
sprints, ya que pueden no ser representativos, o se puede calcular una media
ponderada con un mayor peso de los sprints más recientes, ya que la velocidad se
hace más o menos constante al conseguir un rendimiento más constante después de
los primeros sprints.
Para calcular la velocidad solo se tendrán en cuenta los puntos de historia de las
historias de usuario "completas" hasta el final del sprint.
Utilizamos la velocidad por dos razones:
1. Como referencia para estimar qué cantidad de trabajo puede realizar el

equipo de desarrollo en el próximo sprint. Por ejemplo, la velocidad es de
100 puntos de historia, el equipo de desarrollo seleccionará (de la parte
superior de la Product Backlog) artículos (funcionalidades) por valor de unos
100 puntos de historia.
2. Como una guía para estimar, de forma orientativa, la fecha de finalización
del proyecto. Si la velocidad es de 100 puntos de historia y los puntos de
historia que restan en el Product Backlog son 1.000 puntos, podemos estimar
que serán necesarios unos 10 sprints para terminar el proyecto, siempre que el
Product Backlog no cambie demasiado.
1.5. INCREMENTOS, DOD Y PLANIFICACIÓN DE ENTREGAS

1.5.1. INCREMENTOS
Definición
Un incremento es la suma de todos los elementos del Product Backlog

completados al finalizar un sprint. Cada incremento debe estar "completo" (al
100%) y debe ser entregable. El Product Owner puede decidir entregar o no
entregar un cierto incremento, pero este debe ser potencialmente entregable.

Se puede observar cómo el número de historias del Product Backlog disminuye en

cada sprint, mientras que el número de funcionalidades aumenta (incremento). El
concepto de incremento es acumulativo: cada incremento contiene las características
o funcionalidades de los sprints anteriores.
1.5.2. DEFINICIÓN DE "COMPLETO" DOD (DEFINITION

OF DONE)
- Debe existir un entendimiento común entre los miembros del equipo Scrum de
lo que significa que una pieza de trabajo esté "Completa". Esta definición de
"Completo" debe ser discutida y acordada por el Equipo Scrum al comienzo del
proyecto a fin de que los incrementos futuros puedan ser entregables.
- Cada equipo Scrum tiene su propia definición, pero la “definición de Completo”

es un entendimiento compartido de lo que significa que una tarea está
terminada y que puede generar un incremento potencialmente entregable a
nivel de proyecto.
- Trabajar en metodologías ágiles es trabajar con la mínima documentación

necesaria, e incluiremos la documentación imprescindible de cada historia de
usuario en la definición de Completo.
- Scrum se basa en un desarrollo iterativo e incremental por lo que no se espera

que una serie de historias de usuario estén completas para ejecutar las
pruebas. Las pruebas se ejecutan como parte misma de la definición de
“completo” de cada historia de usuario.
- Al comenzar con Scrum, definimos unos requisitos iniciales para el DoD que
debemos ir afinando, si fuera necesario, como resultado de una retrospectiva
para mejorar el desarrollo del trabajo para los siguientes sprints.
- No se cambiarán los requisitos de la Definición de Completo durante el sprint.
1.5.3. PLANIFICACIÓN DE LAS ENTREGAS
Recuerda
Cada incremento debe ser potencialmente entregable y Scrum se focaliza en

generar dichos incrementos. Incluso podríamos entregar al cliente algunos
elementos antes de la finalización del proyecto para generar ingresos e iniciar
el retorno de su inversión, así como para generar un feedback de mayor
calidad, al provenir directamente del usuario final del cliente.

El Product Owner es responsable de planificar las entregas en colaboración con el

cliente y otros stakeholders.
Para establecerse entregas existen diferentes opciones:

1. Entregas ad-hoc cada cierto tiempo. Como cada incremento es
potencialmente entregable, el Product Owner puede decidir si quiere entregar
el incremento después de la revisión del sprint.
2. Entregas en intervalos predefinidos; por ejemplo, cada 3 sprints. Es

posible que se haga una excepción con la primera versión para asegurarse de
contiene todos los elementos Must have. En cuanto la primera versión esté
disponible, se pueden establecer entregas regulares cada cierto número de
sprints.
3. Entregas definidas en base a las características necesarias de cada

entrega planificada. Se puede establecer una serie de historias de usuario
para cada versión y entregar el Incremento tan pronto como todas esas
características se hayan completado.
2. SEGUIMIENTOS DEL PROCESO

2.1. INTRODUCCIÓN
El Product Owner es responsable de realizar el seguimiento del progreso de todo el

proyecto hacia su finalización, y debe hacerlo al menos una vez por sprint. También
determina la cantidad de trabajo que queda y, comparándolo con el resto de trabajo de
los sprints anteriores, pronostica la fecha de finalización del proyecto. Siguiendo con el
principio de transparencia, todas las partes interesadas deben tener acceso a esta
información.
Se puede utilizar sprint burn-down chart (diagrama de avance del sprint) para
visualizar el progreso durante el desarrollo de un Sprint. Pero también se puede
realizar un seguimiento de todo el proyecto -Project burn-down chart.
Radiadores de Información:
Cualquier elemento o forma de presentar la información relativa al proyecto de manera

visible puede considerarse como un radiador de información. Pueden ser grandes
pantallas o simples tablones colocados sobre la pared.

Las características que deben tener los radiadores de información son:
- Debe tener una finalidad clara.

- La información debe ser la justa, mínima información de máximo valor, de fácil
lectura y comprensión.
- Debe estar ubicado en un lugar accesible y fácil de visualizar.
- Debe reflejar el momento: sirve para ver lo que importa ahora al equipo y en lo
que deben enfocarse. También les dice si van bien o van mal.
- Debe estar vivo: el panel debe estar actualizado al momento. Tan pronto la
realidad cambia, alguien del equipo debería cambiar el panel.
Los radiadores de información en forma de gráficos que se emplean normalmente son

siguientes:
- Project Burn down chart o gráficos de avance de un proyecto (también pueden

ser de barras).
- Burn-up o gráfico de productos.
- Gráfico de flujo acumulado.
- Tablón de sprint.
Nota
Todos los gráficos pueden incluir una estimación de finalización.
2.2. PROJECT BURN-DOWN CHART
El grafico burn-down de un proyecto muestra la cantidad de trabajo restante, en lugar

de la cantidad de trabajo realizado. Por lo tanto, la línea de desempeño real va hacia
abajo a medida que avancemos y cuanto más rápido desciende, más contentos
estaremos.
En el eje vertical (puntos de historia pendiente) se muestra la cantidad de trabajo

pendiente, que es la suma de las estimaciones de cada uno de los elementos del
Product Backlog. Y en el eje horizontal se muestra la cantidad de tiempo transcurrido
desde el inicio del proyecto o el número de sprints pasados.
Por lo general agregamos una segunda línea para representar la distribución del
volumen de trabajo estimado inicialmente para los sprints. Esta línea actúa como

nuestro indicador del progreso planificado, y la utilizaremos comparándola con

nuestros valores reales (Desempeño Real).
Project Burn-down chart - gráfico de barras:
La cantidad de trabajo pendiente depende de las historias ya realizadas y de los

cambios realizados en el Product Backlog.
Hay varias maneras de mostrar los cambios en el Product Backlog junto con el
desempeño real, una de ellas es utilizando un gráfico de barras.
Si empleamos un burn-down podría ser que en algún punto la línea ascendiera en

lugar de descender, ya que se habrían añadido nuevas historias en el Product
Backlog. Este hecho podría llevarnos a confusión y no mostraría el desempeño real
del equipo.
La línea muestra el rendimiento real, y cada barra muestra el volumen de las historias
restantes.
La parte superior de las barras solo cambia en función del volumen de historias
"completas" y, por lo tanto, solo se reduce. Por lo general, se añade una línea en la
parte superior de las barras para visualizar mejor el rendimiento real.
Los cambios en el volumen de historias restantes del Product Backlog se aplican a la

parte inferior de la barra.
2.3. BURN-UP

El diagrama que muestra el volumen de historias completas en lugar de las historias

pendientes se conoce como burn-up o gráfico del producto. En esta gráfica, la línea o
la barra muestran cómo el rendimiento sube a medida que se realiza el trabajo.
El burn up es una herramienta de planificación propia del Product Owner, que presenta
visualmente la evolución previsible del producto. Proyecta en el tiempo la construcción
del producto, en base a la velocidad del equipo.
Ejemplo
Mientras que la línea azul muestra el volumen total de puntos de historia del
Product Backlog hasta un determinado momento, incluidas las que se han
eliminado, la línea de color negro muestra el volumen de historias "completo".
Observa como la línea azul muestra claramente la cantidad de cambios en el

Product Backlog.
Para estimar la fecha de finalización podemos realizar el siguiente cálculo:

El cálculo se basa en el supuesto de que el volumen de historias restantes del

Product Backlog no cambie demasiado.
Gráfico de flujo acumulado:
La siguiente ilustración muestra un gráfico de flujo acumulado:
Observa como las barras negras representan los puntos de historia "completos" y la
barra azul el total de puntos de historia pendientes. Aunque esta es una muy buena
manera de mostrar los cambios en el Product Backlog y el avance del proyecto, los
diagramas de avance son más comunes y conocidos.
También podríamos estimar la fecha de finalización simplemente a partir de los valores

más recientes del Product Backlog.
2.4. SPRINT CHART (TABLÓN DEL SPRINT)

Además de monitorear el progreso del proyecto, también hay que controlar el progreso
de cada uno de los sprint a lo largo de la vida del proyecto. Esto es responsabilidad del
Equipo de Desarrollo y debe hacerse al menos una vez durante el Scrum Diario.
Esta información es necesaria para calcular la probabilidad de alcanzar el objetivo del

sprint y completar todos los elementos del Sprint Backlog.
La información del progreso sprint puede representarse en un burn-down, que puede

ser una parte del tablón del sprint, y estar visible para todo el mundo.
Esta medición se basa generalmente en las tareas. Es una medición más detallada y
genera un gráfico de avance más preciso, que es a su vez más útil para el control del
sprint.

Ejemplo
Observa en el siguiente ejemplo de tablero de Sprint cada uno de los

elementos:
1) El Objetivo del Sprint.
2) Los elementos seleccionados del Product Backlog para completar en el

sprint (azul).
3) El plan detallado (amarllo).
4) Incluye una gráfica de avance del sprint (Sprint Burn-down chart) que nos
ofrece información para el seguimiento del Sprint, y que podría actualizarse
después de cada reunión de Scrum Diario.
En
Objetivo del sprint Pendiente Completado
progreso
Item #1 t1.1
t1.2 t1.3
t1.4 t1.5
Habilitar todas las partes de la tienda
online para permitir que los usuarios t1.6
puedan experimentar un proceso de t2.1 t2.2
compra completa. Esta hará que otras Item #2
características de la página web sean más t2.3
significativas.
Item #3 t3.1
t3.2 t3.3
t3.4 t3.5
Item #4
t4.1 t4.2
t4.3
Item #5
El tablón cuenta además con otra información adicional que permite el

seguimiento de las tareas en las columnas "Pendiente", "En Progreso" y
"Completado".

3. PRINCIPALES OBSTÁCULOS Y HERRAMIENTAS ÁGILES

3.1. IDENTIFICACIÓN DE LOS PRINCIPALES OBSTÁCULOS
3.1.1. DURANTE LA IMPLANTACIÓN
Según los resultados del estudio del 12th anual State of Agile Report -2018, las cinco
principales barreras o frenos más importantes son:
1. La cultura de la organización está en desacuerdo con los valores ágiles.

2. Organización con una clara resistencia al cambio.
3. Elección de un champion o promotor que no tenga suficiente poder e influencia
dentro de la organización.
4. Falta de habilidades y experiencia en metodologías ágiles.
5. Formación y entrenamiento insuficientes.
Para superar las barreras relativas a la gestión del cambio es necesario que
el champion o promotor esté completamente convencido de que los enfoques ágiles
van a generar claros beneficios a la organización.
También es necesario demostrar al equipo directivo y al resto de la organización

cuáles serán los beneficios concretos y cómo van a ayudar a la organización a
conseguir los objetivos estratégicos.
3.1.2. EN LOS COMIENZOS
- Aplicar la metodología ágil a algunas partes o fases del proyecto:
Por ejemplo, se itera solo en la parte de desarrollo. Las demás fases son realizadas
conforme a la tradicional metodología en cascada (waterfall). La entrega de valor al
cliente, con sus fallos y aciertos, tiene lugar al final del proyecto, eliminando las
principales ventajas y mejoras del marco de trabajo ágil.
- Equipo de desarrollo demasiado especializado:

Los equipos Scrum han de ser multifuncionales. En un equipo de desarrollo

multifuncional se dispara la velocidad y la productividad ya que, al no depender tanto
de otras personas para realizar el trabajo se ahorra mucho tiempo en el proceso.
- El equipo de desarrollo no está acostumbrado a ser responsable:
En los proyectos de desarrollo tradicionales en los que los desarrolladores se limitaban

a hacer lo que les decían.
Con Scrum la responsabilidad de la auto-organización recae sobre el Team, así como

la autogestión.
- No disponer de un Product Owner o este no tiene tiempo:
Sin esta figura, nadie revisa la prioridad en los desarrollos (historias de usuario), ni la
utilidad de las entregas, ni aporta feedback. El Product Owner es responsable de
optimizar el valor del producto, y eso requiere un contacto y trabajo constante con el
resto del equipo Scrum, participando en todos los eventos y manteniendo la relación
con los stakeholders. Este ambiente de colaboración es necesario para que se
obtengan buenos resultados.
- El Scrum Master asume un rol controlador:
El Scrum Master se encarga de gestionar y asegurar que el proceso Scrum se lleva a

cabo correctamente, así como de facilitar la ejecución del proceso y sus mecánicas.
Pero no se encarga ni del desarrollo ni de la gestión de las personas que componen el
Team.
- Inconsistencias relativas a las historias de usuario:
Puede ser que las historias de usuario no estén priorizadas o no atiendan a criterio de
proporcionar el mayor valor para el cliente. También puede suceder que las historias
de usuario no sean independientes entre sí y no cumplan con el criterio I.N.V.E.S.T., o
que sean demasiado largas o mal expresadas.
Las épicas y las historias de usuario deben tener un nivel de detalle homogéneo a lo
largo del todo el proyecto.

Otro posible problema es que las historias de usuario no se hayan descompuesto en

tareas.
- Mala ejecución de los eventos de Scrum:
Puede suceder que no se realicen o no se desarrollen adecuadamente las

retrospectivas (sprint retrospective), que busca la participación y colaboración de todo
el equipo y generar un plan de mejora.
- No realizar mediciones o radiadores de información:
Existen casos en los que no utilizan las herramientas de medición y visualización

adecuadas, o, aun teniéndolas, no le prestan la atención necesaria no las actualizan
periódicamente.
3.2. CONSEJOS PARA HACER MÁS EFECTIVAS LAS

REUNIONES SCRUM
3.2.1. EN EL DAILY SCRUM
- No puede durar más de 15 minutos.

- Empieza y acaba la reunión a la hora prevista, independientemente del número
de asistentes.
- Es aconsejable realizarla en pie, aunque el Team se auto-organiza.
- Se debe realizar siempre en el mismo lugar y a la misma hora.
- Debe estar moderada por el Scrum Master.
- Deben asistir todos los miembros del equipo.
- Foco en dar respuesta a las 3 preguntas: ¿qué hice ayer?, ¿qué voy a hacer
hoy?, ¿he tenido algún tipo de problema?
- Hay que evitar distracciones como móviles, tabletas, portátiles…
Tips para el Team:
Para que el Team esté conectado y concentrado, el orden de intervención de las

personas se puede realizar utilizando una pelota que lanza la persona que ha
terminado su intervención y la recoge la siguiente en intervenir.
Si los miembros del equipo se interrumpen mucho, se puede utilizar un objeto que
indique quién puede hablar.

En problemas de duración, se puede utilizar un cronómetro que colocaremos en un

lugar visible para que el Team sea consciente del tiempo que tiene disponible.
3.2.2. EN EL SPRINT PLANNING
- Preparar el Sprint Planning con antelación. Las historias de usuario del

Product Backlog deben estar priorizadas.
- Revisar los parámetros básicos: fecha de inicio y finalización, la fecha y

ubicación del Sprint Review, la disponibilidad del equipo, y la definición de
terminado.
- Presentar y discutir cada historia: se tiene que definir un tiempo máximo

para esta etapa. Es bueno reservar una sección de "historias difíciles" al final,
para poder avanzar más fácilmente si la discusión se estanca en una historia.
- Comprometerse a las historias: revisar la lista y en el orden de prioridad. El

equipo se compromete una a una hasta que no puede comprometerse a más.
- Acuerdo: confirmar la lista de historias comprometidas con el Product Owner.

Es importante que todos tengan claro qué debe hacerse.
Tips para el Team:
Para cumplir con las expectativas, el Team debe tener en cuenta los burn-down charts
y la velocidad para hacer una buena estimación y compromiso con el sprint.
Calcular con mayor precisión el esfuerzo necesario para completar las historias de
usuario.
3.2.3. EN EL SPRINT REVIEW
- Prepara con antelación el lugar de la presentación para que disponga de PCs,

pantalla, videollamada, conexiones, etc. Evitarás fallos técnicos o retrasos.
- No conviertas esta reunión en algo monótono. Puedes variar la sala y el

entorno.
- Evita posiciones enfrentadas. Para ello, intercambia sillas entres entre

miembros del Equipo Scrum y los stakeholders.

- Haz que las diferentes reviews la hagan diferentes miembros del Team, para
que todos ellos se sientan participes y los stakeholders interactúen con todo el
equipo.
- Solicita que los stakeholders compartan su feedback con todo el Equipo Scrum.
Tips para el Team:
Si recibiste feedback de mejora en el sprint anterior, comienza la sesión indicando los

cambios realizados para mejorar.
Invita a participar a los stakeholders que asistan a la reunión. Prepara ordenadores o

dispositivos móviles que los stakeholders puedan “pilotar y tocar directamente”, para
recibir opiniones de experiencia de uso en primera persona. Es mucho mejor que una
demo donde enseñas pantallas.
Celebra lo conseguido y recuerda llevar el feedback al Retrospective Sprint.
3.2.4. EN EL SPRINT RETROSPECTIVE
- Recuerda los principales logros obtenidos durante el sprint.
- Agrupa y prioriza. Respecto a todas las cosas que han funcionado bien y las
que han funcionado mal. La priorización debe realizarse por todo el Team.
- Orientación a la acción. Crea acciones tangibles, medibles y asignados a un

responsable del seguimiento de la acción.
- Haz visibles los planes de acción y compártelas con todo el equipo.
3.3. HERRAMIENTAS ÁGILES
Para comenzar, durante los primeros sprints se utilizan post-its y hojas de Excel,
aunque después se pueden utilizar herramientas específicas. Cuando se ha empezado
a utilizar Scrum surge la necesidad de plantearse utilizar una herramienta digital para
la gestión del Product Backlog y del flujo de trabajo.

La elección de la herramienta depende de la necesidad real del equipo, ya que las

herramientas pueden ser demasiado simples o complicadas por defecto o exceso de
características.
A continuación, presentamos 10 herramientas a considerar:
1. Atlassian JIRA.
Esta herramienta se enfoca en ofrecer un stack completo de Product y Project

Management, desde la gestión de portfolio y budgeting hasta integración
continua, pasando por un wiki y un sistema de help desk.
Lo mejor es la integración de la suite. Lo peor es el esfuerzo de configurarla y

adaptarla.
2. VersionOne.
A raíz de una fuerte colaboración con Scaled Agile Inc, VersionOne ha ido
ganando popularidad durante los últimos años. Ofrece un stack similar al de
Atlassian, quizás más enfocado en el framework SAFe. Es una de las
herramientas de agile más utilizada, ya que es fácil de instalar y usar y tiene
una interfaz intuitiva.
3. Banana Scrum.
Está diseñada para ayudar al equipo a realizar un seguimiento de las cosas. Si

bien, no tiene la intención de reemplazar las necesarias interacciones humanas
del día a día en la gestión del proyecto.
4. Scrumblr.
Se trata de un sistema de publicación de notas en la web, de forma que los

usuarios pueden crearlas y colgarlas en una pizarra virtual. Esto facilita la
organización de las tareas y la coordinación del equipo a la hora de desarrollar
un proyecto. Cada columna de la pizarra virtual puede tener el título
personalizado, indicando el nombre de las personas responsables por cada
tarea, así como el día o mes en el que debe ejecutarse.

5. nTask.
Es una de las herramientas de gestión de proyectos que mejor se adapta a la

filosofía Scrum. Si JIRA te parece que tiene un propósito demasiado “general”,
nTask, seguramente, sea la aplicación a considerar.
6. QuickScrum.
Es otra de esas herramientas a considerar para los proyectos Scrum.
Además de su orientación hacia la metodología Scrum, también está

preparada para trabajar con otros modelos ágiles.
Sus desarrolladores afirman que en torno a QuickScrum se reúne la mayor

comunidad de profesionales y expertos en esa metodología y, de hecho,
ofrece formación y certificaciones profesionales en el uso de esta metodología
de trabajo.
7. VivifyScrum.
Está especialmente pensada para los profesionales que necesiten gestionar

proyectos desde una aproximación Scrum o Kanban.
La herramienta apuesta además por una interfaz minimalista que facilita la

gestión ordenada de ideas y que solo ofrece lo que necesitamos en el
momento preciso.
8. Taiga.
Taiga es un proyecto español que lleva poco tiempo en el mercado, pero es

muy prometedor.
Incorpora una gestión simple de Product Backlog Ítems (aunque ellos les
llaman historias de usuario), un tablero para los equipos y permiten hacer
planificación de producto dentro de la propia herramienta.
9. Pivotal Tracker.
Esta herramienta está diseñada por Pivotal Labs, una compañía de desarrollo
ágil de software que da servicio a clientes.
Pivotal ha sido durante años un referente en cuanto a diseño y usabilidad, y

esa ha sido su mejor baza contra herramientas más grandes.

10. TargetProcess
Esta herramienta, que lleva seis años en el mercado, se enfoca en el desarrollo

de producto más que de proyectos. Desde el Story Mapping hasta el
incremento.
TargetProcess se encuentra a medio camino entre Active Collab y Pivotal

Tracker, permitiendo a la vez una gestión clásica y ágil de los proyectos.
4. EL SCALING SCRUM
4.1. SCRUM DE SCRUMS (SOS)
Definición
Scrum de scrums es una técnica de la a varios equipos que necesitan trabajar

juntos para ofrecer soluciones complejas.
La creación de varios equipos para cumplir un objetivo común, en un único

proyecto, requiere coordinación, de ahí la necesidad de la técnica scrum de
scrums.
Recuerda
Los equipos de Scrum no deben de superar los 9 miembros para ser eficientes
y para que funcione la autoorganización. Si un producto requiere a más de 9
desarrolladores, en vez de hacer crecer a un equipo existente, el enfoque de
agilidad es crear varios equipos y distribuir el trabajo entre todos ellos. Para ello
necesitamos una forma efectiva para la coordinación, el alineamiento y la
comunicación entre estos equipos, así como una integración de las entregas a
final de sprint.
Esta técnica ayuda a los equipos a desarrollar y entregar productos complejos

mediante la transparencia, la inspección y la adaptación a escala. Scrum de Scrums
ofrece resultados especialmente buenos cuando todos los miembros del equipo de
scrum trabajan para alcanzar un mismo objetivo, confían los unos en los otros, se
respetan y están completamente coordinados.

Para que esto funcione, el tamaño del equipo resulta crucial. Los equipos demasiado
pequeños o demasiado grandes podrían tener problemas a la hora de entregar
productos complejos. Lo ideal es equipos de entre 3 y 9 personas.
Dividir un equipo muy grande en dos o tres más pequeños puede ayudar a desarrollar
las relaciones personales y mantener los resultados esperados, aunque es crucial
equilibrar las habilidades entre ellos, redefinir las características de los equipos
establecidos y repartir detenidamente las tareas, ya que podrían darse dependencias
imprevistas y posibles cuellos de botella nuevos que podrían atrasar la entrega.
Es vital prestar especial atención a las retrospectivas y a la jerarquización por orden de

prioridad de las historias ayudará a solucionar estos problemas.
Scrum de scrums: la estructura a escala:
El equipo de Scrum de Scrums utiliza básicamente las mismas prácticas, participa en

los mismos eventos y cuenta con las mismas funciones que el Equipo de Scrum para
ofrecer un producto integrado y que se pueda entregar fácilmente al final de cada
sprint.
Existe la función de Product Owner Principal, que se encarga de supervisar al equipo

Products Owners y de ayudar a orientar la visión global del producto.
Una función nueva es la de experto en Scrum de Scrums, quien debería centrarse en

el progreso y en los backlogs de obstáculos visibles para los otros equipos, de forma
que facilite la jerarquización por orden de prioridad o la eliminación de los obstáculos,
y mejore constantemente la eficacia del Scrum de Scrums.
Estas funciones nuevas hacen uso del scrum diario a escala en una reunión de 15
minutos para alinear, mejorar y atajar los obstáculos. Un representante de cada equipo
debería analizar los obstáculos del equipo, los riesgos para lograr el objetivo del sprint
o las dependencias de otros equipos, siguiendo con cualquier mejora que se haya
detectado y que pueda resultar útil para otros equipos.
Nota
El Scrum de Scrums es una técnica ampliamente utilizada y una forma clave de

escalar Scrum. Un requisito previo indispensable para escalar es componer el

equipo de manera correcta y proporcionarle suficiente tiempo y espacio para

crecer.
No existe una única forma correcta de ampliar la metodología ágil, pero

muchas organizaciones han tenido un gran éxito en la evolución de sus
procesos, equipos y culturas con marcos para llevarla a cabo.
4.2. OTRAS METODOLOGÍAS PARA ESCALAR SCRUM
No hay una única metodología para escalar Scrum en las organizaciones. Las
metodologías más conocidas son:
- SAFe (Scaled Agile Framework):
Este framework describe tres niveles de organización: cartera, programa y

equipo.
Esta estructura suele ser atractiva para grandes organizaciones porque SAFe
emplea un enfoque escalonado para la entrega de trabajo.
Varios equipos ágiles trabajan juntos en cada programa dentro de la

organización. Cada programa contiene varias características y elementos de
trabajo de arquitectura que componen la acumulación de programas.
Como idea general, a nivel de programa encontramos los ART (Agile Release
Train), que son equipos de equipos centrados en mantener el foco de trabajo y
entregar valor de manera sincronizada y cada cierto tiempo.
Es por esto que se considera la cadencia y la sincronización hechos

fundamentales en SAFe.
- Nexus:
Nexus puede ser visto como un contenedor sobre Scrum que se rige por los
mismos pilares valores, roles, eventos y artefactos complementado con aquello
que es necesario para escalar manteniendo la consistencia de Scrum.

Un Nexus puede estar formado con hasta 9 equipos Scrum, para escalar más
de nueve equipos podemos usar Nexus+. Un Nexus+ puede estar formado por
hasta 9 Nexus, y de allí podríamos seguir incorporando otros Nexus o Nexus+
para escalar a toda una organización.
Nexus está enfocado a integrar el trabajo de entre 3 y 9 equipos Scrum que

trabajen sobre un mismo Product Backlog, siendo su principal finalidad la
integración del trabajo de estos equipos al final de cada sprint.
¿En qué consiste?:

o Roles: se introduce un nuevo rol, el Equipo de Integración Nexus, que
se encarga de coordinar, entrenar y supervisar la aplicación de Nexus y
que está formado (al igual que Scrum) por un Product Owner, un Scrum
Master y los Nexus Integration Team Members. Este equipo será el
responsable principal de que se produzca un incremento integrado al
final de cada sprint.
o Artefactos: todos los equipos Scrum utilizarán el mismo Product
Backlog y se incorporará un nuevo artefacto, el Nexus Sprint Backlog, a
fin de que exista la mayor transparencia posible durante cada Sprint. A
su vez cada equipo Scrum tendrá su propio Sprint Backlog.
o Eventos: algunos eventos se añaden y otros reemplazan a los eventos
regulares de Scrum para servirles de suplemento o para mejorarlos.
- LeSS (Large-Scale Scrum):
LeSS es Scrum multi-equipo y trata de descubrir cómo aplicar los principios, el

propósito, los elementos y la elegancia de Scrum en un contexto a gran escala,
y de la forma lo más simple posible.
Nos enseña que no existen mejores prácticas en el desarrollo de productos,

solo hay prácticas que son adecuadas dentro de un contexto determinado, y
esas hay que descubrirlas. Como en toda adopción de agilidad, hay que
cambiar la estructura de la compañía, y LeSS nos enseña que hay que hacerlo
desde los principios.
La fase principal es la de convencimiento de la aplicación de principios, una

fase que suele superar los 6 meses, y una vez llegado al punto de inflexión, la

adopción del entorno LeSS consiste en un aprendizaje continuo mediante

inspección y adaptación, y haciendo transparente todo aquello que sea
necesario para aprender. Nos provee de guías y experimentos con dinámicas
para aprender sobre la compañía, pero hay que evitar o eliminar aquellas que
limitan la mejora continua o simplemente no encajan.
RESUMEN
La auto-organización y auto-gestión del Team o Equipo de Desarrollo se hace evidente

al trabajar las historias de usuario con la estimación del esfuerzo necesario para
desarrollar cada una de ellas. El Team seleccionará las historias de usuario que más
valor aporten al cliente, priorizadas por el Product Owner y las trabajará y planificará
en detalle.
La responsabilidad del Product Owner de hacer seguimiento del avance del proyecto
se ve reflejado en la gestión de los gráficos con los que se trabajan en Scrum, tanto
por el avance mostrado en el Project Burn-down chart como en la actividad sobre el
producto mostrada en el Burn-up chart. También podrá realizar estimaciones sobre la
finalización del proyecto.
Existen diferentes modelos para escalar Scrum, aunque puede suceder que
su implementación termine en fracaso.
Para poner en marcha y realizar con eficiencia los eventos de Scrum es

necesario saber qué hacer y cómo dirigir cada una de las reuniones.

Unidad 03

Cargado por

Copyright:

Formatos disponibles

Unidad 03

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad 03

Cargado por

Copyright:

Formatos disponibles

Unidad didáctica 3

Los documentos y su seguimiento, el

2. Seguimientos del progreso

3. Principales obstáculos y herramientas ágiles

Cuando un equipo trabaja en un proyecto con la metodología Scrum, pero el proyecto

Los objetivos de esta unidad son:

• Conocer la composición de los Product Backlog y cómo se trabajan las

• Entender qué es el Sprint Backlog y la técnica que el Team utiliza para

Durante el proyecto tendremos unos documentos, es decir, unos productos o

En Scrum hay tres artefactos:

Adicionalmente, y para aportar mayor transparencia, hay elementos de seguimiento

• Monitorización del progreso del proyecto.

1.2. PRODUCT BACKLOG, HISTORIAS DE USUARIO Y LA

El Product Backlog es una lista ordenada de todo lo que podría incluir el

Es imprescindible que todos los elementos que componen el Product Backlog se

El Product Backlog es dinámico, cambia y mejora continuamente: nunca tiene el

El Product Owner tiene la responsabilidad de ordenar los elementos del Product

1.2.2. LAS HISTORIAS DE USUARIO, ÉPICAS Y TEMAS

Como <quién> Quiero <qué> Para <objetivo>.

Como Vendedor, quiero registrar los productos y cantidades que me

Las historias de usuario deben ser independientes y de carácter no técnico. Algunas

- Independent (I), independiente: si los elementos del Product Backlog no son

Historia de usuario "épicas":

Por ejemplo, en un sistema de software para gestión contable, el conjunto de historias

recurrentes", "Consultas de navegación y acciones de fidelización", "Pedidos",

Por lo general creamos grupos de elementos relacionados que generan "capacidades

1.2.3. ORDENAR LOS ELEMENTOS DEL PRODUCT

El Product Owner tiene la responsabilidad de ordenar los elementos del Product

En general, el valor del negocio es la ratio beneficio/coste, y es por eso que

1.3. CRITERIOS DE ESTIMACIÓN

En Scrum no se utiliza la estimación tradicional basada en horas/hombre o

- Le asignamos 1 punto historia a esta historia de usuario y luego comparamos

- Si el equipo de desarrollo cree que una determinada historia requiere cinco

Las características principales de los puntos de historia son dos:

1. Se basan en el esfuerzo en vez de en el tiempo.

1.3.2. MÉTODO DE TRIANGULACIÓN

Puedes tener una historia de referencia de 1 punto y otro de 10 puntos. Cuando

Estas comprobaciones dobles que se emplean para aumentar la fiabilidad de

1.3.3. ESTIMACIÓN POR AFINIDAD

Cuando las historias ya están clasificadas, se agrupan en función valores estimados

En Scrum solo las historias de usuario que se encuentran en el Product Backlog

1.3.5. PLANNING POKER O PÓKER DE PLANIFICACIÓN

En esta técnica, el Team se reúne y el Product Owner explica la historia de usuario

La clave de esta estimación está en la forma de realizar la votación. Cuando la

El siguiente dibujo muestra una baraja normal de cartas de póker de planificación:

- Si los valores propuestos por todos están en el mismo rango, el promedio de

- ¿Hay alguna diferencia entre 40 y 41 puntos cuando estamos

Secuencia Fibonacci: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,—

- Se puede incluir el valor 0. El valor de la historia cero significa que esta es

1.4. EL SPRINT BACKLOG Y LA VELOCIDAD

1. Seleccionar el conjunto de elementos o funcionalidades (historias de usuario)

Después de la Sprint Planning, los elementos que componen el Sprint Backlog

La velocidad, en un proyecto Scrum, es la cantidad de puntos de la historia que

La velocidad se calcula como el promedio del número de puntos de historia

Utilizamos la velocidad por dos razones:

1. Como referencia para estimar qué cantidad de trabajo puede realizar el

1.5. INCREMENTOS, DOD Y PLANIFICACIÓN DE ENTREGAS

Un incremento es la suma de todos los elementos del Product Backlog

Se puede observar cómo el número de historias del Product Backlog disminuye en

1.5.2. DEFINICIÓN DE "COMPLETO" DOD (DEFINITION