Release Plan

DoD

INCEPTION Incremento de
• Impact Mapping producto terminado

• User story map

Sprint backlog

User stories
TEXT JIRA
1 Como usuario, quiero poder solicitar un taxi desde mi ubicación actual para llegar rápidamente a mi destino.

2 Como usuario, quiero poder ver la información del conductor asignado para conocer más sobre quién me va a llevar.

3 Como usuario, quiero poder hacer una reserva anticipada de un taxi para planificar con anticipación mi viaje.

4 Como conductor, quiero poder aceptar o rechazar un viaje para tener el control de mi trabajo.

5 Como usuario, quiero poder pagar a través de la aplicación para evitar llevar dinero en efectivo.

6 Como usuario, quiero poder calificar al conductor y al servicio para dar mi opinión y ayudar a mejorar el servicio.

7 Como administrador, quiero poder gestionar los conductores y sus horarios para coordinar mejor las solicitudes de los usuarios.

8 Como usuario, quiero poder ver el tiempo estimado de llegada del taxi para poder planificar mi tiempo.

9 Como conductor, quiero poder visualizar la ruta más eficiente para llegar al destino del usuario.

10 Como usuario, quiero poder cancelar una solicitud de taxi si cambio de opinión o por cualquier otro motivo.

11 Como usuario, quiero recibir notificaciones en tiempo real sobre el estado de mi solicitud de taxi.

12 Como usuario, quiero poder guardar direcciones favoritas para solicitar rápidamente un taxi a esos lugares.

13 Como conductor, quiero poder ver las calificaciones y comentarios de los usuarios para mejorar mi servicio.

14 Como usuario, quiero poder compartir mi ubicación con el conductor para facilitar el encuentro.

15 Como usuario, quiero poder solicitar un tipo específico de vehículo, como un taxi adaptado o un vehículo grande.

16 Como administrador, quiero generar informes de uso y rendimiento de la aplicación.

17 Como usuario, quiero poder contactar al servicio de atención al cliente en caso de problemas o consultas.

18 Como conductor, quiero poder recibir indicaciones de voz para llegar al destino del usuario.
19 Como usuario, quiero poder ver el historial de mis viajes anteriores.
20 Como usuario, quiero recibir un recibo electrónico por correo electrónico después de cada viaje.
 Historia de
Priorización de Historias de Usuario: Usuario Prioridad Puntos de Historia Tareas Estimación (horas)
1.Establecer criterios de priorización: Define los criterios que utilizarás
3 Alta 5 - Diseñar interfaz de solicitud de taxi 8
para determinar la prioridad de las historias de usuario, como el valor
para el cliente, el impacto en el negocio o la complejidad técnica. - Desarrollar lógica de geolocalización 12
2.Utilizar el campo "Prioridad" en Jira: En cada historia de usuario, asigna
una prioridad utilizando el campo "Prioridad" de Jira. Puedes establecer - Implementar función de solicitud de taxi 10
prioridades como Alta, Media o Baja, o utilizar un sistema de numeración.
5 Alta 5 - Diseñar interfaz de aceptación/rechazo de viaje 6
3.Utilizar el backlog ordenado por prioridad: Organiza tu backlog del
producto en Jira arrastrando y soltando las historias de usuario en el
- Implementar lógica de aceptación/rechazo de viaje 8
orden de prioridad deseado. Las historias en la parte superior del backlog
tendrán una mayor prioridad. 7 Alta 3 - Diseñar interfaz de pago 4
4.Utilizar técnicas de votación: Si trabajas en equipo, puedes utilizar
- Integrar pasarela de pago 6
técnicas de votación, como dot voting o planning poker, para obtener la
opinión de todos los miembros del equipo y determinar la prioridad de las 10 Alta 4 - Analizar algoritmos de enrutamiento 8
historias.
- Implementar función de visualización de ruta 6

Estimación de Historias de Usuario: 1 Media 3 - Diseñar interfaz de registro de usuario 4

1.Utilizar puntos de historia: En Scrum, es común utilizar puntos de
historia para estimar el esfuerzo relativo de las historias de usuario. - Implementar función de registro de usuario 6
Asigna puntos de historia a cada historia basándote en la complejidad, el
4 Media 3 - Diseñar interfaz de tiempo estimado de llegada 4
esfuerzo requerido y el nivel de incertidumbre.
2.Utilizar el campo "Estimación" en Jira: En cada historia de usuario, - Obtener datos de tráfico en tiempo real 8
utiliza el campo "Estimación" de Jira para asignar la cantidad de puntos de
historia o la unidad de estimación que hayas definido. 9 Media 3 - Diseñar interfaz de historial de viajes 4
3.Utilizar técnicas de estimación en equipo: Puedes realizar sesiones de
estimación en equipo, como planning poker, donde cada miembro del - Implementar función de visualización de historial de viajes 6
equipo asigna una estimación individual a cada historia y luego se
discuten las diferencias hasta llegar a un consenso. 2 Baja 2 - Diseñar interfaz de inicio de sesión 2
4.Utilizar la técnica del tamaño relativo: En lugar de asignar puntos de - Implementar función de inicio de sesión 4
historia absolutos, puedes comparar las historias de usuario entre sí y
asignarles tamaños relativos, por ejemplo, utilizando la escala de 6 Baja 2 - Diseñar interfaz de información del conductor 4
Fibonacci.
- Implementar función de visualización de información 6
Recuerda que la priorización y estimación de las historias de usuario son actividades
colaborativas y deben involucrar a todos los miembros del equipo. Jira Software
8 Baja 2 - Diseñar interfaz de calificación del conductor 4
proporciona herramientas y campos personalizables para adaptarse a tus
necesidades de priorización y estimación.
- Implementar función de calificación 6
 ID de Historia Duración
Las épicas son unidades de trabajo más grandes que las historias de Nombre de la Épica de Usuario Descripción Sprint (días) Esfuerzo
usuario. Representan funcionalidades o características de alto nivel que Gestión de Usuarios US-1 Como administrador, quiero crear usuarios Sprint 1 3 5
suelen requerir varios sprints para su implementación completa. Las Gestión de Usuarios US-2 Como usuario, quiero iniciar sesión Sprint 1 2 3
épicas se utilizan para agrupar y organizar un conjunto de historias de
Gestión de Usuarios US-3 Como usuario, quiero cambiar mi contraseña Sprint 2 2 3
usuario relacionadas que tienen un objetivo común.
Las épicas son útiles cuando una funcionalidad o requisito es demasiado Gestión de Usuarios US-4 Como administrador, quiero desactivar usuarios Sprint 2 3 5
grande o complejo para implementarse en un solo sprint. Por lo tanto, se
Gestión de Taxis US-5 Como usuario, quiero solicitar un taxi Sprint 1 2 3
desglosan en historias de usuario más pequeñas y manejables durante el
proceso de refinamiento del backlog. Gestión de Taxis US-6 Como conductor, quiero aceptar solicitudes de viaje Sprint 1 3 5

Gestión de Taxis US-7 Como usuario, quiero calificar al conductor Sprint 2 2 3

Las épicas a menudo se definen en una fase inicial del proyecto y se
utilizan para establecer una visión de alto nivel y objetivos a largo plazo. A Gestión de Taxis US-8 Como administrador, quiero visualizar estadísticas de viajes Sprint 3 3 5
medida que se avanza en el desarrollo del producto, las épicas se refinan y
Pago de Servicios US-9 Como usuario, quiero pagar el servicio de taxi Sprint 3 2 3
se descomponen en historias de usuario más detalladas y estimables.
Pago de Servicios US-10 Como administrador, quiero generar reportes de pagos Sprint 3 3 5
Algunas características de las épicas son:
1.Son unidades de trabajo de mayor tamaño que las historias de usuario. Reportes US-11 Como usuario, quiero ver un historial de mis viajes Sprint 1 2 3
2.Representan funcionalidades o requisitos de alto nivel.
3.Pueden requerir varios sprints para su implementación completa. Reportes US-12 Como administrador, quiero generar reportes de uso Sprint 3 3 5

