Metodología Ágil: Scrum

https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Rational+Tea
m+Concert+for+Scrum+Projects/page/SCRUM+como+metodolog%C3%ADa

1. Introducción
2. ¿Qué es Scrum?
3. Beneficios
4. Cómo funciona
5. Fundamentos
6. Historias de Usuario

1. Introducción

“Tanto Scrum como Programación Extrema (XP) requieren que los equipos completen
algún tipo de producto potencialmente liberable al final de cada iteración. Estas
iteraciones están diseñadas para ser cortas y de duración fija.

Este enfoque en entregar código funcional cada poco tiempo significa que los equipos
Scrum y XP no tienen tiempo para teorías. No persiguen dibujar el modelo UML
perfecto en una herramienta CASE, escribir el documento de requisitos perfecto o
escribir código que se adapte a todos los cambios futuros imaginables. En vez de eso,
los equipos Scrum y XP se enfocan en que las cosas se hagan. Estos equipos aceptan
que puede que se equivoquen por el camino, pero también son conscientes de que la
mejor manera de encontrar dichos errores es dejar de pensar en el software a un nivel
teórico de análisis y diseño y sumergirse en él, ensuciarse las manos y comenzar a
construir el producto.”[1]

2. ¿Qué es Scrum?

Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene
origen en unestudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por
el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde
la innovación, la competitividad, la flexibilidad y la productividadson
fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al

cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la
 rotación alta, cuando es necesario identificar y solucionar ineficiencias
sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado
en el desarrollo de producto.

3. Beneficios
Los principales beneficios que proporciona Scrum son:

 Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese

momento, ya completados) lo cual proporciona las siguientes ventajas:
o Gestión regular de las expectativas del cliente y basada en resultados tangibles.
o Resultados anticipados (time to market).
o Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado,
etc.
o Gestión sistemática del Retorno de Inversión (ROI).
o Mitigación sistemática de los riesgos del proyecto.
 Productividad y calidad.
 Alineamiento entre el cliente y el equipo de desarrollo.
 Equipo motivado.
4. Cómo funciona
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un
mes natural y hasta de dos semanas, si así se necesita). Cada iteración tiene que
proporcionar un resultado completo, un incremento de producto final que sea
susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como
plan del proyecto. En esta lista el clienteprioriza los objetivos balanceando el
valor que le aportan respecto a su coste y quedan repartidos en iteraciones y
entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y
el retorno de inversión mediante la replanificación de objetivosque realiza al inicio de cada
iteración.

Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la iteración. Tiene

dos partes:
1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de
requisitos priorizada del producto o proyecto. El equipo pregunta al cliente las dudas
que surgen y selecciona los requisitos más prioritarios que se compromete a completar
en la iteración, de manera que puedan ser entregados si el cliente lo solicita.
2. Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la
iteración necesarias para desarrollar los requisitos a que se ha comprometido. La
estimación de esfuerzo se hace de manera conjunta y los miembros del equipo se
autoasignan las tareas.

Ejecución de la iteración
 Cada día el equipo realiza una reunión de sincronización (15 minutos máximo). Cada
miembro del equipo inspecciona el trabajo que el resto está realizando (dependencias
entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden impedir
este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con
el compromiso adquirido. En la reunión cada miembro del equipo responde a tres
preguntas:
 ¿Qué he hecho desde la última reunión de sincronización?
 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con su
compromiso y de que no se merme su productividad.
 Elimina los obstáculos que el equipo no puede resolver por sí mismo.
 Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.

Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene dos

partes:
1. Demostración (4 horas máximo). El equipo presenta al cliente los requisitos
completados en la iteración, en forma de incremento de producto preparado para ser
entregado con el mínimo esfuerzo. En función de los resultados mostrados y de los
cambios que haya habido en el contexto del proyecto, el cliente realiza las
adaptaciones necesarias de manera objetiva, ya desde la primera iteración,
replanificando el proyecto.
2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar
y cuáles son los problemas que podrían impedirle progresar adecuadamente,
mejorando de manera continua su productividad. El Facilitador se encargará de ir
eliminando los obstáculos identificados.
4.1. Actividades
4.1.1. Planificación de la iteración (Sprint Planning)
La planificación de las tareas a realizar en la iteración se divide en dos partes:

 Primera parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas* :

o El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone
nombre a la meta de la iteración (de manera que ayude a tomar decisiones durante
su ejecución) y propone los requisitos más prioritarios a desarrollar en ella.
o El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade
más condiciones de satisfacción yselecciona los objetivos/requisitos más
prioritarios que se compromete a completar en la iteración, de manera que
puedan ser entregados si el cliente lo solicita.
 Segunda parte de la reunión. Se realiza en un timebox de cómo máximo 4 horas*. El
equipo planifica la iteración, elabora la táctica que le permitirá conseguir el mejor
resultado posible con el mínimo esfuerzo. Esta actividad la realiza el equipo dado que
ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien
mejor conoce cómo realizarlo.
o Define las tareas necesarias para poder completar cada objetivo/requisito, creando
la lista de tareas de la iteración (Sprint Backlog) basándose en la definición de completado.
 o Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
o Cada miembro del equipo se autoasigna a las tareas que puede realizar.
* Estos son tiempos máximos en el caso de iteraciones mensuales. En iteraciones de
tamaño menor el tiempo es proporcionalmente inferior, y se puede ir reduciendo
conforme el equipo va ganando experiencia en este tipo de reuniones, aunque también
dependerá de la complejidad a desarrollar en la iteración.

Beneficios
 Productividad mediante comunicación y creación de sinergias:
o Todos los miembros del equipo tienen una misma visión del objetivo y se ha utilizado los
conocimientos y las experiencias de todos para elaborar la mejor solución entregable en el
mínimo tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y
dependencias entre tareas, etc.
 Potenciación del compromiso del equipo sobre el objetivo común de la iteración:
o Es todo el equipo quien asume la responsabilidad de completar en la iteración los
requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algún
impedimento que bloquea el progreso de la iteración, especialmente si cuando se está
llegando al final de la iteración es necesaria la participación de todos para poder completar
los objetivos comprometidos.
o Es cada una de las personas la que se responsabiliza de realizar sus tareas (a las que
se autoasignó) en los tiempos que proporcionó. Si existe falta de compromiso con
respecto al resto de miembros del equipo se hará muy evidente en las reuniones diarias
de sincronización del equipo (Scrum daily meeting).
 Una estimación conjunta es más fiable, dado que tiene en cuenta los diferentes
conocimientos, experiencia y habilidades de los integrantes del equipo.

4.1.2. Ejecución de la iteración (Sprint)

En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de un
mes natural y hasta de dos semanas). Cada iteración tiene que proporcionar un
resultado completo, un incremento de producto que sea susceptible de ser entregado
con el mínimo esfuerzo cuando el cliente (Product Owner) lo solicite.

 Cada día el equipo realiza una reunión de sincronización, donde cada miembro inspecciona el
trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales
son los impedimentos con que se encuentra, actualiza el estado de lalista de tareas de la
iteración (Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).
  El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso
y de que no se merme su productividad.
o Elimina los obstáculos que el equipo no puede resolver por sí mismo.
o Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.

Recomendaciones
 Para poder completar el máximo de requisitos en la iteración, se debe minimizar el
número de objetivos/requisitos en que el equipo trabaja
simultáneamente (WIP, Work In Progress), completando primero los que den más
valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de
la lista de tareas de la iteración, permite tener más capacidad de reacción frente a cambios
o situaciones inesperadas.
Restricciones
 No se puede cambiar los objetivos/requisitos de la iteración en curso.
o En la reunión de planificación de la iteración el equipo adquirió el compromiso de completar
en la iteración unos requisitos concretos, basó su plan y organización en ellos. Cambiar
los objetivos/requisitos de la iteración dificulta la concentración del equipo, baja su
moral y su compromiso.
o El hecho de no poder cambiar los objetivos/requisitos de la iteración una vez iniciada
facilita que el cliente cumpla con su responsabilidad de conocer qué es lo más
prioritario a desarrollar, antes de iniciar la iteración.
o Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos
que se están desarrollando eran los más prioritarios justo antes de iniciar la iteración
y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas)
como para que la probabilidad de cambios una vez iniciada la iteración sea mínima.

Terminación anormal de la iteración

Sólo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una
terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el contexto
del proyecto ha cambiado enormemente y no es posible esperar al final de la iteración
para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el
compromiso adquirido. En ese caso, se dará por finalizada la iteración y se dará inicio a
otra mediante una reunión de planificación de la iteración.

4.1.3. Reunión diaria de sincronización del equipo (Scrum Daily Meeting)

El objetivo de esta reunión es facilitar la transferencia de información y

la colaboración entre los miembros del equipopara aumentar su productividad, al
poner de manifiesto puntos en que se pueden ayudar unos a otros.

Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que
pueden impedir este objetivo) para al finalizar la reunión poder hacer
lasadaptaciones necesarias que permitan cumplir con el compromiso conjunto que el
equipo adquirió para la iteración (en lareunión de planificación de la iteración).

Cada miembro del equipo debe responder las siguientes preguntas en un timebox de
cómo máximo 15 minutos:
 ¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer todo lo que
tenía planeado? ¿Cuál fue el problema?
 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta
iteración y en el proyecto?
Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la iteración, donde se
actualiza el estado y el esfuerzo pendiente para cada tarea, así como con el gráfico de
horas pendientes en la iteración.

Beneficios
 Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado
que cada miembro pone de manifiesto delante del resto:
o Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su
trabajo o por que hay dependencias (especialmente si existe un retraso).
o Los impedimentos con que se encuentra. El resto de miembros del equipo pueden
ofrecer ayuda a otros en la realización de tareas o para resolver problemas que ya
tuvieron anteriormente. El Facilitador (Scrum Master) se encargará de solucionar los
impedimentos que el equipo no puede solucionar por sí solo o que le quitan tiempo
para cumplir con su compromiso fundamental de desarrollo de requisitos.
o Las tareas no planeadas que está realizando que el equipo no conoce y puede que no
estén alineadas con el compromiso del equipo, aunque él crea que lo que está
haciendo es lo mejor que se puede hacer.
o Cuáles son sus necesidades. Cada miembro entiende las necesidades de los otros
miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar
sus trabajos para que den el máximo valor y no realizar tareas que no proporcionan
ningún beneficio al resto del equipo.
o Cuál es su ritmo de trabajo. Se hace visible si de manera continua un miembro del
equipo está realizando tareas por debajo del rendimiento esperado. Se evita que una
persona señale con el dedo a otra, dado que la reunión de sincronización pone a todos
los miembros del equipo en la misma situación de tener que explicar en qué tareas
están trabajando.
o Cuáles son los criterios que está utilizando para realizar sus tareas, de manera que
estén alineados con los objetivos comunes del equipo.
 Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cómo trabajan
los otros según sus especialidades y experiencias.
 Conocer el estado de la iteración, ver si es posible completar los requisitos a que se
comprometió el equipo, en vista de las desviaciones y de las tareas pendientes.

Restricciones
 La reunión diaria de estado y sincronización del equipo no es para resolver
problemas, los problemas se resuelven después de la reunión.

o No a todos los miembros del equipo les interesan todos los detalles de cada tema.
o En la reunión los miembros del equipo programan reuniones entre ellos donde colaborar
sincronizando tareas, ayudando a resolver problemas, etc.
o No puede haber una persona explicando su estado mientras otras "se han apartado" de
la reunión para comentar un tema particular. Si apareciese alguna conversación de
 interés común (que debe ser rápida), debe poder ser escuchada por todo el equipo sin
distraer el principal objetivo de que todos conozcan en qué están trabajando los
demás. Si la mini conversación no es del interés de todos, debe hacerse después de la
reunión.
 El equipo debe contar con unos criterios consensuados sobre el proceso de
ejecución de las de tareas
o El proceso de ejecución de las tareas debe estar consensuado para evitar que cada
reunión sea una exposición de discrepancias entre los miembros del equipo.

Recomendaciones
 Realizar la reunión diaria de sincronización de pie, para que los miembros del equipo no
se relajen ni se extiendan en más detalles de los necesarios.
 Realizar las reuniones de colaboración entre miembros del equipo justo después de la de
sincronización.

4.1.4. Demostración de los requisitos completados (Sprint Review)

Reunión informal donde el equipo presenta al cliente los requisitos completados en
la iteración, en forma de incremento de producto preparado para ser entregado con el
mínimo esfuerzo, haciendo un recorrido por ellos lo más real y cercano posible al
objetivo que se pretende cubrir.

En función de los resultados mostrados y de los cambios que haya habido en el

contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva,
ya desde la primera iteración, replanificando el proyecto.

Se realiza en un timebox de cómo máximo 4 horas.

Beneficios
 El cliente puede ver de manera objetiva cómo han sido desarrollados los requisitos que
proporcionó, ver si se cumplen sus expectativas, entender más qué es lo que necesita
y tomar mejores decisiones respecto al proyecto.
 El equipo puede ver si realmente entendió cuáles eran los requisitos que solicitó el
cliente y ver en qué puntos hay que mejorar la comunicación entre ambos.
 El equipo se siente más satisfecho cuando puede ir mostrando los resultados que va
obteniendo. No está meses trabajando sin poder exhibir su obra.

Restricciones
 Sólo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas
expectativas y pueda tomar decisiones correctas y objetivas en función de la velocidad
de desarrollo y el resultado realmente completado. Un requisito no completado
quedará como un requisito más a replanificar.

4.1.5. Retrospectiva (Sprint Retrospective)

Con el objetivo de mejorar de manera continua su productividad y la calidad del producto
que está desarrollando, el equipoanaliza cómo ha sido su manera de trabajar durante
la iteración, por qué está consiguiendo o no los objetivos a que se comprometió al inicio de la
 iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él
esperaba o no:

 Qué cosas han funcionado bien.

 Cuales hay que mejorar.
 Qué cosas quiere probar hacer en la siguiente iteración.
 Qué ha aprendido.
 Cuáles son los problemas que podrían impedirle progresar adecuadamente.
El Facilitador se encargará de ir eliminando los obstáculos identificados que el propio
equipo no pueda resolver por sí mismo.
Notar que esta reunión se realiza después de la reunión de demostración al cliente de los
objetivos conseguidos en la iteración, para poder incorporar su feedback y cumplimiento de
expectativas como parte de los temas a tratar en la reunión de retrospectiva

Se realiza en un timebox de cómo máximo 3 horas (si la iteración es mensual).

Beneficios
 Incrementa la productividad en el proyecto, la calidad del producto (cosa que
permite hacerlo crecer de manera sostenida) y potencia el aprendizaje del equipo
de manera sistemática, iteración a iteración, con resultados a corto plazo.
 Aumenta la motivación del equipo dado que participa en la mejora de proceso, se
siente escuchado, toma decisiones consensuadas (y más sostenibles) para ir
eliminando lo que molesta e impide que sea más productivo.

Restricciones
 En necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y
recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es
frustrante encontrar sistemáticamente los mismos obstáculos y no poder solucionarlos

4.1.6. Replanificación del proyecto

En las reuniones de planificación de entregas y/o durante el transcurso de una iteración,
el cliente va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto,
añadiendo requisitos, modificándolos, eliminándolos, repriorizándolos, cambiando el
contenido de iteraciones y definiendo un calendario de entregas que se ajuste mejor a
sus nuevas necesidades [1].

Los cambios en la lista de requisitos pueden ser debidos a:

 Modificaciones que el cliente solicita tras la demostración que el equipo realiza al final de
cada iteración sobre los resultados obtenidos, ahora que el cliente entiende mejor el
producto o proyecto.
 Cambios en el contexto del proyecto (sacar al mercado un producto antes que su
competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc).
 Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto.
 Etc.

Para realizar esta tarea, el cliente colabora con el equipo:

 Para cada nuevo objetivo/requisito conjuntamente se hace una identificación inicial de
sus condiciones de satisfacción(que se detallarán en la reunión de planificación de la
iteración).
  El cliente obtiene del equipo la re-estimación de costes de desarrollo para
completar los objetivos/requisitos siguientes, según la definición de completado. El
equipo ajusta el factor de complejidad, el coste para completar los requisitos y su
velocidad de desarrollo en función de la experiencia adquirida hasta ese momento en el
proyecto.
 El cliente re-prioriza la lista de objetivos/requisitos en función de estas nuevas
estimaciones.

Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la
iteración en curso, (que de hecho eran los más prioritarios al iniciar la iteración). No es
posible cambiar los requisitos que se desarrollan durante la iteración. En la reunión
deplanificación de la iteración el cliente presentará la nueva lista de requisitos para que
sea desarrollada.

Beneficios
De manera sistemática, iteración a iteración, se obtienen los siguientes beneficios:
 El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y
posibles desviaciones:
o Replanificar el proyecto para obtener un nuevo calendario de entregas que cumpla con
sus necesidades actuales.
o Incorporar nuevos recursos.
o Cancelar el proyecto con los requisitos completados hasta el momento plenamente
operativos, si el beneficio pendiente de obtener es menor que el coste de desarrollo
[2].
 El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan
sorpresas de última hora.

4.2. Roles
4.2.1. Product Owner

Las responsabilidades del Product Owner (que puede ser interno o externo a la organización)
son:

 Ser el representante de todas las personas interesadas en los resultados del

proyecto (internas o externas a la organización, promotores del proyecto y usuarios
finales [idealmente también debería ser un usuario clave] o consumidores finales del
producto) y actuar como interlocutor único ante el equipo, con autoridad para tomar
decisiones.
 Definir los objetivos del producto o proyecto.
 Dirigir los resultados del proyecto y maximizar su ROI (Return Of Investment).
o Es el propietario de la planificación del proyecto: crea y mantiene la lista priorizada con los
requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor
que aportará cada requisito y calcula el ROI a partir del coste de cada requisito que le
proporciona el equipo.
o Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas.
 o Antes de iniciar cada iteración replanifica el proyecto en función de los requisitos que
aportan más valor en ese momento, de los requisitos completados en la iteración
anterior y del contexto del proyecto en ese momento (demandas del mercado,
movimientos de la competencia, etc.).
 Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos de
cada iteración:
o Participar en la reunión de planificación de iteración, proponiendo los requisitos más
prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los
requisitos que el equipo se comprometer a hacer.
o Estar disponible durante el curso de la iteración para responder a las preguntas que
puedan aparecer.
o No cambiar los requisitos que se están desarrollando en una iteración, una vez está iniciada.
o Participar en la reunión de demostración de la iteración, revisando los requisitos
completados.

4.2.2. Scrum Master (facilitador)

Lidera al equipo llevando a cabo las siguientes responsabilidades:

 Velar por que todos los participantes del proyecto sigan las reglas y proceso de Scrum,
encajándolas en la cultura de la organización, y guiar la colaboración intraequipo y con el
cliente de manera que las sinergias sean máximas. Esto implica:
o Asegurar que la lista de requisitos priorizada esté preparada antes de la siguiente iteración.
o Facilitar las reuniones de Scrum (planificación de la iteración, reuniones diarias de sincronización del
equipo, demostración, retrospectiva), de manera que sean productivas y consigan sus objetivos.
o Enseñar al equipo a autogestionarse. No da respuestas, si no que guía al equipo con
preguntas para que descubra por sí mismo una solución.
 Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada
iteración (proporcionar un resultado útil al cliente de la manera más efectiva) y poder finalizar el
proyecto con éxito. Estos obstáculos se identifican de manera sistemática en lasreuniones diarias
de sincronización del equipo y en las reuniones de retrospectiva.
 Proteger y aislar al equipo de interrupciones externas durante la ejecución de la
iteración(introducción de nuevos requisitos, "secuestro" no previsto de un miembro del equipo,
etc.). De esta manera, el equipo puede mantener su productividad y el compromiso que
adquirió sobre los requisitos que completaría en la iteración [notar, sin embargo, que el equipo
debe reservar tiempo para colaborar con al cliente en la preparación de la lista de requisitos para la
próxima iteración].

4.2.3. Team (equipo)

Grupo de personas que de manera conjunta desarrollan el producto del proyecto.

Tienen un objetivo común, comparten la responsabilidad del trabajo que realizan (así
como de sucalidad) en cada iteración y en el proyecto.

El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas cualquier
imprevisto o interrupción sobre un miembro del equipo compromete seriamente el
compromiso que han adquirido y, por tanto, el resultado que se va a entregar
al cliente al finalizar la iteración. Por encima de 9 personas, la comunicación y
colaboración entre todos los miembros se hace más difícil y se forma subgrupos (ver
los requisitos de Scrum).
 De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado en
proyectos con 250 personas en varios equipos. Cuando es necesario que más de un
equipo trabaje de manera ágil en un mismo proyecto, existen diferentes técnicas que
permiten esta colaboración, desde el Scrum de Scrums hasta equipos de integración
que dedican parte de su tiempo a trabajar con los equipos de desarrollo, siempre
completando incrementos de producto de manera regular.

Es un equipo autoorganizado, que comparte información y cuyos miembros confían

entre ellos. Realiza de manera conjunta las siguientes actividades:
 Seleccionar los requisitos que se compromete a completar en una iteración, de forma
que estén preparados para ser entregados al cliente.
 Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto o
proyecto.
 En la reunión de planificación de la iteración decide cómo va a realizar su trabajo:
o Seleccionar los requisitos que pueden completar en cada iteración, realizando al cliente
las preguntas necesarias.
o Identificar todas las tareas necesarias para completar cada requisito.
o Estimar el esfuerzo necesario para realizar cada tarea.
o Cada miembro del equipo se autoasigna a las tareas.
 Durante la iteración, trabajar de manera conjunta para conseguir los objetivos de la
iteración. Cada especialista lidera el trabajo en su área y el resto colaboran si es
necesario para poder completar un requisito.
 Al finalizar la iteración:
o Demostrar al cliente los requisitos completados en cada iteración.
o Hacer una retrospectiva la final de cada iteración para mejorar de forma continua su
manera de trabajar.

El equipo es multidisciplinar:
 Los miembros del equipo tienen las habilidades necesarias para poder identificar y
ejecutar todas las tareas que permiten proporcionar al cliente los requisitos
comprometidos en la iteración.
 Tienen que depender lo mínimo de personas externas al equipo, de manera que el
compromiso que adquieren en cada iteración no se ponga en peligro.
 Se crea una sinergia que permite que el resultado sea más rico al nutrirse de las
diferentes experiencias, conocimientos y habilidades de todos. Colaboración creativa.

Los miembros del equipo dedicarse al proyecto a tiempo completo para evitar dañar
su productividad por cambios de tareas en diferentes proyectos, para evitar
interrupciones externas y así poder mantener el compromiso que adquieren en cada
iteración.

Todos los miembros del equipo trabajan en la misma localización física, para poder
maximizar la comunicación entre ellos mediante conversaciones cara a cara, diagramas
en pizarras blancas, etc. De esta manera se minimizan otros canales de comunicación
menos eficientes, que hacen que las tareas se transformen en un “pasa pelota” o que
hacen perder el tiempo en el establecimiento de la comunicación (como cuando se
llama repetidas veces por teléfono cuando la persona no está en su puesto).

El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo
mínimo posible, para poder aprovechar el esfuerzo que les ha costado construir sus
relaciones interpersonales, engranarse y establecer su organización del trabajo.
4.3. Artefactos
4.3.1. Product Backlog (Lista de objetivos / requisitos priorizada)

La lista de objetivos/requisitos priorizada representa la visión y expectativas

del clienterespecto a los objetivos y entregas del producto o proyecto. El cliente es el
responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien
proporciona el coste estimado de completar cada requisito). Dado que reflejar las
expectativas del cliente, esta lista permite involucrarle en la dirección de los resultados
del producto o proyecto.

 Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que se suelen
expresar en forma de historias de usuario. Para cada objetivo/requisito se indica
el valor que aporta al cliente y el coste estimado de completarlo. La lista está
priorizada balanceando el valor que cada requisito aporta al negocio frente al coste estimado
que tiene su desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).
 En la lista se indican las posibles iteraciones y las entregas (releases) esperadas por
el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos
completados hasta ese momento), en función de la velocidad de desarrollo del (los)
equipo(s) que trabajará(n) en el proyecto. Es conveniente que el contenido de cada
iteración tenga una coherencia, de manera que se reduzca el esfuerzo de completar todos sus
objetivos.
 La lista también tiene que considerar los riesgos del proyecto e incluir los requisitos o
tareas necesarios para mitigarlos.

Antes de iniciar la primera iteración, el cliente debe tener definida la meta del
producto o proyecto y la lista de requisitos creada. No es necesario que la lista sea
completa ni que todos los requisitos estén detallados al mismo nivel. Basta con
que estén identificados y con suficiente detalle los requisitos más prioritarios con los
que el equipo empezará a trabajar. Los requisitos de iteraciones futuras pueden ser
mucho más amplios y generales. La incertidumbre y complejidad propia de un proyecto
hacen conveniente no detallar todos los requisitos hasta que su desarrollo esté
próximo. De esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos
(menos prioritarios) está repartido en el período de ejecución del proyecto. En el caso del
desarrollo de un producto, la lista va evolucionando durante toda la vida del producto
(los requisitos "emergen"). En el caso de un proyecto, conforme éste avance irán
apareciendo los requisitos menos prioritarios que falten. Esto produce varias ventajas:

 Se evita caer en parálisis de análisis al inicio del proyecto, de manera que se puede
