SCRUM como metodologa

|Updated November 22, 2010 by javakreator7|Tags: None

Page Actions

Metodologa gil: Scrum

1. Introduccin
2. Qu es Scrum?
3. Beneficios
4. Cmo funciona
5. Fundamentos
6. Historias de Usuario

1. Introduccin
Tanto Scrum como Programacin Extrema (XP) requieren que los equipos completen
algn tipo de producto potencialmente liberable al final de cada iteracin. Estas
iteraciones estn diseadas para ser cortas y de duracin fija.
Este enfoque en entregar cdigo funcional cada poco tiempo significa que los equipos
Scrum y XP no tienen tiempo para teoras. No persiguen dibujar el modelo UML
perfecto en una herramienta CASE, escribir el documento de requisitos perfecto o
escribir cdigo 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 tambin son conscientes de que la
mejor manera de encontrar dichos errores es dejar de pensar en el software a un nivel
terico de anlisis y diseo 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
prcticas paratrabajar colaborativamente, en equipo, y obtener el mejor resultado
posible de un proyecto.Estas prcticas se apoyan unas a otras y su seleccin tiene
origen en un estudio 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 enentornos complejos, donde se necesita obtener
resultados pronto, donde los requisitos son cambiantes o poco definidos, donde
la innovacin, la competitividad, la flexibilidad y laproductividad son
fundamentales.
Scrum tambin 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
reaccin ante la competencia, cuando la moral de los equipos es baja y la
rotacin alta, cuando es necesario identificar y solucionar ineficiencias
sistemticamente 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 ms prioritarios en ese
momento, ya completados) lo cual proporciona las siguientes ventajas:
o Gestin regular de las expectativas del cliente y basada en resultados tangibles.
o Resultados anticipados (time to market).
o Flexibilidad y adaptacin respecto a las necesidades del cliente, cambios en el mercado,
etc.
o Gestin sistemtica del Retorno de Inversin (ROI).
o Mitigacin sistemtica de los riesgos del proyecto.
Productividad y calidad.
Alineamiento entre el cliente y el equipo de desarrollo.
Equipo motivado.

4. Cmo 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 iteracin tiene que
proporcionar un resultado completo, un incremento de producto final que sea
susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que acta

como plan del proyecto. En esta lista el cliente prioriza 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 inversinmediante la replanificacin de objetivos que realiza al
inicio de cada iteracin.
Planificacin de la iteracin
El primer da de la iteracin se realiza la reunin de planificacin de la iteracin. Tiene
dos partes:
1. Seleccin de requisitos (4 horas mximo). 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 ms prioritarios que se compromete a completar
en la iteracin, de manera que puedan ser entregados si el cliente lo solicita.
2. Planificacin de la iteracin (4 horas mximo). El equipo elabora la lista de tareas de
la iteracin necesarias para desarrollar los requisitos a que se ha comprometido. La
estimacin de esfuerzo se hace de manera conjunta y los miembros del equipo se
autoasignan las tareas.

Ejecucin de la iteracin
Cada da el equipo realiza una reunin de sincronizacin (15 minutos mximo).
Cada miembro del equipo inspecciona el trabajo que el resto est realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que
pueden impedir este objetivo) para poder hacer las adaptaciones necesarias que
permitan cumplir con el compromiso adquirido. En la reunin cada miembro del equipo
responde a tres preguntas:
Qu he hecho desde la ltima reunin de sincronizacin?
Qu voy a hacer a partir de este momento?
Qu impedimentos tengo o voy a tener?
Durante la iteracin el Facilitador se encarga de que el equipo pueda cumplir con su
compromiso y de que no se merme su productividad.
Elimina los obstculos que el equipo no puede resolver por s mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.
Inspeccin y adaptacin
El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos
partes:
1. Demostracin (4 horas mximo). El equipo presenta al cliente los requisitos

completados en la iteracin, en forma de incremento de producto preparado para ser

entregado con el mnimo esfuerzo. En funcin 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 iteracin,
replanificando el proyecto.
2. Retrospectiva (4 horas mximo). El equipo analiza cmo ha sido su manera de
trabajar y cules son los problemas que podran impedirle progresar adecuadamente,
mejorando de manera continua su productividad. El Facilitador se encargar de ir
eliminando los obstculos identificados.

4.1. Actividades
4.1.1. Planificacin de la iteracin (Sprint Planning)
La planificacin de las tareas a realizar en la iteracin se divide en dos partes:
Primera parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas* :
o El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto,
pone nombre a la meta de la iteracin (de manera que ayude a tomar decisiones
durante su ejecucin) y propone los requisitos ms prioritarios a desarrollar en ella.
o El equipo examina la lista, pregunta al cliente las dudas que le surgen, aade
mscondiciones de satisfaccin y selecciona los objetivos/requisitos ms
prioritarios que se compromete a completar en la iteracin, de manera que
puedan ser entregados si el cliente lo solicita.
Segunda parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas*. El
equipo planifica la iteracin, elabora la tctica que le permitir conseguir el mejor
resultado posible con el mnimo 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 cmo realizarlo.
o Define las tareas necesarias para poder completar cada objetivo/requisito, creando
la lista de tareas de la iteracin (Sprint Backlog) basndose en ladefinicin de
completado.
o Realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea.
o Cada miembro del equipo se autoasigna a las tareas que puede realizar.
* Estos son tiempos mximos en el caso de iteraciones mensuales. En iteraciones de
tamao menor el tiempo es proporcionalmente inferior, y se puede ir reduciendo
conforme el equipo va ganando experiencia en este tipo de reuniones, aunque tambin
depender de la complejidad a desarrollar en la iteracin.

Beneficios
Productividad mediante comunicacin y creacin de sinergias:
o Todos los miembros del equipo tienen una misma visin del objetivo y se ha utilizado los
conocimientos y las experiencias de todos para elaborar la mejor solucin entregable en el
mnimo tiempo y con el mnimo esfuerzo, eliminando tareas innecesarias, detectando conflictos y
dependencias entre tareas, etc.

Potenciacin del compromiso del equipo sobre el objetivo comn de la iteracin:

o Es todo el equipo quien asume la responsabilidad de completar en la iteracin los
requisitos que selecciona. Facilita la ayuda de cualquier miembro si se detecta algn
impedimento que bloquea el progreso de la iteracin, especialmente si cuando se est
llegando al final de la iteracin es necesaria la participacin 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 lasreuniones diarias
de sincronizacin del equipo (Scrum daily meeting).
Una estimacin conjunta es ms fiable, dado que tiene en cuenta los diferentes
conocimientos, experiencia y habilidades de los integrantes del equipo.
4.1.2. Ejecucin de la iteracin (Sprint)
En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas (iteraciones de
un mes natural y hasta de dos semanas). Cada iteracin tiene que proporcionar un

resultado completo, un incremento de producto que sea susceptible de ser entregado

con el mnimo esfuerzo cuando el cliente (Product Owner) lo solicite.
Cada da el equipo realiza una reunin de sincronizacin, 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 iteracin (Sprint Backlog) y los grficos 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 obstculos 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 mximo de requisitos en la iteracin, se debe minimizar el
nmero de objetivos/requisitos en que el equipo trabaja
simultneamente(WIP, Work In Progress), completando primero los que den ms
valor al cliente. Esta forma de trabajar, que se ve facilitada por la propia estructura de
la lista de tareas de la iteracin, permite tener ms capacidad de reaccin frente a
cambios o situaciones inesperadas.

Restricciones
No se puede cambiar los objetivos/requisitos de la iteracin en curso.
o En la reunin de planificacin de la iteracin el equipo adquiri el compromiso de
completar en la iteracin unos requisitos concretos, bas su plan y organizacin en
ellos. Cambiar los objetivos/requisitos de la iteracin dificulta la concentracin del
equipo, baja su moral y su compromiso.
o El hecho de no poder cambiar los objetivos/requisitos de la iteracin una vez iniciada
facilita que el cliente cumpla con su responsabilidad de conocer qu es lo ms
prioritario a desarrollar, antes de iniciar la iteracin.
o Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos
que se estn desarrollando eran los ms prioritarios justo antes de iniciar la iteracin 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 iteracin sea mnima.

Terminacin anormal de la iteracin

Slo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una
terminacin anormal de la iteracin. Esto puede suceder si, por ejemplo, el contexto
del proyecto ha cambiado enormemente y no es posible esperar al final de la iteracin
para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el
compromiso adquirido. En ese caso, se dar por finalizada la iteracin y se dar inicio a
otra mediante una reunin de planificacin de la iteracin.
4.1.3. Reunin diaria de sincronizacin del equipo (Scrum Daily Meeting)

El objetivo de esta reunin es facilitar la transferencia de informacin y