4.Se desglosan en historias de usuario más pequeñas durante el Gestión de Tarifas US-13 Como administrador, quiero configurar tarifas Sprint 2 2 3
refinamiento del backlog.
Gestión de Tarifas US-14 Como usuario, quiero ver las tarifas vigentes Sprint 2 2 3
5.Ayudan a establecer una visión de alto nivel y objetivos a largo plazo.
6.Evolucionan y se refinan a medida que se avanza en el desarrollo del Gestión de Tarifas US-15 Como administrador, quiero aplicar descuentos especiales Sprint 4 3 5
producto.
Soporte al Cliente US-16 Como usuario, quiero contactar al servicio de atención al cliente Sprint 1 2 3

Soporte al Cliente US-17 Como administrador, quiero gestionar solicitudes de soporte Sprint 4 3 5

Soporte al Cliente US-18 Como usuario, quiero recibir notificaciones de mis solicitudes Sprint 4 2 3

Geolocalización US-19 Como usuario, quiero ver la ubicación de los taxis en tiempo real Sprint 2 2 3
La planificación del sprint (Sprint Planning) es una reunión colaborativa que se lleva a
cabo al comienzo de cada sprint para determinar qué historias de usuario se incluirán en
el sprint y cómo se implementarán. Aquí te explico los pasos para realizar la planificación
del sprint:

1.Preparación: El Product Owner revisa el backlog del producto y selecciona las historias
de usuario prioritarias que se trabajarán en el próximo sprint. El equipo de desarrollo
revisa estas historias y las tareas relacionadas para comprender los requerimientos.
2.Establecer el objetivo del sprint: El Product Owner y el equipo de desarrollo definen un
objetivo claro para el sprint, que representa el resultado deseado al finalizar el sprint.
3.Determinar la capacidad del equipo: El equipo de desarrollo revisa su capacidad de
trabajo y establece cuántas historias de usuario se pueden abordar en el sprint en función
de sus habilidades, disponibilidad y otros compromisos.
4.Desglose de historias de usuario: El equipo de desarrollo analiza las historias de usuario
seleccionadas y las desglosa en tareas más pequeñas y manejables. Estas tareas
representan las actividades necesarias para implementar cada historia.
5.Estimación de tareas: El equipo de desarrollo estima el esfuerzo requerido para cada
tarea utilizando las técnicas de estimación que hayan elegido, como puntos de historia o
estimaciones en horas.
6.Asignación de tareas: El equipo de desarrollo asigna las tareas a los miembros del
equipo, considerando las habilidades y disponibilidad de cada uno.
7.Definición de la definición de "listo" (Definition of Done): El equipo de desarrollo
establece los criterios que deben cumplir las historias de usuario para considerarse
completas y "listas" para ser entregadas al finalizar el sprint.
8.Establecimiento del plan del sprint: El equipo de desarrollo crea un plan detallado para
el sprint, incluyendo las tareas asignadas, las estimaciones de tiempo, las dependencias y
los plazos.
9.Compromiso del equipo: El equipo de desarrollo se compromete a entregar el trabajo
planificado dentro del sprint y alcanzar el objetivo establecido.
Recuerda que la planificación del sprint es una actividad colaborativa en la que el equipo
de desarrollo, el Product Owner y, en ocasiones, el Scrum Master, participan activamente
para establecer un plan realista y alcanzable para el sprint.
SPRINT PLANNING C/ASIGNACIÓN DE FECHAS Y RECURSOS

Nota: Las fechas límite en la tabla son solo un ejemplo y

deben ajustarse según las necesidades y la planificación del
proyecto. Asegúrate de establecer fechas realistas y
considerar la disponibilidad de los miembros del equipo, la
complejidad de las tareas y cualquier dependencia entre
ellas.
RELEASE PLAN

Sprint Fecha de Inicio Fecha de Fin Duración (semanas) Historias de Usuario

1 15/06/2023 30/06/2023 2 US-1, US-2, US-5
2 01/07/2023 15/07/2023 2 US-3, US-4, US-7
3 16/07/2023 30/07/2023 2 US-8, US-9, US-12
4 01/08/2023 15/08/2023 2 US-17, US-20
5 16/08/2023 30/08/2023 2 US-10

DIAGRAMA DE GANTT ó ROADMAP

Definition of Done
Historia de usuario Prioridad
Como usuario, quiero poder iniciar
sesión en la aplicación usando mi Alta
correo electrónico y contraseña.
Como usuario, quiero poder
solicitar un taxi y recibir Alta
información del conductor.
Como conductor, quiero poder
aceptar solicitudes de viaje y ver la Alta
información del pasajero.
Como usuario, quiero poder pagar
mi viaje usando mi tarjeta de Alta
crédito o débito.
Como usuario, quiero poder
Media
cancelar un viaje que he solicitado.
Como conductor, quiero poder
calificar a un pasajero después del Media
viaje.
Como usuario, quiero poder
visualizar mi historial de viajes y Media
recibos.
Como administrador, quiero poder
ver estadísticas y reportes de la Baja
aplicación.
Responsable Definition of Done
El usuario puede iniciar sesión y acceder a su perfil.
Desarrollador Back-End La información de inicio de sesión es segura y se
almacena de manera encriptada.
El usuario puede seleccionar su ubicación y destino,
visualizar la información del conductor, como la
Desarrollador Front-End
matrícula y la calificación, y recibir actualizaciones
sobre la llegada del taxi.
El conductor puede ver la información del pasajero,
Desarrollador Back-End como su nombre y ubicación, y aceptar o rechazar
una solicitud de viaje.
El usuario puede agregar y editar sus métodos de
pago, seleccionar un método de pago para el viaje y
Desarrollador Back-End
confirmar la transacción. La transacción se realiza de
forma segura y se proporciona un recibo.
El usuario puede cancelar un viaje dentro del plazo
Desarrollador Front-End establecido sin penalización. Se proporciona una
confirmación de cancelación al usuario.
El conductor puede calificar al pasajero en función
Desarrollador Back-End
de su comportamiento durante el viaje.
El usuario puede acceder a su historial de viajes y ver
Desarrollador Front-End
la información del viaje, como la tarifa y el recibo.
El administrador puede acceder a estadísticas y
reportes de la aplicación, como la cantidad de viajes
Desarrollador Back-End
realizados y la calificación promedio de los
conductores.
Definition of Done
Historia de usuario
Como usuario, quiero poder
compartir mi ubicación con un
amigo o familiar.
Como usuario, quiero poder
acceder a mi perfil y editar mi
información personal.
Prioridad Responsable Definition of Done
El usuario puede compartir su ubicación actual con
Baja Desarrollador Front-End un amigo o familiar a través de un enlace o mensaje
de texto.
El usuario puede acceder a su perfil, ver su
Baja Desarrollador Front-End
información personal y editarla si es necesario.
Definition of Done
El "Definition of Done" (DoD) es un conjunto de criterios que establece cuándo se considera que una historia de usuario o cualquier elemento
de trabajo está terminado y listo para ser entregado al cliente o al usuario final. Estos criterios pueden variar según el equipo y el contexto,
pero generalmente incluyen aspectos técnicos, de calidad y de valor del producto.

El "Definition of Done" se define y acuerda durante la planificación del proyecto o al inicio del mismo, en colaboración entre el equipo de
desarrollo y el Product Owner. Es responsabilidad del equipo asegurarse de cumplir con los criterios establecidos en el DoD para cada
elemento de trabajo.

El objetivo del DoD es garantizar que el trabajo completado cumpla con los estándares de calidad y sea potencialmente entregable al final de
cada iteración o sprint. Al tener un DoD claro y compartido, se establece una expectativa común y se evitan malentendidos o problemas
relacionados con la calidad del trabajo realizado.

Algunos ejemplos de criterios que podrían estar incluidos en un Definition of Done son:
•Todas las pruebas unitarias y de integración se han ejecutado y pasan satisfactoriamente.
•Se han realizado pruebas de aceptación y se han cumplido los criterios de aceptación establecidos.
•El código ha sido revisado y cumple con los estándares de desarrollo definidos.
•Se han realizado pruebas de rendimiento y el sistema cumple con los requisitos establecidos.
•Se ha realizado la documentación necesaria, como documentación técnica o manuales de usuario.
•Se han solucionado todos los bugs y problemas conocidos.
•El elemento de trabajo ha sido revisado y aprobado por el Product Owner.

En resumen, el Definition of Done es una herramienta importante para asegurar la calidad y la entrega de valor en Scrum. El equipo de
desarrollo y el Product Owner colaboran en su definición y se aseguran de que se cumpla en cada elemento de trabajo completado.
IMPACT MAPPING

El impact mapping es una técnica de colaboración utilizada en metodologías ágiles, como Scrum, para ayudar a los equipos a visualizar y alinear los objetivos
comerciales con las funcionalidades del producto. Proporciona una visión clara de cómo cada funcionalidad contribuye al logro de los objetivos comerciales y
ayuda a priorizar el trabajo en función de su impacto.

El proceso de realización del impact mapping generalmente implica los siguientes pasos:
1.Identificar el objetivo comercial: Comienza por definir el objetivo comercial o el resultado deseado que se quiere lograr con el producto. Esto podría ser
aumentar los ingresos, mejorar la experiencia del usuario, reducir costos, etc.
2.Determinar los actores: Identifica los actores involucrados en el logro del objetivo. Estos pueden ser usuarios, clientes, partes interesadas, etc. Piensa en
quiénes se ven afectados o se benefician directamente del producto.
3.Definir los éxitos medibles: Para cada actor, establece los resultados medibles que representarían el éxito en relación con el objetivo comercial. Estos éxitos
medibles pueden ser números específicos, porcentajes, indicadores clave de rendimiento (KPI), etc.
4.Identificar las funcionalidades clave: Ahora, determina las funcionalidades necesarias en el producto para alcanzar los éxitos medibles y, en última instancia, el
objetivo comercial. Estas funcionalidades se conocen como "épicas" y son las principales categorías o áreas de trabajo.
5.Desglosar en historias de usuario: Para cada funcionalidad (épica), desglosa el trabajo en historias de usuario más pequeñas y manejables. Estas historias de
usuario representan unidades de trabajo que pueden ser desarrolladas e implementadas en un período de tiempo más corto.
6.Asignar a los sprints: Por último, asigna las historias de usuario a los sprints específicos en función de la prioridad, el esfuerzo estimado y las restricciones del
proyecto. Esto ayudará a planificar la implementación gradual de las funcionalidades a lo largo del tiempo.

El impact mapping es una herramienta efectiva para alinear el desarrollo del producto con los objetivos comerciales y fomentar una visión compartida en el
equipo. Ayuda a enfocar los esfuerzos en las funcionalidades que tienen un mayor impacto en el resultado final y a tomar decisiones basadas en datos y
objetivos comerciales claros.
IMPACT MAPPING

Objetivo Comercial Éxito Medible Funcionalidad (Épica) Sprint

Aumentar usuarios 100 nuevos usuarios al mes Registro de usuarios 1, 2, 3
Login de usuarios 1, 2, 3
Perfil de usuario 1, 2, 3
Gestión de pagos 4, 5
Mejorar experiencia del
Tiempo promedio de respuesta < 5 segundos Optimización de consultas 1, 2
usuario
Interfaz de usuario intuitiva 1, 2
Historial de viajes 3
Aumentar ingresos Incremento del 20% en ingresos Tarifas dinámicas 4, 5
Publicidad en la aplicación 1, 4
Optimizar eficiencia
Reducción del tiempo de asignación de taxis Asignación de taxis en tiempo real 1, 2, 3
operativa
Gestión de flota de taxis 4, 5
Mejorar satisfacción del
Aumento del 90% en las calificaciones Sistema de calificación y comentarios 1, 2, 3
cliente
Soporte al cliente en línea 1, 2, 3
Resolución de problemas en tiempo
4, 5
real
Mejorar seguridad y Autenticación y seguridad de la
Reducción del 50% en incidencias de seguridad 1, 2
confiabilidad aplicación
Copias de seguridad y recuperación 3
Pruebas de seguridad y penetración 4, 5
User story Map

1.Prepara un tablero o una pizarra en blanco.

2.En el centro del tablero, coloca el objetivo principal o el problema que deseas abordar con tu producto.
3.Identifica los actores clave que están involucrados en ese objetivo o problema. Estos pueden ser diferentes tipos de
usuarios, clientes, equipos internos, etc.
4.A medida que identificas los actores, coloca notas adhesivas o tarjetas alrededor del objetivo central para representar a
cada actor. Utiliza diferentes colores para distinguir entre los diferentes actores.
5.Ahora, piensa en las acciones o comportamientos que cada actor realiza para lograr el objetivo o resolver el problema. Estas
acciones pueden ser diferentes etapas del proceso, interacciones con el producto, decisiones que toman, etc.
6.A medida que identificas estas acciones, coloca más notas adhesivas o tarjetas debajo de cada actor correspondiente,
representando las acciones específicas que realizan.
7.A continuación, piensa en las funcionalidades del producto que se pueden desarrollar para respaldar esas acciones y
satisfacer las necesidades de los actores. Estas funcionalidades se pueden representar con notas adhesivas o tarjetas más
pequeñas debajo de las acciones correspondientes.
8.Por último, puedes desglosar aún más las funcionalidades en tareas más pequeñas o subtareas, si es necesario, para una
mejor comprensión y planificación.

Recuerda que el User story Map es una herramienta visual y colaborativa. Puedes invitar a tu equipo a participar en la
creación y refinamiento del mapa, utilizando notas adhesivas, tarjetas o cualquier otra herramienta de colaboración en línea.
Esto ayudará a obtener una comprensión compartida de las necesidades de los usuarios y a facilitar la toma de decisiones en
el desarrollo de tu producto.
User story Map

Story maps organize user stories into

a visual presentation, in the form of
a grid, to help capture functionality,
plan releases, groom the backlog,
and identify a journey.

Story mapping helps Agile teams

understand customers and problems
by ordering user stories along X and
Y axes; the axes can represent
priority, complexity, states or stages,
or any other aspect of a story's life
cycle.
INCEPTION
En Scrum, el término "inception" se refiere a una fase inicial de planificación y exploración que se lleva a cabo antes de que comience el
desarrollo del proyecto. Es una práctica común en Scrum para establecer una comprensión compartida y alinear a todo el equipo en cuanto a
los objetivos, el alcance y la visión del proyecto.

Durante la fase de inception, se suelen llevar a cabo actividades como talleres, sesiones de lluvia de ideas, reuniones y discusiones entre el
equipo de desarrollo, el Product Owner y otras partes interesadas clave. Estas actividades tienen como objetivo principal:

1.Establecer la visión del proyecto: Durante la fase de inception, se definen y clarifican los objetivos comerciales y las expectativas del
proyecto. Se establece una visión clara de lo que se quiere lograr y se alinea a todo el equipo en torno a esa visión.

2.Identificar y priorizar el Product Backlog: Durante esta fase, se recopilan los requisitos y las necesidades del producto y se priorizan en
forma de historias de usuario. Esto ayuda a determinar qué funcionalidades son más importantes y cuáles deben incluirse en los sprints
iniciales.

