Introducción a SCRUM. Descubre los principales aspectos que definen este marco de trabajo ágil

1. Introducción al
desarrollo ágil
SCRUM

2. Alguna
experiencia ágil?
Has podido implantar algún aspecto
ágil en vuestro trabajo?

3. Que es
“agilidad”?
Las necesidades se formulan desde la
perspectiva de la adaptación, y no de
la anticipación (predicción)

4. Predictivo vs Adaptativo
• Predictiva: consiste en resolver todas las incertidumbres
antes de empezar el proyecto o en la fase inicial de éste. El
resultado de esto es una «hoja de ruta» (también se conoce
como contrato) que marca la construcción del producto
objeto del proyecto
• Adaptativa: consiste en proporcionar una primea versión
del producto del proyecto útil aunque inacabada, e ir
perfeccionando el producto en sucesivas iteraciones, hasta
llegar a un nivel de funcionalidad tal que permita dar por
finalizado el proyecto

5. Organización "improvisación"
Las personas por encima de los procedimientos y las herramientas
Organización "disciplinada"
Las personas se coordinan mediante procedimientos y herramientas
Síntesis
Los procedimientos evolucionan y se especializan. Las personas no solo "ejecutan"
sinó que aportan y cuidan el conocimiento de la organización
Organización ágil​
Se aplican métodos ágiles en
organizaciones con voluntad de
evolucionar sus procedimientos de
trabajo
Campana de Gauss de les organitzacions àgils?
•Improvisación

6. Que es SCRUM?
Ikujiro Nonaka e Hirotaka Takeuchi
Empresas de manufactura y equipos
The New New Product Development Game, (1986)
Ken Schwaber y Jeff Sutherland
Adaptación a necesidades de proyectos TIC (1995)

7. SCRUM
Definido por Hirotaka Takeuchi y
Ikujiro Nonaka en 1986 como
aproximación al desarrollo de
productos de forma general, haciendo
énfasis en la rapidez y la flexibilidad
Fomento de equipos con talento, autoorganitzados y motivados
The New New Product Development Game (1986)

8. Origen de la palabra “SCRUM”
Hirotaka Takeuchi y Ikujiro Nonaka comparan el trabajo en
equipo en empresas de manufactura con la formación de los
jugadores de rugby. Y en su análisis proponen una técnica que
fomenta la motivación, la autoorganización y el talento
Que es una melé?
• Un grupo de personas que
trabajan en equipo
• Están autoorganizados
• Están enfocados
• Tienen coraje

9. Agile Manifesto
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
Manifiesto para el desarrollo ágil de software
Estamos poniendo al descubierto mejores formas de desarrollar software
Haciendolo y ayudando a otros a hacerlo. Mediante este trabajo hemos acabado
valorando:
Individuos e interacciones per encima de procesos y herramientas
Software que funciona por encima de documentación exhaustiva
Colaboración con el cliente por encima de negociación de contratos
Respuesta al cambio por encima de ceñirse a una planificación
Es decir, aunque elementos de la derecha tienen valor,
nosotros valoramos mas los de la izquierda.

10. Agile Manifesto
Individuos e interacciones por
encima de procesos y herramientas

11. Agile Manifesto
Individuos e interacciones por
encima de procesos y herramientas
Comunicación
La comunicación efectiva es más
importante que los procesos,
metodologias, pautas, herramientas….

12. Agile Manifesto
Software que funciona por
encima de documentación exhaustiva

13. Agile Manifesto
Software que funciona por
encima de documentación exhaustiva
Resultados
Los resultados son lo que hace que las
empresas funcionen, y no el proceso, (sin
menosprecio a su utilidad)

14. Agile Manifesto
Colaboración con el cliente por
encima de negociación de contratos

15. Agile Manifesto
Colaboración con el cliente por
encima de negociación de contratos
Entendimiento
Para que un proyecto llegue a buen fin es mas
importante una colaboración estrecha que
garantice resultados que un contrato

16. Agile Manifesto
Respuesta al cambio por encima
de ceñirse a una planificación

17. Agile Manifesto
Respuesta al cambio por encima
de ceñirse a una planificación
Adaptación
La adaptación es la clave de la respuesta
ante nuevas necesidades y cambios

18. Agile Manifesto
Martin Fowler
UK, 1963
Especialidad en análisis y diseño en POO
UML
Patrones de diseño
Metodologías ágiles: XP

19. Agile Manifesto
Robert Cecil Martin
EEUU, 1952
Ingeniero de software
Muy especializado en técnicas ágiles de
programación, UML y patrones de diseño