lacolaboracin entre los miembros del equipo para 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 iteracin, obstculos que
pueden impedir este objetivo) para al finalizar la reunin poder hacer
las adaptacionesnecesarias que permitan cumplir con el compromiso conjunto que el
equipo adquiri para la iteracin (en la reunin de planificacin de la iteracin).
Cada miembro del equipo debe responder las siguientes preguntas en un timebox de
cmo mximo 15 minutos:
Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que
tena planeado? Cul 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
iteracin y en el proyecto?
Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la iteracin, donde
se actualiza el estado y el esfuerzo pendiente para cada tarea, as como con el grfico
de horas pendientes en la iteracin.

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 realizacin 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
estn alineadas con el compromiso del equipo, aunque l crea que lo que est
haciendo es lo mejor que se puede hacer.
o Cules 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 mximo valor y no realizar tareas que no proporcionan
ningn beneficio al resto del equipo.
o Cul 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 seale con el dedo a otra, dado que la reunin de sincronizacin pone a todos
los miembros del equipo en la misma situacin de tener que explicar en qu tareas
estn trabajando.
o Cules son los criterios que est utilizando para realizar sus tareas, de manera que
estn alineados con los objetivos comunes del equipo.
Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cmo trabajan
los otros segn sus especialidades y experiencias.

 Conocer el estado de la iteracin, 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 reunin diaria de estado y sincronizacin del equipo no es para resolver
problemas, los problemas se resuelven despus de la reunin.
o No a todos los miembros del equipo les interesan todos los detalles de cada tema.
o En la reunin 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 reunin para comentar un tema particular. Si apareciese alguna conversacin de
inters comn (que debe ser rpida), debe poder ser escuchada por todo el equipo sin
distraer el principal objetivo de que todos conozcan en qu estn trabajando los
dems. Si la mini conversacin no es del inters de todos, debe hacerse despus de la
reunin.
El equipo debe contar con unos criterios consensuados sobre el proceso de
ejecucin de las de tareas
o El proceso de ejecucin de las tareas debe estar consensuado para evitar que cada
reunin sea una exposicin de discrepancias entre los miembros del equipo.

Recomendaciones
Realizar la reunin diaria de sincronizacin de pie, para que los miembros del equipo no
se relajen ni se extiendan en ms detalles de los necesarios.
Realizar las reuniones de colaboracin entre miembros del equipo justo despus de la de
sincronizacin.
4.1.4. Demostracin de los requisitos completados (Sprint Review)
Reunin informal donde el equipo presenta al cliente los requisitos completados en
laiteracin, en forma de incremento de producto preparado para ser entregado con el
mnimo esfuerzo, haciendo un recorrido por ellos lo ms real y cercano posible al
objetivo que se pretende cubrir.
En funcin 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 iteracin, replanificando el proyecto.
Se realiza en un timebox de cmo mximo 4 horas.

Beneficios

El cliente puede ver de manera objetiva cmo han sido desarrollados los requisitos que
proporcion, ver si se cumplen sus expectativas, entender ms qu es lo que necesita
y tomar mejores decisiones respecto al proyecto.
El equipo puede ver si realmente entendi cules eran los requisitos que solicit el
cliente y ver en qu puntos hay que mejorar la comunicacin entre ambos.

 El equipo se siente ms satisfecho cuando puede ir mostrando los resultados que va

obteniendo. No est meses trabajando sin poder exhibir su obra.

Restricciones

Slo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas
expectativas y pueda tomar decisiones correctas y objetivas en funcin de la velocidad
de desarrollo y el resultado realmente completado. Un requisito no completado
quedar como un requisito ms 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 equipo analiza cmo ha sido su manera de trabajar
durante la iteracin, por qu est consiguiendo o no los objetivos a que se comprometi
al inicio de la iteracin 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 iteracin.
Qu ha aprendido.
Cules son los problemas que podran impedirle progresar adecuadamente.
ElFacilitador se encargar de ir eliminando los obstculos identificados que el propio
equipo no pueda resolver por s mismo.
Notar que esta reunin se realiza despus de la reunin de demostracin al cliente de
los objetivos conseguidos en la iteracin, para poder incorporar su feedback y
cumplimiento de expectativas como parte de los temas a tratar en la reunin de
retrospectiva
Se realiza en un timebox de cmo mximo 3 horas (si la iteracin 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 sistemtica, iteracin a iteracin, con resultados a corto plazo.
Aumenta la motivacin del equipo dado que participa en la mejora de proceso, se
siente escuchado, toma decisiones consensuadas (y ms sostenibles) para ir
eliminando lo que molesta e impide que sea ms 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 sistemticamente los mismos obstculos y no poder solucionarlos

4.1.6. Replanificacin del proyecto

En las reuniones de planificacin de entregas y/o durante el transcurso de
unaiteracin, el cliente va trabajando en la lista de objetivos/requisitos priorizada del
producto o proyecto, aadiendo requisitos, modificndolos, eliminndolos,

repriorizndolos, 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 demostracin que el equipo realiza al final de
cada iteracin 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 identificacin inicial de
sus condiciones de satisfaccin (que se detallarn en la reunin de planificacin de
la iteracin).
El cliente obtiene del equipo la re-estimacin de costes de desarrollo para
completar los objetivos/requisitos siguientes, segn la definicin de completado.
El equipo ajusta el factor de complejidad, el coste para completar los requisitos y su
velocidad de desarrollo en funcin de la experiencia adquirida hasta ese momento en el
proyecto.
El cliente re-prioriza la lista de objetivos/requisitos en funcin de estas nuevas
estimaciones.
Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la
iteracin en curso, (que de hecho eran los ms prioritarios al iniciar la iteracin). No es
posible cambiar los requisitos que se desarrollan durante la iteracin. En la reunin
de planificacin de la iteracin el cliente presentar la nueva lista de requisitos para
que sea desarrollada.

Beneficios
De manera sistemtica, iteracin a iteracin, 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 organizacin)
son:

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