3.Estimar la duración y el esfuerzo: Durante la fase de inception, se pueden realizar estimaciones preliminares de la duración y el esfuerzo
requeridos para desarrollar las diferentes funcionalidades. Esto proporciona una idea general del alcance del proyecto y ayuda en la
planificación del trabajo.

4.Identificar riesgos y dependencias: Durante esta fase, se identifican los posibles riesgos y dependencias que podrían afectar el proyecto.
Esto permite tomar medidas preventivas y mitigar cualquier problema potencial antes de que se produzcan.

En resumen, el inception en Scrum es una fase inicial de planificación y alineación que se lleva a cabo antes de que comience el desarrollo
real del proyecto. Ayuda a establecer la visión, identificar los requisitos y priorizar el trabajo, estimar el esfuerzo y los plazos, y identificar los
riesgos y dependencias. Esto proporciona una base sólida para el desarrollo posterior y ayuda a garantizar el éxito del proyecto.
INCEPTION
Aquí tienes una lista de actividades que podrías realizar durante la fase de inception para el proyecto de una aplicación de gestión de taxis:

1.Reunión de inicio del proyecto: Organiza una reunión con el equipo de desarrollo, el Product Owner y otras partes interesadas clave para discutir y comprender los objetivos generales del
proyecto, los requisitos básicos y las expectativas.

2.Definición de la visión del proyecto: Trabaja junto con el equipo para establecer una visión clara y compartida de la aplicación de gestión de taxis. Esto implica definir los beneficios clave,
los problemas a resolver y los objetivos comerciales que se espera lograr con el proyecto.

3.Identificación de actores y usuarios: Identifica los diferentes actores que estarán involucrados en el uso de la aplicación, como conductores de taxis, pasajeros, administradores de la
empresa de taxis, etc. Comprende sus necesidades y expectativas.

4.Análisis de requisitos: Realiza un análisis detallado de los requisitos de la aplicación. Identifica las funcionalidades clave que se requieren, como reserva de taxis, seguimiento de viajes,
gestión de pagos, administración de conductores y pasajeros, etc.

5.Priorización de requisitos: Prioriza los requisitos identificados según su importancia y valor para los usuarios y el negocio. Utiliza técnicas como el Value-Based Prioritization para
determinar qué funcionalidades deben incluirse en las primeras etapas del desarrollo.

6.Estimación de esfuerzo y duración: Realiza una estimación inicial del esfuerzo y la duración requeridos para desarrollar las diferentes funcionalidades de la aplicación. Puedes utilizar
técnicas como la Planning Poker o la estimación relativa para obtener estimaciones aproximadas.

7.Análisis de riesgos: Identifica los posibles riesgos y desafíos que podrían surgir durante el desarrollo del proyecto. Evalúa su impacto y probabilidad de ocurrencia y desarrolla estrategias de
mitigación para abordarlos.

8.Definición del Product Backlog: Crea y prioriza el Product Backlog, que es una lista ordenada de todas las funcionalidades, historias de usuario y tareas necesarias para construir la
aplicación de gestión de taxis. Asegúrate de que el Product Backlog esté actualizado y refleje los requisitos y prioridades acordados.

9.Planificación del primer Sprint: Basándote en los requisitos y prioridades establecidos, planifica el primer Sprint. Identifica las historias de usuario y tareas que se abordarán en el primer
Sprint y asigna estimaciones de esfuerzo y duración.

10.Sesiones de trabajo en equipo: Organiza sesiones de trabajo en equipo, como talleres de diseño, para colaborar en el diseño de la interfaz de usuario, la arquitectura del sistema y otros
aspectos clave del proyecto.

Recuerda que estas actividades son solo ejemplos y puedes ajustarlas según las necesidades y características específicas de tu proyecto de gestión de taxis. La fase de inception es una
oportunidad para establecer una base sólida para el desarrollo del proyecto y garantizar una comprensión compartida de los objetivos y requisitos.
INCEPTION

Requisito Valor para el negocio Valor para los usuarios Esfuerzo estimado
Reserva de taxis Alta Alta 5 puntos
Seguimiento de viajes Medio Alto 3 puntos
Gestión de pagos Alta Alta 8 puntos
Administración de conductores Medio Medio 4 puntos

Administración de pasajeros Medio Medio 3 puntos

Calificación de conductores Baja Alta 2 puntos
Historial de viajes Medio Medio 3 puntos
Generación de reportes Medio Baja 2 puntos
Servicio al cliente Baja Alta 1 punto
Integración con mapas Alta Alta 6 puntos

En esta tabla, cada requisito se evalúa en función de su valor tanto para el negocio como para los usuarios, utilizando una escala de
alta, media y baja. También se estima el esfuerzo requerido para desarrollar cada requisito, utilizando puntos de historia u otra unidad
de medida similar.
La priorización se puede determinar calculando un puntaje de prioridad para cada requisito, multiplicando el valor para el negocio y el
valor para los usuarios y dividiendo por el esfuerzo estimado. Cuanto mayor sea el puntaje de prioridad, más alta será la prioridad del
requisito.
Recuerda que la tabla es solo un ejemplo y los valores asignados a cada requisito pueden variar según las necesidades y las
circunstancias específicas de tu proyecto. La técnica Value-Based Prioritization te permite tomar decisiones informadas sobre la
priorización de requisitos, considerando tanto el valor como el esfuerzo requerido para implementarlos.
PLAN DE PRUEBAS
Funcionalidad/Historia de Usuario Fecha de Prueba Responsable Definition of Done
Reserva de taxis 10/05/2023 Tester QA - La reserva de taxis se realiza correctamente

Seguimiento de viajes 12/05/2023 Tester QA - El seguimiento muestra la ubicación del taxi en tiempo real

Gestión de pagos 15/05/2023 Tester QA - El pago se procesa sin errores y se registra correctamente

Administración de conductores 18/05/2023 Tester QA - Se pueden agregar, editar y eliminar conductores

Administración de pasajeros 20/05/2023 Tester QA - Se pueden agregar, editar y eliminar pasajeros
Calificación de conductores 22/05/2023 Tester QA - Los pasajeros pueden calificar a los conductores

Historial de viajes 25/05/2023 Tester QA - El historial muestra los viajes realizados correctamente

Generación de reportes 28/05/2023 Tester QA - Los reportes se generan con la información correcta

Servicio al cliente 30/05/2023 Tester QA - Las consultas y solicitudes de servicio se atienden correctamente

Integración con mapas 02/06/2023 Tester QA - La integración con los mapas muestra la ubicación correcta del taxi

Asegúrate de establecer criterios claros en el Definition of Done para cada funcionalidad o historia de usuario, de modo que se
pueda verificar si se cumplen los requisitos y está lista para su implementación. El Tester QA es el responsable de realizar las
pruebas y asegurarse de que se cumplan los criterios establecidos en el Definition of Done.
Daily Scrum Meeting
1.Establecer un horario y lugar fijo para la reunión diaria.
2.Reunir al equipo de desarrollo, que incluye al Scrum Master, Product Owner y todos los miembros del equipo.
3.Cada miembro del equipo responde a las tres preguntas clave:
1. ¿Qué hice ayer?
2. ¿Qué voy a hacer hoy?
3. ¿Existen impedimentos o bloqueos que me impidan avanzar en mi trabajo?
4.El Scrum Master facilita la reunión, asegurándose de que se cumplan los tiempos establecidos y se aborden los impedimentos.
5.Los miembros del equipo se escuchan mutuamente y evitan interrupciones durante la reunión.
6.El Scrum Master registra los impedimentos o bloqueos mencionados y se compromete a ayudar a resolverlos después de la reunión.
7.El Product Owner puede asistir a la reunión para escuchar las actualizaciones del equipo, pero generalmente no participa activamente en la discusión.
8.La reunión debe durar entre 15 y 30 minutos, asegurándose de mantenerla breve y enfocada en los temas relevantes.
9.Después de la reunión, el equipo puede realizar conversaciones adicionales para abordar problemas específicos o coordinar tareas si es necesario.
10.La Daily Scrum Meeting se lleva a cabo todos los días, preferiblemente al comienzo de la jornada laboral, para sincronizar al equipo y mantener un flujo
constante de información.

