Fase IV: Revisión y retrospectiva #scrum

La fase llamada Revisión y Retrospectiva se ocupa de la revisión de los ntregables y del trabajo que se ha hecho, y determina las mejores prácticas y métodos utilizados para hacer el trabajo relacionado al proyecto.

En las grandes organizaciones, el proceso de Revisión y Retrospectiva puede incluir la convocatoria de Scrum of Scrums Meetings.

Los procesos principales de esta fase:

Convene Scrum of Scrums En este proceso, los representantes del Scrum Team convocan unareunión de Scrum of Scrums (SoS) en intervalos predeterminados o cuando sea necesario para colaborar y realizar un seguimiento de sus respectivos progresos, impediments, y las dependencias entre los equipos. Esto es relevante sólo para grandes proyectos en los que múltiples Scrum Teams están involucrados.

Demonstrate and Validate Sprint En este proceso, el Scrum Team les demuestra el Sprint Deliverable al Product Owner y a los relevantes stakeholders en un Sprint Review Meeting. El propósito de esta reunión es asegurar la aprobación y aceptación del product o servicio por parte del Product Owner.

Retrospect Sprint En este proceso, el Scrum Master y el Scrum Team se reúnen para discutir las lecciones aprendidas a lo largo del Sprint. Esta información se documenta como las lecciones aprendidas que pueden aplicarse a los siguientes Sprints. A menudo, como resultado de esta discusión, puede haber un Agreed Actionable Improvements o Updated Scrum Guidance Body Recommendations.

Scrum Fase III: Implementar #scrum

La fase de Implementar, se relaciona con la ejecución de las tareas y actividades para crear el product de un proyecto. Estas actividades incluyen la creación de varias entregas, la realización de Daily Standup Meetings, y el mantenimiento (es decir, revisiones, ajustes, y actualización periódica) del Product Backlog en intervalos regulares.

Scrum se puede aplicar de manera efectiva a cualquier proyecto en cualquier industria – desde pequeños proyectos o equipos con tan sólo seis miembros por equipo, hasta proyectos grandes y complejos que cuentan con cientos de miembros por equipo.

Importante en esta fase:

Deliverables En este proceso, el Scrum Team trabaja en las tareas del Sprint Backlog para crear Sprint Deliverables. A menudo se utiliza un Scrumboard para realizar el seguimiento del trabajo y actividades que se llevan a cabo. Los issues o problemas que enfrenta el Scrum Team podrían actualizarse en un Impediment Log.

Conduct Daily Standup En este proceso, todos los días se lleva a cabo una reunión Time-boxed altamente concentrada llamada Daily Standup Meeting. Este es el foro donde los miembros del Scrum Team comparten sus progresos y los obstáculos que puedan enfrentar.

 Groom Prioritized Product Backlog En este proceso, el Prioritized Product Backlog se actualiza y mantiene continuamente. Un Prioritized Product Backlog Review Meeting se puede llevar a cabo, en el cual cambios o actualizaciones al backlog se discuten y se incorporan al Prioritized Product Backlog de forma debida.

Algunas Herramientas

Team Expertise: Esto se refiere a la experiencia colectiva de los miembros del Scrum Team para entender los User Stories y tareas en el Sprint Backlog con el fin de crear los entregables finales. La experiencia del equipo se utiliza para evaluar las entradas necesarias para ejecutar el trabajo previsto del proyecto. El juicio y la experiencia de cada miembro se aplica a todos los aspectos técnicos y de gestión del proyecto durante el proceso de Create Deliverables. Los miembros del Scrum Team tienen la autoridad y la responsabilidad de determinar los mejores medios para convertir los elementos Prioritized Product Backlog en productos terminados, sin necesidad de participación de todos los stakeholders del equipo. Experiencia adicional está disponible por parte del Scrum Guidance Body, según sea necesario.

 Software: Las Herramientas de software automatizadas pueden ser utilizadas para la programación, la recopilación de información y la distribución. Las herramientas de colaboración virtuales también son esenciales en projects en los que el Scrum Team no está colocated. Una variedad de herramientas basadas en software automatizadas está disponible permitiendo el seguimiento del progreso, la recopilación y distribución de datos, y contribuyendo a la aceleración de los procesos.

 Otras herramientas de desarrollo: Basado en las especificaciones del proyecto y de la industria, otras herramientas de desarrollo se pueden utilizar.