proyecto (internas o externas a la organizacin, promotores del proyecto y usuarios
finales [idealmente tambin debera 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 planificacin 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 iteracin replanifica el proyecto en funcin de los requisitos que
aportan ms valor en ese momento, de los requisitos completados en la iteracin
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 iteracin:
o Participar en la reunin de planificacin de iteracin, proponiendo los requisitos ms
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 iteracin para responder a las preguntas que
puedan aparecer.
o No cambiar los requisitos que se estn desarrollando en una iteracin, una vez est
iniciada.
o Participar en la reunin de demostracin de la iteracin, 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,
encajndolas en la cultura de la organizacin, y guiar la colaboracin intraequipo y con el
cliente de manera que las sinergias sean mximas. Esto implica:

o Asegurar que la lista de requisitos priorizada est preparada antes de la siguiente iteracin.
o Facilitar las reuniones de Scrum (planificacin de la iteracin, reuniones diarias de
sincronizacin del equipo, demostracin, retrospectiva), de manera que sean productivas y
consigan sus objetivos.

o Ensear al equipo a autogestionarse. No da respuestas, si no que gua al equipo con

preguntas para que descubra por s mismo una solucin.

Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada
iteracin (proporcionar un resultado til al cliente de la manera ms efectiva) y poder finalizar el
proyecto con xito. Estos obstculos se identifican de manera sistemtica en lasreuniones diarias
de sincronizacin del equipo y en las reuniones de retrospectiva.

 Proteger y aislar al equipo de interrupciones externas durante la ejecucin de la

iteracin(introduccin 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 completara en la iteracin [notar, sin embargo, que el equipo
debe reservar tiempo para colaborar con al cliente en la preparacin de la lista de requisitos para
la prxima iteracin].

4.2.3. Team (equipo)

Grupo de personas que de manera conjunta desarrollan el producto del proyecto.
Tienen un objetivo comn, comparten la responsabilidad del trabajo que realizan (as
como de sucalidad) en cada iteracin y en el proyecto.
El tamao del equipo est entre 5 y 9 personas. Por debajo de 5 personas cualquier
imprevisto o interrupcin sobre un miembro del equipo compromete seriamente el
compromiso que han adquirido y, por tanto, el resultado que se va a entregar
al clienteal finalizar la iteracin. Por encima de 9 personas, la comunicacin y
colaboracin entre todos los miembros se hace ms difcil 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 ms de un
equipo trabaje de manera gil en un mismo proyecto, existen diferentes tcnicas que
permiten esta colaboracin, desde el Scrum de Scrums hasta equipos de integracin
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 informacin y cuyos miembros confan
entre ellos. Realiza de manera conjunta las siguientes actividades:
Seleccionar los requisitos que se compromete a completar en una iteracin, de forma
que estn preparados para ser entregados al cliente.
Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto
o proyecto.
En la reunin de planificacin de la iteracin decide cmo va a realizar su trabajo:
o Seleccionar los requisitos que pueden completar en cada iteracin, 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 iteracin, trabajar de manera conjunta para conseguir los objetivos de la
iteracin. Cada especialista lidera el trabajo en su rea y el resto colaboran si es
necesario para poder completar un requisito.
Al finalizar la iteracin:
o Demostrar al cliente los requisitos completados en cada iteracin.
o Hacer una retrospectiva la final de cada iteracin 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 iteracin.
Tienen que depender lo mnimo de personas externas al equipo, de manera que el
compromiso que adquieren en cada iteracin no se ponga en peligro.
Se crea una sinergia que permite que el resultado sea ms rico al nutrirse de las
diferentes experiencias, conocimientos y habilidades de todos. Colaboracin creativa.
Los miembros del equipo dedicarse al proyecto a tiempo completo para evitar daar
su productividad por cambios de tareas en diferentes proyectos, para evitar
interrupciones externas y as poder mantener el compromiso que adquieren en cada
iteracin.
Todos los miembros del equipo trabajan en la misma localizacin fsica, para poder
maximizar la comunicacin entre ellos mediante conversaciones cara a cara, diagramas
en pizarras blancas, etc. De esta manera se minimizan otros canales de comunicacin
menos eficientes, que hacen que las tareas se transformen en un pasa pelota o que
hacen perder el tiempo en el establecimiento de la comunicacin (como cuando se
llama repetidas veces por telfono cuando la persona no est en su puesto).
El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo
mnimo posible, para poder aprovechar el esfuerzo que les ha costado construir sus
relaciones interpersonales, engranarse y establecer su organizacin del trabajo.

4.3. Artefactos
4.3.1. Product Backlog (Lista de objetivos / requisitos priorizada)
La lista de objetivos/requisitos priorizada representa la visin y expectativas
delclienterespecto 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 direccin 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
elvalor 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, basndose en el Retorno de la Inversin
(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 funcin de la velocidad de desarrollo del (los)
equipo(s) que trabajar(n) en el proyecto. Es conveniente que el contenido de cada
iteracin tenga una coherencia, de manera que se reduzca el esfuerzo de completar todos sus
objetivos.

La lista tambin tiene que considerar los riesgos del proyecto e incluir los requisitos o
tareas necesarios para mitigarlos.

Antes de iniciar la primera iteracin, 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 estn detallados al mismo nivel. Basta con
que estn identificados y con suficiente detalle los requisitos ms prioritarios con los
que el equipo empezar a trabajar. Los requisitos de iteraciones futuras pueden ser
mucho ms amplios y generales. La incertidumbre y complejidad propia de un proyecto
hacen conveniente no detallar todos los requisitos hasta que su desarrollo est
prximo. De esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de
requisitos (menos prioritarios) est repartido en el perodo de ejecucin 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 irn apareciendo los requisitos menos prioritarios que falten. Esto produce
varias ventajas:
Se evita caer en parlisis de anlisis 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 podran cambiar durante el transcurso
del proyecto, dado que el cliente conocer mejor cul ha de ser el resultado a conseguir, o bien
por que podran 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 inversin (ROI) que tienen.
Definicin de completado (definition of done)
El cliente y el equipo tienen que acordar la "definicin de completado de los objetivos
/ requisitos en el proyecto:
Debe asegurar que el incremento de producto es potencialmente entregable al cliente
al finalizar cada iteracin, 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 iteracin el equipo le haga
unademostracin de los requisitos completados: cambiar las prioridades en funcin 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 segn sus criterios de entregables y de calidad (producto construido, probado,
documentado, refactorizado para conseguir calidad interna, etc.).

o Adems de esta definicin de completado, a cada objetivo hay que asociarle

sus condiciones de satisfaccin, preferiblemente en forma de casos de prueba de
aceptacin, en el momento de crear la lista de requisitos priorizada (Product Backlog).
o Notar que la definicin de completado tambin sirve como base para identificar las
tareas necesarias para conseguir cada objetivo/requisito, en la reunin deplanificacin
de la iteracin (Sprint planning). Para cada objetivo se crearn ms tareas que la
definicin de completado (o menos) y con ms 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.

Iteracin de entrega (release sprint)

Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta
ese momento, el equipo puede necesitar aadir una iteracin de entrega, ms 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 demostracin.

Uso de la lista
Para medir la velocidad de desarrollo del equipo, ver una progresin 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 estimacin de un requisito no debe ser superior a 10 das (si las iteraciones son
de 20 das laborables).
Cada requisito tiene asociado un factor de complejidad, que permite ajustar su
coste estimado en funcin 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 tecnologas que utiliza.
Si un requisito depende de otro, se coloca en algn punto por debajo del que
depende.
Si un requisito no se finaliza en una iteracin, se le vuelve a poner en alguna de las
siguientes iteraciones, indicando el coste pendiente de desarrollo.
El "origen" permite saber quin podra participar en la definicin de un objetivo/requisito
y sera conveniente que estuviese presente en el momento de su demostracin.
El progreso del proyecto y su velocidad con respecto a requisitos completados se muestra en
ungrfico de trabajo pendiente (Burndown chart).

4.3.2. Lista de tareas de la iteracin (Sprint Backlog)

Lista de tareas que el equipo elabora en la reunin de planificacin de la iteracin
(Sprint planning) como plan para completar los objetivos/requisitos seleccionados para
la iteraciny que se compromete a demostrar al cliente al finalizar la iteracin, 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 autoasignacin que han hecho los miembros del equipo.

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

mediante un grfico de trabajo pendiente (Burndown chart).

Uso de la lista
Los objetivos/requisitos estn ordenados por orden de prioridad para el cliente.
o Por ello, signos de falta de foco, problemas o impedimentos seran que se estn completando
objetivos que no son los primeros de la lista, as como tener demasiados objetivos/requisitos en
progreso simultneamente.

Si una tarea depende de otra, se coloca en algn 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 tamao permitir:
o Que las tareas sean suficientemente pequeas como para poder detectar progreso o
estancamiento de manera diaria.
o Que las tareas no sean muy pequeas, que sean suficientemente relevantes, no generen ruido ni
microgestin.

o Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas dentro

de la iteracin.

El tablero de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteracin (Product Backlog Items) se puede gestionar
mediante un tabln 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 ms pequeos 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 reunin de planificacin

de la iteracin. La lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo
pendiente) a medida que la iteracin avanza, especialmente durante la reunin diaria
de sincronizacin.
Este tabln o cuadro de mandos acta como radiador de informacin tanto para el equipo
como para cualquier otra persona relacionada con el proyecto.
En el siguiente artculo se muestra cmo construirlo y un ejemplo de su uso: Ejemplo de uso del
tablero o pizarra de tareas (Scrum Taskboard).

4.3.3. Grficos de trabajo pendiente (Burndown Chart)

Un grfico 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 grficos de esfuerzo pendiente:

Das pendientes para completar los requisitos del producto o proyecto (product
burndown chart), realizado a partir de la lista de requisitos priorizada (Product
Backlog).
Horas pendientes para completar las tareas de la iteracin (sprint burndown chart),
realizado a partir de la lista de tareas de la iteracin (Iteration Backlog).
Este tipo de grfico permite realizar diversas simulaciones: ver cmo se aplazan las
fechas de entrega si se le aaden requisitos, ver cmo se avanzan si se le quitan
requisitos o se aade 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 priorizacin de los requisitos por valor para el cliente y coste de desarrollo en cada
iteracin.
El control emprico del proyecto. Por un lado, al final de cada iteracin se demuestra al
cliente el resultado real obtenido, de manera que pueda tomar las decisiones
necesarias en funcin 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 potenciacin del equipo, que se compromete a entregar unos requisitos y para ello se
le otorga la autoridad necesaria para organizar su trabajo.
La sistematizacin de la colaboracin y la comunicacin 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 prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la
manera de trabajar de equipos altamente productivos.

6. Historias de Usuario
6.1. Definicin

Una historia de usuario es una representacin de un requerimiento de software escrito en una o

dos frases utilizando el lenguaje comn del usuario. Las historias de usuario son utilizadas en
lasmetodologas de desarrollo giles para la especificacin de requerimientos (acompaadas de
las discusiones con los usuarios y las pruebas de validacin). Cada historia de usuario debe ser
limitada, esta debera poderse escribir sobre una nota adhesiva pequea.
Las historias de usuario son una forma rpida 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 rpidamente a los requerimientos
cambiantes.

6.2. Caractersticas

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 explcita como para considerarse

un contrato, la discusin con los usuarios debe permitir esclarecer su alcance y ste debe dejarse
explcito bajo la forma de pruebas de validacin.
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 ms
que para el desarrollador.
Estimables: Un resultado de la discusin de una historia de usuario es la estimacin del tiempo
que tomar completarla. Esto permite estimar el tiempo total del proyecto.
Pequeas: Las historias muy largas son difciles de estimar e imponen restricciones sobre la
planificacin de un desarrollo iterativo. Generalmente se recomienda la consolidacin 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 verificacin debe automatizarse, de manera
que pueda ser verificada en cada entrega del proyecto.

6.3. Estructura

ID: Identificador de la historia de usuario

TTULO: Ttulo descriptivo de la historia de usuario
DESCRIPCIN: Descripcin sintetizada de la historia de usuario
ESTIMACIN: Estimacin del coste de implementacin en unidades de desarrollo (estas
unidades representarn el tiempo terico de desarrollo/hombre que se estipule al
comienzo del proyecto)
PRIORIDAD: Prioridad en la implementacin de la historia de usuario respecto al resto de
las historias de usuario. A mayor nmero, mayor prioridad. Otra aproximacin a la
priorizacin de tareas se hace a travs del mtodo 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 debera completar este requerimiento si su implementacin no afecta a la
consecucin 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 debera ser dependiente de otra historia,
pero a veces es inevitable. En este apartado se indicaran 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 ingls (Card, Conversation, Confirmation):
TARJETA (Card), la creacin de la tarjeta en s, con la estructura definida anteriormente
y que sirve para determinar QU se debe hacer y cmo planificarlo.
CONVERSACION (Conversation), representado por pequeos documentos y anotaciones
que sirven para aportar detalles y refinar los datos sobre las caractersticas del
requerimiento.
CONFIRMACIN (Confirmation), o pruebas de aceptacin. Pruebas consensuadas
entre el cliente y el desarrollador y que el cdigo debe superar para dar como
finalizada la implementacin del requerimiento.

7. Utilizando la herramienta Rational Team Concert

7.1. Creando una conexin al repositorio
En primer lugar debe asegurarse que Jazz Team Server est corriendo y que el cliente
est abierto.
Para crear una nueva conexin al repositorio, haga click derecho en Conexiones al
repositorio y seleccione Nuevo->Conexin 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 ms 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 conexin al repositorio y
seleccionaNuevo->Usuario.
Seleccione No cuando el cuadro de dilogo para importar usuario se abra.
Ingrese la informacin del usuario que pide la herramienta. El ID que usted ingrese, ser
la contrasea 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 de JazzAdmins.
- JazzUsers: tiene los permisos por defecto en un rea de proyecto. Estos permisos
permiten crear tems de trabajo, ver reportes y usar otras caractersticas 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 pginas. Este tipo de licencia es apropiada para miembros quienes van a
programar y correr aplicaciones.
- Build and ClearCase Connector: este tipo de licencia es tpico para usuarios
administrativos.
- Contributor: es aplicado a usuarios que necesitan solo leer informacin del repositorio.
Tambin 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 ests creando.
Para crear un nuevo rea de Proyecto, haga click derecho en Conexin al repositorio en
la pestaa Artefactos y seleccione Nuevo->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 pestaa Artefactos, puede ver el nuevo

rea de Proyecto creado con sub-carpetas ya creadas, planes, informes, cdigo fuente
y elementos de trabajo. En el editor de rea de Proyecto hay informacin 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 Aadir.
Seleccione los usaurios que desea aadir.
Una vez agregados haga doble click en cada uno de ellos apra asignarles roles.

7.5. Crear lneas de tiempo (Sprints)

El siguiente paso es definir lneas de tiempo para el proyecto, lo cual quiere decir
especificar fechas de comienzo y de trmino 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 iteracin 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 trmino. Asegrese que el checkbox para Se ha
planificado un release para esta iteracin est marcado. Y seleccione Aceptar.
Usted podra hacer ms cambios al rea de Proyecto ms 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 tecnologa Jazz puede soportar equipos grandes con mltiples sub-equipos, Dentro
de las reas de Proyecto, existen reas de Equipo para organizar a los miembros.
Haga click en la pestaa Organizacin de Equipo, Si no est abierta, vaya a Ventana>Mostrar Vista->Organizacin 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 configuracin, seleccione Grabar.

8. Especificacin de la disponibilidad de los miembros del equipo

Para que los clculos del tiempo del trabajo y desempeo 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 participacin limitada. Todos estos
ajustes se realizan en la pgina del usuario. Usualmente, los usuarios son los que
deberan mantener su rea activa por ellos mismos; sin embargo, como parte

importante del clculo del desempeo del equipo correcto, es importante ilustrarlo
aqu.
8.1 Si an no se ha realizado esta accin, es importante seleccionar la pestaa de
Team Organization en el panel izquierdo y expandir en HAVANNAH FOLDER y el
HAVANNAH TEAM.
8.2 Abrir el editor de usuario para algn miembro. Tambin se pueden editar los
detalles de dicho usuario.
8.3 Por ejemplo, un miembro X podra estar disponible slo 75% del tiempo.
Entonces, lo que se hace es seleccionar la pestaa del WORK ENVIRONMENT que est
en la parte inferior, luego en la seccin 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 slo a un equipo, el 100% de su tiempo
(recursos) es asociado con el equipo. Para bajar la asignacin para el usuario, seleccin
la asignacin y pdale un CHANGE o un cambio. Luego descienda la asignacin a 75%.
8.5 Ahora slo acepte o seleccione OK.
8.6 Ahora, si el usuario, tiene por ejemplo un da de vacaciones que se aproxime, sera
conveniente cambiar a la pestaa de ausencias agendadas o SCHEDULED ABSENCES y
seleccionar NUEVO o NEW en el lado derecho de la lista e ingresar una descripcin y
los das o fechas para ese tiempo destinado a vacacionar. Lo siguiente sera aceptar y
guardar los cambios con SAVE.
9. Creando un PRODUCT BACKLOG para el proyecto
Una de los ms importantes artefactos en la metodologa 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 creacin 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, slo se finaliza.
Tip: Si usted no pudiera guardar los cambios que se realizan para el nuevo plan que est
creando, debera revisar y asignar el rol de SCRUM MASTER para poder crear este
artefacto.
Es as como un editor multi-pginas abrir el plan de iteraciones del PRODUCT BACKLOG.
9.5 En la pgina de OVERVIWE, usted podr ingresar informacin 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 slo en modo edicin para
esta pgina) es un gran lugar para aadir nuevos requerimientos u otra documentacin
general que se pertinente para esta entrega; de modo que sean fciles de leer y
disponibles para todos los miembros del equipo. Esta rea de la pgina puede contener
tambin vnculos a pginas Web o documentos externos de repositorios segn lo que
se requiera.
9.7 Ahora, debera poder ir a la pestaa de PLANNED ITEMS para comenzar a aadir los
elementos de BACKLOG.
Si bien es cierto, hay muchas formas de ver un plan, estas, son llamadas MODES. En
el lado derecho de la ventana, usted podr especificar cmo los elementos en el plan
deben ser agrupados y qu tipo de elementos debern ser excludos de la vista.
Existen modos de vistas que estn predefinidos. Usted podra 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 estn almacenados en el servidor y
podrn estar disponibles a otros miembros del equipo, de igual modo, todos los
cambios que se hagan afectarn a los dems 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 pestaa de elementos planeados o PLANNED ITEMS para el BACKLOG, comience
por aadir elementos del BACKLOG o BACKLOG items. Para la administracin de
proyectos SCRUM, los elementos en el PRODUCT BACKLOG son llamados STORIES o, si
son muy extensos, EPICS. Una historia o STORY es una descripcin de la funcionalidad
que ser implementada en el producto, usualmente citada en trminos de lo que los
usuarios quieren y el valor que desean mediante ese producto. Una historia
apropiadamente descrita incluye un resumen o lnea de cabecera, alguna descripcin
de la innovacin y las condiciones de aceptacin 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 rpidamente a los nuevos elementos de trabajo presionando CTRL + ENTER.
10.2 Lo conveniente sera seleccionar, entonces, la carpeta del equipo de proyecto y
aadir un WORK ITEM, SET DEFAULT, STORY.
10.3 Para proceder a la creacin, simplemente, vuelva a seleccionar la carpeta del
equipo de proyecto y fjese en la opcin ADD WORK ITEM, luego aada una STORY.
10.4 Lo que quedara sera el ingreso de datos pertintentes.
10.5 Ahora, se deberan aadir 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 aadidas, el siguiente paso para el
PRODUCT OWNER es el poner prioridades para ellas. Los valores HIGH (ALTA),
MEDIUM(Media), LOW(Baja) estn disponibles para el atributo prioridad. Usted puede
asignar prioridades fcilmente usando la lista desplegable.
10.8 Usted puede darle un puntaje a sus prioridades tambin 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 automticamente asignar el
nuevo valor de alto a su trabajo.
10.9 Cuando el equipo aade un estimado para la complejidad del elemento, deber
ingresar puntos de STORY usando mens 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 ms alto en el rea de
proyecto de configuracin. Para ello, debera realizar lo siguiente:
a. Abrir el PROJECT AREA desde la vista de ARTIFACTS.
b. Dentro de la pestaa de PROCESS CONFIGURATION, expandir el PROJECT.
c. Ahora, deber seleccionar TOP-LEVEL WIRK ITEM TYPES y aadir 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 resmenes 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 descripcin podra ingresar informacin adicional o detalles de lo que
se espera en la historia.
El creador de un elemento es automticamente suscrito a l. En caso de que usted no
necesite esta opcin, podra ubicar el vnculo SUSCRIBERS en la seccin de QUICK
INFORMATION en la parte inferior izquierda y seleccionar UNSUSCRIBE ME para
eliminar su suscripcin.
Lo siguiente sera ubicar la pestaa de ACCEPTANCE TEST en la parte inferior y aadir
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.