Recuerda que la Daily Scrum Meeting es una reunión de sincronización diaria, no es un espacio para discutir detalles técnicos o tomar decisiones importantes. Su
objetivo principal es mantener a todos los miembros del equipo informados sobre el progreso y detectar posibles impedimentos para abordarlos de manera
oportuna.
Scrum Board en Jira Software

1.Inicia sesión en tu cuenta de Jira Software.

2.Navega hasta el proyecto en el que deseas crear el Scrum Board.
3.Haz clic en la pestaña "Boards" en la barra de navegación superior.
4.En el menú desplegable, selecciona "Create Board" y elige la opción "Scrum Board".
5.Se abrirá un formulario para configurar el Scrum Board. Completa la siguiente información:
•Nombre del board: Ingresa un nombre descriptivo para identificar el Scrum Board.
•Project: Selecciona el proyecto en el que se encuentra el backlog de tu equipo Scrum.
•Filter Query: Puedes especificar un filtro de JQL (Jira Query Language) para definir qué issues se mostrarán en el Scrum Board. Por ejemplo, puedes filtrar por
tipo de issue, estado, asignado a un usuario en particular, etc.
•Estimation Statistic: Elije el método de estimación que utilizarás para las historias de usuario, como puntos de historia o tiempo estimado.
•Estimation Field: Selecciona el campo personalizado de Jira donde se registrarán las estimaciones.
•Ranking Field: Si utilizas la funcionalidad de ranking en Jira, elige el campo que se utilizará para establecer el orden de prioridad de las historias de usuario.
6.Haz clic en "Create" para crear el Scrum Board.
7.Ahora puedes personalizar el Scrum Board según las necesidades de tu equipo. Puedes agregar columnas para representar los estados de flujo de trabajo,
configurar swimlanes para agrupar tareas por criterios como asignado a, tipo de issue, etc., y definir cualquier otra configuración específica que desees utilizar.
8.Una vez que hayas personalizado el Scrum Board, podrás comenzar a agregar historias de usuario arrastrándolas desde el backlog o creándolas directamente en el
tablero.
9.Utiliza el Scrum Board para visualizar y realizar un seguimiento del progreso del equipo durante el sprint, mover las historias de usuario a través de las columnas a
medida que avanzan en el flujo de trabajo y realizar cualquier otra acción necesaria para gestionar eficientemente el sprint.

Recuerda que la configuración y personalización exacta de tu Scrum Board puede variar según tus necesidades y preferencias. Puedes experimentar con diferentes
opciones y ajustarlas a medida que avances en la implementación de Scrum en tu proyecto.
Sprint Review
1.Preparación:
•Invitar a los interesados relevantes, como el Product Owner, el equipo de desarrollo, el Scrum Master y los stakeholders clave.
•Reservar un lugar adecuado y establecer una hora conveniente para todos los participantes.
2.Presentación de demostración:
•El equipo de desarrollo realiza una demostración de las funcionalidades completadas durante el sprint.
•Muestra las historias de usuario implementadas y cómo se utilizan en la aplicación.
•Destaca las características más importantes y cómo se alinean con los objetivos del proyecto.
3.Obtención de retroalimentación:
•Se anima a los stakeholders a brindar comentarios y realizar preguntas sobre las funcionalidades demostradas.
•El equipo de desarrollo recopila los comentarios y los registra para su posterior análisis.
4.Revisión del incremento:
•Se discute el incremento del producto y se verifica si cumple con las expectativas y los criterios de aceptación establecidos.
•Se identifican posibles mejoras o ajustes basados en los comentarios y la retroalimentación recibida.
5.Revisión del backlog:
•El Product Owner revisa el backlog del producto y realiza ajustes o adiciones basados en las necesidades y prioridades identificadas durante el sprint.
6.Planificación para el siguiente sprint:
•Se discuten y establecen las prioridades para el próximo sprint en función de los objetivos y las necesidades del proyecto.
•El equipo de desarrollo y el Product Owner colaboran para identificar las historias de usuario que se incluirán en el próximo sprint.
7.Retrospectiva del sprint:
•El equipo de desarrollo y el Scrum Master realizan una breve retrospectiva del sprint para evaluar qué funcionó bien y qué se puede mejorar en los procesos y prácticas.
•Se identifican acciones de mejora y se definen los pasos a seguir para el próximo sprint.
8.Cierre de la reunión:
•Se agradece a todos los participantes por su tiempo y contribución.
•Se registran los acuerdos y las acciones definidas durante la reunión.

Recuerda que las actividades pueden variar según las necesidades y las circunstancias específicas de cada proyecto. Es importante adaptarlas según los requisitos y la dinámica de tu equipo
y organización.
Sprint Review
Incrementos
1.Incremento 1: Registro de usuarios
1. Los usuarios pueden registrarse en la aplicación ingresando su información personal, como nombre, dirección de correo electrónico
y contraseña.
2. Se implementa la validación de datos para garantizar la integridad de la información ingresada.
2.Incremento 2: Búsqueda de taxis cercanos
1. Los usuarios pueden buscar y ver los taxis disponibles en su área actual utilizando la función de geolocalización.
2. Se muestra una lista de taxis con información relevante, como el nombre del conductor, la calificación, el tipo de vehículo y la
distancia estimada.
3.Incremento 3: Reserva de taxis
1. Los usuarios pueden seleccionar un taxi de la lista y realizar una reserva.
2. Se implementa un calendario para que los usuarios elijan la fecha y hora de recogida deseada.
3. Se muestra una confirmación de la reserva y se envía una notificación al conductor correspondiente.
4.Incremento 4: Seguimiento de viajes
1. Los usuarios pueden seguir el progreso de sus viajes en tiempo real a medida que el taxi se acerca a su ubicación.
2. Se muestra un mapa con la ruta estimada y se actualiza en tiempo real con la ubicación del taxi.
5.Incremento 5: Calificación y comentarios
1. Los usuarios pueden calificar y dejar comentarios sobre sus experiencias de viaje.
2. Se implementa un sistema de calificación de estrellas y un campo de texto para los comentarios adicionales.

