Guía interactiva eventos y artefactos Scrum

GUÍA INTERACTIVA EVENTOS Y ARTEFACTOS SCRUM

Grupo 202086806A_1144

Andrés Fernando Fonseca

Julio Antonio Sánchez

Patricia Paola Gómez Sergio Yamit Aparicio Wilson Alexis Fonseca Zulma Yanneth Pachón Directora: Dra Vanessa Paola Pertuz

Escuela de Ciencias Básicas, Tecnología e Ingeniería ECBTI

Universidad Nacional Abierta y a Distancia UNAD Curso de Dirección de Proyectos (Agile) Bogotá D.C., noviembre de 2022

¿QUÉ SON LOS EVENTOS DE SCRUM?

Bloques de tiempo que se programan y asignan para la gestión de un proyecto

Tienen un tiempo estimado

Deben tener un objetivo específico

Contribuyen en el propósito de tener control, hacer seguimiento y mantener una consistencia

Permiten crear un patrón de constancia

Evitan la necesidad de programar reuniones no definidas en el marco de trabajo adaptativo de Scrum

Cada evento es una oportunidad formal para inspeccionar y adaptar los artefactos Scrum

Principales eventos de Scrum

Reunión

Sprint

Figura 1. Eventos de Scrum

Fuente: elaboración propia con información de Schwaber y Sutherland (2020) y SCRUMstudy (2017)

Reunión de la visión del proyecto

Da inicio al flujo del proyecto

Reunión de los Stakeholders

Se define la visión del proyecto

Fuente de inspiración y enfoque durante todo el proyecto

Debe tener en cuenta el caso de negocio

Figura 3.Características de la reunión de la visión del proyecto

Fuente: elaboración propia con información de SCRUMstudy (2017)

Reunión de planificación del Sprint o Sprint Planning Meeting

Evento de inicio de cada Sprint

Duración máxima de 8 horas para Sprint de 1 mes

Tiene en cuenta las historias de usuario de alta prioridad

Se define el objetivo del Sprint

Producto Owner garantiza a los asistentes los insumos requeridos

Pueden invitar a otras personas como asesores

Figura 4. Características de la reunión de planificación del Sprint

Fuente: elaboración propia con información de Schwaber y Sutherland (2020) y SCRUMstudy (2017)

Temas relevantes para tratar en este evento:

¿Por qué es valioso este Sprint?

¿Qué se puede hacer en este Sprint?

¿Cómo se realizará el trabajo que ha sido elegido?

Figura 5. Temas relevantes de la reunión de planificación del Sprint

Fuente: elaboración propia con información de Schwaber y Sutherland (2020)

Reunión diaria del sprint o Daily Scrum

Aspectos relevantes para tratar en este evento:

Qué problemas o impedimentos se han presentado y que impidan completar las tareas en el sprint?

Qué se hizo el día anterior?

Reunión diaria del Sprint

Qué se va a hacer el día actual?

Figura 6.Características de la reunión diaria del Sprint

Fuente: elaboración propia con información de SCRUMstudy (2017)

Reunión de retrospectiva del Sprint o Retrospect Sprint Meeting

Análisis principales para hacer en este evento:

Qué se hizo bien en el Sprint?

Reunión retrospectiva del Sprint

Cómo esos problemas fueron o no resueltos?

Qué problemas se encontraron en el Sprint?

Figura 8.Análisis principales de la reunión retrospectiva del Sprint

Fuente: elaboración propia con información de SCRUMstudy (2017)

Diferentes herramientas y elementos

Diseñados para maximizar la transparencia respecto a información clave

Pueden ser usados por los Stakeholders y equipo en diferentes momentos del proyecto

Están asociados a las fases de Scrum

¿En qué consisten los artefactos de SCRUM?

Artefactos fase de inicio

Caso del negocio del proyecto Producto owner identificado Scrum master identificado Equipo Scrum identificado Stakeholder(s) identificado Declaración de la visión del proyecto

Épica(s) Prototipos (personas) Backlog priorizado del producto Criterios de terminado Cronograma de planificación del lanzamiento Duración del sprint

1. Caso de negocio del proyecto

También conocido como Business Case

Puede ser un documento bien estructurado o una declaración verbal, formal y detallado o informal y breve Debe expresar la razón para iniciar un proyecto

