Este documento describe cómo integrar la analítica dentro de metodologías ágiles como Scrum para mejorar la toma de decisiones en los proyectos. Explica los principios y eventos de Scrum, incluyendo roles como el Product Owner y Scrum Master. También describe los roles del analista y cómo pueden contribuir en cada evento de Scrum, compartiendo información que ayude a priorizar tareas y tomar mejores decisiones. El objetivo es establecer una cultura analítica que utilice datos para la mejora continua de procesos.

2. Conseguir el
mayor impacto
mediante la
información
Integrar la analítica dentro
de metodologías Scrum

3. Analítica dentro de
metodologías Scrum
Objetivos
Mejorar la eficiencia de
procesos mediante
procesos ágiles, tomando
las mejores decisiones para
el negocio.
 Entender y analizar la
importancia de interpretar
la información en la toma
de decisiones.
Dirigido a
Profesionales que se dediquen
a la mejora de procesos.
Analistas de negocio que
trabajen de forma cross
funcional con diferentes áreas.
Gestores de proyectos que
necesiten integrar el análisis de
datos en la toma de decisiones.
Gestores de proyectos que
necesiten integrar la analítica en
el governance de un
departamento/área.

4. Metodologías
Tradicionales VS Ágiles
Comparativa de métodos de gestión de proyectos

5. Cómo trabajamos…
En las organizaciones las tareas están divididas
funcionalmente.
El trabajo interno tiene una manera secuencial que
ordena las tareas, y las asigna dependiendo de los
roles.
Se tienen acuerdos definidos, o se crean acuerdos
internos que dan responsabilidades.
1
2
3

6. Gestión de Proyectos forma tradicional …
Requerimientos Análisis y diseño Implementación Testeo Mantenimiento

7. Pero qué problemas tenemos…
Planificación muy estricta.
El cliente no ve el producto hasta la entrega final.
Se trabaja sobre una versión hasta la solución final y
hasta la fase final no se testea.
El equipo no tiene la visión completa del proyecto.
Avanzamos sin tener información suficiente.

8. Profesional
Puesto
Rol
Formación
Cómo nos comportamos en el trabajo…

9. Evolución de las organizaciones…
Director
Jefe jefe jefe
Pmo
Proyecto
Director
Jefe
empleado empleado
Jefe
empleado
Seguridad, sentido de
pertenencia,
reconocimiento, poder y
autotranscendencia a sus
miembros.
Estructuras
lineales
Estructuras Matriciales
Estructuras
ágiles

10. …Qué es importante en las organizaciones
• Flexibilidad
• Velocidad
• Clientes satisfechos
• Aumentar ingresos.
• Reducir costes
• Clientes satisfechos
Probar lo que funciona, y
hacer cambias hasta
buscar la mejor decisión
Toma lo mejor, deja el resto.
Richard
Richard Branson

11. Requisitos al principio
Planificación estricta
Clientes solo al principio y al final
¿Por que no revisarlos constantemente?
¿Por qué no planificar los proyectos de forma iterativa?
¿Por qué no involucrar al cliente durante el proyecto?
¿Por qué no buscar feedback constante?
…Proyectos gestionados de forma tradicional
1
2
3

12. Manifiesto Ágil valora…
INDIVIDUO y las INTERACCIONES DEL EQUIPO de desarrollo por encima del
proceso y las herramientas.
Desarrollar software (hacer procesos) que FUNCIONEN por encima de la documentación.
Negociación con el CLIENTE por encima del contrato.
La CAPACIDAD ANTE EL CAMBIO antes que un plan establecido.

13. Algunas metodologías Ágiles…
Poco restrictiva Muy restrictivaXPScrumLean Kanban
ScrumKanban XP
•Iteraciones.
•Roles más
definidos.
•Equipo
multidisciplinar.
•Equipo auto
organizado.
•Mejora de flujo de
trabajo.
•Liderazgo en todos
los niveles.
•Funciona bien en
flujos de trabajo
definidos.
•Organización.
•Adaptable a las
circunstancias.
•Pair
programming
LEAN
•Revisión de lo que
no añade valor al
cliente.
•Filosofía Kaizen
•Producto final
testeado,
retroalimentación
del equipo.

14. Metodologías Ágiles VS Tradicionales

15. Principios de metodologías ágiles…
Mejorar la satisfacción del cliente:
• Involucrado durante todo el proyecto.
• Es consciente de los avances y problemas del proyecto.
• Se evitan malentendidos
Implicación del equipo de trabajo
• Mejoran la motivación del equipo
• Todo el equipo sabe en que trabajan los demás.
• Los compromisos y las tareas son adquiridas por los miembros
del equipo
Ahorro de tiempo y mejora continua
• Trabajar más rápido y veloz.
• Cumplir los plazos.
• Entregar versiones funcionales cuanto antes.

