Experimentos que han funcionado en mis últimos 7 años jugando con Scrum en equipos Agile. La presentación cubre 4 pilares de Scrum: - Roles: Product Owner, Scrum Master y Equipo de Desarrollo. - Eventos: Planning Meeting, Daily Stand-up, Grooming/Refinement, Demo y Retrospectiva. - Herramientas: Product Backlog, Historias de usuario, Definition of Done, Sprint Backlog, Sprint Dashboad. - Informes: Fin de Sprint, Inicio de Sprint, Burn-up/Burn-down, Informe de producto.

1. Scrum à la Pablo
Experimentos que han funcionado en mis últimos 7 años jugando con Scrum

2. Autobombo…
(2008-2011)
Program Manager
Microsoft
(2011-2014)
Product Manager /
Product Owner
Softonic
(2015-2015)
Product Manager /
Product Owner
Packlink
(2015-2015)
Product Manager /
Product Owner
EsLife
Certified
Professional Scrum
Master
Scrum.org

3. Lo que viene a continuación ha funcionado con los
equipos con los que he trabajado en el pasado.
Con otros equipos puede que funcione, o no.
Lo mejor es probar.
Si funciona, se queda.
Si no, se descarta y se prueban otras cosas.

4. 1. Roles
2. Reuniones
3. Herramientas
4. Informes
Qué vamos a cubrir

5. Product Owner
• Product Backlog
• Resolver dudas
Scrum Master
• Ayudar con Scrum
• Ayudar con
impedimentos
Development Team
• Gestionar tareas
sprint
• Realizar tareas sprint
Roles

6. • En equipos pequeños, creo que tiene sentido que el SM sea alguien del dev team,
por la carga de trabajo que conlleva una vez el equipo es maduro.
• El SM tiene menos capacidad en el sprint (10%-15%).
• En algunos equipos hemos incluido la figura del Firefighter:
• Es un rol temporal y rotatorio por sprints.
• Bugs urgentes, soporte urgente a otros dptos., etc. durante el sprint.
• Para que el resto del equipo se pueda centrar en las tareas del sprint.
• El firefighter tiene menos capacidad en el sprint (10%-15%).
• Según la teoría, la historia de usuario debería empezarse y terminarse en el
mismo sprint. Normalmente, si hay diseño e implementación, eso es complicado.
En el pasado, la estrategia que mejor ha funcionado es que diseño vaya un sprint
por delante.
Roles:: Adaptaciones

7. Daily
Scrum
Daily
Scrum
Sprint
Planning
Daily
Scrum
Grooming Demo Retro
Reuniones
Daily
Scrum
Daily
Scrum

8. • En vez de lunes, he visto que funciona mejor en martes / jueves.
• Mi esquema con mejores resultados:
Fase I: Revisión de historias
candidatas
• PO + Dev team
• Revisar de historias
candidatas para el sprint
• Resolver dudas del Dev Team
• Unos 15-30 min.
Fase II: Desmenuzar y
estimar
• Dev Team
• Analizar
• Obtener dependencias
• Descomponer en tareas
• Estimar (puntos de historia)
• Unas 3h (sprint de 2
semanas)
Fase III: Cerrar sprint
• PO + Dev team
• Cerrar el sprint backlog con
HU priorizadas
• Definir el goal del Sprint
• Unos 30 min.
Reuniones:: Sprint Planning

9. • 15 minutos.
• Las típicas 3 preguntas (Ayer, Hoy, Impedimentos).
• Sólo cosas relevantes.
• No me vale “Ayer estuve en la reunión de planificación”.
• Sí me vale “Nada relevante” (Aunque no todos los días!).
• Todos prestamos atención.
• Nos pasamos un token.
• Orden aleatorio, pero no vale pasar al compañero adyacente.
• Se actualiza el gráfico del sprint burn-down/burn-up.
Reuniones:: Daily Scrum

10. • No es una reunión “oficial” de Scrum, pero creo que es muy útil.
• PO + algún Dev (como el Lead).
• Un par de días laborables antes del sprint Planning.
• PO y Dev revisan las historias candidatas para asegurarse de que no hay
“agujeros”. Si los hay, el PO tiene tiempo de revisarlo con los stakeholders.
• La idea es que el Dev Team tengan todo lo que necesitan para estimar las
tareas durante el sprint planning.
• No debería durar más de 1h.
Reuniones:: Grooming / Refinement

