Curso de Scrum para Gestión de Proyectos de Software

En este curso de Scrum estudiaremos 5 partes, cada una abarcando la información necesaria para ser todo un experto en el término. Gestionar los trabajos nunca fue tan fácil e interesante con este método, por eso es que hemos decido realizar un curso intensivo para que pueda ser aprendido en poco tiempo. Su complejidad no es tanta, pero, si necesita de un análisis adecuado para poder aplicarlo correctamente.

Curso Scrum: ¿Qué es? - Manifiesto Ágil - Cuando usar - Parte 1

En esta primera parte, nos enfocaremos en las definiciones básicas de los términos más usados en la metodología Scrum. Además, se verá una pequeña comparativa que tiene Scrum y el Manifiesto Ágil, sabrás en qué momento usarlo y para qué sirve exactamente. Notarás que la gestión de la empresa mejorará conforme se vaya aplicando el método.

Curso Scrum: Línea de Tiempo de Scrum - Actividades de Sprint - Parte 2

En la segunda parte del Curso Scrum, estudiaremos la línea de tiempo del Scrum. Sabrás cómo comienza y que lo más importante en este espacio sería el "Sprint". Verás todo lo relacionado al término, inclusive, las actividades Sprint que se hacen con regularidad.

Curso Scrum: Funciones de Scrum - Roles de Scrum - Parte 3

Haciendo un seguimiento de lo que fue la parte 3 del Curso Scrum, continuamos con los Roles que se cumplen en la metodología. Estudiaremos nuevos términos como el Maestro Scrum y el resto de conceptos que requieren análisis para poder llevarlo a la práctica.

Curso Scrum: Eventos Scrum - Flujo de Trabajo - Parte 4

En este apartado veremos la forma en que el evento Scrum se va clasificando en varios segmentos para un correcto seguimiento en los tiempos. Además, el flujo de trabajo será protagonista del evento para un mejor rendimiento en el proceso de creación de actividades Scrum.

Curso Scrum: Artefactos y Documetnos de Scrum - Product Backlog - Sprint backlog - Parte 5

Cerramos el curso al examinar detalladamente lo que son los artefactos y los documentos de Scrum. Buscará, como tal, hacer un correcto uso del procedimiento al manejar los tiempos en un cuadro didáctico. Asimismo, se estudiará el Product Backlog y el Sprint Backlog visto en Scrum.

Sigue de cerca las siguientes partes del Curso Scrum:

Ideas clave

Scrum es un marco iterativo e incremental para la gestión del desarrollo de productos. Se define como "una estrategia de desarrollo de productos flexible y holística en la que un equipo de desarrollo trabaja como una unidad para alcanzar un objetivo común", cuestiona los supuestos del "enfoque tradicional y secuencial" para el desarrollo de productos, y permite a los equipos autoorganizarse fomentando la co-ubicación física o la estrecha colaboración en línea de todos los miembros del equipo, así como la comunicación diaria cara a cara entre todos los miembros del equipo y las disciplinas implicadas.

Un principio clave de Scrum es el doble reconocimiento de que los clientes cambiarán de opinión sobre lo que quieren o necesitan (a menudo llamado volatilidad de los requisitos) y que habrá retos impredecibles para los que no es adecuado un enfoque predictivo o planificado. Como tal, Scrum adopta un enfoque empírico basado en la evidencia, aceptando que el problema no puede ser plenamente comprendido o definido de antemano, y en su lugar se centra en cómo maximizar la capacidad del equipo para entregar rápidamente, para responder a las necesidades emergentes, y para adaptarse a las tecnologías en evolución y los cambios en las condiciones del mercado.

Muchos de los términos usados en Scrum (por ejemplo, scrum master) son típicamente escritos con mayúsculas (por ejemplo, Scrum Master) o como palabras conjuntas escritas en camel case (por ejemplo, ScrumMaster). Sin embargo, para mantener un tono enciclopédico, este artículo utiliza el caso de la oración normal para estos términos, a menos que sean marcas reconocidas (como Certified Scrum Master). Esto se ve ocasionalmente escrito en todas las mayúsculas, como SCRUM. La palabra no es un acrónimo, así que esto no es correcto; sin embargo, probablemente surgió debido a un primer documento de Ken Schwaber que puso en mayúsculas SCRUM en su título.

Si bien se ha permitido que la marca registrada con el término Scrum en sí misma caduque, de modo que se considera que pertenece a la comunidad en general y no a un individuo, se conserva el capital principal, excepto cuando se utiliza con otras palabras (como en el scrum diario o en el equipo de scrum).

Historia

Hirotaka Takeuchi e Ikujiro Nonaka introdujeron el término scrum en el contexto del desarrollo de productos en su artículo de 1986 de la Harvard Business Review, "New New Product Development Game". Takeuchi y Nonaka argumentaron más tarde en The Knowledge Creating Company que se trata de una forma de "creación de conocimiento organizacional, [...] especialmente buena para producir innovación de forma continua, incremental y espiral".