20. Agile Manifesto
Jim Highsmith
EEUU, 1945
Especialidad en metodologías de desarrollo
de software
Creador de ASD (1999): Adaptive Software
Development, (Jim Highsmith I Sam Bayer)
Creador de un modelo en contraposición al
proceso tradicional en cascada, basado en
la colaboración

21. Agile Manifesto
Kent Beck
EEUU, 1961
Ingeniero de software
Tarjetas CRC
Pruebas Unitarias jUnit
Creador de eXtreme Porgramming, (XP) y
de Test-Driven Development (TDD)

22. XP Programming
XP es una de las técnicas de programación
ágil mas conocidas y mas maltratadas de
todos los tiempos
En esencia transmite los mismos principios
que SCRUM:
- Simplicidad
- Comunicación
- Realimentación
- Coraje
- Respeto
SCRUM = Gestión
XP = Buenas prácticas en el
desarrollo
Normas del XP Programming:
- Desarrollo iterativo e incremental
- Pruebas unitarias continuas
- Programació en parejas
- Integración del equipo con el cliente
- Corrección de todos los errores SIEMPRE
- Refactorización de código SIEMPRE
- Propiedad del código compartida
- Simplicidad del código

23. Agile Manifesto
Ken Shwaber i Jeff Sutherland
Ken Shwaber: EEUU, 1945
Jeff Sutherland: EEUU, ????
Desarrolladores de software
Adaptación de SCRUM y principios ágiles
(1995) de la versión original (1986)

24. Principios de SCRUM

25. Principios de SCRUM
• Satisfacción del cliente
• Receptividad ante el cambio de requerimientos
• Trabajo enfocado al producto o servicio
• Desarrollo sostenible
• Cooperación diaria y abierta entre negocio y desarrolladores
• Comunicación directa persona a persona
• Individuos motivados frente individuos dirigidos
• Orientación a la excelencia
• Simplicidad
• Equipos auto-organizados
• Adaptabilidad

26. Principios de SCRUM
Satisfacción del cliente
El objetivo último es la satisfacción del cliente. El cliente ha de obtener lo que
desea y ha de sentir que el producto que le proporcionamos es útil

27. Principios de SCRUM
Receptividad ante el cambio de
requerimientos
Los proyectos no son estáticos. Cambian cada día. Nuestro trabajo diario ha de
dar espacio a asumir este hecho

28. Principios de SCRUM
Trabajo enfocado al producto o servicio
La finalidad es la creación de un producte útil, por encima del método utilizado

29. Principios de SCRUM
Desarrollo sostenible
Capaz de mantener un ritmo que permita aplicar SCRUM

30. Principios de SCRUM
Cooperación diaria y abierta entre negocio y
desarrolladores
Todos los participantes en la creación del producto han de estar en contacto sin
trabas. La información ha de fluir

31. Principios de SCRUM
Comunicación directa persona a persona
La comunicación cara a cara por encima de otros medios de comunicación. La
comunicación cara a cara, si hay compromiso por todas las partes, favorece la
adopción de responsabilidades

32. Principios de SCRUM
Individuos motivados frente a individuos
dirigidos
Los participantes en la creación del producto han de sentirse parte de un equipo,
y han de sentirse cómodos en su trabajo

33. Principios de SCRUM
Orientación a la excelencia
El objetivo no es crear producto “porque si”. El objetivo es crear producto
incremental que mejora en calidad cada día

34. Principios de SCRUM
Simplicidad
Hacer sólo lo que es necesario. No reinventar la rueda. No adalantarse a posibles
necesidades que no han sido solicitadas. Si se detecta una necesidad útil no
solicitada es necesario comunicarlo antes de tomar la decisión unilateral de
construirla

35. Principios de SCRUM
Equipos auto-organizados
El equipo es capaz de hacer el trabajo que se le pide. Les personas
individualmente a lo mejor no, pero el trabajo es del equipo, no de las personas.
El equipo se organiza de forma que pueda asumir todos los aspectos que
comporta ejecutar el trabajo

36. Principios de SCRUM
Adaptabilidad
Los proyectos cambian. Es necesario adaptarse a este cambio y hacer propuestas
que adapten el proyecto a la nueva situación. La adaptabilidad sólo es posible si el
equipo es adaptable

37. Valores de SCRUM

38. Valores de SCRUM
Compromiso, (commitment): Para trabajar en equipo es necesario un alto grado
de compromiso
Enfoque, (focus): Dividir el problema en partes mas pequeñas que nos permitan
concentrarnos en la resolución de un único problema asumible para el equipo.
Organización abierta, (Openness): De forma continua expresemos con el equipo
como nos encontramos y que estamos haciendo para trabajar en equipo.
Aprendemos de los demás. Pedimos ayuda. Ofrecemos ayuda.
Respeto: Con el compromiso y el trabajo en equipo llegamos a respetar nuestro
trabajo y el trabajo de los demás
Coraje: El trabajo en equipo y el respeto nos da el que necesitamos para afrontar
los retos de proyectos complejos e inciertos

39. Los SCRUM no ...
1. Aplicar SCRUM no es prescindir de la documentación (doc
profesional, enfocada a esquema, modelo e iterativa)
2. Aplicar SCRUM no significa prescindir de definir el alcance
antes de iniciar el proyecto
3. Aplicar SCRUM no significa prescindir de las
comunicaciones formales, (siguen siendo útiles actos y
documentación de acuerdos)
4. Adaptarse al cambio no significa resistirse al cambio con
procedimientos o con herramientas
5. Colaborar con el cliente no es “si a todo”

40. SCRUM no es una
metodología
Es un marco de trabajo (framework)
Para poder decir que haces SCRUM, como mínimo has de cumplir:
(Transparencia, Inspección, adaptación y Mejora continua) + (Daily Meeting, Time Box, Sprint)

42. Proyecto

43. Proyecto
complejo, incierto,
cambiante

44. Proyecto
• Acotado en el tiempo Datos, objetivos y decisiones
• Controlado en recursos No sólo los económicos
• Definido en el alcance Objetivos claros

45. SCRUM no da una definición
de Proyecto

46. SCRUM no da una definición
de Proyecto
Por encima del “plan” está el producto

47. SCRUM está basado en la teoría
del control de procesos empíricos
Wikipèdia: El empirismo es una teoría filosófica que enfatiza el papel de la experiencia, ligada a
la percepción sensorial, en la formación del conocimiento

48. En que se caracteriza el Control de
procesos empíricos?
3 pilares que definen el empirismo:
• Transparencia
• Inspección
• Adaptación
+ concepto de Mejora continua

49. La información “ha de fluir”.
Se ha de hablar “el mismo idioma”
Transparencia
3 pilars
Los aspectos significativos del proceso han de ser conocidos por todos los participantes.
Esto requiere que estos aspectos han de estar definidos mediante un estándar común, de
forma que todos tengan la misma percepción de las características de cada aspecto. (por
ejemplo: definición de “acabado”)

50. (también del proceso mismo)
Inspección
3 pilars
Todo proceso persigue un objetivo. Para la consecución de este objetivo es necesario que
los participantes en el proceso evalúen de forma continua sus resultados y el proceso
mismo, para detectar posibles desviaciones del objetivo lo mas pronto posible
Proyecto Objetivos
Evaluación
continua
Desviaciones
Proyecto = Cazar desviaciones

51. Que hacemos cuando detectamos una desviación? Nos adaptamos
Adaptarse es:
1. Crear un plan para corregir la desviación
2. Cambiar los objetivos afectados
Adaptación
3 pilares
Cuando se detecta una desviación, la respuesta a esta desviación ha de ser la adaptación,
es decir, la adopción de acciones o planes que, o bien ayuden a corregir la desviación, o
bien reconfiguren el objetivo

52. SCRUM es
Mejora continua (actitud)

53. Organizaciones de SCRUM