16. Scrum
Scrum en mejora de procesos

17. • Se aplica en desarrollo de software, se puede aplicar a la mejora de procesos.
• Las actividades se repiten en cada iteración, hasta que está terminado.
• Está dispuesta a cualquier modificación.
• El cliente siempre está involucrado.
Qué es Scrum…
…Es una metodología de desarrollo ágil, basada en la adaptación, enfocada a la
satisfacción de cliente, iterativa y dispuesta al cambio.

18. Planificación
Spring
Ejecutar
Spring
Reunión
Diaria
Revisar Sprint
Retrospectiva
…¿Cómo se Organiza Scrum? Los eventos…

19. Artefactos Scrum
Product Backlog
Sprint Backlog
Burndown Chart

20. Eventos Scrum… ¿Cómo se organiza?
Sprint: Es el tiempo en el que el equipo está desarrollando las historias de usuario seleccionadas.
Sprint Planning: Es la planificación del trabajo, en base a las historias de usuario que ha generado
el product owner, se presentan en un backlog y se prioriza. El equipo de trabajo determina
cuantas historias pueden hacer y se compromete ha realizar esas acciones en ese spring.
Daily sprint meeting: Es una reunión breve, de 15 minutos 30 minutos, en la que el equipo se
sincroniza y comparte sus avances y problemas para seguir con el proyecto.
Demo y retrospectiva: Cuando se termina el sprint el equipo presenta las historias realizadas al
product owner. Después de esta reunión el equipo se junto, analiza lo que hizo bien, que se
puede mejorar y como lo pueden perfeccionar para la próxima vez.

21. Eventos Scrum… ¿Cómo se organiza?
v v
v
Product Backlog: Son los requisitos que se denominan historias de usuario. Es
un lenguaje no técnico que se priorizan en base al valor del negocio que
aportan. Estas prioridades se revisan periódicamente en base a la información
que tengamos.
Sprint Backlog: Lista de tareas asignadas al sprint.

22. Roles Scrum
Usuario
Product
Owner
Equipo de trabajo
Scrum
Master

23. Scrum Master
Eficiencia de proyecto.
máximo valor en el negocio.
Gestión de las interacciones
que aportan valor dentro
de la organización
Ayuda al equipo de trabajo
al eliminar los impedimentos durante
el sprint
Responsable de la implantación
de Scrum
Ayuda al equipo de trabajo
A ser autosuficiente, multifuncional
Y ordenado.
Ver la eficiencia burndown chart
Ayuda a que las tareas
en el sprint se puedan realizar
• Daily Meeting
• Spring planning
• Spring review
• Sprint retrospective
Ayuda en la cohesión
Y comunicación del equipo,
Organización mediante reuniones y actividades.

24. Product Owner
Validar que esta todo echo.
Definir criterios de aceptación
Definir historias de usuario
Definir producto mínimo viable
Ordenar product Backlog
Decidir que se hace y que no.
Responsable de requisitos del
Proceso a modificar.
Asegurarse que todo el mundo
Entiende las tareas a realizar
Es el responsable de los sprint
Saber como está funcionando el equipo
Y hacer estimaciones de cuando tendremos
La solución
• Daily Meeting
(Opcional)
• Spring planning
• Spring review
• Sprint retrospective 100% disponibilidad

25. Terminar
Nueva propuesta
1
1
a
El PO presenta las acciones
priorizadas del backlog. El PO y
el equipo colaboran en crear el
Sprint.
Reunión sobre el
“Qué”
Reunión sobre el
“Cómo”
Se reparten las acciones queue
están en el sprint backlog entre
los miembros del equipo. El
equipo se compromete a
hacerlo.
2
3
Inspeccionar y adaptar el producto. El TM prueba lo que se ha
hecho con PO y stakeholders. El PO acepta o rechaza el trabajo.
Todo el mundo colabora en evaluaciones y las nuevas ideas y el
backog del producto podrá ser revisado.
4
Mejorar el proceso. El equipo evalúa el
proceso y como trabajan juntos. Se
establecen acciones de mejoras para
próximas iteraciones
Reunión corta para ver en que
están trabajando los miembros
del equipo
Scrum
Sprint
Planning
1
b
SCRUM diario
Revisión del
SPRINT
SPRINT
retrospective
Product
Baclog

