Scrum à la PabloExperimentos 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 Manager / Product Owner

Packlink

(2015-2015)

Product Manager / Product Owner

EsLife

Certified Professional Scrum

Master

Scrum.org

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.

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 Team

• Gestionar tareas sprint

• Realizar tareas sprint

Roles

• 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

Daily ScrumDaily Scrum

Sprint

Planning

Daily

Scrum

Grooming

Demo

Retro

Reuniones

Daily ScrumDaily

Scrum

• 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

• 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

• 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

• 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

• 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

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.00Retrospectiva

(45 min)

8.00-9.00

9.00-10.00

Planning (2h)

10.00-11.00

11.00-12.00

12.00-13.00

1. Product Backlog2. Historias de usuario3. Nivel de cariño4. Definition of Done (DoD)5. Sprint Backlog6. Sprint Dashboard7. Evaluación de estimaciones8. Informes

Herramientas

• 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

• 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

Herramientas:: Nivel de cariñoNivel 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 cambieExperimento en una landing informativa

Rollo de verano Media Riesgo medio-alto, tráfico bajo, conocimiento sin

validar, con posibilidades de que cambieExperimento 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

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

• 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

• 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

Herramientas:: Ejemplo de DashboardToDo InProgress Buffer

Peer Review

TestingPre

Ready to upload

TestingProd

Done Blocked

Fuego

Must

ASAP

SPRINT BOARD

FIREFIGHTER BOARD

• 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

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

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

Informes:: Inicio de sprint

• 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

Informes:: Cierre de sprint

• 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

Informes:: Producto

Guías de ScrumGuí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/

Pabgarm (at) Gmail (dot) com

@pabgarm

https://es.linkedin.com/in/pabgarm

¡Gracias!

Para dudas, comentarios, preguntas y/o feedback: