0274 PPT Sprint 201Q v1-1

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
• 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
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
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.

0274 PPT Sprint 201Q v1-1

Cargado por

Copyright:

Formatos disponibles

0274 PPT Sprint 201Q v1-1

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

0274 PPT Sprint 201Q v1-1

Cargado por

Copyright:

Formatos disponibles

Sprints

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

Para tener en cuenta:

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

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

• 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.

Flujo de trabajo (workflow)

• Definido por el equipo.

• Aceptación del cliente.

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

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

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

Ejemplo de definición de hecho:

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

• Tiene que estar documentado D, E, F.

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

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

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

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

También podría gustarte