54. Scrum.org, (https://www.scrum.org/)
Scrum Alliance, (http://www.scrumalliance.org/)
European Scrum, (http://www.europeanscrum.org/)
ScrumManager, (www.scrummanager.net)

55. Organización de SCRUM

56. Organización de SCRUM

57. Organización de SCRUM
Modelo tradicional, (cascada) SCRUM
- Predictivo
- Relay race, (carrera de relevos)
- Organización jerárquica
- Departamental
- Objetivos completos (cascada)
- Controlado en Tiempo, presupuesto, alcance y
calidad
- Adaptativo
- Holístico . Deporte de equipo
- Aproximación Matricial
- Autogestionado
- Entregas incrementales. Aportación continua de valor
- Controlado en tiempo, presupuesto, alcance, calidad
y expectativas  El cliente colabora

58. Roles, artefactos, actividades
• Personas
• Herramientas
• Flujo

59. Roles, artefactos, actividades
Product Owner
Scrum Master
Stakeholders
Development Team

60. Roles de SCRUM
Presentación de
los roles
Scrum Team

61. Roles, artefactos, actividades
Scrum Board GraphsLists
Product Backlog
Sprint Backlog
Incidence Backlog
Impediments Backlog
Release Burn-down
Sprint Burn-down

62. Roles, artefactos, actividades
Sprint 0 o First Sprint
Sprint
Sprint Planning, (planificación del Sprint)
Daily Scrum Meeting, (reunión diaria)
Sprint Review, (Revisión del Sprint)
Sprint Retrospective, (Retrospectiva del Sprint)
Refinement / Grooming, (Refinamiento)

63. Artefactos de SCRUM
Presentación

64. Artefactos SCRUM
• Product Backlog
Lista de User Stories
Sólo uno
Responsable: PO

65. Artefactos SCRUM
• Sprint Backlog
Lista de User Stories del Sprint
Se puede tocar?
Divisible en tareas?
Las tareas estimadas en que?
Responsable: DT y el SM

66. Artefactos SCRUM
• Impedimentos, incidencias y
bloqueos
Lista de problemas, que se han de registrar y que
afectan a la ejecución de una tarea y, por tanto, del
sprint

67. Artefactos SCRUM
• Impedimentos, incidencias y bloqueos
• Impediment Backlog (proceso): Lista de problemas, que sirven como registro para
que el Scrum Master pueda buscar soluciones
• Incidence Backlog (tareas): La Incidence Backlog es una lista de problemas
detectados a nivel de tarea para un Sprint. Cualquier cambio no previsto sobre una
tarea se anota en esta lista, para ser tratada en la reunión de Sprint Retrospective.
• Parking Backlog (bloqueos): El Parking Backlog es la lista de tareas que se
encuentran “bloqueadas” en un Sprint. Una tarea puede estar bloqueada porqué se
ha detectado algún problema que impide acabarla, o bien porqué se está a la espera
de un resultado intermedio, etc.

68. Artefactos SCRUM
• Impediment backlog
Problemas que se caracterizan por la “sorpresa” y
requerieren adaptación
Quien informa de los problemas?
Ejemplos?

69. Artefactos SCRUM
• Incidence Backlog
Se caracterizan por representar un “retraso” y que
puede resolverse por el equipo
Quien informa?
Ejemplos?

70. Artefactos SCRUM
• Parking Backlog
Se caracterizan por un “bloqueo” sobre una tarea y
que ha de resolverse en el tiempo del sprint
Quien informa?
Ejemplos?

71. Artefactos SCRUM Scrum Board

72. Roles de SCRUM
Presentación de
los roles
Scrum Team

73. Roles - Product Owner

74. Enlace entre el cliente y el equipo de desarrollo.
Enfocado a negocio o a TIC.
• Da soporte para resolver cualquier cuestión funcional o impedimento
• Estrategia. Conoce el “negocio”
• Define los objetivos
• Mantiene el Product Backlog
• Negocia el alcance con el cliente
• Define consensuadamente los criterios de aceptación del proyecto y de cada sprint
• Mantiene el presupuesto
Roles - Product Owner
Donde participa:
Lo veremos mas tarde
De que es responsable:
Lo veremos mas tarde

75. Roles - Scrum Master

76. Roles - Scrum Master
El Scrum Master NO es el Project Manager.
Es el enlace entre el DT y el PO
• Es un coach/mentor para los componentes del Development Team, (DT)
• Proporciona soporte al DT y resuelve los problemas
• Modera las reuniones de que es responsable
• Reporta, archiva y lleva registro
• Propone, promueve y potencia mejoras sobre el proceso y sobre el Scrum Team
Donde participa:
Lo veremos mas tarde
De que es responsable:
Lo veremos mas tarde

77. Roles
Development Team

78. Roles
Development Team
Entre 3 y 9 personas, sin contar el PO ni el SM
Todos los componentes del equipo deberían estar en
contacto directo entre ellos y con el SM
• Es flexible
• Está auto-organitzado
• Es multidisciplinar
Donde participa:
Lo veremos mas tarde
De que es responsable:
Lo veremos mas tarde
És un equipo!!! No un grupo de trabajo

79. StakeHolders
Product
Owner
Scrum
Master
Development
team
Roles: Direccionalidad de las comunicaciones

80. User Stories y Planning Poker

81. User Stories
Las User Stories son fichas que explican el
detalle funcional de cada ítem del Product
Backlog
Incluyen información descriptiva
Prioridad
Criterios de aceptación
“Peso” en forma de Story Points

82. User Stories
Definición
Las User Stories han de ser INVEST
- Independent
- Negotiable
- Valuable
- Estimable
- Sized appropiatelly
- Testable

83. Story Points
Un Story Point es la forma de consensuar el
esfuerzo para construir una funcionalidad dada

84. Planning Poker
• Para una história de usuario dada, se expomen sus
características y toda la información necesaria para
poder dar una valoración, (incluyendo los criterios de
aceptación). Una vez hecha la exposición, cada
miembro del equipo la puntúa. El objetivo de éste
método de valoración es doble
1. Consenso
2. Imparcialidad
• Si pero... Que representa en esfuerzo 1 Story Point?

85. Scrum Board
En el Scrum Board se muestra:
• Las User Stories del Sprint: Las User Stories se colocan en orden de prioridad,
(a la parte superior las mas prioritàrias), para que el equipo conozca con un simple
vistazo la importancia de cada tarea.
• Las tareas de cada User Story y su situación
• Las listas de incidencias, impedimentos y Parking Backlog
Las tareas son Post-its que se mueven en el Scrum Board
Cada tarea, (post-it), tiene una estimación inicial y el nombre de la persona que se
responsabiliza en cada momento. Si la estimación varia, se ha de anotar al post-it,yi
si la desviación es grave se ha de registrar una incidencia

86. Scrum Board - KANBAN
El Scrum Board es una variante de KANBAN
El término KANBAN fue empleado por Taiichi Onho (Toyota) para definir un sistema de
visualización de tareas en un escenario de cadena de montaje
La comunidad Scrum (no Scrum oficial) lo ha adaptado para el uso en proyectos TIC
El objetivo de KANBAN es:
- Entregar a tiempo
- Evitar cuellos de botella
- Informar del estado
Operativa con KANBAN
- No existe el concepto de Sprint ni de iteración
- No hay roles
- Limita el WIP por estado de flujo
Que es el WIP?
El WIP es una técnica para limitar el
trabajo concurrente en un estado de
flujo concreto. De esta forma se guía
al equipo de trabajo a resolver los
cuellos de botella en cuanto se
producen

87. Scrum Board – KANBAN – Muda/Mura y Muri
Muda / Mura y Muri son 3 variables que nos ayudan a governar el flujo en un tablero KANBAN.
Muda (Desperdicio):
La muda es la merma de tiempo producto de acciones que no tienen que ver
directamente con el proyecto (por ej: burocrácia), o decisiones que enlentecen el
curso del proyecto (por ej: desarrollos no encargados)
Mura (Discrepáncia):
Tiempos muertos. Debido a factores como:
- Secuencia de ejecución de acciones
- Alto grado de especialización del equipo de desarrollo
Muri (Tensión):
Cuellos de botella. Mitigable mediante la aplicación del WIP a nivel de estado de
flujo

88. Scrum Board
Columnas del tablero:
- To Do, (Pendiente)
- In Process
- Acabado
Quien es responsable: El
Scrum Master controla el
Scrum Board con la
colaboración de todo el DT.
Además, el Scrum Master
puede cambiar el Scrum
Board en tiempo real, (fuera
de las Daily Meeting), para
adaptarse a cambios,
reasignar tareas, atender
peticiones del DT si acaba
tareas antes de hora, etc.

89. Scrum Board

90. Ya tenemos las User Stories y el Scrum Board
Com desacemos las user stories en tareas?
Las tareas son “post-its” que circulan por el Scrum Board.
Son el verdadero “trabajo”
Han de cumplir los criterios de SMART:
- Specific: Describen una acción acotada
- Measurable: Se pueden pesar en horas o jornadas de trabajo
- Achievable: Son realistas. Pueden ejecutarse de la forma descrita
- Relevant: Describen una acción que aporta valor
- Time-boxed: Se pueden acabar en el tiempo comprometido

91. Actividades SCRUM
En detalle

92. Sprint 0
Preparatoria
Sprint 1
Sprint n
Sprint
planning
2 horas
Retrospectiva
2 horas
Revisión
1 hora 
Sprint
5 dias
Reunión diaria
Reunión con el cliente / Refinamiento
 Aprovación
Release
Actividades de SCRUM

93. Time Box
Actividad Time Box
Sprint 0 No hay un límite establecido para esta fase. Dependerá del tiempo
disponible para lanzar el proyecto, o las fechas para la entrega de un
prototipo, etc.
Sprint Planning Un máximo de 8h para Sprints de un mes. Siendo proporcional para
Sprints inferiores
Daily meeting En ningún caso mas de 15 minutos
Sprint Review Un máximo de 4h para Sprints de un mes. Siendo proporcional para
Sprints inferiores
Sprint Retrospective Un máximo de 3h para Sprints de un mes. Siendo proporcional para
Sprints inferiores
Grooming Se recomienda un tiempo global de entre el 5% y 10% del Sprint.

94. Actividades de
SCRUM - Sprint Planning
Sprint
planning
RetrospectivaRevisiónSprint

95. Actividades de
SCRUM - Sprint Planning
Para que sirve?
1. Para planificar en detalle el Sprint
2. Para recoger la funcionalidad a
desarrollar
3. Para aclarar dudas
4. Para crear las User Stories
5. Para determinar los criterios de
aceptación del Sprint y de cada User
Story
6. Para separar el User Story en tareas
y determinar el esfuerzo de cada
tarea
Que se necesita?
• User Stories valoradas
• Product Backlog detallado
suficientemente
Que pasa después?
• Tareas valoradas
• Daily Meeting
Sprint
planning
RetrospectivaRevisiónSprint

96. Actividades de
SCRUM - Daily Meeting
Sprint
planning
RetrospectivaRevisiónSprint

97. Actividades de
SCRUM - Daily Meeting
Para que sirve?
1. Para explicarse
2. Para hacer seguimiento del estado a
nivel de tarea
3. Para determinar que tareas hace
cada persona en ese momento
4. Para resolver dudas
Que se necesita?
• Todos los participantes hablan
• Duración máxima: 15 minutos
• Siempre en el mismo sitio
• Siempre a la misma hora
• Obligatorio para el DT
• Voluntario para el SM
• El PO sólo si se le invita
Sprint
planning
RetrospectivaRevisiónSprint

98. Actividades de
SCRUM - Sprint Review
Sprint
planning
RetrospectivaRevisiónSprint

99. Actividades de
SCRUM - Sprint Review
Para que sirve?
(Parte 1)
1. Para mostrar al PO el
resultado/situación final del Sprint
(Parte 2)
1. Para mostrar al usuario/cliente el
incremento de producto
2. Obtener aceptación
Que se necesita?
• Se ha de explicar al usuario los
objetivos del Sprint
• Incluir siempre algún comentario útil
• Se ha de realizar Demo
Que pasa después?
• Sprint Retrospective
• La aceptación lanza el siguiente Sprint
Sprint
planning
RetrospectivaRevisiónSprint

100. Actividades de
SCRUM - Sprint Retrospective
Sprint
planning
RetrospectivaRevisiónSprint

101. Actividades de
SCRUM - Sprint Retrospective
Pera que sirve?
1. Para debatir entre SM y DT sobre el curso
del Sprint
2. Revisar incidentes y bloqueos
3. Para buscar soluciones
4. Para aplicar la mejora continua
Que se necesita?
• Es la aplicación de la mejora continua
Que pasa después?
• Se intentan aplicar las mejoras acordadas en
el siguiente Sprint
Sprint
planning
RetrospectivaRevisiónSprint

102. Actividades de
SCRUM - Sprint Retrospective
Sprint
planning
RetrospectivaRevisiónSprint

103. Relación entre
actividades y roles

104. Relación entre
Actividades y roles
DT SM PO Stakeholder
Sprint 0 Opcional Sí Sí Opcional
Sprint Planning Sí Sí
En la definición de lo
que se hará
Daily meeting Sí Opcional Sólo si es invitado
Sprint Review Recomendable Sí Sí
Sólo a la 2ª parte de
la reunión, donde se
hace demo y se pide
aceptación
Sprint Retrospective Sí Sí Sólo si es invitado
Grooming Opcional Sí Sí Opcional

105. Donde participa:
- Sprint 0
- Sprint Planning (definición de los objetivos)
- Sprint Review
- Sprint Retrospective si se le invita
- Grooming que pida o donde sea invitado
De que es responsable:
- Del Product Backlog
- Del gráfico Release Burn-down
Recomendaciones/Restriccions: El PO no puede
ser a la vez el Scrum Master.
Enlace entre el cliente y el equipo de desarrollo
Enfocado a negocio o a TIC.
• Da soporte para resolver cualquier cuestión funcional o impedimento
• Estrategia. Conoce el “negocio”
• Define los objectivos
• Mantiene el Product Backlog
• Negocia el alcance con el cliente
• Define consensuadamente los criterios de aceptación del proyecto y de cada sprint
• Mantienne el presuposto
Roles - Product Owner

106. Roles - Scrum Master
El Scrum Master NO es el Project Manager.
Es el enlace entre el DT y el PO
• Es un coach/mentor para los componentes del Development Team, (DT)
• Proporciona soporte al DT y resuelve los problemas
• Reporta, archiva y lleva registro
• Propone, promueve y potencia mejoras sobre el proceso y sobre el Scrum Team
Donde participa:
- Sprint 0
- Sprint Planning
- Opcionalmente en los Daily Meetings
- Sprint Review y Sprint Retrospective
- A las reuniones de Grooming que pida y a las que
sea invitado
De que es responsable:
- Del Sprint Backlog junto con el DT
- Del Scrum Board junto con el DT
- Del gráfico Sprint Burn-down
- Del Incident Backlog y del Impediment Backlog
- De coordinar la reunión de Scrum Retrospective

107. Roles
Development Team
Entre 3 y 9 personas, sin contar el PO ni el SM
Todos los componentes del equipo deberían estar en
contacto directo entre ellos y con el SM
• Es flexible
• Està auto-organitzado
• Es multidisciplinar
Donde participa:
- Sprint Planning
- Daily Meeting
- Opcionalment al Sprint Review
- Sprint Retrospective
- A las reuniones de grooming
donde sea invitado
De que es responsable:
- Determinar el detalle de cada funcionalidad descrita al Product Backlog, y hacer la
subdivisión en tareas
- Estimación del esfuerzo, en Story Points al Product Backlog, y en horas a cada tarea
- Gestionar el Sprint Backlog
- Proporcionar producto “acabado”. Convenientemente testejado, siguiendo los criterios de
aceptación marcados.
- Ejecutar diariamente el Daily meeting y cumplir sus normas

108. Los gráficos de SCRUM
En detalle

109. Artefactos SCRUM Graphs

110. Artefactos SCRUM Release Burn Down
Exemples de desviacions en el Release Burn-down a tenir en compte:
Relea se Burn-down
0
20
40
60
80
100
120
S
p
rin
t
1
S
p
rin
t
2
S
p
rin
t
3
S
p
rin
t
4
S
p
rin
t
5
S
p
rin
t
6
S
p
rin
t
7
Sprints
StoryPoints
L’equip va molt ràpid. Sobren Sprints
Release Burn-down
0
20
40
60
80
100
120
Sprint
1
Sprint
2
Sprint
3
Sprint
4
Sprint
5
Sprint
6
Sprint
7
Sprints
StoryPoints
L’equip va molt lent. Falten Sprints o a l’equio
li passa alguna cosa

111. Artefactos SCRUM Sprint Burn Down
Exemples de desviacions en el Sprint Burn-down a tenir en compte:
Sprint Burn-down
0
20
40
60
80
100
120
Dia 1 Dia 2 Dia 3 Dia 4 Dia 5
Dies
HoresLes tasques assignades al Sprint s’estan
resolent molt ràpidament. L’equip va fer una
estimació “pessimista”. Probablement no s’ha
triat el nombre suficient d’items del Product
Backlog. Caldria afegir-ne més
Sprint Burn-down
0
20
40
60
80
100
120
Dia 1 Dia 2 Dia 3 Dia 4 Dia 5
Dies
Hores
Les tasques s’estan resolent molt lentament.
L’equip va fer una estimació “optimista”. Cal
renegociar el Sprint amb el PO. Cal treure
tasques
El gráfico de Sprint Burn-
down muestra en todo
momento re “trabajo
pendiente”, y permite ver la
velocidad a la que se
resuelven las funcionalidades
comprometidas en el sprint.
Para cada día de iteración el
SM incorpora el total de
horas de tareas en las
diferentes columnas de
trabajo pendiente o en curso
Usualmente el gráfico se actualiza después de llevar a cabo la reunión diária

112. Otros conceptos avanzados
de SCRUM

113. Themes, Epics, User Stories y Tareas
Theme
Corresponde a un gran apartado funcional del proyecto. Un módulo, una sección con valor por si
misma. Susceptible de disponer de su propio Product Backlog (por ej: un módulo de gestión de RRHH)
Epic
Una historia de usuario susceptible de ser dividida (una “superhistòoria”). Describe una necesidad
grande que conforma un submódulo (por ej: el corrector ortográfico de word)
User Story
Una necesidad susceptible de ser construida en el ámbito de un Sprint
Tarea
Las User Stories se subdividen en tareas durante el Sprint Planning. Una tarea es na acción que puede
ser ejecutada por una o pocas personas. Es la unidad mínima para poder asignar trabajo a personas y
hacer seguimiento de la ejecución

114. Datos básicos de una User Story
Nombre
Nombre descriptivo y corto que define la User Story en una frase
Descripción
Pequeña descripción que complementa el nombre. En la forma
Como [rol] quiero [objetivo] para poder [resultado]
Story Points (estimación)
Valoración en esfuerzo
Prioridad
Prioridad (governada por el PO)
Criterios de aceptación
Criterios que es necesario examinar para dar la història por terminada

115. User Stories
Priorización
El PO es el responsable de priorizar
Técnica MoSCoW de priorización, que clasifica las User
Stories en 4 categorias:
• M - MUST HAVE (es necesario)
• S - SHOULD HAVE (es recomendable)
• C - COULD HAVE (podría implementarse)
• W - WON'T HAVE (no lo queremos... quizá en un
futuro)

116. User Stories
Criterios de validación
Son muy importantes en SCRUM
Porqué? Porque ayuda a determinar si se ha
alcanzado el concepto de “acabado” para la
User Story
Como escribir los criterios de validación?
SCENARIO Tenemos un texto en word y queremos pasar el corrector ortográfico
GIVEN Tenemos el texto cargado en Word
AND Lo hemos escrito sin activar el corrector automático
WHEN Ejecutamos el corrector de word
THEN Debería marcar los errores ortográficos

117. User Stories
Cuantas histórias seleccionamos en un Sprint?
Team Velocity
La Team Velocity es la velocidad en la que el equip
resuelve los Sprints, en forma de Story Points
El Scrum Master lleva una estadística de la velocidad y
la refleja en el gráfico de Release Burn-down
Las histórias de un nuevo sprint deberian ser por valor
aproximado del histórico de velocidad del equipo

118. User Stories
Subdividir histórias grandes
Tenemos una história por valor superior a la capacidad. Es
necesario subdividirla. No es lícito en Scrum que una User
Story abarque mas de un Sprint
Posibles estratégias de subdivisión:
- Por reglas de negocio
- Por happy/unhappy flow
- Por parámetros o datos
etc

119. User Stories
Selección de históriea para aportar valor
Premisa de Scrum:
Satisfacción del cliente
“El cliente ha de percibir que siempre le
proporcionamos incrementos útiles”
Hay técnicas para proporcionar al cliente incrementos de producto
que verdaderamente aporten valor. Por ej: Visual Story Mapping

120. Sprint 1
Sprint n
Sprint
planning
2 horas
Retrospectiva
2 horas
Revisión
1 hora 
Sprint
Release
La release
La Release es un convenio con el Product Owner,
por el que es posible entregar producto cada
cierto número de Sprints, dependiendo de la
funcionalidad a construïr

121. Otras técnicas de medición
(no sólo de burn-down vive el hombre)
- Medir no és un fin en si mismo
- Medir es costoso
- Medir se puede confundir con
auditar
- Tngamos siempre presente
“Tiempo ideal” y “Tiempo real”

122. Extendiendo SCRUM
Convivir con
otros
métodos

123. Extendiendo SCRUM
A nivel de producto:
1. Un producto te UN ÚNICO Product
Backlog
2. Un producto puede tener diversos PO.
Cada PO ve una “vista” del product
Backlog
3. Un PO puede gestionar diversos SM
4. Un SM responde sólo a un PO para un
producto
5. Un SM puede tener a su cárgo diversos
DT, y tiene UN ÚNICO Sprint Backlog
6. Un DT tiene UN ÚNICO SM

124. Como aplicar SCRUM?
1. [Tienes 3 a 9] + 2?
2. Separar los proyectos. Entender los requerimientos. Conocer el alcance
3. Establecer ciclos, (sprints)
4. Establecer reuniones diarias
5. Hacer partícipe al equipo y fomentar la comunicación
6. Fomentar la transparencia, la inspección y la adaptación
7. Determinar roles y vías de comunicación con el usuario
Como se si aplico SCRUM?
http://scrumbutt.me/
Se puede decir que haces
SCRUM cuando, como mínimo :
(Transparencia, Inspección,
adaptación y Mejora continua)
+ (Daily Meeting, Time Box,
Sprint)

125. Bibliografia
1. SCRUM y XP desde las trincheras
http://www.proyectalis.com/wp-
content/uploads/2008/02/scrum-y-xp-desde-las-trincheras.pdf
2. SCRUM guide de Scrum.org
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-
CAT.pdf#zoom=100
3. Kanban vs Scrum
https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
3. Implantar SCRUM amb èxit
Editorial UOC
CAT: http://www.editorialuoc.cat/implantar-scrum-amb-exit
ES: http://www.editorialuoc.cat/implantar-scrum-con-exito

126. Gracias
2017, Josep Lluis Monte Galiano
moga@moga.cat
www.moga.cat
www.slideshare.net/jlmoga/introscrumes
www.slideshare.net/jlmoga/introscrumcat
www.moga.cat/agils