Sprints

© Universidad de Palermo | Prohibida la reproducción total o arcial de imágenes y textos.

Sprints

Sprint

Un sprint o iteración es una unidad básica de tiempo durante el cual se trabaja para generar un
entregable.

Cada sprint se empieza definiendo la lista de historias de usuarios o Work Items a trabajar durante el
sprint (sprint backlog). Esos ítems se estiman en base al esfuerzo que le representaran al equipo
(StoryPoints, aunque hay equipos que estiman en oras).
h

© 2
Sprints

Sprint

Para tener en cuenta:

Un sprint en scrum tiene una duración prefijada, la cual debe sostenerse (no debe
cambiarse la duración de la sprint).

Cada sprint se empieza definiendo la lista de historias de usuarios a trabajar durante

el sprint. Esto es conocido como sprint backlog.

Esos ítems se estiman en base al esfuerzo que le representaran al equipo. Esto es

conocido como StoryPoints.

© 3
Sprints

Sprint

Duración de
e los sprint

Los Sprints cortos son muy manejables. Permiten a una compañía ser “ágil”, es decir,
cambiar de dirección frecuentemente. Sprints cortos = ciclo de feedback corto = más entregas
y más frecuentes = más feedback del cliente = menos tiempo desarrollando en dirección
incorrecta = aprender y mejorar más rápido, etc.

Pero los Sprints largos también son muy manejables. El equipo tiene más tiempo para
conseguir impulso, tienen más espacio para recuperarse de los problemas que surjan y aun
así cumplir la meta del Sprint, tiene menos carga de gestión en términos de reuniones de
planificación de Sprints, Demos, etc.

© 4
Sprints

Sprint
Consideración de duración

• La duración estándar de Sprint, con la que la mayoría de equipos trabajan, es de 2 semanas.

• Los límites habituales para la duración están ent e 1 y 4 semanas.

• La duración del sprint es algo que se puede cambiar. Si tras varios sprints (alrededor de 5 por
ejemplo) el equipo no está cómodo con la duración, se puede cambiar y probar otra duración.
Nota: La guía Scrum no lo contempla y no es lo esperable aunque podría llegar a ser un acuerdo de equipo, no debiera pasar, y que tiene una desventaja, ya se pierde
toda referencia de velocidad del equipo.

© 5
Sprints

Flujo de trabajo (workflow)

El flujo de trabajo (el workflow) son los pasos que sistemáticamente siguen los integrantes del
equipo.

• Definido por el equipo.

• Compromiso y adhesión.

• Aceptación del cliente.

• Objetivo.

© 6
Sprints

Definición de hecho

La definición de hecho (Definition of Done) permite:

• Establecer un criterio de calidad, define qué entregables y mínimos de calidad se tienen
que cumplir en TODOS los objetivos/requisitos que se van a ir aceptando durante cada
iteración del proyecto.

• Tener siempre un producto “potencialmente entregable” al finalizar cada iteración, no dejar

trabajo pendiente para el final, escondido “debajo de la alfombra”, que pueda impedir
utilizar los resultados del proyecto lo antes posible.

• Esto permite saber claramente en qué punto real se está del proyecto y tomar buenas
decisiones al respecto sobre lo que se ha conseguido hasta ese momento y lo que todavía
no se sabe con certeza cuándo estará acabado.

© 7
Sprints

Definición de hecho

• Por otro lado, lo peor que podría suceder es que, aunque el equipo haya ido presentando
todos los objetivos/requisitos completados durante el proyecto (en cada iteración), se
podría dar el caso de que los días previos a una entrega de repente se den cuenta de que
hay que hacer mucho trabajo de integración y finalización (que podría haberse ido
haciendo antes, durante el proyecto). Esto también les dificultaría estimar cuándo tiempo
necesitan para acabar de terminar el producto (lo cual pondría en peligro la fecha de
entrega).

La definición de hecho se acuerda entre el S keholder (cliente) y el equipo de desarrollo al

principio del proyecto y se puede ir refinando d rante la ejecución del proyecto.

© 8
Sprints

Definición de hecho

Ejemplo de definición de hecho:

• El trabajo de todos los miembros del equipo de desarrollo tiene que estar totalmente integrado en
cada iteración.

• El trabajo de cada miembro del equipo ha sido revisado por al menos otro miembro del equipo.

• Todo el equipo considera que para cada objetivo /requisito se cumplen sus criterios de validación.

• El trabajo en cada iteración tiene que cumplir con los requisitos de calidad X, Y, Z.

• Tiene que estar probado A, B, C (calidad externa, usabilidad, funcionalidad, seguridad).

• El producto sigue los estándares de calidad interna y ha sido refactorizado para conseguir
mantenibilidad.

• Tiene que estar documentado D, E, F.

• El Product Owner ha validado y aceptado el objetivo/requisito.

© 9
Sprints

Definición de hecho
Cada requerimiento (user story) debe especificar sus criterios de aceptación, los cuales
definen cómo se va a probar/demostrar que el requerimiento ha sido desarrollado conforme la
especificación funcional.

Estos criterios de aceptación se acuerdan entre el Product Owner (quien ha relevado el

requerimiento con el cliente) y el equipo de desarrollo en una conversación que permita
reducir la ambigüedad sobre el entregable.

Los criterios de aceptación de los requerimientos a trabajar en una iteración se recogen en la

meeting de planificación (Sprint Planning) o antes.

Es importante destacar que el concepto de “definición de hecho”, transversal al proyecto y

describe o apunta a actividades a ejecutar, es diferente del concepto de criterios de
aceptación, que afecta a cada requerimiento en particular.

© 10
 © Universidad de Palermo
Prohibida la reproducción total o parcial de imágenes y textos.