Se usa en la presentación dirigida a patrocinadores y Stakeholders más relevantes

Stakeholders puedan comprender los beneficios de negocio esperados con el proyecto

Los patrocinadores puedan confirmar que proporcionarán los recursos financieros para el proyecto

Figura 9 Características del caso de negocio del proyecto

Fuente: elaboración propia con información de SCRUMstudy (2017)

Información relevante para incluir en el caso de negocio del proyecto:

Antecedentes del proyecto

Estimaciones de tiempo, esfuerzo y costo

Caso de negocio del proyecto

Lista de riesgos identificados

Análisis FODA y de brecha

Objetivos del negocio

Resultados deseados

Figura 10. Información relevante en el caso de negocio del proyecto

Fuente: elaboración propia con información de SCRUMstudy (2017)

2. Product Owner identificado

Figura 11.Características del Product Owner

De conservar la justificación del negocio para el proyecto

Considerado la voz del cliente

Fuente: elaboración propia con información de SCRUMstudy (2017)

Imagen tomada de:https://letsscrumit.com/scrum roles 2 product owner

Desarrollar

y

Figura 12.Responsabilidades del Product Owner

3. Scrum master identificado

Este rol es un facilitador

Hace de guía para facilitar y enseñar los principios y prácticas de Scrum

Garantiza que se sigan los procesos establecidos en la metodología de Scrum

Contribuye a asegurar que el Equipo Scrum tenga un ambiente propicio

Aporta y propende porque todos comprendan la teoría y práctica de la metodología Scrum

Es un verdadero líder

Figura 13.Características del Scrum master

Fuente: elaboración propia con información de SCRUMstudy (2017)

Imagen tomada de:https://letsscrumit.com/scrum roles 3 scrum master/

5. Stakeholders

Los Stakeholders o partes interesadas del proyecto, son las personas que intervienen en el proyecto, pero no forman parte del equipo scrum, pero de igual forma se considera que tienen uno de los cargos más importante.

Imagen tomada de:https://www.hostgator.mx/blog/que-son-los-stakeholders/ Adicionalmente los Stakeholders son la fuente de información para descubrir, desarrollar, liberar, apoyar y promover el producto, ya que debe promover las herramientas que el equipo necesario, un ejemplo de interesados son los usuarios finales, gerencias, sponsor, equipo de TI, etc.

Cabe resaltar los tipos de interesados que pueden existir al interior de un proyecto, estos son Colabora, Involucra, Consulta e Informa. Con respecto a interesados Colabora son aquellos interesados que demuestran un alto interés y que disponen del empoderamiento necesario sobre el producto, por otro lado, interesados Involucra, que son aquellos que demuestran gran interés, pero poco poder de decisión. También Consulta, que son aquellos que no demuestren interés en el producto, si tienen que influir en el en cualquier momento.

Por último, Informar, estos Stakeholders tiene poco interés y poco poder sobre el producto, es decir que la cantidad de tiempo que ellos invierten debe ser baja.

6. Declaración de la visión del proyecto

La visión permite perfilar los objetivos del proyecto, de manera en que se dirigirá al cliente, como se realizarán las estrategias de desarrollo, adicionalmente se entiende como aquella proyección a futuro, la visión debe ser realista, pero sin dejar de lado cierto margen de ambición que motive y mueva al equipo.

Imagen tomada de: https://5dias.com.py/opinion/adoptemos una vision diferente y aprendamos de los tiempos inciertos

7. Épicas de Scrum

Las épicas son un conjunto de historias de usuario, recogidas dentro de las iniciativas (sinnaps, s.f.). Las épicas por su lado se crean con base en las funcionalidades del producto, de igual forma estas toman más de una sprint o entrega para ser completadas, por ejemplo, las épicas pueden ser Módulo de Autenticación, Evaluación y Creación de cursos.

8. Prototipos

Son personajes ficticios con un gran nivel de detalle y que se caracterizan por representar a la mayoría de los usuarios, así como a diversos Stakeholders quienes no necesariamente usarían directamente el producto final (SCRUMstudy, 2017).

Estos prototipos se crean para identificar las necesidades de los usuarios y su creación contribuye a que el equipo pueda entender mejor a los usuarios, las necesidades que tienen y las metas que buscan