iniciar antes el desarrollo y el cliente puede empezar a obtener resultados útiles.
 Se evita analizar en detalle requisitos no prioritarios que podrían cambiar durante el transcurso
del proyecto, dado que el cliente conocerá mejor cuál ha de ser el resultado a conseguir, o bien
por que podrían ser reemplazados por otros.
 Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los
requisitos restantes, dado el poco retorno de inversión (ROI) que tienen.

Definición de completado (definition of done)

El cliente y el equipo tienen que acordar la "definición de completado” de los objetivos
/ requisitos en el proyecto:

 Debe asegurar que el incremento de producto es potencialmente entregable al cliente

al finalizar cada iteración, que no hay tareas pendientes que puedan impedir utilizar los
resultados del proyecto lo antes posible. De este modo, el cliente podrá tomar
decisiones correctas cuando al final de cada iteración el equipo le haga
una demostración de los requisitos completados: cambiar las prioridades en función de la
velocidad de desarrollo, solicitar una entrega del producto desarrollado hasta ese
momento, etc.
 Debe incluir lo necesario para considerar de manera clara que el cliente obtendrá lo que
necesita según sus criterios de entregables y de calidad (producto construido, probado,
documentado, refactorizado para conseguir calidad interna, etc.).
o Además de esta definición de completado, a cada objetivo hay que asociarle
sus condiciones de satisfacción, preferiblemente en forma de casos de prueba de
aceptación, en el momento de crear la lista de requisitos priorizada (Product Backlog).
o Notar que la definición de completado también sirve como base para identificar las
tareas necesarias para conseguir cada objetivo/requisito, en la reunión de planificación
de la iteración (Sprint planning). Para cada objetivo se crearán más tareas que la definición
de completado (o menos) y con más significado. Por ejemplo, respecto a que el
objetivo tiene que estar “construido”, pueden aparecer varias tareas, del estilo
“construir el componente X”, “modificar la pantalla Y”, “modificar la BBDD”, “preparar
el script de carga”, etc.

Iteración de entrega (release sprint)

Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta
ese momento, el equipo puede necesitar añadir una iteración de entrega, más corta
que las iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o
posible hasta el momento de la entrega final y acabar de corregir defectos detectados
en la última demostración.

Uso de la lista
 Para medir la velocidad de desarrollo del equipo, ver una progresión constante y
extrapolar la fecha de las entregas, es conveniente seguir las siguientes
recomendaciones:
o Los requisitos deben tener un esfuerzo semejante para ser completados.
o La estimación de un requisito no debe ser superior a 10 días (si las iteraciones son
de 20 días laborables).
 Cada requisito tiene asociado un factor de complejidad, que permite ajustar su
coste estimado en función de la incertidumbre de la complejidad de su desarrollo en el
momento de introducirlo en la lista. Este factor de coste se irá ajustando conforme las
iteraciones avancen y el equipo conozca mejor el producto o proyecto, su contexto y
su velocidad de desarrollo con las herramientas y tecnologías que utiliza.
 Si un requisito depende de otro, se coloca en algún punto por debajo del que
depende.
 Si un requisito no se finaliza en una iteración, se le vuelve a poner en alguna de las
siguientes iteraciones, indicando el coste pendiente de desarrollo.
  El "origen" permite saber quién podría participar en la definición de un objetivo/requisito
y sería conveniente que estuviese presente en el momento de su demostración.
El progreso del proyecto y su velocidad con respecto a requisitos completados se muestra en
un gráfico de trabajo pendiente (Burndown chart).

4.3.2. Lista de tareas de la iteración (Sprint Backlog)

Lista de tareas que el equipo elabora en la reunión de planificación de la iteración (Sprint

planning) como plan para completar los objetivos/requisitos seleccionados para
la iteracióny que se compromete a demostrar al cliente al finalizar la iteración, en forma de
incremento de producto preparado para ser entregado.

Esta lista permite ver las tareas donde el equipo está teniendo problemas y no avanza,
con lo que le permite tomar decisiones al respecto.

Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo

pendiente para finalizarlas y la autoasignación que han hecho los miembros del equipo.

El progreso de la iteración y su velocidad con respecto a tareas u horas pendientes se muestra

mediante un gráfico de trabajo pendiente (Burndown chart).

Uso de la lista
 Los objetivos/requisitos están ordenados por orden de prioridad para el cliente.
o Por ello, signos de falta de foco, problemas o impedimentos serían que se estén completando
objetivos que no son los primeros de la lista, así como tener demasiados objetivos/requisitos en
progreso simultáneamente.
 Si una tarea depende de otra, se coloca en algún punto por debajo de la que depende.
 Las tareas deben estar identificadas de manera que tengan un coste semejante para ser
completadas, entre 4 y 16 horas. Este tamaño permitirá:
o Que las tareas sean suficientemente pequeñas como para poder detectar progreso o
estancamiento de manera diaria.
o Que las tareas no sean muy pequeñas, que sean suficientemente relevantes, no generen ruido ni
microgestión.
o Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas dentro
de la iteración.
El tablero de tareas (Scrum Taskboard)
La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar
mediante un tablón de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas
necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para
cambiarlas de estado (pendientes de iniciar, en progreso, hechas). Para cada miembro del
equipo se puede utilizar adhesivos de colores más pequeños sobre cada tarea, de manera que se
pueda ver en qué tareas está trabajando cada cual.

El equipo elabora esta lista de tareas en la segunda parte de la reunión de planificación de

la iteración. La lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo
 pendiente) a medida que la iteración avanza, especialmente durante la reunión diaria de
sincronización.

Este tablón o cuadro de mandos actúa como radiador de información tanto para el equipo
como para cualquier otra persona relacionada con el proyecto.

En el siguiente artículo se muestra cómo construirlo y un ejemplo de su uso: Ejemplo de uso del
tablero o pizarra de tareas (Scrum Taskboard).

4.3.3. Gráficos de trabajo pendiente (Burndown Chart)

Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se

está completando los objetivos/requisitos. Permite extrapolar si el Equipo podrá
completar el trabajo en el tiempo estimado.

Se pueden utilizan los siguientes gráficos de esfuerzo pendiente:

 Días pendientes para completar los requisitos del producto o proyecto (product
burndown chart), realizado a partir de lalista de requisitos priorizada (Product Backlog).
 Horas pendientes para completar las tareas de la iteración (sprint burndown chart),
realizado a partir de la lista de tareas de la iteración (Iteration Backlog).

Este tipo de gráfico permite realizar diversas simulaciones: ver cómo se aplazan las
fechas de entrega si se le añaden requisitos, ver cómo se avanzan si se le quitan
requisitos o se añade otro equipo, etc.

5. Fundamentos
Scrum se basa en:

 El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y

fijos (iteraciones de un mes natural y hasta de dos semanas, si así se necesita).
 La priorización de los requisitos por valor para el cliente y coste de desarrollo en cada iteración.
 El control empírico del proyecto. Por un lado, al final de cada iteración se demuestra al
cliente el resultado real obtenido, de manera que pueda tomar las decisiones
necesarias en función de lo que observa y del contexto del proyecto en ese momento.
Por otro lado, el equipo se sincroniza diariamente y realiza las adaptaciones
necesarias.
 La potenciación del equipo, que se compromete a entregar unos requisitos y para ello se le
otorga la autoridad necesaria para organizar su trabajo.
 La sistematización de la colaboración y la comunicación tanto entre el equipo y como con el
cliente.
 El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y
conseguir resultados.

Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la

manera de trabajar de equipos altamente productivos.

6. Historias de Usuario

6.1. Definición
 Una historia de usuario es una representación de un requerimiento de software escrito en una o
dos frases utilizando el lenguaje común del usuario. Las historias de usuario son utilizadas en
las metodologías de desarrollo ágiles para la especificación de requerimientos (acompañadas de
las discusiones con los usuarios y las pruebas de validación). Cada historia de usuario debe ser
limitada, esta debería poderse escribir sobre una nota adhesiva pequeña.

Las historias de usuario son una forma rápida de administrar los requerimientos de los usuarios sin
tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para
administrarlos. Las historias de usuario permiten responder rápidamente a los requerimientos
cambiantes.

6.2. Características

Independientes unas de otras: De ser necesario, combinar las historias dependientes o buscar
otra forma de dividir las historias de manera que resulten independientes.
Negociables: La historia en si misma no es lo suficientemente explícita como para considerarse un
contrato, la discusión con los usuarios debe permitir esclarecer su alcance y éste debe dejarse
explícito bajo la forma de pruebas de validación.
Valoradas por los clientes o usuarios: Los intereses de los clientes y de los usuarios no siempre
coinciden, pero en todo caso, cada historia debe ser importante para alguno de ellos más que para
el desarrollador.
Estimables: Un resultado de la discusión de una historia de usuario es la estimación del tiempo que
tomará completarla. Esto permite estimar el tiempo total del proyecto.
Pequeñas: Las historias muy largas son difíciles de estimar e imponen restricciones sobre la
planificación de un desarrollo iterativo. Generalmente se recomienda la consolidación de historias
muy cortas en una sola historia.
Verificables: Las historias de usuario cubren requerimientos funcionales, por lo que generalmente
son verificables. Cuando sea posible, la verificación debe automatizarse, de manera que pueda ser
verificada en cada entrega del proyecto.

6.3. Estructura

 ID: Identificador de la historia de usuario

 TÍTULO: Título descriptivo de la historia de usuario
 DESCRIPCIÓN: Descripción sintetizada de la historia de usuario
  ESTIMACIÓN: Estimación del coste de implementación en unidades de desarrollo (estas
unidades representarán el tiempo teórico de desarrollo/hombre que se estipule al
comienzo del proyecto)
 PRIORIDAD: Prioridad en la implementación de la historia de usuario respecto al resto de
las historias de usuario. A mayor número, mayor prioridad. Otra aproximación a la
priorización de tareas se hace a través del método MoSCoW:
o M – Must, se debe completar este requerimiento para finalizar el proyecto
o S – Should, se debe completar este proyecto por todos los medios, pero el éxito del
proyecto no depende de él.
o C – Could, se debería completar este requerimiento si su implementación no afecta a la
consecución de los objetivos principales del proyecto.
o W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en
futuras versiones del mismo)
 DEPENDENCIAS: Una historia de usuario no debería ser dependiente de otra historia,
pero a veces es inevitable. En este apartado se indicarían los IDs de las tareas de las
que depende una tarea

El ciclo de vida de la tarjeta se compone de tres fases, conocidas como “Las 3 C” por
sus iniciales en inglés (Card, Conversation, Confirmation):

 TARJETA (Card), la creación de la tarjeta en sí, con la estructura definida anteriormente

y que sirve para determinar QUÉ se debe hacer y cómo planificarlo.
 CONVERSACION (Conversation), representado por pequeños documentos y anotaciones
que sirven para aportar detalles y refinar los datos sobre las características del
requerimiento.
 CONFIRMACIÓN (Confirmation), o pruebas de aceptación. Pruebas consensuadas
entre el cliente y el desarrollador y que el código debe superar para dar como
finalizada la implementación del requerimiento.

7. Utilizando la herramienta Rational Team Concert

7.1. Creando una conexión al repositorio

 En primer lugar debe asegurarse que Jazz Team Server está corriendo y que el cliente
está abierto.

 Para crear una nueva conexión al repositorio, haga click derecho en Conexiones al
repositorio y seleccione Nuevo->Conexión a repositorio de Jazz.

 Ingrese el URI y el ID de usuario con el password correspondiente.

7.2.Agregar usuarios

El siguiente paso es crear usuarios con la finalidad de que puedan participar en más de
un área de proyecto y potencialmente, usar otro tipo de herramientas almacenadas en
 el servidor. Vamos a asumir que se está usando Tomcat como servidor y necesitas
crear usuarios en un nuevo repositorio.

 Para crear un nuevo usuario, haga click derecho en conexión al repositorio y

selecciona Nuevo->Usuario.

 Seleccione No cuando el cuadro de diálogo para importar usuario se abra.

 Ingrese la información del usuario que pide la herramienta. El ID que usted ingrese, será
la contraseña para el usuario que está creando.

 Escoja los permisos que va a tener el usuario. El usuario que va a administrar el

proyecto debe tener el permiso deJazzAdmins.

- JazzUsers: tiene los permisos por defecto en un área de proyecto. Estos permisos
permiten crear ítems de trabajo, ver reportes y usar otras características definidas por
las opciones de seguridad del proyecto.

- JazzAdmins: pueden acceder a varias opciones relacionadas con Jazz Team Server y
proyectos.

 Seleccione el tipo de licencia para el usuario

- Developer (Desarollador): permite crear plantillas de proceso, áreas de proyecto, crear o

editar páginas. Este tipo de licencia es apropiada para miembros quienes van a
programar y correr aplicaciones.

- Build and ClearCase Connector: este tipo de licencia es típico para usuarios
administrativos.

- Contributor: es aplicado a usuarios que necesitan solo leer información del repositorio.
También puede crear ítems de trabajo.

7.3.Crear Áreas de Proyecto

El siguiente paso es crear un área de proyecto, el cual servirá como contenedor para
los planes, ítems de trabajo y otras cosas relacionadas al proyecto que estás creando.

 Para crear un nuevo Área de Proyecto, haga click derecho en Conexión al repositorio en
la pestaña Artefactos y seleccioneNuevo->Área de Proyecto.

 Ingrese un nombre para el proyecto y pulse Next.

 Cuando sea crea un Área de Proyecto por primera vez, necesitas una plantilla de
proceso, así que haga click en Plantillas de Proceso.
  Escoja Scrum como plantilla de proceso y selecciona Finalizar.

En la columna de la izquierda, dentro de la pestaña Artefactos, puede ver el nuevo

Área de Proyecto creado con sub-carpetas ya creadas, planes, informes, código fuente
y elementos de trabajo. En el editor de Área de Proyecto hay información relacionada
al proyecto.

7.4. Agregar miembros y especificar roles

Como creador del Área de Proyecto, usted es el administrador inicial. Por otro lado, los
permisos para modificar la estructura del proyecto dentro del proceso Scrum, les
pertenecen al Scrum Master y al Product Owner

 Haga click derecho en el Proyecto que ha creado y seleccione Abrir.

 Haga click en la flecha Miembros para expandir el panel.

 Haga en click en Añadir.

 Seleccione los usaurios que desea añadir.

 Una vez agregados haga doble click en cada uno de ellos apra asignarles roles.

7.5. Crear líneas de tiempo (Sprints)

El siguiente paso es definir líneas de tiempo para el proyecto, lo cual quiere decir
especificar fechas de comienzo y de término para liberar o terminar un sprint

 Seleccione Relealse 1.0 y pulse en Editar propiedades tal como se muestra en la

imagen:

 Usted puede crear una iteración o seleccionar la que está por defecto.

 El identificador debe de ser único, pero puede modificarlo de acuerdo a sus necesidades.

 Ingrese las fechas de comienzo y término. Asegúrese que el checkbox para “Se ha
planificado un release para esta iteración” esté marcado. Y seleccione Aceptar.
 Usted podría hacer más cambios al Área de Proyecto más adelante si lo desea. Para
abrirlo, haga click derecho en en el Proyecto y seleccione Abrir.

7.6. Especificar un Área de Equipo y agregar miembros

La tecnología Jazz puede soportar equipos grandes con múltiples sub-equipos, Dentro
de las Áreas de Proyecto, existen Áreas de Equipo para organizar a los miembros.

 Haga click en la pestaña Organización de Equipo, Si no está abierta, vaya a Ventana-

>Mostrar Vista->Organización de Equipo para abrirlo.

 Haga click derecho en el Área de Proyecto y seleccione Nuevo->Área de Equipo.

 Ingrese un nombre para el Área de Equipo.

 Agregue a los usuarios que desee como miembros del equipo.

 Usted puede seleccionar los roles de cada miembro.

 Una vez finalizada la configuración, seleccione Grabar.

8. Especificación de la disponibilidad de los miembros del equipo

Para que los cálculos del tiempo del trabajo y desempeño sean precisos, es importante
ajustar la disponibilidad de los miembros del equipo. Esto debe hacerse incluso si un
miembro del equipo está de vacaciones o tiene su participación limitada. Todos estos
ajustes se realizan en la página del usuario. Usualmente, los usuarios son los que
deberían mantener su área activa por ellos mismos; sin embargo, como parte
importante del cálculo del desempeño del equipo correcto, es importante ilustrarlo
aquí.

8.1 Si aún no se ha realizado esta acción, es importante seleccionar la pestaña de

Team Organization en el panel izquierdo y expandir en HAVANNAH FOLDER y el
HAVANNAH TEAM.

8.2 Abrir el editor de usuario para algún miembro. También se pueden editar los
detalles de dicho usuario.

8.3 Por ejemplo, un miembro ‘X’ podría estar disponible sólo 75% del tiempo.
Entonces, lo que se hace es seleccionar la pestaña del WORK ENVIRONMENT que está
en la parte inferior, luego en la sección de WORK ASSIGNMENT o asignaciones de
trabajo, seleccionará la linea del TEAM y cambiará las opciones.

8.4 Por defecto, si un usuario es asignado sólo a un equipo, el 100% de su tiempo

(recursos) es asociado con el equipo. Para bajar la asignación para el usuario,
selección la asignación y pídale un CHANGE o un cambio. Luego descienda la
asignación a 75%.
 8.5 Ahora sólo acepte o seleccione OK.

8.6 Ahora, si el usuario, tiene por ejemplo un día de vacaciones que se aproxime, sería
conveniente cambiar a la pestaña de ausencias agendadas o SCHEDULED ABSENCES y
seleccionar NUEVO o NEW en el lado derecho de la lista e ingresar una descripción y
los días o fechas para ese tiempo destinado a vacacionar. Lo siguiente sería aceptar y
guardar los cambios con SAVE.

9. Creando un PRODUCT BACKLOG para el proyecto

Una de los más importantes artefactos en la metodología SCRUM es el PRODUCT

BACKLOG.

9.1 Para crear un PRODUCT BACKLOG en este ejemplo, se deberá dirigir a la vista de TEAM
ARTIFACTS o artefactos del equipo y, en el proyecto creado, seleccionará RELEASE
1.0, click derecho para obtener el menú de contexto y luego se seleccionará un NUEVO
PLAN (NEW, PLAN)

9.2 En esta nueva ventana de creación de nuevo Plan, ingrese el nombre PRODUCT BACKLOG y
escoja PRODUCT BACKLOG como tipo de plan (PLAN TYPE).

9.3 Para TEAM MEMBERS, TIMELINE e ITERATION, dejarlos en DEFAULT.

9.4 Ahora, sólo se finaliza.

Tip: Si usted no pudiera guardar los cambios que se realizan para el nuevo plan que está
creando, debería revisar y asignar el rol de SCRUM MASTER para poder crear este
artefacto.

Es así como un editor multi-páginas abrirá el plan de iteraciones del PRODUCT BACKLOG.

9.5 En la página de OVERVIWE, usted podrá ingresar información acerca de su producto usando
formato de estilo wiki.

9.6 El área de adjuntos, al final de la vista de editor (que es visible sólo en modo edición para
esta página) es un gran lugar para añadir nuevos requerimientos u otra
documentación general que se pertinente para esta entrega; de modo que sean fáciles
de leer y disponibles para todos los miembros del equipo. Esta área de la página puede
contener también vínculos a páginas Web o documentos externos de repositorios
según lo que se requiera.

9.7 Ahora, debería poder ir a la pestaña de PLANNED ITEMS para comenzar a añadir los
elementos de BACKLOG.

Si bien es cierto, hay muchas formas de ver un plan, eéstas, son llamadas MODES. En
el lado derecho de la ventana, usted podrá especificar cómo los elementos en el plan
deben ser agrupados y qué tipo de elementos deberán ser excluídos de la vista.
Existen modos de vistas que están predefinidos. Usted podría definir, incluso, su propia
vista personalizada. Para hacer esto, usted puede usar las opciones de EDIT | COPY en
el panel derecho, debajo de VIEW AS. Otros modos están almacenados en el servidor y
podrán estar disponibles a otros miembros del equipo, de igual modo, todos los
 cambios que se hagan afectarán a los demás usuarios del PROJECT AREA o ÁREA DE
TRABAJO.

Importante: Usted puede agrupar elementos del plan de grupo por tipo (BACKLOG,
ITERATIONS, TEAMS y WORK BREAKDOWN)

10. Para llenar o asignar elementos de trabajo al PRODUCT BACKLOG

En la pestaña de elementos planeados o PLANNED ITEMS para el BACKLOG, comience

por añadir elementos del BACKLOG o BACKLOG items. Para la administración de
proyectos SCRUM, los elementos en el PRODUCT BACKLOG son llamados STORIES o, si
son muy extensos, EPICS. Una historia o STORY es una descripción de la funcionalidad
que será implementada en el producto, usualmente citada en términos de lo que los
usuarios quieren y el valor que desean mediante ese producto. Una historia
apropiadamente descrita incluye un resumen o línea de cabecera, alguna descripción
de la innovación y las condiciones de aceptación del PRODUCT OWNER. En el ejemplo
de proyecto, los elementos son fraseados como STORIES; de modo que su BACKLOG
debe estar asignado con historias.

10.1 Primero, coloque por defecto los nuevos elementos para STORY. Esto le permitirá
entrar rápidamente a los nuevos elementos de trabajo presionando CTRL + ENTER.

10.2 Lo conveniente sería seleccionar, entonces, la carpeta del equipo de proyecto y

añadir un WORK ITEM, SET DEFAULT, STORY.

10.3 Para proceder a la creación, simplemente, vuelva a seleccionar la carpeta del

equipo de proyecto y fíjese en la opción ADD WORK ITEM, luego añada una STORY.

10.4 Lo que quedaría sería el ingreso de datos pertintentes.

10.5 Ahora, se deberían añadir todos los elementos que son pedidos por el PRODUCT
OWNER.

10.6 Finalmente grabar en la parte superior de la ventana, en todo momento es

importante grabar su trabajo.

10.7 Luego de que todas las STORIES son añadidas, el siguiente paso para el
PRODUCT OWNER es el poner prioridades para ellas. Los valores HIGH (ALTA),
MEDIUM(Media), LOW(Baja) están disponibles para el atributo prioridad. Usted puede
asignar prioridades fácilmente usando la lista desplegable.

10.8 Usted puede darle un puntaje a sus prioridades también a modo de RANKING,
esto se logra arrastrando los elementos en el orden de prioridad. Recuerde que debe
agrupar sus elementos al momento de puntuar, si usted arrastra un elemento de nivel
medio a un grupo de nivel alto, el motor de trabajo automáticamente asignará el
nuevo valor de alto a su trabajo.

10.9 Cuando el equipo añade un estimado para la complejidad del elemento, deberá
ingresar puntos de STORY usando menús de lista desplegable.
 Es importante recordar esto para EPICS e STORIES

Por defecto, estos dos elementos son objetos de trabajo del PRODUCT BACKLOG. En el
caso de que el equipo quisiera ver las tareas en el PRODUCT BACKLOG, usted deberá
agregar ese elemento como un elemento de trabajo del nivel más alto en el área de
proyecto de configuración. Para ello, debería realizar lo siguiente:

a. Abrir el PROJECT AREA desde la vista de ARTIFACTS.

b. Dentro de la pestaña de PROCESS CONFIGURATION, expandir el PROJECT.

c. Ahora, deberá seleccionar TOP-LEVEL WIRK ITEM TYPES y añadir TASKS u otro tipo de
elemento de trabajo seleccionando las opciones correspondientes con los CHECKS.

Por supuesto que, no se puede decir mucho de un PRODUCT BACKLOG si todo lo que
se tiene son resúmenes de STORIES.

Para ello, por cada STORY, usted deberá poder seleccionarlo dos veces para mostrar su
editor y proceder a ingresar el contenido.

En los campos de descripción podría ingresar información adicional o detalles de lo que

se espera en la historia.

El creador de un elemento es automáticamente suscrito a él. En caso de que usted no

necesite esta opción, podría ubicar el vínculo SUSCRIBERS en la sección de QUICK
INFORMATION en la parte inferior izquierda y seleccionar UNSUSCRIBE ME para
eliminar su suscripción.

Lo siguiente sería ubicar la pestaña de ACCEPTANCE TEST en la parte inferior y añadir

las ACCEPTANCE TESTS identificadas por el equipo y el PRODUCT OWNER como prueba
de que la STORY ha sido completada satisfactoriamente y podrá darse a conocer
mediante las expectativas del STAKEHOLDER.