Estos ejemplos de incrementos representan funcionalidades que se agregan gradualmente a la aplicación en cada sprint. Cada incremento
agrega valor al producto y se basa en las prioridades establecidas por el Product Owner y el equipo de desarrollo.
• Lead time
• Time to market
• Cycle time
Sprint Retrospective
1.Preparación:
1. Programa la reunión de retrospectiva al finalizar el sprint.
2. Asegúrate de que todos los miembros del equipo estén disponibles y participen activamente.
2.Establecer el ambiente:
1. Crea un ambiente seguro y de confianza donde los miembros del equipo se sientan cómodos para expresar sus opiniones.
2. Establece las reglas básicas de la retrospectiva, como el respeto mutuo, la escucha activa y la confidencialidad.
3.Recopilar datos:
1. Invita al equipo a compartir sus observaciones sobre el sprint.
2. Pide a cada miembro del equipo que escriba en notas adhesivas los aspectos positivos, los problemas y las posibles mejoras identificadas durante el
sprint.
3. Agrupa las notas adhesivas según temas o áreas comunes.
4.Discutir los temas:
1. Comienza la discusión abordando cada tema o grupo de notas adhesivas.
2. Anima a todos los miembros del equipo a compartir sus opiniones y experiencias relacionadas con cada tema.
3. Fomenta la participación equitativa y la escucha activa.
5.Identificar acciones de mejora:
1. A medida que se discuten los temas, identifica las acciones que el equipo puede tomar para mejorar en el próximo sprint.
2. Fomenta la generación de ideas y la colaboración entre los miembros del equipo.
6.Priorizar las acciones:
1. Pide al equipo que priorice las acciones de mejora identificadas.
2. Utiliza técnicas como la votación o el consenso para llegar a un acuerdo sobre las acciones más importantes o urgentes.
7.Definir el plan de acción:
1. Con base en las acciones priorizadas, establece un plan de acción con tareas específicas, responsables y fechas límite.
2. Asegúrate de que las acciones sean claras y medibles.
8.Cierre de la retrospectiva:
1. Recapitula las principales conclusiones y acuerdos alcanzados durante la retrospectiva.
2. Agradece al equipo por su participación y compromiso.
3. Asegúrate de que el plan de acción se registre y se comparta con todos los miembros del equipo.
Recuerda que la retrospectiva es una oportunidad para el equipo de reflexionar sobre su desempeño y mejorar continuamente. Es importante mantener un
enfoque constructivo y utilizar la retrospectiva como una herramienta para el aprendizaje y la evolución del equipo.
Diferencias entre el Sprint Retrospective y el Sprint Review

Sprint Review
Sprint Retrospective
Reflexionar sobre el proceso de trabajo y buscar Revisar el incremento del producto y recopilar
Objetivo
mejoras para el próximo sprint comentarios y retroalimentación de los stakeholders
Equipo de desarrollo, Product Owner, Scrum Master y
Participantes Equipo de desarrollo y Scrum Master
stakeholders
Evaluar el incremento del producto y su alineación
Enfoque Mejorar el proceso y el trabajo en equipo
con los objetivos
Discutir los aspectos positivos y los problemas,
Demostrar las funcionalidades completadas, recopilar
Actividades identificar acciones de mejora y establecer un plan
comentarios y realizar ajustes en el backlog
de acción
Comentarios y retroalimentación de los stakeholders,
Resultados Plan de acción para mejorar el próximo sprint ajustes en el backlog y priorización de
funcionalidades
Frecuencia Después de cada sprint Al finalizar cada sprint
Enfoque retrospectivo Pasado Presente y futuro
Sprint 1: Sprint 2: Sprint 3:
Historia de Puntos de Estimación Historia de Puntos de Estimación Historia de Puntos de Estimación
Usuario Historia (horas) Asignado a Usuario Historia (horas) Asignado a Usuario Historia (horas) Asignado a
Desarrollador Desarrollador Desarrollad
3 5 30 4 3 12 2 2 8
1 2 or 1
Desarrollador Desarrollador Desarrollad
5 5 14 9 3 10 6 2 12
2 1 or 2
Desarrollador Desarrollador Desarrollad
7 3 10 2 2 6 8 2 10
1 2 or 1
Desarrollador Desarrollador Desarrollad
10 4 14 6 2 10 1 3 10
2 1 or 2
Desarrollador Desarrollador Desarrollad
1 3 10 8 2 10 4 3 12
1 2 or 1

Sprint 4: Sprint 5:
Historia de Puntos de Estimación Historia de Puntos de Estimación
Usuario Historia (horas) Asignado a Usuario Historia (horas) Asignado a
Desarrollador Desarrollador
9 3 12 9 3 10
1 2
Desarrollador Desarrollador
2 2 6 2 2 6
2 1
Desarrollador Desarrollador
6 2 10 6 2 10
1 2
Desarrollador Desarrollador
8 2 8 8 2 8
2 1
Desarrollador Desarrollador
1 3 12 1 3 10
1 2
El Product Owner en Scrum desempeña un papel crucial en la gestión y entrega exitosa del producto. Sus principales funciones y
responsabilidades incluyen:

1.Definir y priorizar el Product Backlog: El Product Owner es responsable de definir y mantener el Product Backlog, que es una lista ordenada
de las funcionalidades, características y requisitos del producto. Debe asegurarse de que el Product Backlog esté actualizado, sea comprensible
y refleje las necesidades y prioridades del negocio y los stakeholders.
2.Establecer la visión y los objetivos del producto: El Product Owner debe tener una comprensión clara de la visión del producto y trabajar en
colaboración con los stakeholders para establecer objetivos claros y medibles. Debe asegurarse de que todas las funcionalidades y
características del producto estén alineadas con esta visión y objetivos.
3.Desglosar las funcionalidades en historias de usuario: El Product Owner trabaja en estrecha colaboración con el equipo de desarrollo para
desglosar las funcionalidades del producto en historias de usuario más pequeñas y manejables. Estas historias de usuario deben ser claras,
comprensibles y estar listas para ser implementadas por el equipo.
4.Establecer la prioridad de las historias de usuario: El Product Owner debe establecer la prioridad de las historias de usuario en el Product
Backlog. Utiliza criterios como el valor para el negocio, las necesidades de los stakeholders y las dependencias técnicas para determinar qué
historias de usuario deben implementarse primero.
5.Colaborar con el equipo de desarrollo: El Product Owner trabaja de cerca con el equipo de desarrollo durante todo el proyecto. Participa en
las reuniones diarias, el Sprint Planning, la revisión de sprint y el Sprint Retrospective para proporcionar orientación, aclarar dudas y tomar
decisiones relacionadas con el producto.
6.Asegurar la entrega de valor: El Product Owner tiene la responsabilidad final de asegurar que el producto entregado agregue valor al cliente y
cumpla con los objetivos establecidos. Debe estar constantemente involucrado en la retroalimentación de los stakeholders, realizar pruebas de
aceptación y realizar ajustes en el Product Backlog según sea necesario.
7.Tomar decisiones claras y oportunas: El Product Owner debe tomar decisiones rápidas y claras en relación con el producto. Esto incluye
tomar decisiones sobre la priorización, el alcance, los cambios y los compromisos con los stakeholders. Estas decisiones deben basarse en la
visión del producto y en lo que mejor beneficie al negocio y a los usuarios finales.

En resumen, el Product Owner es el responsable de definir y gestionar el producto en colaboración con los stakeholders y el equipo de desarrollo. Su objetivo
principal es maximizar el valor del producto, asegurando que se entreguen las funcionalidades adecuadas en el momento adecuado y cumpliendo con las
expectativas del negocio y los usuarios finales.
El perfil profesional de un Product Owner en Scrum es crucial para el éxito del proyecto. A continuación se detallan las características y habilidades que suelen
asociarse con el rol de Product Owner:
Perfil profesional:
1.Conocimiento del dominio del producto: El Product Owner debe tener un buen entendimiento del dominio en el que se encuentra el producto, incluyendo las
necesidades de los usuarios, las tendencias del mercado y las oportunidades de negocio.
2.Visión estratégica: El Product Owner debe tener una visión clara y estratégica del producto, comprendiendo cómo se alinea con los objetivos del negocio y cómo
puede generar valor para los usuarios y los stakeholders.
3.Habilidades de comunicación: El Product Owner debe ser un excelente comunicador, capaz de transmitir la visión y los requerimientos del producto de manera
efectiva a todo el equipo. Además, debe ser capaz de recibir retroalimentación y adaptar la estrategia en función de las necesidades cambiantes.
4.Capacidad de toma de decisiones: El Product Owner es responsable de tomar decisiones rápidas y efectivas en relación a las prioridades del backlog, los
cambios en los requerimientos y las entregas del producto. Debe tener la habilidad de evaluar diferentes opciones y tomar decisiones basadas en el valor y el
impacto del producto.
5.Empoderamiento y liderazgo: El Product Owner debe ser capaz de empoderar al equipo y liderarlos hacia los objetivos del proyecto. Debe ser capaz de influir en
las decisiones y motivar al equipo a alcanzar los resultados deseados.

