Scrum à la Pablo
Experimentos que han funcionado en mis últimos 7 años jugando con Scrum
Autobombo…
(2008-2011)
Program Manager
Microsoft
(2011-2014)
Product Manager /
Product Owner
Softonic
(2015-2015)
Product ...
Lo que viene a continuación ha funcionado con los
equipos con los que he trabajado en el pasado.
Con otros equipos puede q...
1. Roles
2. Reuniones
3. Herramientas
4. Informes
Qué vamos a cubrir
Product Owner
• Product Backlog
• Resolver dudas
Scrum Master
• Ayudar con Scrum
• Ayudar con
impedimentos
Development Tea...
• En equipos pequeños, creo que tiene sentido que el SM sea alguien del dev team,
por la carga de trabajo que conlleva una...
Daily
Scrum
Daily
Scrum
Sprint
Planning
Daily
Scrum
Grooming Demo Retro
Reuniones
Daily
Scrum
Daily
Scrum
• En vez de lunes, he visto que funciona mejor en martes / jueves.
• Mi esquema con mejores resultados:
Fase I: Revisión d...
• 15 minutos.
• Las típicas 3 preguntas (Ayer, Hoy, Impedimentos).
• Sólo cosas relevantes.
• No me vale “Ayer estuve en l...
• 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 labor...
• Sólo se hace demo de historias 100% hechas (según la Definition of Done).
• Las tareas 100% técnicas que pueden sonar a ...
• Después de la Demo.
• Asiste todo el equipo Scrum (PO+SM+Dev Team).
• Se revisan los compromisos de la retro anterior.
•...
Reuniones:: Ejemplo de calendario
Sprint de 1
semana
Lunes Martes Miércoles Jueves Viernes
Daily Scrum (15 min) Daily Scru...
1. Product Backlog
2. Historias de usuario
3. Nivel de cariño
4. Definition of Done (DoD)
5. Sprint Backlog
6. Sprint Dash...
• Sólo lo actualiza el Product Owner.
• Aunque las estimaciones únicamente las proporciona el Dev Team.
• Contiene todo en...
• Título: Título descriptivo-
• Descripción: Siguiendo el formato Como… Quiero…Para…
• El Como… es desde el punto de vista...
Herramientas:: Nivel de cariño
Nivel de
cariño
Calidad
de código
Explicación Ejemplo (Amazon)
Rollete de
una noche
Baja
Ba...
• Definición global de qué significa que algo está hecho.
• Una historia no está terminada si no se satisfacen todas las
c...
• Historias/ítems del Product Backlog que se harán en el sprint.
• Se cierra al final del sprint planning.
• Todas las his...
• Refleja el estado de todas las historias/tareas/bugs del sprint.
• Permite ver si hay algún “problema” en función de la ...
Herramientas:: Ejemplo de Dashboard
ToDo InProgress Buffer
Peer
Review
Testing
Pre
Ready to
upload
Testing
Prod
Done Block...
• Tabla junto al dashboard con todas las tareas y sus estimaciones
iniciales.
• Cuando una tarea se pasa a Done, se añade ...
Para mejorar la visibilidad del avance del producto podemos usar:
• Sprint Burn-up/Burn-down: Gráfico que monitoriza el pr...
Informes:: Burn-up / Burn-down
http://www.burndowngenerator.com/
• Título del sprint:
• Número de Sprint. Ej. Sprint 1.
• Semanas cubiertas por el sprint. Ej. Sprint 15-16.
• Otros nombre...
Informes:: Inicio de sprint
• Tareas planificadas y terminadas: Tareas inicialmente planificadas
para el sprint que se consideran Done (según la DoD)....
Informes:: Cierre de sprint
• Resumen de épicas/funcionalidades: Resumen del estado de todas
las épicas/nuevas funcionalidades planeadas (normalmente ...
Informes:: Producto
Guías de Scrum
Guía oficial de Scrum
• Ken Schwaber & Jeff Sutherland. Creadores de Scrum
• Link: http://www.scrumguides.o...
Pabgarm (at) Gmail (dot) com
@pabgarm
https://es.linkedin.com/in/pabgarm
¡Gracias!
Para dudas, comentarios, preguntas y/o ...
Próxima SlideShare
Cargando en…5
×

Scrum à la Pablo (Español)

422 visualizaciones

Publicado el

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.

Publicado en: Empresariales

Scrum à la Pablo (Español)

  1. 1. Scrum à la Pablo Experimentos que han funcionado en mis últimos 7 años jugando con Scrum
  2. 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. 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. 4. 1. Roles 2. Reuniones 3. Herramientas 4. Informes Qué vamos a cubrir
  5. 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. 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. 7. Daily Scrum Daily Scrum Sprint Planning Daily Scrum Grooming Demo Retro Reuniones Daily Scrum Daily Scrum
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Informes:: Burn-up / Burn-down http://www.burndowngenerator.com/
  25. 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. 26. Informes:: Inicio de sprint
  27. 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. 28. Informes:: Cierre de sprint
  29. 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. 30. Informes:: Producto
  31. 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. 32. Pabgarm (at) Gmail (dot) com @pabgarm https://es.linkedin.com/in/pabgarm ¡Gracias! Para dudas, comentarios, preguntas y/o feedback:

×