El documento describe los principios y prácticas del framework ágil de desarrollo de software, incluyendo los derechos de programadores y propietarios de productos, así como las reuniones diarias, de planificación y retrospectivas. Se enfoca en la importancia de la comunicación, confianza y trabajo en equipo para entregar valor al cliente de manera iterativa.

1. Agile software development framework

2. Somos un único equipo
Tenemos una misma obsesión

3. Confianza en el otro
Conseguir una relación de confianza entre todos los miembros del equipo

4. Programador, tienes derecho a:
• Tienes el derecho a conocer que se necesita hacer, por orden de
prioridad.

5. Programador, tienes derecho a:
• Tienes el derecho a conocer que se necesita hacer, por orden de
prioridad.
• Tienes el derecho a producir siempre código de alta calidad.

6. Programador, tienes derecho a:
• Tienes el derecho a conocer que se necesita hacer, por orden de
prioridad.
• Tienes el derecho a producir siempre código de alta calidad.
• Tienes el derecho de pedir y recibir ayuda de compañeros,
superiores y clientes.

7. Programador, tienes derecho a:
• Tienes el derecho a conocer que se necesita hacer, por orden de
prioridad.
• Tienes el derecho a producir siempre código de alta calidad.
• Tienes el derecho de pedir y recibir ayuda de compañeros,
superiores y clientes.
• Tienes el derecho de hacer y modificar tus propias estimaciones.

8. Programador, tienes derecho a:
• Tienes el derecho a conocer que se necesita hacer, por orden de
prioridad.
• Tienes el derecho a producir siempre código de alta calidad.
• Tienes el derecho de pedir y recibir ayuda de compañeros,
superiores y clientes.
• Tienes el derecho de hacer y modificar tus propias estimaciones.
• Tienes el derecho de aceptar tus responsabilidades, en lugar de
ser impuestas.

9. Product Owner, tienes derecho a:
• Tienes el derecho a una planificación general, a conocer que se
puede cumplir, cuando y a qué coste.

10. Product Owner, tienes derecho a:
• Tienes el derecho a una planificación general, a conocer que se
puede cumplir, cuando y a qué coste.
• Tienes el derecho a recibir el máximo valor posible de cada
semana de programación.

11. Product Owner, tienes derecho a:
• Tienes el derecho a una planificación general, a conocer que se
puede cumplir, cuando y a qué coste.
• Tienes el derecho a recibir el máximo valor posible de cada
semana de programación.
• Tienes el derecho de ver evolución en un sistema funcionando.

12. Product Owner, tienes derecho a:
• Tienes el derecho a una planificación general, a conocer que se
puede cumplir, cuando y a qué coste.
• Tienes el derecho a recibir el máximo valor posible de cada
semana de programación.
• Tienes el derecho de ver evolución en un sistema funcionando.
• Tienes el derecho a cambiar de opinión, a cambiar funcionalidades
y a cambiar las prioridades sin tener que pagar un precio
exhorbitante.

13. Product Owner, tienes derecho a:
• Tienes el derecho a una planificación general, a conocer que se
puede cumplir, cuando y a qué coste.
• Tienes el derecho a recibir el máximo valor posible de cada
semana de programación.
• Tienes el derecho de ver evolución en un sistema funcionando.
• Tienes el derecho a cambiar de opinión, a cambiar funcionalidades
y a cambiar las prioridades sin tener que pagar un precio
exhorbitante.
• Tienes el derecho a estar informado de los cambios de
planificaciones, con el tiempo para poder elegir el scope para
restaurar la fecha original.

14. Planning meeting

15. De esta reunión sale el objetivo del sprint

16. Planning meeting
• El Product Backlog ya está ordenado y el equipo lo tiene revisado.

17. Planning meeting
• El Product Backlog ya está ordenado y el equipo lo tiene revisado.
• Los clientes resolverán las dudas que pueda tener el equipo.

18. Planning meeting
• El Product Backlog ya está ordenado y el equipo lo tiene revisado.
• Los clientes resolverán las dudas que pueda tener el equipo.
• El equipo estima el valor de las historias usando las Planning Poker Cards.

19. Planning meeting
• El Product Backlog ya está ordenado y el equipo lo tiene revisado.
• Los clientes resolverán las dudas que pueda tener el equipo.
• El equipo estima el valor de las historias usando las Planning Poker Cards.
• El equipo decide las cantidad de puntos que se compromete a entregar al
finalizar el Sprint.

21. “¿Cuánto se tarda?”
Es una pregunta técnica y necesita ser respondida por gente técnica

23. Puntos

24. Si nos hemos equivocado,
te lo haremos saber lo antes posible

25. Todo esto va de comunicación,
no tanto de estimación
Y por supuesto no de negociación

26. Daily stand-up meetings

27. Conocer el estado del progreso del Sprint
Solucionar los posibles impedimentos que surjan

28. Daily stand-up meetings
• Conocer el estado del progreso del Sprint
• Mejorar
• Motivar
• Foco
• Hacer equipo

29. La reunión pertenece al equipo
La conduce el equipo, no el SM

30. Daily stand-up meetings
• Qué hice ayer.

31. Daily stand-up meetings
• Qué hice ayer.
• Qué haré hoy.

32. Daily stand-up meetings
• Qué hice ayer.
• Qué haré hoy.
• Qué obstáculos impiden mi progreso.

33. Debe durar 15 minutos o menos

34. Si es demasiado baja: El SM buscará y propondrá alternativas al PO para volver a marcar un objetivo alcanzable.
Si es demasiado alta: El SM puede proponer añadir nuevas historias al Sprint.

35. Sprint Retrospective

36. Trabajar de forma más eficiente tras
cada sprint

37. No debería durar más de 1 hora
Una reunión larga hace que la gente se canse, se aburra y se distraiga

38. Sprint Retrospective
• El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint)

39. Sprint Retrospective
• El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint)
• Acciones ya implementadas del anterior plan de acción.

40. Sprint Retrospective
• El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint)
• Acciones ya implementadas del anterior plan de acción.
• Cada persona expone “3 cosas que han funcionado bien” y “3 cosas a mejorar”.

41. Sprint Retrospective
• El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint)
• Acciones ya implementadas del anterior plan de acción.
• Cada persona expone “3 cosas que han funcionado bien” y “3 cosas a mejorar”.
• De la lista completa, cada persona reparte 3 a cada lista.

42. Sprint Retrospective
• El SM presenta los KPIs del Sprint. (Ha sido o no ha sido un buen sprint)
• Acciones ya implementadas del anterior plan de acción.
• Cada persona expone “3 cosas que han funcionado bien” y “3 cosas a mejorar”.
• De la lista completa, cada persona reparte 3 a cada lista.
• De lo más votado a mejorar, se propondrá un plan de acción y un responsable
que lo llevará a cabo.