26. Otros elementos… Historias de usuario
Se utilizan para identificar los requerimientos del proyecto.
Descripciones cortas y simples de una funcionalidad, desde el punto de vista del
usuario
Yo como un [Rol], necesito [Descripción de la funcionalidad], con la finalidad de [Descripción de
la consecuencia]
Potenciar
participación
equipo
Evolucionan
con el proyecto
Funcionalidades
concretas
Peticiones
concretas

27. 27
Otros elementos… Criterios de aceptación
Se crean antes de
comenzar el
desarrollo
Son los parámetros
que validan que la
historia está
terminada
Las valida el PO El equipo de trabajo
las debe conocer
Ayudan a entender
mejor la historia
Técnicas de
comportamiento, si
ocurre a entonces
b…
…
Scenario) Escenario [Número de escenario] [Titulo del
escenario]:
(Given) En caso que [Contexto] y adicionalmente
[Contexto],
(When) cuando [Evento],
(Then) entonces el sistema [Resultado /
Comportamiento esperado]

29. Product Owner
Quién es el product owner de nuestras organización

30. Role Product Owner
Entregar o mejorar el proceso adecuado.
Articular y aunar la visión del proyecto.
Crea y prioriza el product backlog.
Colabora con el equipo, el usuario y los
stakeholders trasladando la visión de trabajo,
Maneja las expectativas y el plan de trabajo.
Es la figura tradicional
del product manager,
acercándolo al usuario
y al equipo que genera
el proyecto

31. Alcance del Product Owner
Product
Owner
Orientado a cliente
Estrategia
largo plazo
Estrategia
corto plazo
• Experiencia cliente
• Producto
• Equipo de trabajo
(Backlog,
iteraciones)
• Finanzas
• Unidad de Negocio

32. Análisis
De dónde sacamos los números y que hacemos con ellos

33. v v v v
Rol del analista (I)
Un analista busca la mejora continua, y una filosofía adecuada puede ser (KAIZEN), como
ciclo completo de mejora continua
Planificar
Medir
AnalizarInsights
Acción

34. v
Rol del analista (II)
AnalistaCapacidades
técnicas
Eficiencia
Calidad Metódico
Orientado a
costes
Gestión de
equipos

35. Rol Analista (III)
Facilitar insights para
La validación de historias
De usuario
Dar insights que aporten
Valor al negocio
Responsable de compartir
La información
Descomponer el problema junto con el PO
y establecer metodología de medición
• Daily Meeting
(Opcional)
• Spring planning
• Spring review
• Sprint retrospective
Hacer análisis ad hoc y proponer
Acciones nuevas. Aportar soluciones nuevas al cliente
No toma decisiones, las facilita. Está alineado
Con el PO
Es el responsable de saber dónde
Y que pautas se necesitan en el volcado
De la información (Lo que no se mide no existe)

36. Tipo de analista…
Analista de negocio
Es la persona con visión de negocio, analiza procesos y es capaz de ver
cómo impacta la información en los procesos de la compañía. Tiene
además una visión técnica que le permite trabajar con analistas más
técnicos como los de datos.
Analista de datos
Es el encargado de sacar datos necesarios de problemas de negocio que
se le atribuyen, encuentra tendencias concretas, patrones de
información y facilita esta información como análisis más concretos.
Data scientist
Este rol analiza un volumen importante de información aplicando
algoritmos matemáticos y ecuaciones para desarrollar productos en
base a las necesidades de negocio.

37. Roles Scrum + Analista
Usuario
Product Owner
Equipo de trabajo
•Mejorar la comunicación
•Tener feedback + continuado
•Colaborar en vez de negociar
Scrum Master
Analista

38. v v v v
Incluir siempre al analista… desde el principio
H
Desarrollar proceso
Hacer seguimiento de
KPIS
Incluir en BAU
Piloto
Análisis Ad hoc
Compartir insights
Implementar producto
Reporte seguimiento

39. v v v
Output analista…
Análisis
Ad hoc
Piloto Reporting

40. Mi Manifiesto Analítica Ágil…
La información como hilo conductor entre INDIVIDUO e INTERACCIONES para la toma
de decisiones por encima del proceso y las herramientas.
Los datos para decidir si el desarrollo/Proceso FUNCIONA vs realizar procesos por
encima de la documentación.
Los resultados analíticos como base de la NEGOCIACIÓN por encima del contrato para
añadir valor al cliente.
Los datos como IMPULSOR DEL CAMBIO antes que un plan establecido.