Refactoring : Es una herramienta específica para los proyectos de software. El objetivo de esta técnica es mejorar el mantenimiento del código existente y hacerlo más simple, más conciso y más flexible. Refactoring significa mejorar el diseño del código actual, sin cambiar el comportamiento del código. Se trata de lo siguiente:

La eliminación de código repetitivo y redundante

Reducir los métodos y las funciones en rutinas más pequeñas

Definir las variables con claridad y los nombres de los métodos

Simplificar el diseño del código

Hacer que el código sea más fácil de entender y modificar

La refactorización regular optimiza el diseño de código de poco a poco, durante un período de tiempo. En última instancia, la refactorización resulta en códigos más fáciles de mantener, mientras se preservan todas las funcionalidades.

Design Patterns: Proporcionan una manera formal de registrar una resolución de un problema de diseño en un campo específico de especialización. Estos patrones registran tanto el proceso que se utiliza, como la misma resolución, que puede ser reusada para mejorar la toma de decisiones y la productividad.

Scrum Fase II: Planear y Estimar #scrum

La fase de Plan and Estimate consiste en procesos relacionados con la planificación y las tareas de estimación, que incluyen Create User Stories, Approve, Estimate, and Commit User Stories, Create Tasks, Estimate Tasks, y Create Sprint Backlog.

Una descripción general de los procesos de la fase Planear y Estimar es la siguiente:

  • Create User Stories En este proceso, User Stories y sus afines User Story Acceptance Criteria se crean. Los User Stories son generalmente escritos por el Product Owner y están diseñados para asegurar que los requisitos del Customer estén claramente representados, y que puedan ser plenamente comprendidos por todos los stakeholders. User Story Writing Workshops se pueden llevar a cabo lo cual implica que los miembros del Scrum Team creen User Stories. Estos User Stories se incorporan en el Prioritized Product Backlog.
  • Approve, Estimate, and Commit User Stories En este proceso, el Product Owner aprueba los User Stories para un Sprint. Luego, el Scrum Master y el Scrum Team estiman el esfuerzo necesario para desarrollar la funcionalidad descrita en cada User Story. Por último, el Scrum Team se compromete a entregar los requisitos del Customer mediante Approve, Estimate, and Commit User Stories.
  • Create Tasks En este proceso, los Approved, Estimated, and Committed User Stories se dividen en tareas específicas y se compilan en un Task List. A menudo, un Task Planning Meeting se lleva a cabo con este fin.
  • Estimate Tasks En este proceso, el Scrum Core Team, en las reuniones de Task Estimation, estima el esfuerzo necesario para realizar cada tarea del Task List. El resultado de este proceso es un Effort Estimated Task List.
  • Create Sprint Backlog  En este proceso, el Scrum Team tiene un Sprint Planning Meeting donde el grupo crea un Sprint Backlog que contiene todas las tareas que deben completarse en el Sprint.

Scrum Fase I: Iniciar – Herramientas #scrum

Herramientas

Project Vision Meeting*

Project Vision Meeting es una reunión con el/los Program Stakeholder(s), Program Product Owner, Program Scrum Master, y Chief Product Owner. Ayuda a identificar el contexto empresarial, business requirements y las expectativas de los stakeholders con el fin de desarrollar un Project Vision Statement eficaz. Scrum cree en la participación y colaboración cercana con todos los representantes de las empresas para obtener su buy-in (convencimiento de su importancia) del project y para ofrecer un valor más significativo.

 

JAD Sessions

Joint Application Design (JAD) Session es una técnica de recopilación de requisitos. Se trata de un taller facilitado altamente estructurado que acelera el proceso de Create Proyect Vision, ya que permite al/a los stakeholder(s) y a otros que toman decisiones llegar a un consenso sobre el alcance, los objetivos, y otras especificaciones del project. Esta técnica consiste en métodos para aumentar la participación del usuario, lo que acelera el desarrollo y la mejora de las especificaciones. Los Relevant Program Stakeholder(s), Program Product Owner, Program Scrum Master y Chief Product Owner podrían reunirse para delinear y analizar los resultados de negocio deseados y visualizar su visión para el project Scrum.

 

SWOT Analysis

SWOT es un enfoque estructurado para la planificación que ayuda a evaluar los/las StrengthsWeaknesses, Opportunities y Threats (puntos fuertes y débiles, oportunidades y amenazas) relacionados con un project. Este tipo de análisis ayuda a identificar tanto los factores internos como externos que podrían afectar el project. Las fortalezas y debilidades son factores internos, mientras que opportunities y amenazas son factores externos. La identificación de estos factores ayuda a los stakeholders y a aquellos que toman decisiones a finalizar los procesos, las herramientas y las técnicas que se utilizarán para lograr los objetivos del project. La realización de un SWOT permite la identificación precoz de las prioridades, los cambios potenciales, y los risks.

 

Gap Analysis

 Gap Analysis es una técnica que se utiliza para comparar el estado actual con el estado deseado. En una organización, se trata de determinar y documentar la diferencia entre las capacidades actuales del negocio y el conjunto final deseado de capacidades. Normalmente, se inicia un proyecto para que una organización alcance una situación deseada, por lo que llevar a cabo un Gap analysis ayudaría a quienes toman decisiones a determinar la necesidad de un project.

Los principales pasos a seguir en Gap Analysis:

sc-h1

Scrum Fase I: Iniciar – Entradas #scrum

Los procesos de Scrum abordan las actividades y el flujo específico de un proyecto Scrum. En total hay diecinueve procesos que se agrupan en cinco fases: Iniciar, Planear y Estimar, Implementar, Revisión y retrospectiva y Lanzamiento.

Los procesos relacionados con la iniciación de un proyecto:

  1. Create Project Vision—En este proceso, el Project Business Case es revisado para crear un Project Vision Statement que servirá de inspiración y proporcionará un enfoque de todo el project. El Product Owner se identifica en este proceso.
  1. Identificar al Scrum Master y al/a los stakeholder(s)—En este proceso, el Scrum Master y los stakeholders se identifican utilizando criterios de selección específicos.
  2. Form Scrum Team—En este proceso, se seleccionan a los miembros del Scrum Team. Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero a menudo lo hace en collaboration con el Scrum Team.
  3. Develop Epic(s)—En este proceso, el Project Vision Statement sirve como la base para el desarrollo de epics. User Group Meetings pueden tomar lugar para discutir el/los Epic(s) apropiado(s).
  1. Create Prioritized Product Backlog—En este proceso, los Epic(s) son refinados, elaborados, y luego priorizados para crear el Prioritized Product Backlog del proyecto. Lo que se conoce como Done Criteria también se establece en este punto.
  1. Conduct Release Planning—En este proceso, el Scrum Core Team revisa los User Stories en el Prioritized Product Backlog para desarrollar un Release Planning Schedule, que es esencialmente un program de implementación por fases que se puede compartir con los stakeholders del project. Los Length of Sprints también se determinan en este proceso.

Entradas

Project Business Case

Un caso de negocio (business case) puede ser un documento bien estructurado o simplemente una declaración verbal que expresa la razón para iniciar un project. Puede ser formal y detallado, o informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los  antecedentes del project, los objetivos del negocio y los resultados deseados, un SWOT y Gap Analysis, una lista de los risks identificados, y las estimaciones de tiempo, el esfuerzo y costo.

El project se inicia con la presentación del Project Business Case. Un caso de negocio se le presenta a los stakeholders y patrocinadores (sponsors). Los stakeholders así comprenden los beneficios de negocio esperados de tal project y los patrocinadores confirman que van a proporcionar los recursos financieros para el project.

 

Program Product Owner

El Program Product Owner es la persona responsable de maximizar el valor del negocio para un program. Él/ella es responsable de la articulación de requisitos de los customers y de mantener business justification para el program y puede aportar de forma importante sobre qué projects deben ser implementados, y de que manera, en un program. El Program Product Owner también administra el Program Product Backlog.

El Program Product Owner interface con el Portfolio Program Owner para asegurar la alineación del programa con las metas y objetivos del portfolio. Él/ella también tiene que ver con el nombramiento de los Product Owners para los proyectos individuales, y debe asegurar que la visión, los objetivos, los resultados, y las liberaciones de los projects individuales en el program estén alineados con los del programa.

 

Program Scrum Master

El Program Scrum Master es un facilitador que asegura que todos los equipos del project en el program dispongan de un entorno propicio para completar con éxito sus projects. El Program Scrum Master guía, facilita y les enseña las prácticas de Scrum a todos los que participan en el program; también sirve como guía para los Scrum Masters de los distintos projects; elimina los impediments de los diferentes equipos del project; coordina con el Scrum Guidance Body para definir los objetivos relacionados con la normativa de calidad, el gobierno, la seguridad y otros parámetros claves de la organización; y asegura que los procesos de Scrum se estén siguiendo de manera efectiva a lo largo del program.

El Program Scrum Master debe interactuar con el Portfolio Scrum Master para segurar la alineación del program con las metas y objetivos del portfolio. También tiene que ver con el nombramiento del Scrum Masters para projects individuales y debe asegurar que la visión, los objetivos, los resultados, y las liberaciones de los proyects individuales en el program estén alineados con los del program.

 

Program Stakeholder(s)

Program Stakeholder(s) es un término colectivo que incluye a los customers, los usuarios y patrocinadores para un program. Influyen en todos los projects del program durante todo el desarrollo del project. El/Los Program Stakeholder(s) también puede(n) ayudar a definir la visión del project y a proporcionar orientación en relación con el valor del negocio.

El/Los Program Stakeholder(s) debe(n) interactuar con los Portfolio Stakeholders para asegurar la alineación del program con las metas y objetivos del portfolio. Ellos también están involucrados con el nombramiento del/de los Stakeholder(s) para projects individuales y se aseguran que la visión, los objetivos, los resultados, y los lanzamientos de los projects individuales en el program estén alineados con los del program.

 

Chief Product Owner

En el caso de grandes projects con numerosos Scrum Teams, podría ser neceario tener un Chief Product Owner. Esta función se encarga de coordinar el trabajo de los múltiples Product Owners. El Chief Product Owner prepara y mantiene el Prioritized Product Backlog para los projects grandes, usándolo para coordinar el trabajo a través de los Product Owners de los Scrum Teams. Los Product Owners, a su vez, gestionan sus respectivas partes del Prioritized Product Backlog.

El Chief Product Owner también se comunica con el Program Product Owner para asegurar la alineación de los projects grandes con las metas y objetivos del program.

 

Program Product Backlog

El Program Product Owner desarrolla el Program Product Backlog del product que contiene una lista de prioridades de negocios de alto nivel y los requisitos del project escritos preferiblemente en forma de Program Backlog Items del program. Luego, estos son refinados por los Product Owners de los projects individuales, ya que crean y dan prioridad a pedidos pendientes del product para sus projects.

Estos Prioritized Product Backlogs tienen User Stories más pequeños pero detallados que pueden ser aprobados, estimados, y aplicados por miembros del Scrum Team.

El Program Product Owner mantiene de forma continua el Program Product Backlog para garantizar que los nuevos business requirements se añadan y que los requisitos existentes estén debidamente documentados y priorizados. Esto asegura que a los requisitos más valiosos en el cumplimiento de los objetivos del program se les esté dando alta prioridad y que los restantes reciban una prioridad más baja.

El Program Product Backlog creado para el program presenta una imagen más grande de todos los projects que forman parte del program. Por lo tanto, puede servir de orientación en relación con los objetivos del project, el alcance, los objetivos y los beneficios esperados del negocio.

 

Trial Project

Si es factible, un demo o prueba del project en pequeña escala podría ser ejecutado como un experimento para predecir y evaluar la viabilidad, tiempo, costo, risks, y los posibles efectos del project. Esto ayuda a evaluar el entorno de práctica y guías del diseño del project con anterioridad a la iniciación del project.

Proof of Concept

Proof of Concept demuestra y verifica que la idea detrás del proyecto actual es potencialmente viable en el entorno real. A menudo esto se hace en la forma de un prototipo diseñado para determinar la viabilidad técnica y financiera, ayudar a comprender los requisitos, y ayudar en la evaluación de las decisiones de diseño al principio del proceso. Sin embargo, Proof of Concept no necesita representar necesariamente los verdaderos Deliverables (Entregables) del project.

Company Vision

La comprensión del Company Vision ayuda a que el project mantenga su enfoque en los objetivos de la organización y el futuro probable de la empresa. El Product Owner se puede guiar por el Company Vision para crear el Project Vision Statement.

 

Company Mission

Company Mission ofrece un marco para la formulación de las estrategias de la empresa y orienta la toma de decisiones en general en la empresa. Project Vision debe enmarcarse de tal manera que su cumplimiento ayuda a la organización a llevar a cabo su misión.

 

Market Study

Market Study se refiere a la investigación organizada, la recopilación, la comparación y el análisis de datos relacionados con las preferencias de los customers sobre los products. A menudo incluye numerosos datos sobre las tendencias del mercado, la segmentación del mercado y los procesos de comercialización.

Estudio de mercado podría incluir también un estudio analítico de los competidores que proporciona una mejor comprensión de las fortalezas y debilidades de los competidores y puede ayudar a los que toman decisiones a formular productos mejor posicionados.

Recomendaciones del Scrum Guidance Body

El Scrum Guidance Body (SGB) es una función opcional. Por lo general, se compone de un grupo de documentos y/o un grupo de expertos que normalmente están involucrados en la definición de objetivos relacionados con la calidad, las regulaciones gubernamentales, la seguridad y otros parámetros claves de la organización. Estos objetivos guían la labor llevada a cabo por el Product Owner, Scrum Master, y el Scrum Team. El Scrum Guidance Body también ayuda a capturar las mejores prácticas que se deben utilizar en todos los projects Scrum en la organización.

El Scrum Guidance Body no toma decisiones relacionadas con el project. Este actúa como una consultoría o una estructura de orientación para todos los niveles de jerarquía en el project de organización del portfolio, program y project. Los Scrum Teams tienen la opción de pedirle asesoramiento al Scrum Guidance Body.

Es importante asegurarse de que la visión del project esté alineada con las recomendaciones proporcionadas por el Scrum Guidance Body y que los procesos cumplan con las normas y directrices establecidas por el Body (la Administración).

Artefactos Scrum #scrum

En Scrum los Artefactos son los resultados, o productos, de las actividades de gestión. Están diseñados para aumentar la transparencia de la información relativa a la entrega del proyecto, y propiciar oportunidades para la inspección y adaptación del mismo.