A partir de un prototipo, el Product Owner puede priorizar de manera más efectiva las funciones para crear el Backlog Priorizado del Producto.

Imagen tomada de: https://lafabricadeinventos.com/blog/prototipos-para-que-sirven/

9. Backlog priorizado del producto

Según la guía SCRUM, el backlog priorizado de producto, solo puede ser gestionado por el product Owner, la principal característica del backlog priorizado de producto es que es dinámico, es decir, cambia cada día, puesto que las necesidades del proyecto son diferentes y adaptativas, así mismo las actividades más importantes varían, es por lo cual el product ownerdebehacerunchequeodiario delproductbacklogeinformaral equiposSCRUMsobre sus cambios cotidianos.

10. Criterios de terminado

SegúnlaguíadeSCRUM, los criteriosdeterminado,seaplicanalos diferentes sprint en cada fase, son un conjunto de reglas o de parámetros con los que debe cumplir un cierto entregable para poder dar como finalizada su ejecución; los criterios de terminado entre otras pueden ser aceptados o rechazados si:

• Los miembros del equipo SCRUM así lo determinan.

• No cumple un test al cual se somete una vez finalizado el sprint.

• No cumple con los parámetros de calidad que se estipularon desde e inicio

• No demuestra satisfacer las expectativas del cliente final.

Imagen tomada de: https://dosideas.com/noticias/desarrollo de software/952 definicion de terminado ddt un ejemplo

Se debe tener en cuenta que usualmente el término “criterio de terminado” tiende a confundirse con “criterio de aceptación”, en este sentido, si bien es cierto que comparten ciertas características como la calidad de los entregables, podríamos afirmar que el criterio de terminado es un insumo para poder obtener el criterio de aceptación, puesto que el criterio de terminado solo supone que el entregable ha sido finalizado pero no se hace la revisión completa en conjunto para aceptarlo por parte del cliente final o no.

11. Cronograma de planificación del lanzamiento

Como su nombre lo indica, el cronograma de planificación de lanzamiento, de lo que se encarga principalmente es de tener la organización con fechas estipuladas para poder enviar los entregables al cliente final así mismo, indica los intervalos de tiempo con los que se contara por parte del equipo SCRUM para trabajar en dichos lanzamientos y e sus entregables.

Imagen tomada de: https://arrobasystem.com/blogs/blog/administra tus lanzamientos de productos a traves de un calendario

Es importante recordar que este cronograma también incluye algunas sesiones de planificación las cuales deben estar incluidas con fecha fijada, en dichas sesiones solo se tratan los temas correspondientes al calendario de entregables, lanzamiento y en general a la organización cronológica del equipo, cualquier otro punto que se desee tocar, deberá posponerse para su respectiva fase.

12. Duración del sprint

Por parte de la guía de SCRUM, se recomienda que la duración en tiempo efectivo para el sprint en desarrollo sea de 4 semanas, si bien este es un periodo considerable para tener los entregables de cada sprint, también se debe tener en cuenta que cada sprint tiene diferentes características que lo hacen único y dichos periodos pueden variar desde una semana, hasta 6 semanas, así mismo recordemos que hay proyectos que tienen mayor carga de entregables en las fases tempranas, y otros en fases tardías, por lo tanto, también se deber recordar que la programación de sprints cortos o largos tienen ventajas y desventajas que se deben tener en cuenta.

Imagen tomada de: https://focuscycles.medium.com/cu%C3%A1l es la duraci%C3%B3n ideal de un sprint de trabajo a702f1732cc

Por ejemplo, los Sprints cortos permiten un mayor control de los entregables puesto que se hacen revisiones periódicas, mientras que Sprint más largos pueden dar mayor comodidad y ayudan al trabajo en equipo de los participantes.

Artefactos fase de planificación y estimación

Historias de usuario

Criterios de aceptación historias de usuarios

Lista de tareas del esfuerzo terminado

Sprint backlog

Sprint Burndown Chart

1. Historias de usuario

¿Cómo son historias de usuario?