Habilidades blandas:
1.Empatía: El Product Owner debe ser capaz de comprender las necesidades y expectativas de los usuarios y stakeholders, poniéndose en su lugar y trabajando
para satisfacer sus requerimientos.
2.Negociación: El Product Owner debe ser un buen negociador, capaz de equilibrar las necesidades de los diferentes stakeholders y encontrar soluciones que
beneficien a todos.
3.Flexibilidad: El Product Owner debe ser flexible y estar abierto al cambio, ya que los requerimientos pueden evolucionar durante el proyecto. Debe ser capaz de
adaptarse y ajustar la dirección del producto según sea necesario.
4.Orientación al cliente: El Product Owner debe estar enfocado en el cliente, buscando siempre entregar valor y satisfacer sus necesidades. Debe ser capaz de
representar los intereses de los usuarios y stakeholders en el desarrollo del producto.
5.Resolución de problemas: El Product Owner debe ser un solucionador de problemas, capaz de identificar y abordar los obstáculos y desafíos que surjan durante
el desarrollo del producto.

En resumen, el Product Owner es un profesional con conocimientos técnicos y habilidades blandas que le permiten liderar el desarrollo de un producto exitoso.
Su perfil combina el entendimiento del negocio y el dominio del producto con habilidades de comunicación, toma de decisiones, liderazgo y empatía.
Certified Scrum Product Owner" (CSPO)

La certificación más reconocida y ampliamente aceptada para los Product Owners es la "Certified Scrum Product Owner"
(CSPO), que es ofrecida por varias organizaciones de capacitación y certificación en metodologías ágiles.
La certificación CSPO se enfoca en validar el conocimiento y las habilidades necesarias para desempeñar eficazmente el rol
de Product Owner en un equipo Scrum. Para obtener la certificación, generalmente se requiere asistir a un curso de
capacitación impartido por un instructor certificado y aprobar un examen que evalúa la comprensión de los conceptos y
prácticas relacionadas con el rol de Product Owner.
La certificación CSPO abarca temas como la creación y gestión del Product Backlog, la colaboración con el equipo de
desarrollo, la priorización de historias de usuario, la definición de los criterios de aceptación y la maximización del valor del
producto, entre otros.
Es importante destacar que obtener una certificación como CSPO puede ser beneficioso para los profesionales que buscan
fortalecer su conocimiento y experiencia en el rol de Product Owner y demostrar su capacidad para aplicar prácticas ágiles
de manera efectiva. Sin embargo, es igualmente importante tener en cuenta que la certificación por sí sola no garantiza el
éxito en el desempeño del rol. La experiencia práctica, la colaboración efectiva y el desarrollo continuo de habilidades son
fundamentales para ser un Product Owner exitoso.
Certified Scrum Product Owner" (CSPO)

El camino para convertirse en un Product Owner exitoso puede variar según la experiencia y los antecedentes de cada persona, pero aquí
hay un posible roadmap que puedes seguir:

1.Familiarízate con la metodología Scrum: Comienza por adquirir un buen entendimiento de los principios y prácticas de Scrum. Lee libros,
artículos y recursos en línea sobre Scrum y familiarízate con los roles, eventos y artefactos en Scrum.
2.Obtén experiencia práctica: Busca oportunidades para trabajar en proyectos ágiles o equipos Scrum. Esto puede ser como miembro del
equipo de desarrollo, colaborando estrechamente con un Product Owner existente o tomando el rol de Product Owner en proyectos más
pequeños.
3.Amplía tus conocimientos: Busca cursos y talleres especializados en Product Ownership. Puedes considerar obtener la certificación
Certified Scrum Product Owner (CSPO) para fortalecer tus conocimientos y credenciales en este rol.
4.Desarrolla habilidades de gestión de productos: Aprende sobre técnicas de gestión de productos, como la definición de requisitos, la
creación de historias de usuario, la priorización del backlog, la comunicación efectiva con stakeholders y la toma de decisiones basadas en el
valor del producto.
5.Participa en actividades de desarrollo profesional: Asiste a conferencias, seminarios y meetups relacionados con la gestión de productos y
las metodologías ágiles. Esto te permitirá estar al tanto de las últimas tendencias y prácticas en el campo.
6.Colabora con otros roles en Scrum: Trabaja en estrecha colaboración con Scrum Masters, equipos de desarrollo y stakeholders para
comprender mejor cómo funciona el flujo de trabajo en un entorno ágil y cómo se puede maximizar el valor del producto.
7.Desarrolla habilidades blandas: Como Product Owner, necesitarás habilidades de comunicación efectiva, negociación, toma de decisiones
y gestión de conflictos. Trabaja en el desarrollo de estas habilidades blandas para ser capaz de interactuar y colaborar con diferentes
personas en el proceso de desarrollo del producto.
Recuerda que el camino hacia convertirse en un Product Owner exitoso es un proceso continuo. Siempre hay oportunidades para aprender
y mejorar tus habilidades. Mantente actualizado con las últimas tendencias y prácticas en gestión de productos y metodologías ágiles, y
busca oportunidades para aplicar tus conocimientos en proyectos reales.
Certified Scrum Product Owner" (CSPO)

La certificación Certified Scrum Product Owner (CSPO) es ofrecida por varias organizaciones de capacitación y certificación en metodologías
ágiles, y el contenido y el proceso de evaluación pueden variar ligeramente según la entidad que la imparta. Sin embargo, en general, la
certificación CSPO evalúa el conocimiento y las habilidades de un individuo en relación con el rol de Product Owner en un entorno Scrum.

El proceso de certificación CSPO generalmente incluye los siguientes elementos:

1.Asistir a un curso de capacitación: Para obtener la certificación CSPO, se requiere asistir a un curso de capacitación de dos días impartido
por un instructor certificado en Scrum. Durante el curso, se cubrirán los principios, roles, eventos y artefactos de Scrum, con un enfoque
específico en el rol de Product Owner.
2.Completar el examen: Después de finalizar el curso de capacitación, se puede requerir completar un examen para evaluar el conocimiento
adquirido. El examen puede ser en forma de preguntas de opción múltiple o de casos de estudio, donde se espera que demuestres la
comprensión de los conceptos clave y las mejores prácticas relacionadas con el rol de Product Owner.
Algunos de los temas que pueden evaluarse en el examen de certificación CSPO incluyen:
•Roles y responsabilidades del Product Owner.
•Creación y gestión del Product Backlog.
•Colaboración con el equipo de desarrollo y stakeholders.
•Priorización y refinamiento del backlog.
•Definición de los criterios de aceptación.
•Técnicas de estimación y planificación.
•Maximización del valor del producto.
Es importante destacar que las preguntas del examen pueden variar y dependerán de la organización de certificación específica. Por lo
tanto, es recomendable revisar la guía y los recursos proporcionados por la entidad de certificación correspondiente antes de realizar el
examen.