41. Analista en los diferentes eventos de Scrum
Sprint
planning
•El analista ayuda a priorizar las acciones al PO
Spring
execution
•El analista pilota el siguiente spring.
Daily
meeting
•El analista anota lo que está terminado y lo analiza
Sprint
review
•El analista muestra los datos, los comparte siempre, en el review
Sprint
retrospectiv
e
•Se involucra en la reunión:
•Necesita que la información se vuelque de determinada manera.
•Necesita extraer la información diaria en vez de semanal.
•Necesita sentarse con el equipo para preguntar dudas del proceso

42. Analista E2E
Conocimientos técnicos Propuestas de valor Compartir información

43. El círculo de trabajo
• Habla con
stakeholders
• Prioriza y toma
decisiones
Product Owner
• Desarrolla las tareas
• Se auto-organiza
• Se compromete a
realizar las tareas
Equipo de trabajo
• Entiende el proceso
• Facilita información
• No toma decisiones de
negocio
Analista
• Se asegura que la
metodología se
cumpla.
• Facilita las tareas al
equipo
Scrum master

44. Governance.. como escalar la información
Analista Cross
Área A Área B Área C
Scrum Master
PO –decision making
Director BDirector A Director C
Director ABCSteerco
después
de cada
iteración
Comité
ejecutivo
Escalado de información
S
C
R
U
M
Cliente
Equipo trabajoAnalistaScrum MPO

45. Cultura analítica, ¿está la organización preparada?
La cultura analítica no es otra cosa que utilizar los datos como base para la toma de decisiones. Es
basar la toma de decisiones, en la gestión rápida y eficaz de la información
• Procesos de información, como se comparte la información? Quien tiene
acceso a la información? Como se almacena la información?
• Habilidades, Los empleados pueden gestionar grandes volúmenes de
información? Tienen habilidades técnicas?
• Tecnologías, qué herramientas tenemos para extraer la información? Cómo
de tecnológico es el sector?
• Cultura, se utilizan los datos para tomar decisiones? Como se mejoran los
procesos?

46. Cultura analítica… ¿está la organización preparada?
Individualista Empresas con objetivos a corto plazo, actúan de manera reactiva y se adaptan tarde a
las nuevas tendencias.
Departamental: Los departamentos crecen de forma independiente, cada uno gestiona su información,
no fluye y se generan roces por la competencia que ello genera.
Empresa: La empresa consolida un “Data warehouse” la información está centralizada, pero cada uno
coge la información y la interpreta como le parece.
Optimización: Se desarrollan informes de reporte y seguimiento, existe un equipo de Business
intelligence y profesionales cualificados para la realización de análisis. Se utilizan los datos como base
para la toma de decisiones.
Innovación: Intenta la mejora continua, además abre las fuentes de datos a fuentes externas, como
redes sociales , datos.. por lo que necesita especialistas de big data. Gestiona esta información para ser
tendencia en el mercado. Son empresas que promueven lo creativo
1
2
3
4
5

47. Visualización de datos
Qué medios tenemos

48. Categorías de visualización…
Tendencias: Evolución de un indicador, patrón de comportamiento de los
elementos.
Patrones: Estacionalidad: Un modelo predecible, que se repite reiteradamente.
Anomalías: Datos diferentes debido a un efecto puntual
Correlaciones: Indicadores que están relaciones y que cambian de forma similar
cuando uno de ellos varía.
Comparaciones: Cuando se puede hacer una comparativa entre dos indicadores.
Jerarquía: Cuando una información depende de otra, como una sub-
segmentación de un segmento.

49. Datos en una organización…
•Adquirido a través de la
experiencia.
•Difícil de transferir
Sabiduría
•Insights
•Asimilación personal
Conocimiento
•Datos estructurados
•Kpis
•Dashboards
Información

50. Seguimiento Kpis & Dashboard
Excel Bases de
datos SQL
Visualización
de datos Statistics
BI
Analytics

51. v
Herramientas de visualización…
Tableau
Google
Fusion
Table
Visual.ly
R
Gephi

52. Eficiencia del proyecto… burndown chart
La otra es el sprint burndown chart, con las estimaciones hechas por los
miembros del equipo podremos saber cuando tiempo nos falta para
terminar el sprint en base al Sprint backlog.
Gráfico que nos permite saber la velocidad a la que se está
completando los requisitos del proyecto. Esto nos permitirá saber
si podremos terminar el proyecto a tiempo
Product backlog, con las acciones listadas y priorizadas podremos ver cuánto
puede llevarnos terminar el proyecto Cómo dividiremos el trabajo en
iteraciones, podremos ver sobre el trabajo pendiente cuánto nos queda para
terminar. X:Iteraciones Y:Tiempo
0
200
400
600
800
1000
1200
1 2 3 4 5 6 7

53. Conclusiones

54. ¡Gracias!
¿Alguna pregunta?