Son una forma simple de documentar los requerimientos solicitados por los usuarios con oraciones breves, sencillas y fáciles de entender que incluye tres elementos sobre lo que quiere el usuario, respondiendo: ¿Quién? ¿Qué quiere? y ¿Para qué? Para lo cual se necesita saber del negocio o definir la Visión del negocio.

Bill Wake inventó el acrónimo INVEST para describir las características de las historias las cuales deben ser Independientes, Negociables, Valiosas, Estimable, Small (Pequeña) y Testeable (verificarse y validar lo requerido).

• Independiente, es decir, cada una debe corresponder con una única funcionalidad y puede completarse en cualquier orden.

• Negociable, si es pequeña puede formar parte de otras historias, y si es grande, se debe dividir, estos detalles se pueden negociar entre el Product Owner y el equipo Scrum

• Valiosa, debe aportar valor para los procesos del usuario y el cliente

• Estimable, se puede definir la cantidad de trabajo requerido para completarla

• Escalable, pequeña, puntual, simple, entendible y específica, que entre en un post it, que permita asignar una prioridad y ser desarrollada junto con otras historias en una iteración (sprint).

• Testeable, la historia debe ser sencilla y completa en su descripción de manera que cuente con la información suficiente para poder ser comprobada en los criterios de aceptación que se definan para verificar el requerimiento

2.

Criterios de aceptación

¿Qué son los criterios de aceptación?

Un criterio de aceptación se define de manera eficaz mediante el método SMART.

Son las condiciones específicas de cada requerimiento, funcionalidad o requisito respecto a su comportamiento, calidad y definición, para que se puedan entender, desarrollar, comprobar y cumplan con las solicitudes del cliente, son escritas y refinadas por Product Owner, el equipo Scrum.

SMART es el acrónimo de: S Specific, M Measurable, A Achievable, R Relevant, T Time boxed

• Specific: Una tarea debe ser lo suficientemente específica para que todos puedan entenderla comprenderla y desarrollarla.

• Measurable: Debe ser cuantificable y verificable en el tiempo

• Achievable: Se debe poder lograr y realizar para lo que se debe definir de manera sencilla, entendible sin complejidad y específico.

• Relevant: Cada tarea debe ser tener valor y características de manera clara

• Time Boxed: Una tarea debe estar limitada a una duración específica en el tiempo.

Para la definición de los criterios de aceptación orientados a escenarios se incluyen tres elementos para describirlos:

Dado que [Contexto] y adicionalmente [Contexto] cuando [Evento]entonces [Resultado / Comportamiento esperado]

Los Criterios de Aceptación definidos y orientados a condición:

• Contexto acción requerida

Definición de condición para que se pueda ejecutar el contexto de la acción requerida Definición de criterios de aceptación orientado a reglas de definición de información:

• Definición de criterios de aceptación orientado personalizado:

3. Lista de tareas del esfuerzo estimado

¿Qué es la lista de esfuerzo estimado?

Es una lista de tareas asociadas con las historias de usuario incluidas en un sprint (iteración).

Típicamente la precisión de las estimaciones varía dependiendo de las habilidades del equipo.

El esfuerzo estimado se expresa en términos de los criterios de estimación acordados por el equipo.

• Se utiliza también para determinar cuándo el equipo necesita reducir su compromiso o asumir historias de usuario adicionales durante la planificación del sprint.

• El Equipo Scrum utiliza la Effort Estimated Task List durante las reuniones de planificación del sprint a fin de crear el Sprint Backlog y el Sprint Burndown Chart.

• La lista de tareas, desarrollada como parte del proceso de Identificar tareas, incluyendo las estimaciones iniciales de historias de usuario que deben revisarse con base en actividades de estimación más detalladas llevadas a cabo en el proceso de Estimar tareas.

• También pueden ser re-estimaciones que resulten después de revisar los primeros sprints o cambiar el entendimiento colectivo del Equipo Scrum sobre los requerimientos de las historias de usuario. (Guía SBOK, 2017, p 372).

4.

•

El Sprint Backlog es un pronóstico del Equipo de Desarrollo sobre qué funcionalidad habrá en el próximo Incremento y el trabajo necesario para entregar esa funcionalidad en un Incremento "Hecho".

• Debe ser conocido por todo el equipo, para asegurarse que el foco debe estar en este grupo de tareas. la planificación del Sprint no cambia durante el sprint, solo se permite cambiar el plan para poder desarrollarlas.

• El Sprint Backlog hace visible todo el trabajo que el equipo de Desarrollo identifica como necesario para cumplir con el Objetivo Sprint. Para garantizar la mejora continua, incluye al menos una mejora de proceso de alta prioridad identificada en la reunión retrospectiva anterior.

• El Sprint Backlog permite visualizar, durante cada Sprint, aquellos elementos que aún no han empezado a desarrollarse, aquellos que sí y quiénes están trabajando en los mismos, así como aquellos que están esperando a desplegarse o están completamente terminados.1

• Este artefacto permite entender cuál es la evolución del trabajo durante el Sprint, así como hacer un análisis de riesgos.

1 https://www2.deloitte.com/es/es/pages/technology/articles/artefactos scrum.html

• Dado que cada Sprint tiene una meta específica, el Sprint Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. De esta forma, maximizamos el retorno de la inversión en desarrollo.

5. Sprint Burndown Chart

El progreso del proyecto se mide en el burndown chart donde el Scrum Master actualiza el gráfico en cada sprint donde el eje vertical muestra los sprints y el eje horizontal el trabajo pendiente a realizar en el sprint.

La gran ventaja del burndown chart es que permite a todo el equipo conocer lo que está sucediendo y lo avances en cada sprint.

Existen tres tipos de Burndown Chart: Sprint Burndown Chart, release burndown chart y product burndown chart.

Sprint Burndown Chart:

Cada miembro del equipo determina el esfuerzo y tiempo requerido para desarrollar el sprint. Al avanzar el sprint se actualiza el esfuerzo y tiempo de cada tarea. De esta manera el Scrum Master creará el gráfico Burndown Chart.

Release burndown chart:

Es el proceso de las tareas comprendido desde el desarrollo hasta llegar al cliente donde se va liberando el producto cuando cumple los requisitos de funcionalidad y expectativa del cliente. En este momento el producto está constituido por varios Sprints de la misma duración.

Product burndown chart:

Aquí se monitorea el trabajo pendiente para cumplir con los objetivos del producto.

El gráfico muestra los story points del backlog para cada sprint completado representando la evolución de los requisitos en el tiempo.

Un burndown chart está constituido por:

Eje X (horizontal):

Representa la cantidad de tiempo en días para completar el proyecto.

Eje Y (vertical):

Representa el esfuerzo restante para completar el proyecto visualizando las tareas del backlog.

Línea de trabajo real:

Representa el trabajo real por realizar estimando los obstáculos surgidos durante el proyecto al igual que el tiempo adicional para completar la tarea.

En caso de presentarse novedades la línea de trabajo no será lineal.

Línea ideal de trabajo restante (trabajo estimado):

Representa la línea de trabajo del escenario ideal donde la línea siempre será recta.

Puntos de historia:

Representa los días para completar el trabajo.

Objetivo del sprint:

Si el trabajo real no cumple el objetivo es importante tener un objetivo para alcanzar y de esta manera las tareas continúan avanzando.

Figura 15. Burndown Chart

Artefactos fase de implementación

Scrumboard actuallizado

Entregables del sprint

Impediment Log actualizado

1. Scrumboard actualizado

El scrumboard es una instantánea visual del trabajo en equipo donde se planifican los sprints en sus periodos de tiempo para crear un incremento de trabajo a entregar. El scrumboard está constituido por: Historias: Las historias de usuario son listas de trabajo gestionados por el propietario del producto.

To do: Son subtareas que aún no han comenzado donde se incluyen detalles de los propietarios y fechas de entrega. In progress: Son las subtareas en las cuales el equipo está trabajando actualmente. Done: Son las subtareas completadas las cuales se eliminan del sprint.

Figura 16. Scrumboard actualizado

2. Entregables del sprint

Dentro de los entregables del Sprint se encuentran el Product backlog, Burndown chart, Definition of done y Definition of ready.

Definition of done:

El equipo determina cuando una tarea está finalizada para iniciar con otra tarea.

Definition of ready:

El equipo determina cuando una tarea está lista para ser presentada al cliente y a su vez comprendida por todo el equipo.

Figura 17. Entregables del sprint

3. Impediment Log actualizado

Es el listado de riesgos priorizados por nivel de impacto crítico, alto, medio y bajo, para lograr continuar el incremento planeado al inicio del sprint.

Impedimentos más comunes:

Enfermedad de un miembro del equipo.

Dependencia de terceros.

Falta de recursos. Falta de dedicación de product owner.

Restricciones excesivas.

Presión excesiva.

Figura 18. Impedimento log actualizado

2. Entregables aceptados

El objetivo de un SPRINT es la creación de entregables que cumplan con los criterios de aceptación definidos durante la creación de las historias de usuario y socializados a lo largo del desarrollo del SPRINT en los Daily Stand Up meetings, de manera que durante la reunión de revisión del Sprint se pueda obtener la aceptación de por parte del cliente la mayoría o los entregables que mayor valor le puedan aportar al avance del proyecto.

Los entregables no aceptados dentro de la ejecución de un SPRINT se deberán llevar al siguiente con el fin de completar todos los requerimientos del producto definidos por las historias de usuarios.

Figura 20. Características de la reunión de revisión del Sprint

Fuente: GPD Master (2021)

3. Agreed actionable improvements

Las mejoras aceptables acordadas (Agreed Actionable Improvements) son el principal resultados de las reuniones de retrospectiva de los SPRINT, consiste en una lista de mejoras aceptadas por el equipo de proyecto con el fin de mejorar y optimizar los procesos propios del y poder así mejorar el desempeño en futuros SPRINTS.

Como lo hemos identificado a lo largo de este curso la metodología SCRUM se basa en procesos de mejoramiento continuo, esta premisa hace que el este artefacto se convierta en uno de los más importantes ya que de esta forma se pretender garantizar que al final de cada SPRINT se encuentre opciones de mejora que permitan a futuro reducir los tiempos de ejecución, reducir los reprocesos y, de ser posible mejorar la calidad de los entregables en futuros SPRINTS.

Figura 20. Retrospectiva del Sprint Diagrama de flujo de datos.

Fuente: SCRUMStudy (2017, P261)

Es importante resaltar que la metodología SCRUM se basa en el ciclo de calidad PHVA y este artefacto corresponde a la etapa de VERIFICAR donde se evalúa el trabajo realizado en el SPRINT y se listan las opciones de mejora encontradas en la revisión de las tareas realizadas.

Referencias bibliográficas

Chamoun, Y., (2015), Administración Profesional de Proyectos, Mc Graw Hill Editorial.ITESM http://homepage.cem.itesm.mx/alesando/index_archivos/Admon.DeProyectos/app cap1.pdf

Chaouch, S., Mejri, A., & Ghannouchi, S. A. (2019). A framework for risk management in Scrum development process. Procedia Computer Science, 164, 187 192. e-biblioteca UNAD https://doi-org.bibliotecavirtual.unad.edu.co/10.1016/j.procs.2019.12.171

Tavares, B. G., da Silva, C. E. S., & de Souza, A. D. (2017). Risk management analysis in Scrum software projects. International Transactions in Operational Research, 26(5). e biblioteca UNAD https://bibliotecavirtual.unad.edu.co/login?url=http://search.ebscohost.com/login.aspx?di rect=true&db=edselc&AN=edselc.2 52.0 85014662590&lang=es&site=eds live&scope=site

OVI Unidad 3 Eventos y Artefactos de SCRUM

Schwaber, K; Sutherland, J. (2020). La guía definitiva de Scrum: las reglas del juego. https://scrumguides.org/docs/scrumguide/v2020/2020 Scrum Guide Spanish Latin South American.pdf

SCRUMstudy. (2017). Una guía para el Cuerpo de Conocimiento de Scrum. Guía SBOK. 3ra Edición. https://www.tenstep.ec/portal/images/pdfs/Suscripciones_TenStep/Silver/SCRUMstudy _GUIA_SBOK_espanol.pdf

Torres, J. L. (2019). Eventos y Artefactos de SCRUM. Repositorio UNAD https://repository.unad.edu.co/handle/10596/30894

GDP Master (2021). Roles y responsabilidades de un proyecto SCRUM. Rocket 24 Network. URL: https://www.gestiondeproyectos master.com/roles y responsabilidades en un proyecto scrum/