11. • Sólo se hace demo de historias 100% hechas (según la Definition of Done).
• Las tareas 100% técnicas que pueden sonar a chino a los stakeholders nos
las podemos ahorrar.
• La demo se prepara previamente, no se improvisa con los stakeholders
delante. Si no sale bien, se mina la credibilidad del Dev team.
• Al cierre del sprint, se envía el listado de historias para la Demo a los
stakeholers, para que sepan qué se va a revisar.
• No debería durar más de 1,5h (para sprints de 2 semanas).
Reuniones:: Demo

12. • Después de la Demo.
• Asiste todo el equipo Scrum (PO+SM+Dev Team).
• Se revisan los compromisos de la retro anterior.
• Se resumen los highlights del sprint en 2 categorías:
• Qué ha ido bien
• Qué se puede mejorar
También puede hacerse con | More of | Less of | Keep doing | Start doing | Stop doing |
Idealmente, la información se recopila durante el sprint y se lleva ya preparado.
• Se acuerdan compromisos de mejora para el siguiente sprint (con personas asignadas!).
• Debería durar unas 2h (para un sprint de 2 semanas).
Reuniones:: Retrospectiva

13. Reuniones:: Ejemplo de calendario
Sprint de 1
semana
Lunes Martes Miércoles Jueves Viernes
Daily Scrum (15 min) Daily Scrum (15 min) Daily Scrum (15 min) Daily Scrum (15 min)
13.00-14.00
14.00-15.00
15.00-16.00
Grooming
(30 min) Demo
(1h)
16.00-17.00
Retrospectiva
(45 min)
8.00-9.00
9.00-10.00
Planning
(2h)
10.00-11.00
11.00-12.00
12.00-13.00

14. 1. Product Backlog
2. Historias de usuario
3. Nivel de cariño
4. Definition of Done (DoD)
5. Sprint Backlog
6. Sprint Dashboard
7. Evaluación de estimaciones
8. Informes
Herramientas

15. • Sólo lo actualiza el Product Owner.
• Aunque las estimaciones únicamente las proporciona el Dev Team.
• Contiene todo en lo que se va a trabajar en futuros sprints.
• Historias de usuario, bugs, tickets, etc.
• Las historias han de ser entendibles para una audiencia no técnica.
• Sólo hay 1 product backlog por producto, aunque haya varios equipos Scrum.
• Es un listado priorizado, con un nivel de detalle decreciente. Idealmente, la cima está casi
detallada al 100%.
• En Excel, Google Docs, Trello, Jira u otra herramienta, pero idealmente disponible para
stakeholders y el resto de la organización.
Herramientas:: Product Backlog

16. • Título: Título descriptivo-
• Descripción: Siguiendo el formato Como… Quiero…Para…
• El Como… es desde el punto de vista del usuario final, no del reporter.
• Due date (opcional): Para cuándo tiene que estar listo (si aplica).
• Criterios de aceptación: Aquello que se va a comprobar para decidir si está lista para subir.
• Nivel de cariño: Indica qué nivel de detalle hay que incluir dependiendo de si es algo que se va a
quedar, si es un test o un parche temporal.
• Épica: Grupo de funcionalidades a la que pertenece la historia.
• Reporter: Quién lo ha solicitado, por si hay dudas en el futuro.
• Estimación inicial: Estimación de alto nivel del Dev Team.
Herramientas:: Partes de mis historias de usuario

17. Herramientas:: Nivel de cariño
Nivel de
cariño
Calidad
de código
Explicación Ejemplo (Amazon)
Rollete de
una noche
Baja
Bajo riesgo, tráfico medio, conocimiento sin
validar, con posibilidades de que cambie
Experimento en una landing
informativa
Rollo de
verano
Media
Riesgo medio-alto, tráfico bajo, conocimiento sin
validar, con posibilidades de que cambie
Experimento en el funnel de
compra
Novieta Alta
Riesgo bajo, tráfico bajo-medio, conocimiento
validado, poco probable que cambie
Cambios en el perfil del usuario
Novia formal Muy alta
Crítico, tráfico medio-alto, alto impacto en
usuarios, validado, poco probable que cambie
Integración de una nueva
plataforma de pago
Boda Extrema
Crítico para el funcionamiento del producto,
validado y poco probable que cambie
Tramitación de compra y envío

18. • Definición global de qué significa que algo está hecho.
• Una historia no está terminada si no se satisfacen todas las
condiciones de la DoD.
• Lo definen Dev Team + PO.
Algunos aspectos a considerar:
• ¿Quién tiene que dar el OK? (QA, PO, PO + Stakeholders)
• ¿En qué entorno tiene que estar? (Development, Pre, Staging, Prod)
• ¿Con/Sin unit test?
Herramientas:: Definition of Done (DoD)