Los autores describieron un nuevo enfoque para el desarrollo de productos comerciales que aumentaría la velocidad y la flexibilidad, basado en estudios de casos de empresas manufactureras de los sectores de automoción, fotocopiadoras e impresoras. Llamaron a esto el enfoque holístico o de rugby, ya que todo el proceso es realizado por un equipo multifuncional a través de múltiples fases superpuestas, donde el equipo "trata de ir la distancia como una unidad, pasando el balón hacia adelante y hacia atrás"(En el fútbol de rugby, se utiliza un scrum para reiniciar el juego, ya que los delanteros de cada equipo se entrelazan con la cabeza hacia abajo e intentan obtener la posesión del balón).

A principios de la década de 1990, Ken Schwaber utilizó lo que se convertiría en Scrum en su compañía, Advanced Development Methods; mientras que Jeff Sutherland, John Scumniotales y Jeff McKenna, desarrollaron un enfoque similar en Easel Corporation, refiriéndose a él usando la palabra Scrum.

En 1995, Sutherland y Schwaber presentaron conjuntamente un documento que describía el marco Scrum en el Taller de Diseño e Implementación de Objetos de Negocio (Business Object Design and Implementation Workshop) celebrado como parte de la Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones (OOPSLA) en Austin, Texas. En los años siguientes, Schwaber y Sutherland colaboraron para combinar este material -con su experiencia y buenas prácticas en evolución- para desarrollar lo que se conoció como Scrum.

En 2001, Schwaber trabajó con Mike Beedle para describir el método en el libro, Agile Software Development with Scrum. El enfoque de Scrum para planificar y gestionar el desarrollo de productos implica llevar la autoridad en la toma de decisiones al nivel de las propiedades y certezas de las operaciones.

En 2002, Schwaber fundó, junto con otros, la Scrum Alliance y creó la serie de acreditaciones Certified Scrum. Schwaber dejó la Scrum Alliance a finales de 2009 y fundó Scrum.org, que supervisa la serie paralela de acreditaciones Professional Scrum.

Desde 2009, existe un documento público llamado The Scrum Guide que define una especie de versión oficial de Scrum y que es revisado ocasionalmente. En 2018 se amplió con la publicación de la Guía Kanban para equipos Scrum.

Roles

Hay tres funciones básicas en el marco de Scrum. Estos están idealmente ubicados en el mismo lugar para ofrecer incrementos de producto potencialmente transportables en cada sprint. Juntos, estos tres roles forman el equipo de scrum. Mientras que muchas organizaciones tienen otros roles involucrados en la definición y entrega del producto, Scrum define sólo estos tres.

Propietario del producto

El propietario del producto representa a las partes interesadas del producto y la voz del cliente, y es responsable de garantizar que el equipo aporte valor al negocio. El propietario del producto define el producto en términos centrados en el cliente (típicamente historias de usuarios), los agrega a la cartera de productos y los prioriza en función de su importancia y dependencias. Los equipos de Scrum deben tener un propietario de producto. Este rol no debe ser combinado con el del scrum master. El propietario del producto debe centrarse en el aspecto empresarial del desarrollo del producto y pasar la mayor parte de su tiempo en contacto con las partes interesadas y no debe dictar cómo el equipo llega a una solución técnica. Este papel es equivalente al papel de representante del cliente en otros marcos de trabajo ágiles como la programación extrema (XP).

La comunicación es una responsabilidad fundamental del propietario del producto. La capacidad de transmitir prioridades y sentir empatía con los miembros del equipo y las partes interesadas es vital para dirigir el desarrollo del producto en la dirección correcta. El papel del propietario del producto cierra la brecha de comunicación entre el equipo y sus grupos de interés, sirviendo como representante de los grupos de interés para el equipo y como representante del equipo ante la comunidad general de grupos de interés.

Como cara del equipo a los grupos de interés, las siguientes son algunas de las tareas de comunicación del propietario del producto a los grupos de interés.

• Demuestra la solución a las partes interesadas clave que no estuvieron presentes en una revisión de sprint;
• Define y anuncia los lanzamientos;
• Comunica el estado del equipo;
• Organiza revisiones de hitos;
• Educa a las partes interesadas en el proceso de desarrollo;
• Negocia las prioridades, el alcance, la financiación y el calendario;
• Garantiza que la cartera de pedidos sea visible, transparente y clara.

La empatía es un atributo clave que debe tener el propietario de un producto: la capacidad de ponerse en la piel del otro. El propietario de un producto conversa con diferentes partes interesadas, que tienen una variedad de antecedentes, funciones laborales y objetivos. El propietario de un producto debe ser capaz de ver desde estos diferentes puntos de vista. Para ser eficaz, es aconsejable que el propietario de un producto conozca el nivel de detalle que necesita la audiencia. El equipo de desarrollo necesita una retroalimentación completa y especificaciones para poder construir un producto a la altura de las expectativas, mientras que un patrocinador ejecutivo sólo necesita resúmenes de los avances. Proporcionar más información de la necesaria puede hacer que las partes interesadas pierdan interés y tiempo. Un medio de comunicación directo es el preferido por los propietarios de productos ágiles y experimentados.

La capacidad del propietario de un producto para comunicarse de manera efectiva también se ve mejorada por su habilidad en técnicas que identifican las necesidades de las partes interesadas, negocian las prioridades entre los intereses de las partes interesadas y colaboran con los desarrolladores para asegurar la implementación efectiva de los requisitos.

Equipo de desarrollo

El equipo de desarrollo es responsable de entregar incrementos de producto potencialmente transportables cada sprint (el objetivo sprint).

El equipo tiene de tres a nueve miembros que llevan a cabo todas las tareas necesarias para construir los incrementos de producto (análisis, diseño, desarrollo, pruebas, redacción técnica, etc.) Aunque habrá varias disciplinas representadas en el equipo, sus miembros se denominan genéricamente desarrolladores. Para evitar la confusión potencial de que esto sólo se refiere a los programadores, algunas organizaciones llaman a esto un equipo de entrega y a sus miembros sólo miembros del equipo.

El equipo de desarrollo en Scrum se auto-organiza, aunque puede haber interacción con otros roles fuera del equipo, como una oficina de gestión de proyectos (PMO).

Maestro Scrum

Scrum es facilitado por un maestro de Scrum, quien es responsable de eliminar los impedimentos a la habilidad del equipo para entregar los objetivos y entregables del producto. El maestro no es un líder de equipo o gerente de proyecto tradicional sino que actúa como un amortiguador entre el equipo y cualquier influencia que lo distraiga. El maestro de scrum se asegura de que se siga la estructura. El maestro de scrum ayuda a asegurar que el equipo siga los procesos acordados en el marco de Scrum, a menudo facilita sesiones clave, y anima al equipo a mejorar. También se ha hecho referencia a esta función como facilitador del equipo o líder-sirviente para reforzar estas perspectivas duales.

Las responsabilidades centrales de un maestro de scrum incluyen (pero no se limitan a):

• Ayudar al propietario del producto a mantener la cartera de pedidos de manera que se asegure de que el trabajo necesario se
• Entienda bien para que el equipo pueda progresar continuamente.
• Ayudar al equipo a determinar la definición de lo que se ha hecho para el producto, con la participación de las partes interesadas clave.
• Entrenar al equipo, dentro de los principios de Scrum, con el fin de ofrecer características de alta calidad para su producto
• Promover la autoorganización dentro del equipo
• Ayudar al equipo de scrum a evitar o eliminar los impedimentos para su progreso, ya sea interno o externo al equipo.
• Facilitar eventos de equipo para asegurar el progreso regular
• Educar a las partes interesadas clave en el producto sobre los principios de Scrum
• Entrenar al equipo de desarrollo en auto-organización e interfuncionalidad

Una de las maneras en que el rol del maestro scrum difiere del de un gerente de proyecto es que este último puede tener responsabilidades de administración de personal y el maestro scrum no. Scrum no reconoce formalmente el papel de gestor de proyectos, ya que las tendencias tradicionales de mando y control causarían dificultades.

Flujo de trabajo

Sprint

Un sprint (o iteración) es la unidad básica de desarrollo en Scrum. El sprint es un esfuerzo cronometrado, es decir, limitado a una duración determinada. La duración se fija de antemano para cada sprint y suele estar comprendida entre una semana y un mes, siendo dos semanas las más frecuentes.

Cada sprint comienza con un evento de planificación de sprint que tiene como objetivo definir un retraso de sprint, identificar el trabajo para el sprint, y hacer un pronóstico estimado para el objetivo de sprint. Cada sprint termina con una revisión de sprint y una retrospectiva de sprint, que revisa el progreso para mostrar a las partes interesadas e identificar lecciones y mejoras para las próximas carreras.

Scrum hace hincapié en el producto de trabajo al final del sprint que realmente se hace. En el caso del software, esto probablemente incluye que el software ha sido completamente integrado, probado y documentado, y es potencialmente enviable.

Planificación Sprint

Al comienzo de un sprint, el equipo de scrum realiza un evento de planificación de sprint.

• Discutir y acordar mutuamente el alcance del trabajo que se pretende realizar durante ese sprint.
• Seleccione los productos pendientes que se pueden completar en un sprint
• Preparar una cartera de pedidos de sprint que incluya el trabajo necesario para completar los productos seleccionados.
• La duración recomendada es de cuatro horas para un sprint de dos semanas (prorrateado para otras duraciones de sprint).
  • Durante la primera mitad, todo el equipo de scrum (equipo de desarrollo, maestro de scrum y propietario del producto) selecciona los productos que creen que podrían ser completados en ese sprint.
  • Durante la segunda mitad, el equipo de desarrollo identifica el trabajo detallado (tareas) que se requieren para completar los elementos de la cartera de productos, lo que resulta en una cartera de pedidos de sprint confirmada.
    • A medida que se elabora el trabajo detallado, algunos ítems de la cartera de productos se pueden dividir o volver a poner en la cartera de productos si el equipo ya no cree que pueda completar el trabajo requerido en un solo sprint.
• Una vez que el equipo de desarrollo ha preparado su sprint atrasado, pronostican (generalmente por votación) qué tareas serán entregadas dentro del sprint.

Scrum Diario

Un scrum diario en la sala de computación. Esta ubicación centralizada ayuda al equipo a comenzar a tiempo.

Cada día durante un sprint, el equipo realiza un scrum (o stand-up) diario con pautas específicas:

• Todos los miembros del equipo de desarrollo vienen preparados. El scrum diario:
  • Comienza exactamente a tiempo, incluso si faltan algunos miembros del equipo de desarrollo
  • Debe ocurrir a la misma hora y en el mismo lugar todos los días
  • Tiene un límite de tiempo de quince minutos
• Cualquiera es bienvenido, aunque sólo los miembros del equipo de desarrollo deben contribuir.
• Durante el scrum diario, cada miembro del equipo típicamente responde tres preguntas:
  • ¿Qué completé ayer que contribuyó a que el equipo cumpliera nuestra meta de sprint?
  • ¿Qué planeo completar hoy para contribuir a que el equipo cumpla con nuestra meta de sprint?
  • ¿Veo algún impedimento que pueda impedirnos a mí o al equipo alcanzar nuestra meta de sprint?

Cualquier impedimento (por ejemplo, tropiezo, riesgo, problema, dependencia retardada, suposición demostrada infundada) identificado en el scrum diario debe ser capturado por el maestro de scrum y mostrado en el tablero de scrum del equipo o en un tablero de riesgo compartido, con una persona acordada designada para trabajar hacia una resolución (fuera del scrum diario). No debe haber discusiones detalladas durante el scrum diario.

Reseña de Sprint

Al final de un sprint, el equipo celebra dos eventos: la revisión del sprint y la retrospectiva del sprint.

En la revisión sprint, el equipo:

• Revisa el trabajo que se completó y el trabajo planificado que no se completó.
• Presenta el trabajo completado a las partes interesadas (también conocido como la demostración)
• El equipo y las partes interesadas colaboran en qué trabajar a continuación

Pautas para las revisiones de sprint:

• No se puede demostrar el trabajo incompleto
• La duración recomendada es de dos horas para un sprint de dos semanas (proporcional para otras duraciones de sprint).

Retrospectiva de Sprint

En la retrospectiva del sprint, el equipo:

• Reflexiona sobre el sprint pasado
• Identifica y acuerda acciones de mejora continua de los procesos

Pautas para retrospectivas de sprint:

• En la retrospectiva de sprint se plantean dos preguntas principales: ¿Qué fue bien durante el sprint? ¿Qué se puede mejorar en el próximo sprint?
• La duración recomendada es de una hora y media para un sprint de dos semanas (proporcional para otras duraciones de sprint).
• Este evento es facilitado por el maestro scrum

Extensiones

Las siguientes actividades se realizan comúnmente, aunque no son consideradas por todos como una parte esencial de Scrum:

Refinamiento de la cartera de pedidos

El refinamiento de la cartera de pedidos (una vez llamado preparación de la cartera de pedidos) es el proceso continuo de revisión de los artículos de la cartera de pedidos y de comprobación de que están debidamente priorizados y preparados de manera que sean claros y ejecutables para los equipos una vez que entran en los sprints a través de la actividad de planificación de sprint. Los elementos de la cartera de pedidos pueden dividirse en varios más pequeños; los criterios de aceptación pueden aclararse; y las dependencias, la investigación y el trabajo preparatorio pueden identificarse y acordarse como puntas técnicas.

Aunque originalmente no era una práctica básica de Scrum, se ha añadido a la Guía de Scrum un refinamiento de la cartera de pedidos y se ha adoptado como una forma de gestionar la calidad de los productos pendientes de entrega que entran en un sprint, con una inversión recomendada de hasta el 10% de la capacidad de sprint de un equipo.

La cartera de pedidos también puede incluir la deuda técnica (también conocida como deuda de diseño o deuda codificada). Este es un concepto en el desarrollo de software que refleja el costo implícito de la revisión adicional causada por la elección de una solución fácil ahora en lugar de utilizar un enfoque mejor que tomaría más tiempo.

Cancelar un sprint

El propietario del producto puede cancelar un sprint si es necesario. El propietario del producto puede hacerlo con la información del equipo, el maestro de scrum o la gerencia. Por ejemplo, la dirección puede desear que el propietario del producto cancele un sprint si circunstancias externas niegan el valor del objetivo de sprint. Si un sprint se termina anormalmente, el siguiente paso es llevar a cabo una nueva planificación de sprint, donde se revisa la razón de la terminación.

Artefactos

Cartera de productos

La cartera de productos comprende una lista ordenada de requisitos de productos que un equipo scrum mantiene para un producto. El formato de los productos atrasados varía, los formatos comunes incluyen historias de usuarios, casos de uso o cualquier otro formato de requisitos que el equipo encuentre útil. Estos definirán características, correcciones de errores, requisitos no funcionales, etc., lo que sea que se deba hacer para entregar exitosamente un producto viable. El propietario del producto prioriza los elementos de la cartera de pedidos (PBI) en función de consideraciones como el riesgo, el valor comercial, las dependencias, el tamaño y la fecha necesaria.

La cartera de pedidos es lo que se entregará, ordenada en la secuencia en la que debe entregarse. Es visible para todo el mundo, pero sólo puede modificarse con el consentimiento del propietario del producto, que es el responsable en última instancia del pedido de los productos pendientes para que el equipo de desarrollo los elija.

La cartera de productos contiene la evaluación del valor de negocio del propietario del producto y la evaluación del equipo de desarrollo del esfuerzo de desarrollo, que a menudo, pero no siempre, se declaran en puntos históricos utilizando la escala redondeada de Fibonacci. Estas estimaciones ayudan al propietario del producto a calcular el plazo de tiempo y pueden influir en el pedido de los productos pendientes; por ejemplo, si dos características tienen el mismo valor comercial, el propietario del producto puede programar la entrega antes del que tiene el menor esfuerzo de desarrollo (porque el retorno de la inversión es mayor) o el que tiene el mayor esfuerzo de desarrollo (porque es más complejo o más arriesgado, y quieren retirar ese riesgo antes).

La cartera de pedidos y el valor comercial de cada artículo de cartera de pedidos es responsabilidad del propietario del producto. Sin embargo, el tamaño (es decir, la complejidad o el esfuerzo estimado) de cada elemento lo determina el equipo de desarrollo, que contribuye con su tamaño en puntos de la historia o en horas estimadas.

Scrum aboga por que se asigne el papel de propietario del producto. El propietario del producto es responsable de maximizar el valor del producto. El propietario del producto recoge información y recibe comentarios de muchas personas y es presionado por ellas, pero en última instancia hace la llamada sobre lo que se construye.

La cartera de productos:

• Captura las solicitudes de modificación de un producto, incluidas las nuevas funciones, la sustitución de funciones antiguas, la eliminación de funciones y la solución de problemas.
• Garantiza que el equipo de desarrollo tenga un trabajo que maximice el beneficio comercial para el propietario del producto.

Típicamente, el dueño del producto y el equipo scrum se juntan y escriben todo lo que debe ser priorizado, y esto se convierte en contenido para el primer sprint - que es un bloque de tiempo destinado para el trabajo enfocado en artículos seleccionados que pueden ser acomodados dentro de un marco de tiempo. La cartera de pedidos puede evolucionar a medida que aparece nueva información sobre el producto y sobre sus clientes, por lo que los sprints posteriores pueden abordar nuevos trabajos.

Los siguientes elementos suelen formar parte de la cartera de productos: características, errores, trabajo técnico y adquisición de conocimientos. Se desea una característica, mientras que un error es involuntario o no deseado (pero no necesariamente algo defectuoso). Un ejemplo de trabajo técnico podría ser ejecutar una comprobación de virus en las estaciones de trabajo de todos los desarrolladores. Un ejemplo de adquisición de conocimiento podría ser investigar bibliotecas de plugins de WordPress y hacer una selección.

Gestión

Una cartera de productos, en su forma más simple, no es más que una lista de elementos en los que trabajar. Tener reglas bien establecidas sobre cómo se añade, se quita y se ordena el trabajo ayuda a todo el equipo a tomar mejores decisiones sobre cómo cambiar el producto.

El propietario del producto da prioridad a los elementos de la cartera de pedidos en función de los cuales se necesitan lo antes posible. A continuación, el equipo elige los elementos que pueden completar en el sprint que viene. En el tablero de scrum, el equipo mueve los ítems de la cartera de productos a la cartera de sprints, que es la lista de ítems que ellos construirán.

Conceptualmente, es ideal para el equipo seleccionar sólo lo que creen que pueden lograr de la parte superior de la lista, pero no es inusual ver en la práctica que los equipos son capaces de tomar los elementos de menor prioridad de la lista junto con los primeros seleccionados. Esto normalmente sucede porque queda tiempo dentro del sprint para acomodar más trabajo. Los elementos que se encuentran en la parte superior de la cartera de pedidos, los elementos en los que se debe trabajar en primer lugar, deben dividirse en historias que sean adecuadas para que el equipo de desarrollo trabaje en ellas. Cuanto más se reduzca la cartera de pedidos, menos refinados deberán ser los artículos.

Como dicen Schwaber y Beedle: "Cuanto menor es la prioridad, menor es el detalle, hasta que apenas se puede distinguir el trabajo atrasado".

A medida que el equipo trabaja con la cartera de pedidos, se debe asumir que el cambio se produce fuera de su entorno: el equipo puede aprender sobre las nuevas oportunidades de mercado para aprovechar, las amenazas de la competencia que surgen y la retroalimentación de los clientes que puede cambiar la forma en que el producto debe funcionar. Todas estas nuevas ideas tienden a provocar que el equipo adapte el trabajo atrasado para incorporar nuevos conocimientos. Esto es parte de la mentalidad fundamental de un equipo ágil. El mundo cambia, el atraso nunca termina.

Cartera de pedidos de Sprint

La lista es derivada por el equipo de scrum seleccionando progresivamente los productos pendientes en orden de prioridad desde la parte superior de la lista de productos pendientes hasta que sientan que tienen suficiente trabajo para llenar el sprint. El equipo de desarrollo debe tener en cuenta su rendimiento en el pasado evaluando su capacidad para el nuevo sprint, y usarlo como una guía de cuánto `esfuerzo' pueden completar.

El equipo de desarrollo puede dividir los elementos de la cartera de productos en tareas. Las tareas de la cartera de pedidos de sprint nunca se asignan; más bien, los miembros del equipo registran las tareas según sea necesario de acuerdo con la prioridad establecida y las habilidades del equipo. Esto promueve la auto-organización del equipo de desarrollo y la participación de los desarrolladores.

El sprint backlog es propiedad del equipo de desarrollo, y todas las estimaciones incluidas son proporcionadas por el equipo de desarrollo. A menudo se usa un tablero de tareas acompañante para ver y cambiar el estado de las tareas del sprint actual, como hacer, en progreso y hechas.

Una vez que un sprint backlog está comprometido, no se puede añadir trabajo adicional al mismo, excepto por el equipo. Una vez que se ha entregado un sprint, se analiza la cartera de productos y se establece un nuevo orden de prioridades si es necesario, y se selecciona el siguiente conjunto de funciones para el siguiente sprint.

Incremento de producto

El incremento (o incremento potencialmente enviable, PSI) es la suma de todos los productos pendientes de entrega completados durante un sprint, integrados con el trabajo de todos los sprints anteriores. Al final de un sprint, el incremento debe ser completo, de acuerdo con la definición de "realizado" (DoD) del equipo de scrum, en pleno funcionamiento y en condiciones utilizables, independientemente de si el propietario del producto decide realmente lanzarlo. De cambiar las prioridades si es necesario, y se selecciona el siguiente conjunto de funciones para el siguiente sprint.

Extensiones

Los siguientes artefactos son de uso común, aunque no todos los consideran una parte esencial del Scrum:

Tabla de quemado Sprint

Una tabla de muestra para un sprint completo, mostrando el esfuerzo restante al final de cada día.
Artículo principal: Gráfico de quemado

La tabla de sprint burn-down es una tabla pública que muestra el trabajo restante en el sprint backlog. Actualizada todos los días, da una visión simple del progreso del sprint. También proporciona visualizaciones rápidas como referencia. El eje horizontal de la tabla de quemado de sprint muestra los días de una carrera, mientras que el eje vertical muestra la cantidad de trabajo que queda cada día (típicamente representando un estimado de las horas de trabajo restantes).

Durante la planificación del sprint se traza el gráfico de quemado ideal. Luego, durante el sprint, cada miembro recoge las tareas del sprint atrasadas y trabaja en ellas. Al final del día, actualizan las horas restantes para las tareas a completar. De esta manera, el gráfico de quemado real se actualiza día a día.

Liberar la tabla de quemado

Un ejemplo de tabla de quemado para un lanzamiento, mostrando el telescopio completado en cada sprint

La tabla de quemado de liberación es una manera para que el equipo proporcione visibilidad y rastree el progreso hacia una liberación. Actualizado al final de cada sprint, muestra el progreso hacia la entrega de un alcance de pronóstico. El eje horizontal de la tabla de quemado de lanzamientos muestra las carreras en un lanzamiento, mientras que el eje vertical muestra la cantidad de trabajo completado al final de cada carrera (típicamente representando puntos acumulativos de trabajo completado). El progreso se traza como una línea que crece hasta alcanzar una línea horizontal que representa el alcance del pronóstico; a menudo se muestra con un pronóstico, basado en el progreso hasta la fecha, que indica cuánto alcance podría completarse en una fecha de lanzamiento dada o cuántas carreras se necesitarán para completar el alcance dado.

Definición del realizado (DoD)

Los criterios de salida para determinar si una posición de atraso de producto está completa. En muchos casos, el DoD requiere que todas las pruebas de regresión sean exitosas. La definición de realizado puede variar de un equipo de scrum a otro, pero debe ser consistente dentro de un equipo.

Velocidad

El esfuerzo total que un equipo es capaz de hacer en un sprint. El número se obtiene evaluando el trabajo (típicamente en puntos de la historia del usuario) completado en el último sprint. La recopilación de datos históricos de velocidad es una guía para ayudar al equipo a comprender cuánto trabajo puede realizar en un sprint futuro.

Spike

Un periodo de tiempo en el que se investiga un concepto o se crea un prototipo simple. Los picos pueden planificarse para que se produzcan entre sprints o, en el caso de equipos más grandes, un pico puede ser aceptado como uno de los muchos objetivos de entrega de sprints. A menudo se introducen picos antes de la entrega de productos grandes o complejos con el fin de asegurar el presupuesto, ampliar el conocimiento o producir una prueba de concepto. La duración y los objetivos de un pico se acuerdan entre el propietario del producto y el equipo de desarrollo antes del comienzo. A diferencia de los compromisos de sprint, los spikes pueden o no ofrecer una funcionalidad tangible, transportable y valiosa. Por ejemplo, el objetivo de un pico podría ser alcanzar con éxito una decisión sobre un curso de acción. El pico se acaba cuando se acaba el tiempo, no necesariamente cuando se ha cumplido el objetivo.

Bala trazadora

También llamada púa de zángano, una bala rastreadora es una púa con la arquitectura actual, el conjunto de tecnología actual, el conjunto actual de mejores prácticas que resulta en código de calidad de producción. Puede ser una implementación muy estrecha de la funcionalidad, pero no es código desechable. Es de calidad de producción, y el resto de las iteraciones pueden construirse sobre este código. El nombre tiene orígenes militares como munición que hace visible la trayectoria de la bala, permitiendo correcciones. A menudo estas implementaciones son un 'tiro rápido' a través de todas las capas de una aplicación, como conectar el campo de entrada de un único formulario al back-end, para probar que las capas se conectan como se esperaba.

Limitaciones

El Scrum no funciona tan bien en las siguientes circunstancias:

• Equipos cuyos miembros están geográficamente dispersos o a tiempo parcial: En Scrum, los desarrolladores deben tener una interacción estrecha y continua, idealmente trabajando juntos en el mismo espacio la mayor parte del tiempo. Si bien los recientes avances tecnológicos han reducido el impacto de estas barreras (por ejemplo, poder colaborar en una pizarra digital), el manifiesto ágil afirma que la mejor comunicación es cara a cara.
• Equipos cuyos miembros tienen habilidades muy especializadas: En Scrum, los desarrolladores deberían poder trabajar en cualquier tarea o retomar el trabajo que otro desarrollador haya iniciado. Esto puede ser manejado por un buen liderazgo de Scrum. Si bien los miembros del equipo con habilidades muy específicas pueden contribuir bien y de hecho lo hacen, se les debe animar a aprender más sobre otras disciplinas y a colaborar con ellas.
• Productos con muchas dependencias externas: En Scrum, dividir el desarrollo de productos en sprints cortos requiere una planificación cuidadosa; las dependencias externas, como las entregas de software de otros equipos, pueden provocar retrasos y el fracaso de sprints individuales.
• Productos maduros o heredados o con control de calidad regulado: En Scrum, los incrementos de producto deben ser completamente desarrollados y probados en un solo sprint; los productos que necesitan grandes cantidades de pruebas de regresión o pruebas de seguridad (por ejemplo, dispositivos médicos o control de vehículos) para cada lanzamiento son menos adecuados para carreras cortas que para lanzamientos en cascada más largos.

Desde una perspectiva de negocio, Scrum tiene muchas virtudes, una de las cuales es que está diseñado para producir las mejores soluciones de negocio. Sin embargo, la eficiencia con la que lo hace en cualquier organización puede variar ampliamente, y depende en gran medida de la capacidad de la organización para adherirse a las directrices de implementación. Cada empresa tiene su propia estructura organizativa, cultura y conjunto de prácticas empresariales, y algunas de ellas se adaptan de forma más natural a esta metodología que otras.

Herramientas para la implementación

Como otros métodos ágiles, la adopción efectiva de Scrum puede ser soportada a través de una amplia gama de herramientas.

Muchas empresas utilizan herramientas universales, como hojas de cálculo, para construir y mantener artefactos como el retraso del sprint. También existen paquetes de software propietario y de código abierto para Scrum, que se dedican al desarrollo de productos utilizando el marco de trabajo de Scrum, o admiten múltiples enfoques de desarrollo de productos, incluido Scrum.

Otras organizaciones implementan Scrum sin herramientas de software y mantienen sus artefactos en papel, pizarras y notas adhesivas.

Valores de Scrum

Scrum es un enfoque empírico basado en la retroalimentación que, al igual que todo control empírico de procesos, se sustenta en los tres pilares de la transparencia, la inspección y la adaptación. Todo el trabajo dentro del marco de Scrum debe ser visible para los responsables del resultado: el proceso, el flujo de trabajo, el progreso, etc. Para hacer estas cosas visibles, los equipos scrum necesitan inspeccionar frecuentemente el producto que se está desarrollando y qué tan bien está trabajando el equipo. Con inspecciones frecuentes, el equipo puede detectar cuando su trabajo se desvía fuera de los límites aceptables y adaptar su proceso o el producto en desarrollo.

Estos tres pilares requieren confianza y apertura en el equipo, que permiten los siguientes cinco valores de Scrum:

1. Compromiso: Los miembros del equipo se comprometen individualmente a alcanzar las metas de su equipo, en todos y cada uno de los sprints.
2. Coraje: Los miembros del equipo saben que tienen el coraje de trabajar juntos a través de conflictos y desafíos para poder hacer lo correcto.
3. Concentración: Los miembros del equipo se centran exclusivamente en los objetivos de su equipo y en el volumen de trabajo acumulado del sprint; no se debe hacer ningún otro trabajo que no sea el de su volumen de trabajo acumulado.
4. Apertura: Los miembros del equipo y sus partes interesadas acuerdan ser transparentes sobre su trabajo y los desafíos que enfrentan.
5. Respeto: Los miembros del equipo se respetan unos a otros por ser técnicamente capaces y por trabajar con buenas intenciones.

Adaptaciones

La hibridación de Scrum con otras metodologías de desarrollo de software es común ya que Scrum no cubre todo el ciclo de vida de desarrollo de productos; por lo tanto, las organizaciones encuentran la necesidad de añadir procesos adicionales para crear una implementación más completa. Por ejemplo, al comienzo del desarrollo del producto, las organizaciones suelen añadir orientación de proceso sobre el caso de negocio, la recopilación de requisitos y el establecimiento de prioridades, el diseño inicial de alto nivel y la previsión de presupuestos y calendarios.

Varios autores y comunidades de personas que usan Scrum también han sugerido técnicas más detalladas sobre cómo aplicar o adaptar Scrum a problemas u organizaciones particulares. Muchos se refieren a estas técnicas metodológicas como 'patrones' - por analogía con los patrones de diseño en arquitectura y software. Tales patrones han extendido Scrum fuera del dominio de desarrollo de software a Manufactura, Finanzas y Recursos Humanos.

Scrumban

Este es un modelo de producción de software basado en Scrum y Kanban. Scrumban es especialmente adecuado para el mantenimiento de productos con elementos de trabajo frecuentes e inesperados, como defectos de producción o errores de programación. En tales casos, las carreras de tiempo limitado de la estructura de Scrum pueden ser percibidas como de menor beneficio, aunque los eventos diarios de Scrum y otras prácticas todavía pueden ser aplicadas, dependiendo del equipo y de la situación en cuestión. La visualización de las etapas de trabajo y las limitaciones para el trabajo inacabado y los defectos simultáneos son familiares en el modelo Kanban. Usando estos métodos, el flujo de trabajo del equipo se dirige de una manera que permite un tiempo mínimo de finalización para cada elemento de trabajo o error de programación y, por otro lado, asegura que cada miembro del equipo esté constantemente empleado.

Para ilustrar cada etapa de trabajo, los equipos que trabajan en el mismo espacio suelen utilizar notas post-it o una pizarra grande. En el caso de los equipos descentralizados, software de ilustración de escenarios como Assembla, JIRA o Agilo.

La mayor diferencia entre Scrum y Kanban es que en Scrum el trabajo se divide en sprints que duran una cantidad fija de tiempo, mientras que en Kanban el flujo de trabajo es continuo. Esto es visible en las tablas de etapas de trabajo, que en Scrum se vacían después de cada sprint, mientras que en Kanban todas las tareas se marcan en la misma tabla. Scrum se centra en equipos con un saber hacer polifacético, mientras que Kanban hace posible equipos especializados y funcionales.

Scrum de scrums

El Scrum de scrums es una técnica para operar Scrum a escala, para múltiples equipos que trabajan en el mismo producto, permitiéndoles discutir el progreso de sus interdependencias, centrándose en cómo coordinar la entrega de software, especialmente en áreas de superposición e integración. Dependiendo de la cadencia (tiempo) del scrum de scrums, el scrum diario relevante para cada equipo de scrum termina designando a un miembro como embajador para participar en el scrum de scrums con embajadores de otros equipos. Dependiendo del contexto, los embajadores pueden ser colaboradores técnicos o el maestro de scrum de cada equipo.

En lugar de ser simplemente una actualización del progreso, el scrum de scrums debe enfocarse en cómo los equipos están trabajando colectivamente para resolver, mitigar o aceptar cualquier riesgo, impedimento, dependencia y suposiciones (RIDAs) que hayan sido identificados. El scrum de scrums rastrea estos RIDAs a través de su propia acumulación de trabajo, tal como una junta de riesgos (a veces conocida como junta de ROAM por sus iniciales en inglés de resolved, owned, accepted, and mitigated), la cual típicamente conduce a una mayor coordinación y colaboración entre equipos.

Esto debería ser similar a un scrum diario, con cada embajador contestando las siguientes cuatro preguntas:

• ¿Qué riesgos, impedimentos, dependencias o suposiciones ha resuelto su equipo desde la última vez que nos reunimos?
• ¿Qué riesgos, impedimentos, dependencias o suposiciones resolverá su equipo antes de que nos volvamos a encontrar?
• ¿Existen nuevos riesgos, impedimentos, dependencias o suposiciones que ralenticen a su equipo o se interpongan en su camino?
• ¿Está a punto de introducir un nuevo riesgo, impedimento, dependencia o suposición que se interpondrá en el camino de otro equipo?

Scrum a gran escala

Scrum a gran escala (LeSS) es un marco de desarrollo de productos que amplía Scrum con reglas y directrices de escalado sin perder los propósitos originales de Scrum.

El marco de trabajo tiene dos niveles: el primer nivel de LeSS está diseñado para un máximo de 8 equipos; el segundo nivel, conocido como "LeSS Huge", introduce elementos adicionales de escalado para el desarrollo con hasta cientos de desarrolladores. "Escalar Scrum comienza con entender y ser capaz de adoptar el estándar real de un solo equipo Scrum. El Scrum a gran escala requiere examinar el propósito de los elementos Scrum de un solo equipo y averiguar cómo alcanzar el mismo propósito al tiempo que se mantienen dentro de las restricciones de las reglas estándar del Scrum"

Bas Vodde y Craig Larman desarrollaron el marco LeSS a partir de sus experiencias de trabajo en el desarrollo de productos a gran escala, especialmente en las industrias de telecomunicaciones y finanzas. Evolucionó tomando Scrum y probando muchos experimentos diferentes para descubrir lo que funciona. En 2013, los experimentos se consolidaron en las reglas del marco de LeSS. La intención de LeSS es "descalcificar" la complejidad organizativa, disolviendo soluciones organizativas complejas innecesarias y resolviéndolas de forma más sencilla. Menos roles, menos gestión, menos estructuras organizativas.