INCREMENT

ARTEFACTOS
Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado cada Sprint. El Incremento es la suma de todas las tareas, casos de uso, user stories y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software al final del mismo Un incremento es el resultado del Sprint. Es una pieza de Software, acorde con los elementos seleccionados durante el Sprint Planning del Sprint Backlog que aporta un valor de negocio al producto que se está desarrollando Construir software de manera ágil se basa en hacerlo de manera iterativa e incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del software: Planificación, diseño, desarrollo, testeo y entrega…
Leer más

SPRINT BACKLOG

ARTEFACTOS
Una vez que se hace el Sprint Backlog, todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo del Sprint y está gestionado por el Development Team. Su propósito es mantener la transparencia dentro del desarrollo El Sprint Backlog nos proporciona una visión del trabajo a realizar durante el Sprint actual. Está gestionado por el equipo de desarrollo, que se encarga de mantenerlo actualizado y transparente durante toda la iteración, especialmente a través de los daily Scrums Después del Sprint Planning, el equipo de desarrollo obtiene una lista de elementos en los que van a trabajar durante un Sprint. Estos elementos normalmente se deshacen en tareas técnicas más pequeñas. Facilitan la implementación…
Leer más

PRODUCT BACKLOG

ARTEFACTOS
El Product Backlog es un inventario. Contiene cualquier tipo de trabajo que haya que hacer en el producto. Requerimientos, casos de uso, tareas, dependencias. Todas ellas están representadas en el Product Backlog y este es la fuente principal de información sobre el producto en Scrum. El Product Backlog es una lista en cualquier formato que contiene todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con los distintos Stakeholders de la organización, y refleja el estado real del trabajo pendiente de implementar en un producto El Product Backlog está gestionado por el Product Owner. Puede contener cualquier tipo de tarea en cualquier formato y su única condición es que esté priorizado con aquellos items que tienen más valor en ese…
Leer más

SPRINT RETROSPECTIVE

EVENTOS
La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En ella se hacen transparentes los problemas del equipo y se llegan a acuerdos para solucionarlos. También se inspecciona y adapta la definition of Done Justo después del Sprint Review, ocurre la retrospectiva, que marca el fin del Sprint. El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo Sprint. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal que distintos miembros del equipo Scrum vayan rotando el rol de facilitador durante la retrospectiva. Un formato común es analizar Qué ha ido bien durante el Sprint, Qué ha fallado y Qué se puede mejorar. Este formato se puede facilitar pidiendo a los miembros del…
Leer más

SPRINT REVIEW

EVENTOS
El Sprint Review es una reunión que ocurre al final del Sprint, donde el Product Owner presenta a los Stakeholders el Incremento terminado para su inspección y adaptación. Esta reunión, organizada por el Product Owner, es el momento de medir cual es la situación y actualizar el Product Backlog con nuevas condiciones que puedan afectar al negocio. El Sprint Review marca la finalización de un Sprint. El equipo ha pasado hasta cuatro semanas desarrollando un incremento terminado de software que ahora mostrará a los Stakeholders. Para ello, el Product Owner se encarga de convocar una reunión donde se revisaran varias cosas. No se trata de una demostración, sino de una reunión de trabajo. El software ya ha sido mostrado y validado junto con el Product Owner Por un lado, se…
Leer más

DAILY MEETING

EVENTOS
El Daily Scrum es una reunión diaria de planificación de 15 minutos en la que participa el Development Team. Durante el Daily Scrum, se inspecciona el Sprint Backlog y se adaptan las tareas. Se hacen transparentes los impedimentos y el progreso hacia el Sprint Goal. El Daily Scrum es una reunión de inspección y adaptación en Scrum de una duración de unos 15 minutos. Durante esta reunión, el equipo de desarrollo se reúne y analizan cuales son los elementos en los que están trabajando y que impedimentos encuentran. También comunican si existe riesgo de no alcanzar la meta marcada durante el Sprint -el Sprint goal-. En Scrum existen varios feedback loops, pequeñas interacciones que nos dan la oportunidad de inspeccionar y adaptar nuestro trabajo. Eso nos permite planificar riesgos y…
Leer más

SPRINT PLANNING

EVENTOS
El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el producto backlog y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente sprint. Durante esta reunión el Product Owner presenta el Product Backlog actualizado, que el equipo de desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crean necesarios. En el Sprint Planning participa el equipo Scrum al completo, pero no Stakeholders. En el Sprint Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y la Definition of Done y se adaptan el Sprint Backlog, el Forecast y el Sprint GoalEl Sprint Planning se divide en dos partes.…
Leer más

SPRINT

EVENTOS
El sprint es un contenedor para el resto de los eventos de Scrum. El Sprint es continuo, es decir, su duración no cambia y se puede interpretar como una medida de ritmo que no cambia a lo largo del tiempo y nos permite reducir complejidad y comparar resultados a lo largo de diferentes Sprints. El Sprint sirve a la transparencia Y permite inspeccionar y adaptar todos los otros eventos de Scrum. Scrum prescribe que un Sprint debe durar 30 días o menos. La duración de un Sprint está determinada por el periodo mínimo en que un equipo de desarrollo puede generar valor a través de un Incremento terminadoEl Sprint es una iteración definida (time boxed) que sirve al desarrollo iterativo e incremental. Todo el desarrollo se realiza durante el mismo…
Leer más

DEVELOPMENT TEAM

ROLES
El Equipo de desarrollo está formado por 3 a 9 profesionales que se encargan de desarrollar el producto, se autoorganizan y deciden cual es la mejor manera de conseguir entregar un incremento de software al final del ciclo de desarrollo. Nótese que en Scrum no importa el número de individuos sino el rol, y este solo hay uno, independientemente de cuantos miembros tenga el equipo de desarrollo y cuales sean sus roles internos. Cómo el equipo de desarrollo decida gestionarse internamente es su propia responsabilidad y tiene que rendir cuentas por ello; hay que evitar intervenir en sus dinámicas. El equipo de desarrollo se encarga de crear un incremento terminado a partir de los Product Backlog items seleccionados durante el Sprint Planning. El Equipo de desarrollo tiene un tamano recomendado…
Leer más

SCRUM MASTER

ROLES
El Scrum Master se encarga de gestionar y asegurar el proceso Scrum, que éste se lleva a cabo correctamente y de facilitar la ejecución del proceso y sus mecánicas, siempre atendiendo a los tres pilares del control empírico de procesos. Además, se encarga de eliminar impedimentos que puedan afectar a la entrega de producto. También se encarga de hacer coaching al resto del equipo Scrum cuando lo necesitan, además de facilitar reuniones y eventos si es necesario. El Scrum Master puede ser compartido entre varios equipos, aunque su disponibilidad afectara al resultado final del proceso Scrum.
Leer más