En Scrum hay seis artefactos:

  1. El Backlog de Producto (https://proyectosagiles.org/lista-requisitos-priorizada-product-backlog/): una lista ordenada de todos los elementos que podría necesitar el producto final, conocidos como historias o historias de usuario.
  2. El Backlog del Sprint (https://proyectosagiles.org/lista-tareas-iteracion-sprint-backlog/ ): se compone de los artículos seleccionados (historias) del Backlog del Producto que se entregarán a través de un Sp int, junto con el objetivo del Sprint y los planes para la entrega de los artículos y la realización del objetivo del Sprint.
  3. Incremento (https://www.scrummanager.net/bok/index.php?title=Incremento) : se refiere al conjunto de todos los elementos “completos” del Backlog del Producto hasta el fin del Sprint actual.
  4. La definición de “Completo” (http://managementplaza.es/blog/la-definicion-completo-scrum/) : es la comprensión compartida entre todos los miembros del Equipo de Desarrollo de lo que significa que un elemento de trabajo se considere “completo”, 100% realizado.
  5. Monitoreo del progreso hacia la meta (http://managementplaza.es/blog/seguimiento-del-progreso-proyectos-scrum/) se refiere a la medición de los resultados y las previsiones para todo el proyecto
  6. Monitoreo del progreso hacia el Sprint (http://managementplaza.es/blog/seguimiento-del-progreso-del-sprint-scrum/) : es la medición de los resultados y las previsiones para un solo Sprint

Les invito a visitar cada uno de los link que hace explicación de calidad para entender en forma correcta cada uno de los artefactos

Los 05 Eventos Scrum: Evento 5 Retrospectiva del Sprint #scrum

Es una reunión de tres horas para Sprints de un mes, y proporcionalmente más corta en función de la duración del Sprint.

Después de la Revisión de Sprint y justo antes del final del Sprint, se lleva a cabo una reunión cuyo objetivo es la mejora de procesos (lecciones aprendidas), que se conoce como Retrospectiva del Sprint.

En Scrum la regla es que debemos buscar constantemente formas de mejorar, no importa lo pequeña que sea la mejora, pero debe haber una mejora. Esta reunión es una oportunidad formal para generar mejoras, aunque no debemos limitarnos ni esperar a los resultados de esta reunión; debemos buscar y aplicar mejoras constantemente.

Durante la Retrospectiva del Sprint inspeccionaremos el Sprint actual en lo referente a las personas, los procesos y las herramientas, e identificaremos formas de mejorar para el próximo Sprint.

Refinamiento del Backlog del Producto

Además de los eventos de tiempo limitado (time box) que hemos comentado, existe una actividad en los proyectos Scrum conocida como “refinamiento” del Backlog del Producto.

Consiste en revisar y modificar los elementos del Backlog del Producto y normalmente implica añadir detalles, estimaciones y ordenar los elementos. Mientras que el Dueño del Producto es responsable de ordenar (priorizar) los artículos, el equipo de desarrollo es responsable de estimar el esfuerzo requerido para completarlos.

La principal diferencia entre esta actividad y los cinco eventos de Scrum es que los eventos de Scrum se realizan todos en “bloques o cajas de tiempo” pero el “refinamiento” es una actividad constante que sucede a lo largo de todo el Sprint. Esta actividad no debe consumir más de un 10% del tiempo del equipo de desarrollo.
 

Los 05 Eventos Scrum: Evento 4 Revisión del Sprint #scrum

La duración de esta reunión es normalmente de cuatro horas para Sprints de un mes. Si los Sprints son más cortos, la reunión será proporcionalmente más corta.

Al final del Sprint el Equipo Scrum y las otras partes interesadas se reúnen y mantienen una reunión de tiempo limitado en función de la duración del Sprint, para presentar y revisar los artículos “Completos”, el incremento del actual Sprint, y actualizar el Backlog del Producto. El propósito de presentar el incremento en esta reunión, es recabar información y conocer las solicitudes de cambio a la mayor brevedad.

El equipo de desarrollo no presentará un elemento a menos que este completo al 100% en base a la definición acordad de “Completo”. El Dueño del Producto debe asegurarse antes de la Revisión del Sprint, que los elementos que se presentan están “completos”. El Equipo de Desarrollo es responsable de demostrar y explicar los elementos.

El Dueño del Producto examina el estado del Backlog del Producto y las fechas de probables de finalización y los progresos realizados.

Por último, todo el equipo de Scrum participa en la revisión del backlog delproducto en base a los resultados del Sprint y el feedback del cliente.

 

Los 05 Eventos Scrum: Evento 2 Planificación del Sprint #scrum

La reunión de planificación del sprint es uno de los eventos de scrum técnico.  Les recomiendo visitar el siguiente link para ver detalles antes de leer este post.

El Equipo de desarrollo no tiene que esperar hasta que el Backlog de Producto esté planificado al 100% para comenzar a desarrollar el proyecto. Tan pronto como el Backlog de Producto esté lo bastante maduro, tenga el número necesario de historias como para proporcionar la información de primer Sprint, el Dueño del Producto y el Equipo de Desarrollo comienzan con el primer Sprint.

El equipo de desarrollo debe estimar la capacidad de trabajo que puede ofrecer en un solo Sprint. Previamente el Dueño del Producto ya ha clasificado y ordenado los elementos del Backlog del Producto en base al valor de los artículos. El Dueño del Producto también es responsable de asegurarse de que los elementos (historias) sean fáciles de entender.

A continuación el equipo de desarrollo selecciona un número de elementos de la parte superior del Backlog del Producto y los pone en el Backlog del Sprint, para completarlos y entregarlos en el Sprint actual. Es el Equipo de Desarrollo el que calcula la cantidad de trabajo que requiere cada artículo. La cantidad total de trabajo de los elementos seleccionados del Backlog del Producto, debería estar cerca de la capacidad de trabajo estimada del Equipo de Desarrollo.

Seleccionados los artículos, el Equipo Scrum debería redactar el objetivo del Sprint. El objetivo del Sprint es el objetivo que debería alcanzarse durante el Sprint a través del desarrollo de los elementos seleccionados del Backlog del Producto, y proporciona orientación al Equipo de Desarrollo sobre por qué se está construyendo el incremento.

El Backlog del Producto debería estar ordenado de forma que facilite el establecimiento del objetivo del Sprint. Establecer y redactar el objetivo del Sprint es responsabilidad de todo el equipo Scrum.

El alcance del Sprint, que está compuesto por los distintos elementos seleccionados del Backlog del Producto, podría necesitar un mayor grado de detalle conforme el Sprint vaya evolucionando. Este mayor grado de detalle, deberá estar siempre alineado con el Objetivo del Sprint, y en el caso que fuera necesario negociarse, deberá estar presente el Dueño del Producto. El objetivo del Sprint también se incluye en el Backlog del Sprint.

Una vez seleccionado los elementos a entregar y establecido el objetivo del Sprint, es momento de planificar cómo los distintos artículos del Backlog del Sprint van a “transformarse” en un incremento del producto “Completo”, y como a través de estos se hará realidad el objetivo del Sprint. Esta es la última parte del Backlog del Sprint.

Un plan detallado es un elemento del Backlog de Producto (historias de usuario) descompuesto en tareas que habrá que hacer con el fin crear dicho elemento. Cada tarea puede contener estimaciones, dependencias y cualquier otra información similar necesaria para su seguimiento.

Las notas adhesivas amarillas (post-its) son las tareas que se crean al descomponer cada una de las historias de usuario (azules). Estas tareas (en amarillo) definen lo que el equipo de desarrollo va a hacer para entregar cada elemento, y son responsables de su preparación. Algunas tareas se crean en la reunión de Planificación del Sprint, y otros a lo largo de todo el Sprint.

El Backlog del Sprint está compuesto de:

  1. El Objetivo del Sprint
  2. Los artículos seleccionados del Backlog de Producto, que se entregarán a través de la Sprint (en azul)
  3. Un plan detallado para convertir los elementos seleccionados (historias o historias de usuario) en un Incremento “Completo” del producto y realizar el objetivo del Sprint

Puedes observar en el Tablón del Sprint los tres elementos del Backlog del Sprint: 1) el Objetivo del Sprint, 2) los elementos seleccionados del Backlog del Producto para completar en el Sprint, y 3) el plan detallado. El tablón cuenta además con otras características adicionales que permiten el seguimiento de las tareas en las columnas “Pendiente“, “En Progreso” y “Completado“.

tablero1

También puedes observar que se han añadido tareas adicionales a los elementos situados en la parte baja del cuadro (item # 3 al # 5). Son el resultado de la planificación detallada que se lleva a cabo durante el Sprint.

tablero2

Los elementos del Backlog del Sprint guardan por lo general el mismo orden que tenían en el Backlog del Producto, por lo tanto, el equipo de desarrollo debe trabajar primero en los artículos de la parte alta de la tabla.

Cuando escalamos Scrum, los miembros de cada uno de los equipos de desarrollo se reúnen con el Dueño del producto y seleccione sus elementos. De esta manera, cada equipo forma su propio Backlog del Sprint por separado, pero sobre un único Backlog de Producto.

Te recomiendo visitar:  Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard)

 

Los 05 Eventos Scrum: Evento 01 El Sprint #scrum

Un proyecto que sigue Scrum se gestiona en base a cinco eventos claves:

scrum evento 1

Evento 1: El Sprint

En un proyecto Scrum el producto final se entrega después de un número de iteraciones, que se llaman Sprints. En cada Sprint se desarrolla un incremento, que es una parte potencialmente entregable del producto final. Un incremento es la suma de todos los elementos del Backlog de Producto completados hasta un punto determinado del proyecto, que continuará creciendo tras de cada Sprint hasta que el proyecto concluya.

Puedes considerar que cada nuevo Incremento al final de un Sprint es una versión actualizada del Incremento anterior, con nuevos características y funcionalidades, y que puede o no entregarse al cliente, pero siempre debe ser potencialmente entregable.

La clave está en que generalmente los clientes solicitan cambios cuando ven el incremento, durante la Revisión del Sprint. Estas nuevas solicitudes se añaden al Backlog de Producto y se desarrollaran en función de su valor (valor de negocio). Recuerda que es el Dueño del Producto el encargado de esta establecer los criterios para determinar el valor de cada uno de los elementos del Backlog de Producto.

Cada elemento del Backlog del Producto (historia de usuario) debería poder completarse en un Sprint, ya que así son mucho más fáciles de gestionar. El Dueño del Producto y el Equipo de Desarrollo seleccionan los artículos de la parte superior del Backlog de Producto, que ya ha sido previamente ordenado por el Dueño del Producto. Su objetivo es conseguir que estos estén “Completo” al 100% cuando el Sprint termine, y generar un incremento. Un incremento es la suma de todos los elementos completados durante el Sprint actual y todos los Sprints anteriores.

Es importante llegar a un acuerdo sobre una definición de “completo” al inicio del proyecto. No diremos que algo está “completo”, a menos que se ajuste a dicha definición. Un elemento hecho al 99.999% no puede ser considerado como “completo”, no sería parte del incremento y por lo tanto no sería mostrado al cliente durante la Revisión del Sprint.

Sprint time box: La mayoría de las organizaciones trabajan con Sprints de entre 2 y 4 semanas. Si trabajamos con Sprints más largos es probable que los cambios no aplicados sean lo suficientemente “grandes” como para generar problemas, aumentando la complejidad y el riesgo. Por lo tanto debemos limitar los Sprints a no más de un mes de calendario. Pero por otro lado, los Sprints tampoco deben ser demasiado cortos porque entonces no seremos capaces de producir artículos completos durante los mismos. Recuerda que nuestro objetivo es ofrecer al cliente el producto, o solución final, artículo por artículo, dentro de los límites de los Sprints; no queremos dividir la realización de un artículo del Backlog de Producto entre varios Sprints.

¿Puede cancelarse un sprint? A pesar de que como ya sabemos los Sprint son “bloques de tiempo” que no cambian, el Dueño del Producto tiene la autoridad para cancelar un Sprint. Esto puede suceder cuando el Objetivo de Sprint ha quedado obsoleto, bien por cambios en el Backlog de Producto, en la estrategia, en el enfoque, etc. Cuando se cancela un Sprint, los elementos que están “completos” son revisados y aceptados, y el resto de los artículos (aquellos que no se han iniciado o están parcialmente completos) se añaden de nuevo al Backlog del Producto para completarse en el futuro, en caso de que fuera necesario.