19. • Historias/ítems del Product Backlog que se harán en el sprint.
• Se cierra al final del sprint planning.
• Todas las historias están estimadas y divididas en tareas más
pequeñas (también estimadas).
• Queda reflejado en el Sprint dashboard.
• Sólo se pueden añadir tareas “haciendo hueco” (quitando otras).
• El Dev Team se compromete a terminar todo lo que deciden que
entra.
Herramientas:: Sprint Backlog

20. • Refleja el estado de todas las historias/tareas/bugs del sprint.
• Permite ver si hay algún “problema” en función de la distribución de las tareas.
• Idealmente, se trabaja con versión online y física.
• El online se actualiza al momento, en cuanto hay cambios en la tarea.
• El físico se puede actualizar durante el Daily Scrum.
• Los encargados de mantenerlo son el Dev Team.
• Se pueden usar post-it de varios colores para identificar distintos tipos de ítems
(Historias, Tareas, Bugs, Tickets, etc.)
• Se puede usar una sección para imprevistos con | Fuegos | Must | ASAP|
Herramientas:: Sprint Dashboard

21. Herramientas:: Ejemplo de Dashboard
ToDo InProgress Buffer
Peer
Review
Testing
Pre
Ready to
upload
Testing
Prod
Done Blocked
Fuego
Must
ASAP
SPRINT BOARD
FIREFIGHTER BOARD

22. • Tabla junto al dashboard con todas las tareas y sus estimaciones
iniciales.
• Cuando una tarea se pasa a Done, se añade el esfuerzo real invertido.
• Si hay diferencia con la estimación inicial, se anota el motivo.
• Sirve para identificar desviaciones en las estimaciones para aprender
de cara a futuras estimaciones.
• Puede discutirse durante la Retro.
Herramientas:: Evaluación de estimaciones

23. Para mejorar la visibilidad del avance del producto podemos usar:
• Sprint Burn-up/Burn-down: Gráfico que monitoriza el progreso del sprint
con los puntos de historia “quemados”. Se actualiza al final del Daily Scrum.
• Informe de cierre/inicio de sprint: Se envía a todos los stakeholders a final
de sprint e inicio del siguiente con detalles de cómo ha terminado el sprint
y qué se ha planificado para el siguiente.
• Informe de producto: Se envía a todos los stakeholders con detalles sobre
el progreso del producto.
Informes

24. Informes:: Burn-up / Burn-down
http://www.burndowngenerator.com/

25. • Título del sprint:
• Número de Sprint. Ej. Sprint 1.
• Semanas cubiertas por el sprint. Ej. Sprint 15-16.
• Otros nombres: Ej. Planetas de Star Wars, Personajes de los Simpson, etc.
• Objetivo del sprint: Acordado durante el sprint planning.
• Capacidad del sprint: Suma de la capacidad de cada Dev.
• Sprint backlog: Listado de las historias/tareas a realizar durante el sprint.
• Total planificado: Total de puntos de historia planificados .
• Capacidad del sprint: Total de puntos de historia disponibles durante el sprint.
• Buffer disponible: Puntos no planificados de la capacidad.
Informes:: Inicio de sprint

26. Informes:: Inicio de sprint

27. • Tareas planificadas y terminadas: Tareas inicialmente planificadas
para el sprint que se consideran Done (según la DoD).
• Tareas planificadas y no terminadas: Tareas inicialmente planificadas
para el sprint que no se consideran Done.
• Tareas no planificadas y terminadas: Tareas que no se incluyeron en
la planificación inicial pero que se han terminado en el sprint.
• Resumen: Resumen de la capacidad, los puntos de historia
planificados, los terminados y los no planificados.
Informes:: Cierre de sprint

28. Informes:: Cierre de sprint

29. • Resumen de épicas/funcionalidades: Resumen del estado de todas
las épicas/nuevas funcionalidades planeadas (normalmente por
trimestre).
• Evolución del equipo de Scrum: Evolución del rendimiento del equipo
Scrum en cuanto a cumplimiento de puntos de historia.
Informes:: Producto

30. Informes:: Producto

31. Guías de Scrum
Guía oficial de Scrum
• Ken Schwaber & Jeff Sutherland. Creadores de Scrum
• Link: http://www.scrumguides.org/
The Scrum Master Training Manual
• Nader K. Rad, Frank Turley. Management Plaza
• Link: http://mplaza.pm/product/scrum-master-training-manual/

32. Pabgarm (at) Gmail (dot) com
@pabgarm
https://es.linkedin.com/in/pabgarm
¡Gracias!
Para dudas, comentarios, preguntas y/o feedback: