El documento describe un encuentro sobre Scrum, un marco de trabajo para desarrollo ágil que enfatiza la calidad y productividad mediante roles específicos como el Scrum Master y Product Owner. Se explican los elementos clave del proceso, incluyendo el backlog de producto y las historias de usuario. Además, aborda la planificación de sprints y la importancia de la colaboración entre el equipo y los stakeholders.

1. An evening with… Scrum
Arkho Innova Meetup series
August 2017

2. • Un espacio para compartir experiencias y conocimiento
• Un espacio para hacer relaciones entre personas y
equipos con intereses afines
• Un espacio para pasarla bien
Gracias por su asistencia!!!
ARKHO Innova
Meetup series

3. ¿Qué es Scrum?

4. ¿Qué es Scrum?
• Es un framework que especifica el proceso de desarrollo dentro las metodologías ágiles
• Utiliza un paradigma incremental
• Replantea la forma tradicional de desarrollo de software, concentrándonos en los
resultados mas que en la formalidad.
• El objetivo es la calidad y la productividad
• Se definen nuevos roles que en otras metodologías no existen, pero que ayudan a controlar y
llevar a cabo el proceso sin mayores problemas
• Scrum Busca el rápido desarrollo, entrega y corrección (FAIL FAST)

5. Scrum

6. Es un framework o una especificación ?

7. Roles Scrum
SCRUM

8. Scrum Master
• El rol del Scrum Master es llevar al éxito del desarrollo de
cada Sprint. Es como un director o un coach del equipo de
desarrollo
• Entre sus responsabilidades están:
• Liderazgo
• Facilitar que las tareas se cumplan.
• Elimina los obstáculos que se puedan producir en el
proceso
• Ayuda a adoptar y organizar el proceso Scrum

9. Product Owner
• Es el dueño del producto que se va a desarrollar y
dueño del product Backlog
• Entre sus responsabilidades están:
• Conocimiento del dominio de negocio
• Conocimiento del negocio y sus necesidades
• Recopilar las prioridades del negocio para
organizar el product backlog
• Intermediario entre el equipo y los Stakeholders
• Debe tener cierto conocimiento técnico

10. Equipo Scrum
• Encargado de ejecutar los incrementos
planificados dentro del Sprint.
• Ellos son dueños del Sprint Backlog
• Responsabilidades del Equipo:
• Tener un objetivo común
• Buscar la mejor de ejecutar el Sprint
• Avisar oportunamente cualquier problema
que obstaculice el avance del sprint
• Sprint Backlog

11. Stakeholders
• Los Stakeholders son otros roles
que tienen relación con el proceso
pero que no tienen influencia en
su funcionamiento
• Stakeholders son personas que
tienen conocimiento del dominio y
que también se ven beneficiados
del producto que se esta
desarrollando
• Es responsabilidad del Product
Owner la comunicación con ellos
• Producen el Backlog de producto

12. Proceso y Artefactos
SCRUM

13. Sprint

14. Product Backlog
• Pila de requerimientos
• Ordenados por prioridad
• Es único en el proyecto no existe otro.
• El dueño del product Backlog es el product Owner
• Tiene todos los derechos sobre el backlog
• El consumo del backlog se hace a través de grupos
de requerimientos llamados Sprint
• Los requerimientos se generan a través de User
Stories

15. Sprint Backlog
• Es un subconjunto de
requerimientos del Product
backlog
• Son los requerimientos que se van
a ejecutar para producir un
incremento y generar un
producto potencialmente
funcional
• Este subconjunto se ejecuta dentro
de un ciclo llamado Sprint.

16. Sprint Planning
• Se define su duración, la que podría ser de 1 a 4
semanas
• En este punto se definen las historias necesarias desde
el backlog para completar una funcionalidad
potencialmente entregable.
• Se define que funcionalidad se debe completar en
ese periodo de tiempo, y la cual es una pieza
potencialmente productiva.
• Otra actividad que se debe lograr es estimar las
historias en unidades de complejidad, llamadas story
points.

17. Daily Scrum Meeting
Objetivo: Responder 3 simples preguntas:
• ¿Qué hice ayer?
• ¿Qué tareas voy a hacer hoy?
• ¿Qué problemas tengo para resolverlas?

18. Resumen

19. User Stories & Releases
SCRUM

20. User Story
• Es una narración de una necesidad o requerimiento desde el punto de vista de un usuario
• Una historia de usuario no debe estar redactada desde el punto técnico. Debe ser comprensible por parte
de un usuario común y corriente.
• Una buena historia debería cumplir con:
★ Independiente: Evitar la interdependencia de historias
★ Comprobable: las condiciones de satisfacción deben estar presentes
★ Valorable: Es decir tengan valor para el usuario
★ Estimable: Si no se cumple con esta condición quizá estamos frente a una Epic
★ Verificable: En cada entrega del proyecto
https://www.mountaingoatsoftware.com/agile/user-stories

21. Redacción de una historia de Usuario
Según la definición de Mike Cohn:
As a < type of user >, I want < some goal > so that < some reason >.
Interpretación:
Como un <Usuario o Rol>, Quiero <Objetivo> de manera que <Justificación>
EJ:
• Como Cliente quiero poder seleccionar los productos en la pagina para poder comprarlos online
• Como Cliente, quiero pagar mi suscripción mensual vía sitio web por medio de transferencia bancaria
o tarjeta de crédito.
http://www.pmoinformatica.com/2015/05/historias-de-usuario-ejemplos.html

22. Historias Épicas (Epics Stories)
• Son historias grandes, que en su narrativa implican varias funcionalidades que pueden ser descritas en 2 o mas
User Stories.
• Poseen un nivel de detalle muy general y son difíciles de estimar por que podrían tomar mucho tiempo al equipo
• Son difíciles de encontrar por que pueden abarcar varias dimensiones
• Por ser historias con nivel general estas se pueden subdividir en varias historias que cumplan con las
características de una buena historia.
• EJ:
Como Vicepresidente de mercadeo y ventas, quiero revisar el desempeño histórico de las
ventas, para poder identificar las regiones geográficas y productos de mejor desempeño
Esta historia épica se puede subdividir en:
• Como VP de Mercadeo, quiero seleccionar el período de tiempo en el cual realizaré la revisión de las ventas.
• Como VP de Mercadeo, puedo clasificar la información de ventas por región geográfica y productos.

23. Tareas
• Una historia de usuario esta compuesta de una o varias tareas.
• Una tarea es la realización de una actividad concreta para
satisfacer la necesidad que especifica la historia de usuario.
• Para completar un User Story se deben seguir una secuencia de
tareas.
• Las tareas deben ser medibles.

24. Releases
• Definición: Un Release es una entrega de un producto o
incremento funcional totalmente terminado
• Un release puede estar compuesto por uno o varios Sprint
• Tiene una fecha de entrega en la cual el Usuario final
Product Owner y Stakeholders dan revisan y aprueban
la funcionalidad
• Todos los sprint deben planificarse en función del tiempo
comprometido para la entrega del release

25. Relación

26. An evening with … Scrum
Arkho Innova Meetup series
August 2017