Una vez que se haya completado con éxito el curso y se haya aprobado el examen, se otorgará la certificación CSPO al individuo, lo que
valida su conocimiento y comprensión del rol de Product Owner en Scrum.
Certified Scrum Product Owner" (CSPO)
Estas preguntas se basan en los conceptos y principios generales de Scrum y el rol del Product Owner. Recuerda que los exámenes reales
pueden variar según la organización de certificación específica. Aquí tienes algunos ejemplos:
1.¿Cuál es el principal responsable de maximizar el valor del producto? a) Scrum Master b) Equipo de desarrollo c) Product Owner d)
Stakeholders
2.¿Cuál de las siguientes opciones describe mejor el rol del Product Owner? a) Proporciona coaching y apoyo al equipo de desarrollo. b)
Define y prioriza los requisitos del producto. c) Facilita las reuniones del equipo y asegura la entrega de incrementos. d) Gestiona los
impedimentos y asegura la calidad del producto.
3.¿Cuál de las siguientes actividades es responsabilidad del Product Owner? a) Asistir a la reunión de revisión del sprint. b) Estimar el
esfuerzo de las historias de usuario. c) Definir las tareas diarias para el equipo de desarrollo. d) Facilitar las retrospectivas del sprint.
4.¿Cuál de las siguientes opciones describe mejor el Product Backlog? a) Una lista de tareas diarias que deben completar los miembros del
equipo. b) Un conjunto de requisitos y funcionalidades del producto priorizados. c) Una estimación del esfuerzo requerido para cada historia
de usuario. d) Un registro de impedimentos y problemas encontrados durante el sprint.
5.¿Cuál de las siguientes opciones es una responsabilidad clave del Product Owner durante el sprint? a) Actualizar el Burndown Chart
diariamente. b) Participar en la Daily Scrum Meeting. c) Asegurarse de que se cumpla el Definition of Done. d) Realizar pruebas de aceptación
en las historias de usuario.
6.¿Cuál de las siguientes opciones describe mejor la función del Product Owner durante el Sprint Planning? a) Establecer el objetivo del
sprint y definir las tareas para el equipo de desarrollo. b) Revisar el incremento y obtener feedback de los stakeholders. c) Estimar el esfuerzo
requerido para completar las historias de usuario. d) Priorizar y seleccionar las historias de usuario para el sprint.
7.¿Cuál de las siguientes opciones describe mejor la colaboración entre el Product Owner y el equipo de desarrollo? a) El Product Owner
asigna tareas específicas a los miembros del equipo. b) El Product Owner actúa como facilitador para resolver conflictos dentro del equipo. c)
El Product Owner define y prioriza los requisitos del producto con el equipo. d) El Product Owner asume la responsabilidad de la calidad del
producto.
Certified Scrum Product Owner" (CSPO)
8.¿Cuál de las siguientes opciones describe mejor el propósito de la reunión de revisión del sprint? a) Presentar el
incremento del producto al cliente o a los stakeholders. b) Evaluar el desempeño individual de los miembros del equipo. c)
Identificar y resolver impedimentos y obstáculos en el proceso de desarrollo. d) Revisar y ajustar las estimaciones y
compromisos del equipo para el siguiente sprint.
9.¿Cuál de las siguientes opciones describe mejor el papel del Product Owner en la gestión del Product Backlog? a) Estimar el
esfuerzo requerido para completar las historias de usuario. b) Actualizar el Burndown Chart y monitorear el progreso del
sprint. c) Priorizar las historias de usuario y ajustar el backlog según las necesidades del producto. d) Facilitar la comunicación
y colaboración entre el equipo de desarrollo y los stakeholders.
10.¿Cuál de las siguientes opciones describe mejor el concepto de "Definition of Done" (Definición de Hecho)? a) Una lista de
tareas diarias que deben completar los miembros del equipo. b) Un conjunto de criterios que deben cumplirse para que una
historia de usuario se considere completa. c) Una estimación del tiempo requerido para completar una historia de usuario. d)
Una revisión formal del producto con los stakeholders al final del sprint.
11.¿Cuál de las siguientes opciones describe mejor la colaboración entre el Product Owner y los stakeholders? a) Los
stakeholders definen y priorizan las historias de usuario. b) El Product Owner comunica las necesidades y requisitos del
producto a los stakeholders. c) Los stakeholders asumen la responsabilidad de la estimación y planificación del sprint. d) El
Product Owner toma todas las decisiones clave relacionadas con el producto.
12.¿Cuál de las siguientes opciones describe mejor la función del Product Owner durante la Daily Scrum? a) Presentar el
progreso del sprint al equipo de desarrollo. b) Facilitar la reunión y asegurarse de que se cumplan los tiempos establecidos. c)
Discutir los obstáculos y problemas encontrados durante el sprint. d) Revisar y actualizar el Burndown Chart con el equipo de
desarrollo.
Certified Scrum Product Owner" (CSPO)
13.¿Cuál de las siguientes opciones describe mejor el objetivo del Product Owner en la reunión de Sprint Review? a) Obtener feedback del
cliente o de los stakeholders sobre el incremento del producto. b) Establecer el plan de trabajo detallado para el próximo sprint. c) Discutir y
resolver los problemas encontrados durante el sprint. d) Actualizar y ajustar el Product Backlog en base a los cambios identificados.
14.¿Cuál de las siguientes opciones describe mejor la responsabilidad del Product Owner en la gestión del riesgo del proyecto? a) Identificar
y evaluar los riesgos potenciales del proyecto. b) Implementar medidas para mitigar los riesgos identificados. c) Supervisar y controlar los
riesgos a lo largo del desarrollo del proyecto. d) Trabajar en estrecha colaboración con el equipo de desarrollo para gestionar los riesgos.
15.¿Cuál de las siguientes opciones describe mejor la relación entre el Product Owner y el Scrum Master? a) El Product Owner es
responsable de la gestión y coordinación del equipo de desarrollo. b) El Scrum Master es responsable de la priorización y definición de los
requisitos del producto. c) El Product Owner y el Scrum Master colaboran estrechamente para asegurar el éxito del proyecto. d) El Scrum
Master supervisa y evalúa el desempeño del Product Owner durante el sprint.
16.¿Cuál de las siguientes opciones describe mejor la función del Product Owner en la priorización del Product Backlog? a) El Product Owner
asigna puntos de historia a cada historia de usuario. b) El Product Owner determina la duración estimada de cada historia de usuario. c) El
Product Owner define y prioriza las historias de usuario en función del valor para el negocio. d) El Product Owner decide la secuencia en la
que se implementarán las historias de usuario.
17.¿Cuál de las siguientes opciones describe mejor el objetivo de un Sprint Goal? a) Proporcionar una descripción detallada de cada historia
de usuario en el sprint. b) Establecer la fecha límite para completar todas las historias de usuario del sprint. c) Identificar las tareas
específicas que deben completarse durante el sprint. d) Definir el objetivo general que el equipo de desarrollo se esforzará por lograr durante
el sprint.
18.¿Cuál de las siguientes opciones describe mejor la función del Product Owner en la gestión del alcance del proyecto? a) Definir y
comunicar claramente los límites y las expectativas del proyecto. b) Identificar y resolver cualquier conflicto o desacuerdo dentro del equipo.
c) Establecer los horarios y las fechas de entrega para cada historia de usuario. d) Supervisar y controlar el avance del proyecto en relación
con el alcance definido.
Certified Scrum Product Owner" (CSPO)
19.¿Cuál de las siguientes opciones describe mejor la responsabilidad del Product Owner en la gestión de los stakeholders? a) Mantener una
comunicación constante con los stakeholders para recopilar y entender sus necesidades. b) Tomar decisiones finales sobre los requisitos y las
funcionalidades del producto sin consultar a los stakeholders. c) Limitar la participación de los stakeholders en el proceso de desarrollo del
producto. d) Comunicar las decisiones del equipo de desarrollo a los stakeholders sin tener en cuenta sus opiniones.
20.¿Cuál de las siguientes opciones describe mejor la responsabilidad del Product Owner en la gestión de los cambios en el Product Backlog?
a) Evaluar y aprobar todos los cambios propuestos por los stakeholders. b) Trabajar en estrecha colaboración con el equipo de desarrollo
para evaluar y priorizar los cambios. c) Rechazar cualquier cambio que se proponga después de que se haya iniciado el sprint. d) Comunicar
los cambios a los stakeholders sin involucrar al equipo de desarrollo.
Certified Scrum Product Owner" (CSPO)