Qué son los sprints? Un sprint es un período breve de tiempo fijo en el que un equipo de scrum trabaja para completar una cantidad de trabajo establecida. Los sprints se encuentran en el corazón de las metodologías scrum y ágil, y hacer bien los sprints ayudará a tu equipo ágil a lanzar mejor software con menos quebraderos de cabeza. "Con scrum, un producto se basa en una serie de iteraciones llamadas sprints que dividen proyectos grandes y complejos en porciones minúsculas", sostiene Megan Cook, gestora de productos de grupo de Jira Software en Atlassian. "Gracias a los sprints, los proyectos son más fáciles de gestionar, permiten a los equipos enviar trabajo de gran calidad más rápido y con más frecuencia, y les ofrecen más flexibilidad para adaptarse al cambio". Muchos asocian los sprints de la metodología scrum con el desarrollo de software ágil, hasta tal punto que suelen pensar que las metodologías scrum y ágil son lo mismo, pero no lo son. La metodología ágil constituye una serie de principios y la metodología scrum es un marco de trabajo para conseguir resultados. Las numerosas similitudes que hay entre los valores ágiles y los procesos de scrum suponen una asociación justa. Los sprints ayudan a los equipos a seguir el principio de la metodología ágil de "entregar software de trabajo con frecuencia", así como vivir el valor ágil de "dar respuesta a un cambio por encima del seguimiento de un plan". Los valores de transparencia, inspección y adaptación de la metodología scrum son complementarios a los ágiles y centrales al concepto de sprints. La guía de la metodología scrum constituye un trabajo preliminar sólido y teórico para este debate sobre los sprints. Nuestro objetivo consiste en añadir cierto color a este tema ofreciendo prácticas recomendadas de personas que llevan a cabo este trabajo cada día. Cómo planificar y ejecutar sprints de la metodología scrum Los que inventaron la metodología scrum pensaron en todo: si lo que quieres es planificar tu próximo sprint, ya tienes las reuniones de planificación de sprints. La planificación de sprints es un evento de colaboración donde el equipo responde a dos preguntas básicas: qué trabajo se puede llevar a cabo en este sprint y cómo se llevará a cabo el trabajo escogido. Elegir los elementos de trabajo adecuados para un sprint es un esfuerzo de colaboración entre el propietario del producto, el experto en scrum y el equipo de desarrollo. El propietario del producto analiza el objetivo que debería lograr el sprint y los elementos del backlog del producto que, tras la finalización de una tarea, lograrían el objetivo del sprint. A continuación, el equipo crea un plan sobre cómo crearán y finalizarán los elementos del backlog antes del fin del sprint. Los elementos de trabajo elegidos y el plan sobre cómo completarlos se conocen como el backlog del sprint. Al terminar de planificar un sprint, el equipo está listo para empezar a trabajar en el backlog del sprint, es decir, completará todos los elementos del backlog que tengan el estado "En curso". Durante un sprint, el equipo comprueba durante el scrum diario, o reunión rápida, cómo progresa el trabajo. El objetivo de esta reunión es descubrir los impedimentos y retos que afectarían a la capacidad de los equipos para lograr el objetivo del sprint. Después de un sprint, el equipo demuestra lo que han realizado durante la revisión. De este modo, el equipo tiene la oportunidad de exponer su trabajo ante las partes interesadas y compañeros antes de poner en marcha la producción. Completa tu ciclo de sprints con mi reunión favorita: la retrospectiva del sprint. De esta forma, tus equipos tienen la oportunidad de identificar áreas de mejora para el próximo sprint. Así, estaréis preparados para el próximo ciclo de sprints. ¡Adelante! Qué hacer y qué no hacer Aun conociendo los conceptos básicos, la mayoría de los equipos tendrán dificultades cuando empiecen a ejecutar sprints. Megan Cook completa este tema con algunas prácticas recomendadas y otras que conviene evitar, y que ella misma ha ido recopilando con los años. Prácticas que seguir: Asegúrate de que el equipo establece y entiende el objetivo del sprint y cómo se medirá el éxito. Esta es la clave para mantener a todos en sintonía y encaminados hacia el mismo destino. Asegúrate de que dispones de un backlog bien preparado con tus prioridades y dependencias ordenadas. Esto puede suponer todo un reto que podría estropear el proceso si no se gestiona adecuadamente. Asegúrate de que conoces bien la velocidad y que esta refleja aspectos como los permisos y las reuniones de los equipos. Utiliza la reunión de planificación de sprints para desarrollar minuciosos detalles del trabajo que hay que llevar a cabo. Anima a los miembros de los equipos a idear cometidos para todas las historias, errores y tareas que intervienen en el sprint. Excluye trabajo en el que no puedas atender las dependencias, como trabajos de otros equipos, diseños y aprobaciones legales. Por último, una vez que se haya tomado una decisión o se haya ideado un plan, asegúrate de que alguien recopila esa información en tu herramienta de colaboración o gestión de proyectos, como tus tickets de Jira. De esa forma, todo el mundo podrá ver más adelante la decisión y el razonamiento con facilidad. Mientras te preparas para convertirte en todo un experto en scrum con estas recomendaciones, también debes tener en cuenta cosas que evitar: Prácticas que evitar: No publiques demasiadas historias, no sobrestimes la velocidad ni empieces tareas que no se puedan realizar en el sprint. Ni a ti ni a tu equipo os conviene fracasar. No te olvides de la calidad ni de la deuda técnica. Asegúrate de presupuestar el tiempo de control de calidad y el trabajo sin funciones, como los errores y el estado de la ingeniería. No dejes que el equipo se haga una idea confusa de lo que conlleva el sprint. Acláralo y no te centres tanto en avanzar rápido: recuerda que todo el mundo ha de moverse en la misma dirección. Asimismo, no asumas una gran cantidad de trabajo de alto riesgo o que no conozcas. Analiza historias completas o de gran incertidumbre, y no temas dejar parte del trabajo para el próximo sprint. Si llegan a tus oídos preocupaciones por parte del equipo, ya sea sobre la velocidad, sobre el trabajo de poca certidumbre o sobre el hecho de que el volumen de trabajo es mayor del que estimaban, no las ignores. Aborda la incidencia y vuelve a calibrar el trabajo si es necesario. Más información sobre los sprints Los sprints son tan conocidos (y eficaces) que, a menudo, se consideran el primer paso del camino hacia una mayor agilidad. Como hemos visto, para dominar los sprints es preciso dominar también una serie de conceptos de la metodología scrum y ágil que se basan los unos en los otros. Utiliza nuestros otros artículos sobre la metodología scrum para completar tus conocimientos y para acercarte más que nunca a la felicidad que aporta la metodología scrum. Qué es la planificación de sprints? La planificación de sprints es un evento en scrum que inicia el sprint. El objetivo de la planificación de sprints es definir lo que se puede entregar en el sprint y cómo se conseguirá ese trabajo. La planificación de sprints se hace en colaboración con todo el equipo de scrum. A diferencia del deporte, scrum te anima a que no dejes de trabajar en el sprint para que puedas entregar software funcional, al tiempo que aprendes y mejoras continuamente. En scrum, el sprint es un período definido de tiempo en el que se hace todo el trabajo. Sin embargo, antes de poder ponerte manos a la obra tienes que preparar el sprint. Tienes que decidir cuánto tiempo vas a dar, el objetivo del sprint y dónde vas a empezar. La sesión de planificación de sprints inicia el sprint definiendo el programa y el punto de atención. Si se hace correctamente, también crea un entorno en el que el equipo está motivado, se siente retado y puede triunfar. Las malas planificaciones de sprints pueden fastidiar al equipo al definir expectativas no realistas. El qué: el propietario del producto describe el objetivo (o propósito) del sprint y qué elementos del backlog contribuyen a dicho objetivo. El equipo de scrum decide qué se puede hacer en el próximo sprint y qué hará durante el sprint para conseguirlo. El cómo: el equipo de desarrollo planifica el trabajo necesario para alcanzar el objetivo del sprint. Básicamente, el plan del sprint resultante es una negociación entre el equipo de desarrollo y el propietario del producto en función del valor y el esfuerzo. El quién: no puedes planificar sprints sin el propietario del producto ni el equipo de desarrollo. El propietario del producto define el objetivo en función del valor que busca. El equipo de desarrollo tiene que entender cómo puede o no puede alcanzar dicho objetivo. Si alguno de los dos no está en este evento, la planificación del sprint será casi imposible. Las entradas: un buen punto de partida para el plan del sprint es el backlog del producto, ya que proporciona una lista de "cosas" que potencialmente podrían formar parte del sprint actual. Además, el equipo debería analizar el trabajo realizado en el incremento y tener visión de la capacidad. Las salidas: el resultado más importante para la reunión de planificación de sprints es que el equipo puede describir el objetivo del sprint y cómo empezará a trabajar hacia ese objetivo. Esto se refleja en el backlog de sprint. Preparación de la reunión de planificación de sprints Organizar un gran evento de planificación de sprints requiere un poco de disciplina. El propietario del producto debe estar preparado, combinando las lecciones de la revisión del sprint anterior, los comentarios de la parte interesada y su visión del producto, para allanar el terreno del sprint. Por motivos de transparencia, el backlog del producto debería estar actualizado y perfeccionado para ofrecer claridad. La mejora del backlog es un evento opcional en scrum, porque algunos backlogs no lo requieren. Sin embargo, para la mayoría de los equipos, es mejor reunir al equipo para revisar y perfeccionar el backlog antes de la planificación de sprints. CONSEJO DE EXPERTO: Si tienes un sprint de dos semanas, organiza una reunión de mejora del backlog a mitad del sprint. Al equipo le viene muy bien distanciarse del sprint y mirar qué viene a continuación. Eso no solo ayuda a prepararse para la planificación de sprints, sino que también puede darle otra perspectiva al trabajo actual. Definición de un límite de tiempo para la planificación de sprints La planificación de sprints debería limitarse a no más de dos horas por cada semana del sprint. Así, por ejemplo, la reunión de planificación de sprints de un sprint de dos semanas no debería durar más de cuatro horas. Esto se llama "fijar el tiempo máximo", o establecer una cantidad máxima de tiempo para que el equipo termine una tarea, en este caso, planificar el sprint. El experto en scrum es el responsable de que se entienda el tiempo máximo. Si el equipo está satisfecho antes de que haya terminado el tiempo máximo, entonces el evento ha terminado. Hay un tiempo máximo permitido, pero no hay un tiempo mínimo. CONSEJO DE EXPERTO:Centra la primera parte de la planificación de sprints en el objetivo del sprint en vez de en los detalles del backlog. Al centrarse en el objetivo en vez de en el trabajo, es posible encontrar alternativas inteligentes para cómo se consigue ese objetivo. Céntrate en los resultados, no en el trabajo Durante la planificación de sprints, es fácil "empantanarse" en el trabajo centrándose en qué tarea debería ir primero, quién debería hacerla y cuánto tiempo llevará. Para el trabajo complejo, el nivel de información que sabes al principio puede ser bajo y la mayor parte se basa en suposiciones. Scrum es un proceso empírico, lo que significa que no puedes planificar por adelantado, sino más bien aprender con la práctica, y después volver a incorporar esa información en el proceso. El objetivo del sprint describe el propósito del sprint en términos generales, pero los elementos del backlog también pueden escribirse con un resultado en mente. Las historias de usuario son una forma estupenda de describir el trabajo desde el punto de vista de un cliente. Las historias de usuario, escritas como la de abajo, reorientan los defectos, las incidencias y las mejoras hacia el resultado que el cliente está buscando en vez de hacia el problema observado. Al añadir resultados claros y cuantificables a la historia de usuario, los resultados se pueden cuantificar claramente y sabes cuando has terminado. Asimismo, al disponer del máximo posible de claridad del trabajo en el que se está centrando el equipo por adelantado, todos tienen la transparencia necesaria para ponerse manos a la obra. Por ejemplo, dejar una cosa poco precisa es mucho peor que describir algo como una pregunta que se tiene que responder durante el sprint. CONSEJO DE EXPERTO: No saber algo es diferente de ser poco preciso. No ignores lo desconocido: es la realidad de los trabajos complicados. Pero tampoco los ocultes usando palabras poco precisas. En su lugar, sé claro cuando no sepas algo y enmarca el trabajo en términos de entender algo. Las estimaciones son necesarias, pero no pretendas que sabes más de lo que en realidad sabes La planificación de sprints requiere cierto nivel de estimación. El equipo tiene que definir lo que puede o no puede hacerse en el sprint: esfuerzo estimado frente a capacidad. A menudo, se confunde la estimación con los compromisos. Las estimaciones son por su propia naturaleza previsiones que se basan en el conocimiento a mano. Técnicas como los puntos de historia o las tallas de camisetas añaden valor al proceso dándole al equipo una forma diferente de encarar el problema. Sin embargo, no son herramientas mágicas con las que descubrir la verdad absoluta, cuando esta no existe. Cuanto más cosas no se sepan, menos probable será que la estimación sea correcta. Una buena estimación requiere un entorno basado en la confianza donde la información se proporcione libremente y las suposiciones se discutan en busca de aprendizaje y mejora. Si las estimaciones se utilizan de una forma negativa y confrontacional una vez que se ha terminado el trabajo, es probable que las futuras estimaciones sean mucho superiores para asegurarse de que no vuelven a estar mal nunca más o el tiempo necesario para crearlas sea mucho mayor, ya que el equipo se lo pensará dos veces preocupado por las consecuencias de que estén mal. CONSEJO DE EXPERTO Prueba a utilizar diferentes técnicas de estimación como las tallas de camisetas o los puntos de historia. Diferentes técnicas podrían proporcionar diferentes visiones del problema. Prácticas recomendadas de la planificación de sprints Es fácil empantanarse tanto con los detalles de la planificación de sprints que te olvidas de que el objetivo de esta es crear un plan "suficientemente bueno" para el siguiente sprint. Ese plan no debería convertirse en un problema para el equipo, sino que debería orientar al equipo hacia resultados valiosos y permitir protecciones para la autoorganización. Un buen plan de sprint motiva a todo el mundo al definir un resultado y un plan claro para el éxito. Sin embargo, ten cuidado y no planifiques con demasiada antelación. En vez de crear el plan de sprint más completo "en el que se refleje cada minuto del sprint", céntrate en el objetivo y crea lo suficiente del backlog de sprint para comenzar. A continuación, asegúrate de que el backlog del producto esté ordenado para que el equipo pueda asumir trabajo si han alcanzado el objetivo del sprint de manera anticipada. Scrum es un marco de trabajo compuesto de procesos que pretende solucionar problemas complejos. Los problemas complejos requieren un proceso empírico (aprender con la práctica). Los procesos empíricos son muy difíciles de planificar, así que no te engañes a ti mismo: no puedes crear el plan perfecto. En su lugar, céntrate en los resultados y avanza. No tiene por qué ser complicado, incluso aunque el problema que estás resolviendo lo sea. ¿Qué es un backlog del producto? El backlog de un producto es una lista de trabajo ordenado por prioridades para el equipo de desarrollo que se obtiene de la hoja de ruta y sus requisitos. Los elementos más importantes se muestran al principio del backlog del producto para que el equipo sepa qué hay que entregar primero. El equipo de desarrollo no trabaja con el backlog al ritmo que dicta el propietario del producto, y este no presiona al equipo de desarrollo para que saque el trabajo adelante. En su lugar, el equipo de desarrollo saca trabajo del backlog del producto en la medida de sus capacidades, ya sea de forma continua (kanban) o por iteraciones (scrum). CONSEJO DE EXPERTO: Mantén todo en un gestor de incidencias: no uses varios sistemas para realizar el seguimiento de los errores, requisitos y elementos de trabajo de ingeniería. Si se trata de trabajo para el equipo de desarrollo, mantenlo en un único backlog. Comienza por las dos erres La hoja de ruta y los requisitos de un equipo son la base del backlog del producto. Las iniciativas de la hoja de ruta se dividen en varios epics, y cada epic tendrá varios requisitos e historias de usuario. Veamos la hoja de ruta de un producto ficticio llamado Equipos en el Espacio. Dado que el sitio web de Equipos en el Espacio es la primera iniciativa en la hoja de ruta, dividiremos esa iniciativa en epics (que se muestran aquí en verde, azul y turquesa) y en historias de usuario para cada uno de esos epics. A continuación, el propietario del producto organiza las historias de usuario en una única lista para el equipo de desarrollo. El propietario del producto puede optar por entregar primero un epic completo (izquierda), p puede que sea más importante para el programa reservar un vuelo barato que requiera historias de diversos epics (derecha). A continuación, puedes ver ambos ejemplos. ¿Qué aspectos pueden influir en la priorización de un propietario del producto? Prioridad del cliente La urgencia de obtener comentarios Dificultad de implementación relativa Relaciones simbióticas entre elementos de trabajo (por ejemplo, B resulta más sencillo si hacemos A primero) Si bien el propietario del producto es el encargado de priorizar el backlog, esta tarea no se hace de forma aislada. Los propietarios del producto eficaces buscan los comentarios y las opiniones de los clientes, los diseñadores y el equipo de desarrollo para optimizar la carga de trabajo de todos y la entrega del producto. Mantener un backlog saludable Una vez creado el backlog del producto, es importante realizar un mantenimiento periódico para que siga el ritmo del programa. Los propietarios del producto deben revisar el backlog antes de cada reunión para planificar la iteración para garantizar que la priorización sea correcta y que se han incorporado los comentarios de la iteración anterior. La revisión periódica del backlog se denomina "limpieza del backlog" en entornos ágiles (hay quien usa también el término "ajuste del backlog"). Cuando el backlog aumenta, los propietarios del producto deben agruparlo en elementos a corto y a largo plazo. Los elementos a corto plazo deben estar completamente descritos antes de etiquetarlos como tales. Esto significa que se han diseñado historias de usuario completas, se ha acordado la colaboración con diseño y desarrollo, y el equipo de desarrollo ha realizado estimaciones. Los elementos a largo plazo pueden seguir siendo algo abstractos, aunque es una buena idea tener una estimación aproximada del equipo de desarrollo para ayudar a su priorización. La palabra clave aquí es "aproximada": las estimaciones cambiarán cuando el equipo entienda completamente esos elementos a largo plazo y empiece a trabajar en ellos. El backlog funciona como conexión entre el propietario del producto y el equipo de desarrollo. El propietario del producto es libre de cambiar la prioridad del trabajo en el backlog en cualquier momento debido a los comentarios de los clientes, los ajustes de las estimaciones y los nuevos requisitos. No obstante, una vez que el trabajo se está realizando, los cambios deben ser mínimos, ya que interrumpen el trabajo del equipo de desarrollo y afectan a la concentración, el ritmo y el ánimo. CONSEJO DE EXPERTO: Una vez que el backlog sea mayor que la capacidad a largo plazo del equipo, se pueden cerrar incidencias que el equipo nunca atenderá. Marca esas incidencias con una resolución específica, como "fuera de alcance", en el gestor de incidencias del equipo para usarlo con fines de investigación más adelante. Antipatrones que se deben tener en cuenta El propietario del producto prioriza el backlog al inicio del proyecto, pero no lo ajusta a medida que los desarrolladores y las partes interesadas envían comentarios. El equipo limita los elementos del backlog a aquellos diseñados para los clientes. El backlog se conserva como un documento almacenado de forma local y que se comparte con poca frecuencia, lo que evita que las partes interesadas obtengan actualizaciones. ¿Cómo ayudan los backlogs del producto a los procesos ágiles del equipo? Los propietarios del producto con experiencia cuidan rigurosamente el backlog del producto de su programa, convirtiéndolo en un esquema fiable de los elementos de trabajo de un proyecto que se puede compartir. Los backlogs incitan debates y decisiones que mantienen la salud de un programa. No todo puede tener máxima prioridad. Las partes interesadas pueden discutir las prioridades, y eso está bien. Fomentar las conversaciones sobre qué es importante sirve para sincronizar las prioridades de todo el mundo. Estas conversaciones crean una cultura de priorización colectiva que garantiza que todos compartan la misma idea del programa. El backlog del producto también sirve como base para planificar iteraciones. Todos los elementos de trabajo deben incluirse en el backlog: historias de usuario, errores, cambios de diseño, deuda técnica, solicitudes de clientes, elementos de acción de la retrospectiva, etc. Así se garantiza que los elementos de trabajo de todos se incluyan en la conversación general de cada iteración. Los miembros del equipo pueden negociar con el propietario del producto antes de iniciar una iteración con un conocimiento completo de todo lo que debe realizarse. CONSEJO DE EXPERTO: Los propietarios del producto dictan la prioridad de los elementos de trabajo en el backlog, mientas que el equipo de desarrollo dicta la velocidad a la que se trabaja en el backlog. Esta puede ser una relación poco convincente para los nuevos propietarios del producto que deseen presionar al equipo para que trabaje. Encontrarás más información en nuestro artículo sobre límites y flujo del trabajo en curso. as revisiones de sprints no son retrospectivas. Una revisión de sprint consiste en demostrar el duro trabajo de todo un equipo: diseñadores, desarrolladores y el propietario del producto. En Atlassian, nos gusta mantener la informalidad de nuestras revisiones de sprints. Los miembros del equipo se reúnen en torno a un escritorio para demostraciones informales y describen el trabajo que han realizado para esa iteración. Es hora de formular algunas preguntas, probar nuevas funciones y ofrecer comentarios. Compartir el éxito es una parte importante de la construcción de un equipo ágil. Primero vamos a revisar por qué la definición del equipo de "finalizado" es tan importante para este protocolo de la metodología ágil. Paso 1: Define "finalizado" Como usuario habitual de Jira, nada me satisface más que mover una tarea del estado de "revisión del código" al de "finalizado". Ese movimiento de una tarjeta ágil representa el trabajo completado que nos propusimos lograr como equipo. ¡Hecho y finalizado! Cruzar la línea de meta y completar el trabajo requiere una buena planificación, una clara definición de "finalizado" y una ejecución centrada. La mayoría de esto sucede durante la planificación de sprints, pero para tener un sprint y una revisión de sprints con éxito, los equipos tienen que hacer algo más que planificar. Tienen que desarrollar una cultura clara de cómo entregar el trabajo, así como lo que significa que esté "finalizado". Una cultura de entrega Los equipos eficientes aportan procesos claros y una cultura de desarrollo a todos y cada uno de los elementos de trabajo. Utiliza estas preguntas para evaluar tu proceso, y asegúrate de que este funciona de forma óptima en tu equipo: ¿Han definido bien el propietario del producto, el diseñador y el equipo de ingeniería las historias antes de la implementación? ¿Comprende y vive todo el mundo la cultura y los valores de ingeniería del equipo? ¿Existen definiciones y requisitos claros en torno a la revisión del código, las pruebas automatizadas y la integración continua para fomentar un desarrollo ágil sostenible? Después de que el equipo complete una historia, ¿surgen demasiados errores? En otras palabras, ¿significa el término "finalizado" realmente eso? La cultura del equipo en torno a la calidad y la finalización debería estar por encima de cualquier historia de usuario, elemento de trabajo de ingeniería y error. Esta cultura refleja cómo el equipo aborda el desarrollo de software y su entrega. Definición de "finalizado" en cada trabajo Una definición clara del término "finalizado" ayuda a los equipos a centrarse en el objetivo final de cada elemento de trabajo. Cuando el propietario del producto añade trabajo al backlog del equipo, la definición de los criterios de aceptación es una parte fundamental del proceso de este. ¿Qué implica la finalización de una historia de usuario? En Atlassian, el equipo de Jira realiza un seguimiento de los criterios de aceptación y las notas de las pruebas en consonancia con el resto de la historia de usuario dentro de Jira. De esa forma, el equipo al completo tiene una visión clara del éxito en cada incidencia. ¿Qué son los criterios de aceptación y las notas de las pruebas? Criterios de aceptación: mide los usos del propietario del producto para confirmar que la historia se ha implementado de forma satisfactoria. Notas de las pruebas: breve asesoramiento específico del equipo de control de calidad que permite al ingeniero de desarrollo escribir mejor código de funciones y realizar pruebas automatizadas. Contar con unas incidencias bien definidas durante la implementación permite a todos tener éxito. Con Jira, resulta fácil añadir campos. Como administrador, simplemente haz clic en el botón de administración en la incidencia. Paso 2: Celebración con el equipo En Atlassian, uno de nuestros principales valores es el de "Juega en equipo". Las revisiones de sprints son fantásticas para celebrar los logros del equipo y de todos los integrantes durante una iteración. Normalmente, organizamos estas revisiones el viernes por la tarde, mientras todos en la oficina se relajan antes del fin de semana. Las revisiones de sprints no son iguales que las retrospectivas, así que asegúrate de organizar la revisión de sprints después de una iteración, pero antes de la retrospectiva. Los participantes externos siempre son bienvenidos, pero en la reunión suelen encontrarse el propietario del producto, el equipo de desarrollo al completo y el experto en scrum. Como práctica recomendada, proponemos dedicar entre 30 minutos y 1 hora a cada iteración que se trate en la reunión. Nos encantan las revisiones de sprints, porque protegen la salud y la moral del equipo. Las revisiones de sprints se basan en el trabajo en equipo. La revisión no es un procedimiento acusatorio ni un examen, sino un evento colaborativo entre todo el equipo en el que cada uno muestra su trabajo, plantea sus dudas y obtiene comentarios. Si una revisión de sprints no se convierte en una actividad positiva en el equipo, puede ser indicativo de lo siguiente: El equipo está asumiendo demasiado trabajo y no lo está completando durante una iteración. El equipo lucha contra la deuda técnica. No se están desarrollando de forma sostenible las funciones para garantizar que no se introducen nuevos errores en la base de código. Las prácticas de desarrollo del equipo no está tan ajustadas como deberían. El propietario del producto está cambiando las prioridades en una iteración y el equipo de desarrollo ha quedado marginado por la ampliación descontrolada del alcance. Nota: Todos los equipos sufren a veces de iteraciones difíciles. Tómate el tiempo necesario para comprender por qué cambia una iteración en la retrospectiva del equipo e idea un plan para abordar las incidencias en el siguiente sprint. Paso 3: Contacta desde distintas geografías Las empresas con equipos distribuidos se enfrentan a desafíos especiales en torno al escalado de protocolos de la metodología ágil en diversas geografías. Las revisiones de sprints no son una excepción. El equipo de Jira cuenta con miembros en el mundo entero: Sídney, Gdansk, Ho Chi Minh y San Francisco. Aunque estamos distribuidos, las revisiones de sprints son una parte importante de nuestra cultura de equipo. Los miembros del equipo crean vídeos informales y los comparten en una página de Confluence para que todo el equipo lo vea. Estos vídeos informales mantienen a todo el mundo al día del progreso del desarrollo a pesar de las diferencias horarias. Ver una demostración de la función de la mano del desarrollador refuerza al equipo de dos formas: Comprensión del producto: todo el equipo tiene la oportunidad de escuchar la intención, el razonamiento y la implementación de la función. Amplía el conocimiento que todos tienen del producto completo. Formación de equipos: los vídeos crean conexiones más personales en todo el equipo. Cada uno de nosotros logra ver quién está detrás de cada detalle de un producto. Los lazos creados mediante esta práctica nos unen más y nos hacen un grupo más integrado a pesar de la distancia. Un último consejo Para los equipos que son nuevos en esto de las revisiones de sprints, existe una fuerte tentación de convertir la revisión de sprints en una retrospectiva. Una revisión de sprints es un protocolo independiente a la retrospectiva de un sprint. Tómate el tiempo necesario para disfrutar del fruto de tu trabajo. Celebra libremente tus logros. Las revisiones de sprints eficaces suben la moral y aumentan la motivación del equipo. Esta idea de celebración es muy importante para nosotros en el equipo de Jira. Por esa misma razón, hemos añadido la idea de "¡Adelante, celebra!" a nuestra declaración de principios. Las reuniones rápidas son una de las partes fundamentales del desarrollo ágil y, con frecuencia, la que menos se comprende. Seamos realistas: las reuniones rápidas por sí mismas no hacen que tu equipo sea ágil. No pretenden inflar egos ni justificar descripciones de puestos de trabajo. No son un momento para planear; para eso, ya existe la planificación de sprints. Y tampoco son el único momento para mencionar los impedimentos. Si estás atascado, ¡pide ayuda! En este artículo, hablaremos sobre cómo gestionar de forma eficaz los impedimentos, y ofreceremos fantásticos consejos y trucos que utilizamos en Atlassian. Queremos ayudarte a que tus reuniones rápidas (y tu programa de metodología ágil en general) sean fantásticas. ¿Qué es entonces una reunión rápida en scrum? En muchos deportes como el fútbol americano y el rugby, el equipo forma una piña antes de cada partido. La piña es una cuestión estratégica: mantiene al equipo informado, conectado y calibrado a lo largo del partido. Para los equipos de software, la reunión rápida es como esa piña. Incluso se conoce habitualmente como scrum diario, y refuerza la idea de "nosotros" para mantener a todos al tanto del panorama y el progreso del equipo. Para los equipos de software, la reunión rápida es como la piña de un equipo deportivo. Dicho de otra forma, una reunión rápida es una reunión diaria en la que se implica al equipo básico: propietarios del producto, desarrolladores y el experto en scrum. La esencia de la reunión es única para cada equipo, pero en Atlassian utilizamos tres sencillas preguntas para generar una estructura: ¿En qué estuve trabajando ayer? ¿En qué estoy trabajando hoy? ¿Qué incidencias me están bloqueando? Estas preguntas resaltan el progreso y ayudan a señalar los impedimentos de los equipos. Asimismo, fortalece al equipo cuando todo el mundo comparte el progreso con el que está contribuyendo al equipo. El refuerzo diario que aporta compartir los planes y éxitos individuales mantiene a todo el mundo entusiasmado con la contribución general del equipo a la organización. A nivel individual, es importante acudir a la reunión rápida del día sabiendo lo que se va a decir. Mantiene la vitalidad de la reunión y a todo el mundo involucrado. En Atlassian, la gente utiliza los tableros de Jira para mantenerse al tanto de sus proyectos con filtros rápidos. Dos filtros importantes que pueden usarse a la vez para ayudarte a preparar la reunión rápida son los de "solo mis incidencias" y "actualizadas recientemente". Cuando estos dos filtros se usan juntos, muestran las incidencias que tienes asignadas y las que se han actualizado en el último día. CONSEJO DE EXPERTO Una personalización popular del filtro "Solo mis incidencias" es añadir el campo de participantes del complemento de Jira Toolkit. Este añade cualquier incidencia en la que hayas participado en lugar de mostrarte únicamente las que se te hayan asignado. El JQL para ese filtro sería: assignee = currentuser() or participants in (currentuser()) Reuniones rápidas en Atlassian Las reuniones rápidas no son una reunión general. En Atlassian, cada equipo celebra reuniones rápidas personalizadas que mantienen a todo el mundo involucrado y comprometido. No hay dos exactamente iguales. Indaga en lo que hace que una reunión rápida sea fantástica, y comprueba algunos de nuestros ejemplos. 1. Elige un horario que funcione para todos: en Atlassian, la mayoría de las reuniones rápidas para equipos ubicados en el mismo lugar tienen lugar entre las 9 y las 10 de la mañana. Así todo el mundo tiene tiempo para situarse con el trabajo del día y no requiere que todos los miembros del equipo sean madrugadores. Para los equipos repartidos en distintos lugares de la geografía, elige una hora que vaya bien a todos. Por ejemplo, el equipo de Jira Service Desk está dividido entre San Francisco y Sídney. Su reunión rápida tiene lugar a las 15:30 (hora de San Francisco). Sin duda, una reunión rápida por la tarde es poco habitual, pero es una gran manera de estar en contacto con los compañeros del otro lado del planeta en Sídney. 2. Logra que la reunión rápida resulte eficaz: muchos equipos de Atlassian cronometran, de manera informal, sus reuniones rápidas con el fin de mantener a todos los participantes centrados y de lograr que la reunión resulte eficaz. Ve turnando a los encargados de cronometrar para asegurarte de que todos sean responsables. Limita la duración de las reuniones rápidas a 15 minutos como máximo. ¿Tienes un equipo más pequeño? Convierte en una práctica el lograr que las reuniones rápidas sean aún más breves. 3. Juega a atrapar la pelota: el equipo de Jira lanza una pelota de playa entre los miembros para mantener a todo el mundo involucrado. Nadie puede lanzar la pelota al que tiene al lado ni a alguien que ya la haya tenido. ¡No hay distracciones que valgan! Si no has probado la técnica, debes saber que es una gran manera de mantener a todos involucrados. 4. Convierte la reunión rápida en parte de la retrospectiva del equipo: las reuniones rápidas forman parte de muchas culturas ágiles, pero eso no significa que el equipo no pueda debatir la eficacia de estas en las retrospectivas. Algunos equipos de Atlassian se reúnen a diario. Otros se reúnen tres veces en semana. El equipo de Jira suele debatir en las retrospectivas cómo hacer que las reuniones rápidas sean mejores para el equipo. Si el equipo no saca partido a la reunión rápida, averigua por qué. ¡Haz algunos cambios! Las reuniones rápidas también son ágiles. CONSEJO DE EXPERTO Algunos equipos de Atlassian integran Crontabs, Pandora y el mural de Jira del equipo. Crontabs carga Pandora (y la música favorita del equipo) 15 segundos antes de la reunión rápida para llamar la atención de todo el mundo y dar comienzo a la reunión en hora. El mural del equipo resalta cualquier incidencia bloqueada en la que el equipo deba centrarse durante el día. Reuniones rápidas para equipos distribuidos En Atlassian, contamos con equipos repartidos por todo el mundo: en una de nuestras 12 oficinas, o bien trabajando de forma remota. Confiamos en las reuniones rápidas para mantenerlos a todos conectados en las distintas zonas geográficas. Nuestra heurística para los equipos remotos es sencilla: si un miembro del equipo trabaja de forma remota, trata a todos los miembros del equipo como remotos. Esto se aplica tanto a las reuniones rápidas como a todos los protocolos de equipo. Nuestro consejo para los equipos distribuidos es que todos los miembros del equipo se unan a una reunión rápida por vídeo en su propio ordenador. Con todo el mundo en su propio espacio exclusivo y en la misma llamada de videoconferencia, el equipo ha equilibrado el terreno de juego. Todos los miembros del equipo pueden ver, escuchar y experimentar la misma información al mismo tiempo. Imagínate a un equipo de ocho personas, con cinco de los miembros del equipo que trabajan en la misma oficina en una sala de reuniones y tres miembros del equipo remotos en una llamada de videoconferencia. Esto supone un reto para los miembros del equipo remotos que quieren enterarse de las conversaciones secundarias, el lenguaje corporal y los gestos que no siempre se transmiten a través del vídeo. Por no mencionar el reto que supone interrumpir para hablar en un grupo grande. Si los ocho miembros del equipo están en sus propias máquinas, nadie se perderá ninguna dinámica de equipo importante. Consejos para las reuniones rápidas remotas: Haz que los miembros del equipo se vean: en Trello, los equipos utilizan la vista de “La tribu de los Brady” en las llamadas de videoconferencia del equipo. Esto da visibilidad a todos los miembros del equipo para que puedas conectar no solo con la persona que está hablando. Zoom ofrece esta función, al igual que otras plataformas de conferencias. Consulta tu tablero de scrum: reunirse "en" el tablero de scrum de tu equipo puede ser una forma poderosa de que todos remen en la misma dirección. Tu tablero de trabajo puede ayudar a visualizar cada historia de usuario y elemento de trabajo a medida que los miembros del equipo comparten en qué están trabajando y dónde están bloqueados. Sé receptivo a las reuniones rápidas asíncronas: para los equipos sin horas de trabajo coincidentes, las reuniones rápidas asíncronas son la solución. Los equipos pueden utilizar Slack o comentarios en su tablero de trabajo para compartir las actualizaciones cuando se conecten. Con Slack y Jira Software integrados, podrás comunicar toda la información que te gustaría obtener de una reunión rápida. Añadir unos emoticonos y algo de personalidad a las reuniones rápidas asíncronas ayuda a mantener el interés de todo el mundo. Las reuniones rápidas son solo una parte de un programa de metodología ágil sano. Al igual que otros protocolos de scrum como la planificación de sprints, las revisiones de sprints y las retrospectivas, las reuniones rápidas requieren tiempo e iteración para salir bien. No tengas miedo de hacer mejoras para adaptarlas a tu equipo y tu programa. Y no te olvides de pasártelo bien Qué es un experto en scrum? Los expertos en scrum son los moderadores de la metodología scrum, el marco ágil y ligero con un enfoque en las iteraciones limitadas llamadas “sprints”. Como moderadores, los expertos en scrum actúan como orientadores del resto del equipo; “líderes sirvientes”. como dice la guía de scrum. Todo experto en scrum que se precie se compromete con los fundamentos y valores de la metodología scrum, pero siguen siendo flexibles y estando abiertos a las oportunidades para que el equipo mejore su flujo de trabajo. Responsabilidades del experto en scrum En el mundo ágil ideal, el equipo gestionaría su propio proceso y herramienta; sin embargo, hemos observado que muchos equipos que dan el salto a la metodología ágil suelen depender del experto en scrum como propietario del proceso. La responsabilidad y la autoridad tardan en difundirse por un equipo. En este contexto transformador, la función puede ser tan ligera como la programación de las ceremonias de scrum o tan involucrada como la de cualquier otro miembro del equipo de scrum. Aunque en la guía de scrum se indica la forma en la que el experto en scrum cumple otras funciones de scrum, no se trata de una lista exhaustiva de responsabilidades. De hecho, observamos que los expertos en scrum suelen realizar algunas o todas las siguientes funciones, pero no todas se definen en la metodología de scrum: 1. Reuniones rápidas: facilitan las reuniones rápidas diarias (o el scrum diario) según sea necesario. 2. Reuniones de planificación de la iteración o sprint: protegen al equipo de un exceso de compromiso y de una corrupción del alcance. Ayudan en la estimación y creación de subtareas. 3. Revisiones de sprints: participan en la reunión y recopilan los comentarios. 4. Retrospectivas: anotan las áreas de mejora y los elementos de acción para los futuros sprints. 5. Administración de tableros: trabajan como administradores del tablero de scrum. Se aseguran de que las tarjetas estén actualizadas y que la herramienta de scrum, Jira software o cualquier otra, funcione bien. 6. Reuniones individuales: se reúnen de manera individual con los miembros del equipo y las partes interesadas, según sea necesario. Resuelven los desacuerdos del equipo sobre el proceso y los estilos de trabajo. Aunque muchos profesionales de scrum son reacios a celebrar reuniones individuales, ya que creen que estas comunicaciones deben realizarse durante las reuniones rápidas, algunos equipos, en particular los nuevos, prefieren tener estas interacciones periódicas cara a cara con miembros específicos del equipo. El experto en scrum puede decidir que estas interacciones individuales son cruciales para el desarrollo del equipo y para conocerse mutuamente. 7. Consultoría interna: los expertos en scrum deben estar preparados para consultar a los miembros del equipo y a las partes interesadas internas sobre la mejor manera de trabajar con el equipo de scrum. 8. Generación de informes: análisis periódicos de los gráficos de trabajo pendiente y otras herramientas de planificación de carteras para entender qué se desarrolla y a qué cadencia. 9. Impedimentos: el experto en scrum ayuda al equipo eliminando los impedimentos externos y gestionando los internos mediante mejoras en el proceso o el flujo de trabajo. 10. Trabajo con mucha actividad: si el equipo de scrum no está contento, es problema del experto en scrum. Tal vez eso implique arreglar ordenadores rotos, mover escritorios o incluso ajustar el termostato. Los expertos en scrum deben sentirse cómodos haciendo cualquier cosa para ayudar al equipo y no deben escabullirse para tomarse un café o algún tentempié si eso es lo que el equipo realmente necesita. ¿Necesito un experto en scrum? Cualquier instructor de scrum enseñará que un equipo de scrum debe disponer de un experto en scrum. Sin él, estás aplicando una metodología que solo se acerca al verdadero scrum, a menudo llamada “semiscrum”. Cuando se empieza con el scrum, puede ser de gran ayuda contar con alguien que ocupe la función que haya visto antes cómo funciona la metodología scrum; mejor aún, que haya visto muchos ejemplos de su funcionamiento. Por esta razón, los expertos en scrum se suelen contratar como consultores, en lugar de como empleados a tiempo completo. No obstante, cada equipo de scrum es distinto. Muchos equipos experimentados se encargan de las responsabilidades que se han enumerado antes como una unidad, y se enorgullecen y disfrutan de una gestión compartida del proceso. La función del experto en scrum rota por los miembros del equipo, es decir, son ellos los que se encargan de indicar cuándo se llevan a cabo las reuniones rápidas y las retrospectivas cuando les toque. Además, para algunos equipos, lo correcto es que la misma persona desempeñe la función todos los días. Por desgracia, el desconocimiento de la función del experto en scrum suele llevar a los gestores actuales a asumir que es su función. Para entender mejor el motivo por el que esto puede suponer un problema, comparemos la función de experto en scrum con otras funciones que no sean de scrum y que ya tengas en la organización, y la razón por la que es importante que dicha función la desempeñe otra persona. Comparación del experto en scrum y del gestor de productos Tal y como defendemos en el resumen de gestión de productos ágil, cuanto más implicado esté un gestor de productos con el equipo de desarrollo, mejor. Esa participación debe ser similar a la de un propietario del producto que defiende las necesidades del cliente, el motivo por el que se ha desarrollado el producto. Cuando la participación se pierde en la asignación de tareas, la forma en la que el equipo debe desarrollarlo, hay un problema. Incluso con las mejores intenciones, este tipo de mentalidad de uso tiende a ocultar las dificultades: defectos, transferencias e incógnitas. Intercalar el alcance y el proceso tiende a bloquear el alcance, la planificación y la calidad; es una fórmula abocada al fracaso. Por este motivo el experto en scrum y el propietario del producto cubren dos necesidades distintas en un equipo de scrum, que a menudo se combinan con la gestión de software tradicional. Además, resulta tentador en equipos pequeños evitar la percepción de la sobrecarga de otra función; sin embargo, cuando surgen obstáculos o se producen cambios, se requiere una división clara entre la gestión de procesos y la dirección del producto. El hecho de contar con un experto en scrum ayuda a equilibrar el coste de cambiar el curso con los beneficios de la eficiencia. Un experto en scrum que se precie lo hace dando libertad al equipo para decidir la forma de alcanzar mejor los objetivos mediante la autoorganización. Comparación del experto en scrum y del gestor de proyectos La contraparte no técnica (o no ágil) del experto en scrum es el gestor del proyecto. Ambas funciones se centran en la forma de llevar a cabo la labor y resolver los problemas del flujo de trabajo a través del proceso y la simplificación. Entonces, ¿los necesitas a ambos? Seguramente no. Tanto un gestor de proyectos tradicional como un experto en scrum son responsables de ayudar a sus equipos a realizar el trabajo, pero sus enfoques son muy distintos. El gestor de proyectos establece y hace un seguimiento de los plazos e hitos, informa sobre el progreso y coordina la comunicación del equipo; sin embargo, lo lleva a cabo desde una posición de control, en una función de gestión más tradicional. El experto en scrum ayuda al equipo a mejorar y racionalizar los procesos mediante los cuales logran sus objetivos. Lo ideal es que lo hiciera como miembro del equipo o colaborador, no como alguien que tiene el control. Los mejores equipos de scrum se autoorganizan y, por lo tanto, no reaccionan bien a la gestión descendente. Estas son solo algunas de las posibles configuraciones de la gestión del equipo de scrum. Algunas organizaciones cumplen con todas estas funciones, otras tienen una o ninguna. Los expertos en Scrum y las organizaciones más grandes Hay una consideración que se eleva por encima del resto cuando se piensa en contratar a un experto en scrum: solo si la organización está implicada con la metodología scrum e invierte en el proceso. Todas las funciones anteriores pueden gestionar un equipo de desarrollo de muchas maneras, pero un experto en scrum solo puede ser eficaz con una participación total en la metodología scrum. Fin de la historia. Gracias a un experto en scrum que ayude a todos los equipos a gestionar los procesos, toda la organización podrá obtener grandes ganancias. Además de proporcionar valor a los clientes de forma regular (el principal objetivo de la metodología scrum), los compañeros de equipo y los gestores podrán centrarse en lo que mejor saben hacer: los gestores de productos, en la estrategia; los desarrolladores, en escribir el mejor código y Kyle de ventas, en hacer sonar esa maldita campana. ¿Cómo suena todo eso? Suena como un scrum muy funcional, música para nuestros oídos. Cuáles son las tres funciones de scrum? Scrum presenta tres funciones: el propietario del producto, el experto en scrum y los miembros del equipo de desarrollo. Aunque esto está bastante claro, lo que hay que hacer con los cargos actuales puede resultar confuso. Muchos equipos se preguntan si deben cambiar los cargos al adoptar scrum. La respuesta corta es “no”. En este artículo definiremos las funciones de scrum y la forma en la que puedes incorporarlas en la organización, sin imprimir tarjetas de visita nuevas. Comparación de cargos y funciones de scrum Las tres funciones de scrum describen las responsabilidades clave de los miembros del equipo de scrum. No son cargos, lo que significa que cualquier cargo, incluso los actuales, pueden desempeñar una de las funciones. Como la esencia del scrum es el empirismo, la autoorganización y la mejora continua, las tres funciones dan una definición mínima de las responsabilidades y obligaciones para permitir a los equipos realizar el trabajo de manera eficaz; así se consigue que asuman la tarea de organizarse y seguir mejorando. Formación de un equipo de scrum Scrum es un marco sobre el que los equipos desarrollan sus procesos. Proporciona la estructura básica para hacer reuniones periódicas, crear artefactos y definir quién hace qué. Lo que no hace es ofrecer un modelo único en el que los equipos puedan trabajar. Por ejemplo, si el equipo está trabajando en una aplicación de seguros web, necesitará gente que conozca la tecnología, los sistemas back-end y el dominio del negocio. Si, por el contrario, está trabajando en la próxima versión de Donkey Kong, las habilidades necesarias serían muy diferentes. Incluirían un diseñador gráfico, un ingeniero de sonido y un desarrollador gráfico. Como los problemas son distintos, las estructuras del equipo y las habilidades necesarias también son diferentes. Esto se hace más difícil cuanto más complejo es el problema que un equipo está tratando de resolver. Como dice el viejo refrán: “A más vivir, más saber”. Puede que los equipos no sepan las habilidades ni la cantidad de trabajo necesario por adelantado, y requieran la flexibilidad de cambiar de rumbo una vez que obtengan más datos. Con el fin de organizar un poco este mundo complejo, cambiante y, a menudo, fastidioso, scrum ofrece una estructura ligera con las tres funciones de scrum: miembro del equipo de desarrollo, propietario del producto y experto en scrum. El equipo de desarrollo: nueva definición de “desarrollador” El equipo de desarrollo es la gente que hace el trabajo. De primeras, solemos pensar que el “equipo de desarrollo” solo está formado por ingenieros, pero no siempre es así. Según la guía de scrum, puede estar compuesto por todo tipo de personas, entre las que se incluyen diseñadores, redactores, programadores, etc. Puedes pensar en ello de la misma manera que cuando tienes un proyecto de casa y contratas a un promotor. Ellos desarrollan el proyecto y llevan a cabo el trabajo. Sí, puede que esto signifique que ponen ladrillos, instalan la fontanería e incluso cavan hoyos, pero la persona se denomina “promotor”. Si lo extrapolamos a la función de “desarrollador” en scrum, se trata de un miembro del equipo que tiene las habilidades adecuadas, como parte del equipo, para realizar el trabajo. Mito del scrum: el desarrollador de scrum implica que solo los programadores pueden formar parte de un equipo de scrum El equipo de desarrollo debe ser capaz de autoorganizarse para poder tomar decisiones con el fin de llevar a cabo el trabajo. Piensa en un equipo de desarrollo como en un equipo de apoyo a la producción al que se contacta durante la noche porque algo ha salido mal. El equipo de desarrollo, al igual que el equipo de apoyo a la producción, puede tomar decisiones y entregar el arreglo o el valor del problema en cuestión. La autoorganización no consiste en faltar al respeto a la organización, sino en capacitar a las personas más cercanas al trabajo para que hagan lo necesario para resolver el problema. Entre las responsabilidades del equipo de desarrollo se encuentra la siguiente: Entrega del trabajo a través del sprint. Con el fin de garantizar la transparencia durante el sprint, se reúnen diariamente en el scrum diario (a veces llamado “reunión rápida”). El scrum diario proporciona transparencia al trabajo y ofrece un lugar exclusivo para que los miembros del equipo busquen ayuda, hablen sobre el éxito y destaquen las incidencias y los impedimentos. El experto en scrum puede facilitar el scrum diario, pero, en última instancia, es responsabilidad del equipo de desarrollo llevar a cabo esta reunión, ya que sirve para ayudarles, como grupo, a inspeccionar y adaptar el trabajo que están haciendo y trabajar de una manera más eficaz. El propietario del producto: fijación de una dirección clara Los equipos ágiles son, por naturaleza, flexibles y receptivos, y es responsabilidad del propietario del producto asegurarse de que están entregando el valor máximo. La empresa está representada por esta persona, que le dice al desarrollador lo que prima entregar. La confianza entre estas dos funciones es crucial. El propietario del producto no solo debe conocer al cliente, sino también contar con una visión del valor que el equipo de scrum le está entregando. También equilibra las necesidades de otras partes interesadas en la organización. Así que el propietario del producto debe tomar todos estos aportes y establecer la prioridad del trabajo. Esta es probablemente su responsabilidad más importante porque las prioridades conflictivas y las instrucciones que no sean muy claras no solo reducirán la eficacia del equipo, sino que también podrían romper la importante relación de confianza que la empresa tiene con el equipo de desarrollo. Los equipos ágiles se han diseñado para inspeccionar y adaptarse, lo que significa que un cambio de prioridad puede llevar a un cambio masivo en la estructura de estos, en los productos de trabajo y en el resultado final. Por lo tanto, resulta fundamental, para que los equipos de scrum tengan éxito, que solo una persona establezca la prioridad: el propietario del producto. En la guía de scrum se definen las responsabilidades de los propietarios del producto de la siguiente manera: Gestión del backlog de scrum: esto no significa que sean los únicos en poner los elementos nuevos del backlog del producto en el backlog, pero, en última instancia, son responsables del backlog que el equipo de desarrollo saca para lanzar. Esto significa que el propietario del producto debe ser consciente de todo lo que hay en el backlog y otras personas que añaden elementos al backlog del producto deben asegurarse de que se comunican con el propietario del producto. Gestión de publicaciones: el sprint no es un ciclo de publicación, sino un ciclo de planificación. Eso significa que los equipos de scrum pueden realizar lanzamientos en cualquier momento. Lo ideal sería que hicieran lanzamientos frecuentes durante el sprint, lo que permitiría que en la revisión del sprint se comprobara el uso real de los clientes y sus comentarios; sin embargo, la entrega continua no siempre es posible y se requieren otros modelos de publicación. Es importante que el propietario del producto sepa cuándo se pueden y se deben publicar los elementos. Gestión de partes interesadas: en cualquier producto participarán muchas partes interesadas, desde los usuarios, los clientes, la administración y el equipo directivo de la organización. El propietario del producto tendrá que trabajar con todas estas personas para garantizar de forma eficaz que el equipo de desarrollo esté aportando valor, lo que puede implicar una gran cantidad de gestión y comunicación con las partes interesadas. Mito de scrum: el propietario del producto crea todos los requisitos, redacta todos los criterios de aceptación y desarrolla todas las historias. El experto en scrum: la unión El experto en scrum es la función que se encarga de unir todo y asegurar que el scrum se haga bien. En términos prácticos, eso significa que ayuda al propietario del producto a definir el valor, al equipo de desarrollo a entregarlo y al equipo de scrum a mejorar. Es un líder servidor que no solo representa un estilo de liderazgo de apoyo, sino que refleja lo que hacen en el día a día. Sirve al propietario del producto ayudándole a entender y comunicar mejor el valor, a gestionar el backlog, a planificar el trabajo con el equipo y a desglosarlo para ofrecer el conocimiento más eficaz. Al servir al equipo de desarrollo, el experto en scrum les ayuda a autoorganizarse, a centrarse en los resultados, a conseguir un incremento de tareas finalizadas y a gestionar los impedimentos. También sirve a la organización en general y les ayuda a entender qué es el scrum y a crear un ambiente que lo fomente. Mito de scrum: el experto en scrum tiene que ejecutar el scrum diario. De hecho, no dirige ninguno de los eventos, solo se asegura de que se produzca y que se lleven a cabo correctamente. El experto en scrum se centra en lo siguiente: Transparencia: para inspeccionar y adaptar de forma eficaz es importante que las personas adecuadas puedan ver lo que está pasando; sin embargo, esto resulta en realidad mucho más complicado de lo que parece. El experto en scrum tiene la tarea de garantizar que el equipo de scrum trabaje de manera transparente. Entre los ejemplos se incluyen la creación de mapas de historias y la actualización de las páginas de Confluence con las ideas de las retrospectivas. Empirismo: la idea de que la mejor manera de planificar es llevar a cabo el trabajo y aprender de él constituye un aspecto básico para las estrategias ágiles y de scrum. El proceso empírico no es fácil y requiere que el experto en scrum oriente al equipo de scrum en el desglose del trabajo, y que proporcione resultados claros y los revise. Autoorganización: decir a un equipo de desarrollo que puede autoorganizarse significa que el equipo se autoorganizará. De hecho, la autoorganización llega con el tiempo y requiere de ayuda y apoyo. El experto en scrum animará a los miembros del equipo a salir de su zona de confort y probar cosas distintas y utilizar prácticas como el “póker de delegación” para exponer y cuestionar las ideas predefinidas sobre los límites de las funciones y responsabilidades. Valores: scrum define cinco valores de voluntad, concentración, compromiso, respeto y transparencia, no porque sea bueno tenerlos, sino porque crean un ambiente de seguridad fisiológica y confianza. Este entorno es necesario para que la agilidad prospere. Seguir los valores es responsabilidad de todos en el equipo de scrum, pero el experto en scrum asume una función activa para alentar y recordar a todos la importancia de dichos valores. El experto en scrum sirve al propietario del producto en la planificación del sprint y en las revisiones de este para garantizar que la dirección se haya establecido y que el valor se haya descrito con claridad. Sirve al equipo de desarrollo en el scrum diario asegurando que el trabajo se esté realizando y que los impedimentos se estén eliminando. También se responsabiliza de los impedimentos que se encuentran fuera de la capacidad de resolución del equipo. El experto en scrum comprueba que todas las oportunidades de mejorar se hagan transparentes para el equipo de scrum y que la retrospectiva cuente con un conjunto claro de resultados que se puedan ejecutar. Las funciones de scrum de metodología ágil Los tres funciones de scrum son bastante simples para describir las tres principales áreas de responsabilidad en cualquier equipo de scrum, pero a menudo resulta complicado asignarlas a tu propio puesto de trabajo. Así que por aquí se empieza: Si tienes muchas habilidades para entregar valor al cliente y eso es lo que te emociona, deberías ser miembro del equipo de desarrollo de scrum. De hecho, el equipo es el elemento más importante de cualquier organización ágil, ya que realmente entrega valor a los clientes y a las partes interesadas. Eso significa que la antigüedad está determinada por la cantidad de valor que entregues o cuánto ayudes a otros a hacerlo. Si eres experto en el cliente, la gestión de las partes interesadas y el dominio de la empresa, la función del propietario del producto sería la más adecuada para cumplir tus deseos. En la mayoría de las organizaciones, esta persona debe contar con el respeto y la confianza de la empresa, para que pueda tomar decisiones. La función también requiere cierto nivel de politiqueo mientras negocias las compensaciones y mantienes a todos satisfechos. Si quieres ayudar a los equipos a trabajar juntos de forma eficaz y también deseas cambiar el mundo con el scrum y la metodología ágil, la función de experto en scrum es para ti; ya que se centra mucho en las personas y hace mucho hincapié en la orientación, la formación y el asesoramiento. Aprende scrum con Jira Software Instrucciones pormenorizadas sobre cómo dirigir un proyecto basado en scrum Tutorial de scrum En este tutorial, ofrecemos instrucciones pormenorizadas sobre cómo dirigir un proyecto basado en scrum, priorizar y organizar tu backlog mediante sprints y ejecutar protocolos de scrum en Jira Software, entre otras muchas más opciones. Tiempo: 10 minutos de lectura. Completar en 2 semanas Público de destino: Para los nuevos usuarios de scrum, el desarrollo de software ágil o Jira Software Requisito previo: Haber creado una cuenta de Jira Software ¿QUÉ ES SCRUM? Scrum es uno de los marcos más conocidos para implementar el método ágil. Con scrum, el producto se crea en una serie de iteraciones de longitud fija llamadas sprints que ofrece a los equipos un marco para realizar los envíos con una cadencia periódica. Paso 1: Crea un proyecto de scrum Una vez que crees una cuenta de Jira Software e inicies sesión en ella, puedes crear un proyecto. Cuando se te solicite que selecciones una plantilla de proyecto, selecciona Scrum. También puedes aprender a crear un proyecto Kanban aquí. Como alternativa, si buscas una experiencia más sencilla u optimizada, piensa en probar nuestra plantilla de nueva generación de Scrum. Consulta Introducción a los proyectos de nueva generación en la Comunidad de Atlassian para obtener más información. Una vez que hayas creado el proyecto, entrarás en el backlog vacío. El backlog también se conoce como el backlog del producto y contiene una lista continua de los elementos de trabajo potenciales de tu equipo en relación con el proyecto. Paso 2: Crear historias de usuario o tareas en el backlog En Jira Software, llamamos "incidencias" a los elementos de trabajo, como las historias de usuario, las tareas y los errores. Crea algunas historias de usuario con la opción de creación rápida en el backlog. Si no tienes ninguna historia de usuario en mente, simplemente crea historias de usuario de ejemplo para empezar y ver cómo funciona. ¿QUÉ SON LAS HISTORIAS DE USUARIO? Las historias de usuario se utilizan para describir elementos de trabajo en un lenguaje no técnico y desde la perspectiva de un usuario. Como {tipo de usuario}, quiero {objetivo} para que pueda {obtener un beneficio}. Utilicemos un sitio web como ejemplo sencillo de cómo crear una historia de usuario. Como cliente, deseo crear una cuenta para que pueda ver mis compras anteriores. El propietario del producto suele esbozar y priorizar las historias de usuario y después el equipo de desarrollo determina las tareas detalladas que son necesarias para completar la historia en un próximo sprint. El equipo de desarrollo también es responsable de estimar el esfuerzo relativo necesario para completar la historia. Una vez que hayas creado algunas historias de usuario, puedes comenzar a priorizarlas en el backlog. En Jira Software, puedes clasificar o priorizar tus historias arrastrándolas y soltándolas en el orden en que deberían estar. Estas son solo las primeras historias de tu proyecto. Seguirás creando historias mientras dure el proyecto. Esto responde a que la metodología ágil implica un aprendizaje y una adaptación continuos. Paso 3: Crear un sprint Crea tu primer sprint en el backlog para que puedas empezar a planificar el sprint. ¿QUÉ ES UN SPRINT? En scrum, los equipos realizan pronósticos para completar una serie de historias de usuario u otros elementos de trabajo durante un periodo fijo conocido como sprint. En términos generales, los sprints duran una, dos o cuatro semanas. Corresponde al equipo determinar la longitud de los sprints. Nosotros recomendamos empezar con dos semanas. Es el tiempo suficiente para conseguir algo, pero no tanto como para que el equipo no reciba feedback de forma periódica. Cuando se determina la cadencia de un sprint, el equipo trabaja constantemente en esa cadencia. Los sprints de longitud fija refuerzan las habilidades de estimación y predicen la futura velocidad del equipo a medida que este trabaja en las tareas del backlog. Paso 4: Organizar la reunión de planificación de sprints Al principio de cada sprint, deberías celebrar una reunión con el resto del equipo para planificar el sprint. La reunión de planificación del sprint es una ceremonia en la que se sientan las bases para todo el equipo para que el sprint resulte un éxito. En esta reunión, todo el equipo debate el objetivo del sprint y las historias del backlog del producto priorizado. El equipo de desarrollo crea tareas detalladas y estimaciones de las historias de alta prioridad. El equipo de desarrollo se compromete a completar un determinado número de historias en el sprint. Estas historias y el plan para completarlas se convierte en lo que se conoce como el backlog del sprint. Añade estimaciones de puntos de historia añadiendo un número al campo Estimación de puntos de historia. También puedes añadir más detalles a las historias o hacer clic en el icono Crear subtarea para desgranar el trabajo de la historia. Cuando estés preparado, arrastra las historias acordadas en la reunión de planificación del sprint al sprint que acabas de crear. Este es tu backlog del sprint. ¿EN QUÉ CONSISTE LA REUNIÓN DE PLANIFICACIÓN DE SPRINTS? Asistentes: Obligatorios: equipo de desarrollo, experto en scrum, propietario del producto Cuándo: Al principio de un sprint. Duración: Normalmente dos horas por semana de iteración; p. ej., un sprint de dos semanas comienza con una reunión de planificación de cuatro horas. La reunión termina cuando se ha alcanzado su propósito. Propósito: Planificar el trabajo del sprint. El equipo acuerda el objetivo del sprint y el backlog del sprint. ¿QUÉ ES EL OBJETIVO DEL SPRINT? Al crear un sprint, el propietario del producto suele identificar un objetivo del sprint. Esto ofrece un tema para que se complete el trabajo en el sprint. El objetivo del sprint también ofrece flexibilidad en cuanto al número de historias que se completan en un sprint. Un sprint se considera un éxito si se consigue el objetivo del sprint. ¿QUÉ ES LA ESTIMACIÓN ÁGIL? Los equipos de software tradicionales dan estimaciones en un formato de tiempo: días, semanas, meses. Sin embargo, muchos equipos que han adoptado la metodología ágil pasan a utilizar los puntos de historia. Los puntos de historia valoran el esfuerzo relativo del trabajo, a menudo en un formato similar a la secuencia de Fibonacci: 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Las estimaciones te permiten medir la cantidad de trabajo que deberás añadir al siguiente sprint basándote en el número de componentes de tu equipo. Tras unos sprints, tu equipo sabrá con más certeza la cantidad de trabajo que puede asumir durante el sprint, lo que evitará comprometerse a hacer más trabajo del que se puede asumir. Paso 5: Iniciar el sprint en Jira Asigna un nombre al sprint. Algunos equipos asignan el nombre al sprint en función de su objetivo. En caso de que varias incidencias del sprint tengan algún rasgo en común, asigna un nombre al sprint en torno a ese tema. También puedes asignar al sprint el nombre que quieras. Añade una duración del sprint y las fechas de inicio y de finalización. Dichas fechas deberían adaptarse a la planificación del equipo. Por ejemplo, algunos equipos inician los sprints el lunes y los finalizan el viernes de la siguiente semana, por la mañana. Otros equipos deciden iniciar y finalizar tus sprints a mediados de semana. Depende de ti. Si no estás seguro de cuál debería ser la duración de los sprints, te recomendamos probar con dos semanas. Añade el objetivo del sprint tal y como se haya acordado en la reunión de planificación del sprint. Una vez que comiences el sprint, accederás a la pestaña Sprints activos del proyecto. Este es el sitio en el que el equipo trabajará para seleccionar los elementos de la columna de tareas pendientes y llevarlos a la de tareas en curso y, por último, a la de tareas finalizadas. Si utilizas la plantilla de última generación de Scrum, se le llamará Tablero. Paso 6: Organizar las reuniones rápidas diarias Tras iniciar el sprint, el equipo se debe reunir a diario, normalmente por la mañana, para revisar las tareas que realiza cada uno. El objetivo de esta reunión es comprobar si alguien del equipo está experimentado bloqueos que le impiden realizar las tareas del sprint. ¿EN QUÉ CONSISTEN LAS REUNIONES RÁPIDAS DIARIAS? Asistentes (principalmente): equipo de desarrollo Cuándo: una vez al día, normalmente por las mañanas Duración: no más de 15 minutos. No reserves ninguna sala de reuniones y haz la reunión de pie. Al estar de pie la reunión será más corta. Propósito: la reunión rápida diaria está pensada para informar a todos rápidamente del trabajo que el equipo tiene entre manos y para planificar las tareas del día. No se trata de una reunión completa. El tono debe ser ligero y divertido, a la vez que informativo. Plantea a cada miembro del equipo las siguientes preguntas: ¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Hay algo que bloquee mi trabajo? Existe una responsabilidad implícita en informar del trabajo que realizaste ayer delante de tus compañeros. Nadie quiere ser ese miembro del equipo que siempre está trabajando en lo mismo y no realiza ningún progreso. Consejo de experto: algunos equipos utilizan temporizadores para llevar un seguimiento de todos los miembros. Otros lanzan una pelota a diferentes miembros del equipo para asegurarse de que todos están prestando atención. Muchos equipos cuyos miembros trabajan en lugares distintos utilizan videoconferencias o chats grupales para salvar el hueco que deja la distancia. Tu equipo es único, y las reuniones rápidas que organizas también deben serlo. Puedes utilizar los sprints activos del tablero de scrum durante la reunión rápida diaria para que cada miembro del equipo pueda ver las tareas en las que está trabajando. Paso 7: Consultar el diagrama de trabajo pendiente Es buena idea consultar el diagrama de trabajo pendiente durante un sprint. En Jira Software, el diagrama de trabajo pendiente muestra la cantidad estimada y la cantidad real de trabajo que se debe realizar en un sprint. El diagrama de trabajo pendiente se actualiza automáticamente en Jira conforme completas las tareas. Para ver este diagrama, haz clic en Informes en la barra lateral y, a continuación, selecciona el diagrama de trabajo pendiente de la lista desplegable de informes. QUÉ ES UN DIAGRAMA DE EVOLUCIÓN Y CÓMO SE INTERPRETA El diagrama de trabajo pendiente muestra la cantidad de trabajo real y estimada que hay que hacer en un sprint. El eje X horizontal de un diagrama de trabajo pendiente indica el tiempo, mientras que el eje Y vertical indica los puntos de historia. El diagrama de trabajo pendiente se utiliza para supervisar todo el trabajo restante y proyectar la posibilidad de alcanzar el objetivo del sprint. Supervisar el trabajo total restante mediante iteraciones permite al equipo gestionar su progreso y responder de la forma correspondiente. ANTIPATRONES ANTE LOS QUE ESTAR ALERTA El equipo termina antes de tiempo todos los sprints porque no está asumiendo la cantidad de trabajo que debería. El equipo no cumple el objetivo del sprint previsto sprint tras sprint porque está asumiendo demasiado trabajo. La línea del trabajo pendiente presenta caídas abruptas en lugar de una evolución más gradual porque el trabajo no se ha dividido en fragmentos granulares. El propietario del producto añade o cambia el alcance del sprint con el sprint ya comenzado. Paso 8: Consultar el informe de sprints En cualquier momento durante o después del sprint puedes consultar el informe de sprints o supervisar el sprint. ¿QUÉ ES EL INFORME DE SPRINTS? El informe de sprints incluye el gráfico de trabajo pendiente, indica el trabajo completado, el trabajo sin completar y cualquier trabajo que se haya añadido tras iniciar el sprint. Paso 9: Organizar la reunión de revisión del sprint La revisión del sprint o la demo del sprint es una reunión participativa en la que el equipo muestra lo que ha lanzado en cada sprint. Cada sprint suele producir una parte funcional del producto que recibe el nombre de incremento. Se trata de una reunión en la que se comparten muchas opiniones sobre el proyecto e incluye una sesión de lluvia de ideas para poder decidir cuál es el siguiente paso. Asistentes (principalmente): el equipo de desarrollo, el experto en scrum, el propietario del producto. Opcional: las partes interesadas Cuándo: normalmente el último día del sprint Duración: normalmente dos horas para un sprint de dos semanas Propósito: inspeccionar el incremento y la actualización colaborativa del backlog del producto. Preguntas que deben hacerse: ¿Cumplió el equipo la previsión del script? ¿Se añadió o quitó trabajo una vez el sprint estuvo en marcha? ¿Hubo alguna parte del trabajo que no se completara durante el sprint? Si así fuera, ¿cuál? Paso 10: Organizar la reunión retrospectiva del sprint Tras finalizar el sprint, el equipo debe hacer una retrospectiva. Documenta la retrospectiva en alguna plataforma. ¿Qué tal si usamos Confluence? ¿EN QUÉ CONSISTE UNA REUNIÓN RETROSPECTIVA DE SPRINTS? Asistentes: el equipo de desarrollo, el experto en scrum, el propietario del producto. Cuándo: al finalizar una iteración. Duración: normalmente 90 minutos para un sprint de dos semanas. Propósito: el equipo se inspecciona, incluidos sus procesos, herramientas y la interacción del equipo. Las incidencias de mejora suelen añadirse al backlog del siguiente sprint. Las restrospectivas no son el momento de expresar quejas sin hacer propuestas de mejora. Utiliza las retrospectivas para descubrir lo que funciona para que el equipo pueda seguir centrándose en esas áreas. También sirven para detectar lo que no funciona, buscar soluciones creativas y desarrollar un plan de acción. La mejora continua es lo que sostiene e impulsa el desarrollo dentro de un equipo ágil, y las retrospectivas constituyen un elemento clave para ello. Preguntas que deben hacerse: ¿Qué hemos hecho bien durante el sprint? ¿Qué podríamos haber hecho mejor? ¿Qué vamos a mejorar para la próxima vez? Consejo de experto: Aunque las cosas vayan bien en el equipo, no dejes de hacer retrospectivas. Las retrospectivas ofrecen una guía constante para que el equipo siga haciendo las cosas bien. Paso 11: Completar el sprint en Jira Al final del sprint, debes completarlo. Si el sprint tiene incidencias incompletas, puedes: Mover las incidencias al backlog. Mover las incidencias a un sprint futuro. Mover las incidencias a un nuevo sprint que Jira se encargará de crear. Paso 12: Repetir desde el paso 2 Llegados a este punto, dispones de los conocimientos básicos sobre cómo crear el backlog con las historias de usuario, cómo organizar las historias de usuario en sprints, iniciar el sprint y celebrar ceremonias de scrum. Tienes la capacidad de decidir si esto funciona para tu equipo o si te gustaría pasar a algunos temas más avanzados. Una vez que tu equipo y tú hayáis perfeccionado los pasos anteriores, pasa al artículo avanzado: Cómo realizar prácticas avanzadas de scrum con Jira Software. utorial avanzado de scrum En este tutorial, ofrecemos instrucciones pormenorizadas sobre prácticas de scrum más avanzadas como el uso de epics, la personalización del flujo de trabajo y el uso de informes en Jira Software. Duración: Lectura de 10 minutos de duración. Completar en 2 semanas. Público: Ya conoces las prácticas básicas de scrum y has empezado a utilizar Jira Software. Realiza el primer tutorial aquí Requisito previo: Crear una cuenta de Jira Software. Pruébalo gratis Paso 12: Utilizar épicas en el backlog Es posible que tu equipo tenga que trabajar en funcionalidades que se componen de una muestra de trabajo más amplia. Si esto ocurre, deberías considerar usar las épicas al planificar el trabajo y limpiar el backlog. Las épicas son historias de usuario de gran tamaño que se pueden dividir en historias de usuario más pequeñas. Además, las épicas pueden abarcar varios proyectos. Por tanto, si tu equipo está trabajando en historias de usuario que conforman una historia de usuario más grande, que afecta a varios proyectos, adelante, utiliza las épicas. En estos casos, facilitan el seguimiento del proyecto. Para utilizar las épicas, dirígete al backlog del tablero y amplía el panel de épicas haciendo clic en EPICS (ÉPICAS). Consulta Trabajar con épicas para conocer más prestaciones de las épicas.(guiño) Paso 13: Personalizar el workflow En el workflow predeterminado de Jira Software, tus tiques pasan por tres estados: por hacer, en curso y hecho. Si esto es demasiado sencillo, puedes crear tu propio workflow de modo que los estados de Jira Software coincidan con el proceso de tu equipo. Por ejemplo, si tu equipo trabaja en un proyecto de desarrollo de software, puede que quieras añadir estados, como los de revisión del código, en espera de control de calidad o listo para hacer un merge. Puedes hacer que Jira refleje cómo trabaja tu equipo con tanto detalle o tan poco como necesites. Para obtener más información, consulta el artículo de workflows de tiques. Paso 14: Emplear el diagrama de velocidad Jira Software pretende ayudarte a desatar el potencial tu equipo. Con el diagrama de velocidad, puedes ver un resumen del trabajo que el equipo entrega en cada uno de los sprints. Puedes utilizar esta información para predecir la cantidad de trabajo que tu equipo puede completar, de manera realista, en futuros sprints. Durante las reuniones de planificación de sprints, de hecho, tu equipo puede pasar por las imágenes de lo que ha ocurrido en anteriores sprints —el compromiso del equipo frente a la finalización real— y, después, presentar nuevos compromisos realistas. Consulta el diagrama de velocidad para obtener más detalles sobre cómo usarlo. Paso 15: Uso de murales Con todo lo que ocurre en tu proyecto, también merece la pena plantearse el uso de murales para que el equipo se ponga al día rápido de un simple vistazo. Conecta tu ordenador al monitor de la televisión y ¡voilà! El panel de Jira Software es ahora un mural físico, con el poder de los gadgets ágiles de Jira Software mostrando el progreso de tu equipo en tiempo real. Para obtener más detalles sobre cómo configurar tu panel y tu mural, consulta la sección de configuración de paneles. Tutorial sobre kanban En este tutorial encontrarás instrucciones detalladas sobre cómo dirigir un proyecto de kanban, priorizar el trabajo, visualizar el flujo de trabajo y minimizar el trabajo en curso para evitar que el equipo esté sobrecargado, todo ello con Jira Software. Tiempo: 10 minutos de lectura. Se completa en unas semanas Público de destino: Para los nuevos usuarios del desarrollo de software de kanban y/o Jira Software Requisito previo: Haber creado una cuenta de Jira Software Pruébalo gratis ¿QUÉ ES KANBAN? kanban es similar a scrum, en cuanto a que ayuda a los equipos a publicar software pronto y con frecuencia. No obstante, kanban otorga mayor flexibilidad en términos de planificación y ejecución. En lugar de trabajar con sprints basados en plazos, en kanban, el trabajo se entrega de forma continua y el equipo saca trabajos individuales del backlog y los mueve con los demás trabajos completados. Paso 1: Crear un proyecto de kanban Una vez que hayas iniciado sesión en Jira Software, tendrás la opción de crear un proyecto. Cuando llegues a la selección del tipo de proyecto, asegúrate de seleccionar el proyecto de desarrollo de software de kanban. El nuevo proyecto de desarrollo de software de kanban también incluirá un tablero de kanban. Una vez que hayas creado el proyecto, lo primero que verás será el tablero de kanban de tu equipo. Este es el lugar en el que el equipo realizará el seguimiento de su trabajo. Paso 2: Configurar el workflow En Jira Software, el proyecto de kanban te ofrece un flujo de trabajo listo para usar con las columnas Backlog, Seleccionado para desarrollo, En curso y Hecho. Esto permite al propietario del producto añadir tareas al backlog y moverlas a la sección "lista para su desarrollo" una vez que la tarea o la historia de usuario está totalmente preparada. Los miembros del equipo pueden entonces seleccionar elementos de dicha columna y moverlos a las columnas En curso y Hecho. Si tu flujo de trabajo de desarrollo es diferente, resulta fácil añadir o quitar un estado de flujo de trabajo. Por ejemplo, muchos equipos quieren añadir un control de calidad o una fase de revisión en su flujo de trabajo. Para configurar las columnas y el flujo de trabajo, haz clic en Tablero en la esquina superior derecha del backlog y selecciona Configurar. Una vez en la página de configuración del tablero, selecciona Columnas en la barra lateral. Desde ahí, puedes añadir un estado o una columna con los botones de la derecha o pulsar el botón de la papelera para eliminar una columna. Cuando tengas las columnas de flujo de trabajo que quieras, pulsa Volver al tablero en la esquina superior derecha. Paso 3: Añadir tareas, bugs o historias de usuario al backlog Utiliza el botón Crear para empezar a añadir tareas, errores o historias de usuario al backlog. En kanban, esta es la primera columna del tablero. Si no tienes un proyecto o una función en mente, intenta crear algunas tareas de ejemplo para empezar y ver cómo funciona. ¿QUÉ SON LAS HISTORIAS DE USUARIO? En un marco de trabajo ágil, las historias de usuario son las unidades de trabajo más pequeñas. Como {tipo de usuario} , quiero { objetivo} para poder { obtener beneficios}. Utilizaremos un sitio web como ejemplo sencillo de cómo crear una historia de usuario. Como cliente, quiero crear una cuenta para poder ver las compras que hice el año pasado y poder crear mis presupuestos para el año siguiente. El propietario del producto diseña las historias de usuario y, a continuación, el equipo del producto al completo determina en conjunto los requisitos detallados. Paso 4: Priorizar el backlog Para clasificar o priorizar los elementos en el backlog, arrastra y suelta las tarjetas en la parte superior o inferior de la primera columna en función de la prioridad. PRIORIZACIÓN EN KANBAN: Un equipo de kanban solo se centra en el trabajo que está en curso. Una vez que el equipo completa un elemento de trabajo, selecciona el siguiente. El propietario del producto tiene la libertad de establecer nuevas prioridades de trabajo en el backlog sin interrumpir al equipo, ya que cualquier cambio fuera de los elementos actuales de trabajo no afecta al equipo. Mientras el propietario del producto mantenga los elementos de trabajo más importantes al principio del backlog, el equipo de desarrollo tendrá la seguridad de estar devolviendo el máximo valor a la empresa. Así pues, no hacen falta las iteraciones de longitud fija que encontramos en scrum. Puede resultar útil utilizar la opción de prioridad al añadir incidencias al tablero para que se visualicen fácilmente al establecer las prioridades. La configuración predeterminada en kanban añadirá carriles a tu tablero, uno para los elementos prioritarios, etiquetado como "Rápido" y otro para todo lo demás. Además, puedes usar herramientas como etiquetas o funciones en cada incidencia para que te ayuden a categorizar las partes del trabajo. ¿QUÉ SON LOS CARRILES? Un carril te permite categorizar incidencias de modo que los equipos ágiles puedan ver en cuáles de ellas deben trabajar después. Para editar los carriles predeterminados, ve a la configuración del tablero en la esquina superior derecha del backlog y selecciona Carriles en la barra lateral. En esa pantalla, puedes añadir carriles mediante la categorización de las incidencias con JQL. Paso 5: Seleccionar trabajo del backlog En Kanban, los miembros del equipo toman los elementos de la columna Backlog o Seleccionado para desarrollo y los mueven a En curso. Se recomienda limitar el trabajo que se encuentra en curso. Para facilitarlo, considera la posibilidad de añadir límites a las columnas. Al hacerlo, se mostrará una advertencia si tu equipo desplaza demasiadas tareas a una columna. ¿POR QUÉ LIMITAR EL TRABAJO EN CURSO? Puedes establecer límites para el trabajo en curso (WIP), lo cual, básicamente, te permite definir la cantidad mínima y máxima de trabajo que se encuentra en cada columna del tablero. Los límites de trabajo en curso reducen la cantidad de trabajo "prácticamente listo" obligando al equipo a centrarse en un conjunto de tareas más pequeño, lo que, en esencia, mejora el modo en que el equipo trabaja durante el proceso. Los límites del trabajo en curso también ponen de manifiesto los cuellos de botella en los procesos de entrega de un equipo antes de que la situación se vuelva peligrosa. Estas ventajas aceleran los incrementos del valor al cliente, de modo que los límites del trabajo en curso son una herramienta valiosa en el desarrollo ágil. Más información aquí. En Jira Software, puedes añadir límites mínimo y máximo a cada columna en la sección Columnas de la configuración del tablero. Paso 6: Celebrar reuniones de equipo En kanban, las reuniones rápidas diarias y las retrospectivas son opcionales. No obstante, se recomienda que sea el equipo quien decida la cadencia de las reuniones. Es posible que las reuniones rápidas diarias sigan siendo beneficiosas para que el equipo resalte en qué puntos existen impedimentos en su trabajo. También pueden resultar útiles para que el propietario del producto comparta lo que ha priorizado y el porqué. Averigua lo que funciona para tu equipo y pruébalo. Siempre puedes realizar ajustes sobre la marcha. ¿EN QUÉ CONSISTEN LAS REUNIONES RÁPIDAS DE PIE DIARIAS? Asistentes obligatorios: el equipo de desarrollo y el propietario del producto Opcional: las partes interesadas del equipo Cuándo: una vez al día, normalmente por la mañana Duración: no más de 15 minutos. No reserves ninguna sala de reuniones y haz la reunión rápida. Al estar de pie la reunión será más corta. Marco de trabajo ágil: scrum y kanban. Propósito: la reunión de pie diaria está pensada para informar a todos rápidamente del trabajo que el equipo tiene entre manos y para planificar las tareas del día. No se trata de una reunión completa. El tono debe ser ligero y divertido, a la vez que informativo. Plantea a cada miembro del equipo las siguientes preguntas: ¿Qué hice ayer? ¿Qué voy a hacer hoy? ¿Hay algo que bloquee mi trabajo? Existe una responsabilidad implícita en informar del trabajo que realizaste ayer delante de tus compañeros. Nadie quiere ser ese miembro del equipo que siempre está trabajando en lo mismo y no realiza ningún progreso. Consejo de experto: algunos equipos utilizan temporizadores para llevar un seguimiento de todos los miembros. Otros lanzan una pelota a diferentes miembros del equipo para asegurarse de que todos están prestando atención. Muchos equipos cuyos miembros trabajan en lugares distintos utilizan videoconferencias o chats grupales para salvar el hueco que deja la distancia. Tu equipo es único, y las reuniones rápidas que organizas también deben serlo. Paso 7: Utilizar el gráfico de control A intervalos periódicos, puedes echar un vistazo al gráfico de control para supervisar el progreso del equipo. ¿QUÉ HAY EN EL GRÁFICO DE CONTROL? El gráfico de control muestra la siguiente información: Cuánto tiempo pasa cada incidencia en un estado en particular antes de moverse. La duración del ciclo de tu equipo, que es la duración media que se tarda en completar cada incidencia. Puedes ver la duración del ciclo para tu producto o versión. Una media acumulada de la duración del ciclo de tu equipo. A medida que tu equipo se vuelve más eficiente, deberías ver decrecer este número. El gráfico de control resulta útil porque te ayuda a analizar la forma en que trabaja tu equipo. Algunas de las preguntas que podrías hacerte son las siguientes: ¿Hay determinados tipos de incidencias que tardan demasiado en completarse? Esto puede deberse a que las incidencias son demasiado complejas o a que se retrasan continuamente por otras tareas que tienen más prioridad. ¿Se está tardando demasiado en la transición de las incidencias desde un estado en particular? Esto puede indicar un cuello de botella en el proceso de tu equipo. ¿Cuál es la media acumulada de tu equipo? ¿Tu equipo está siendo más eficiente? ¿Por qué o por qué no? Paso 8: Utilizar el backlog de kanban (opcional) A muchos equipos les encanta la flexibilidad de kanban, pero es posible que empiecen a notar que la primera columna de su tablero, el backlog, resulta ser largo y difícil de gestionar. Por eso hemos añadido un backlog en los proyectos de desarrollo de software de kanban. El backlog de kanban proporciona un backlog para tu tablero, que está en una ventana distinta del proyecto. Básicamente, ofrece a los gestores de productos un espacio mayor y especializado para crear y priorizar el backlog como deseen, sin distraer al equipo de su trabajo actual. El gestor de productos puede trasladar el trabajo del backlog al estado de listo para desarrollo para que el equipo sepa cuál es el próximo trabajo. Consulta Cómo usar tu backlog de kanban y Cómo activar el backlog de kanban para obtener más información. CÓMO ACTIVAR EL BACKLOG DE KANBAN Inicia sesión como usuario con el permiso global de los administradores de Jira. Selecciona Administración de Jira en la barra superior > Aplicaciones y, a continuación, desplázate hacia abajo hasta la sección Jira Software. En Laboratorios de Jira Software, selecciona las funciones que te interesen. Diagrama de trabajo hecho Backlog de kanban Prácticas avanzadas Es posible que ya te hayas dado cuenta del alto grado de personalización de Jira Software. Sigue leyendo para obtener información sobre consejos y sugerencias que tu equipo puede utilizar para dar rienda suelta a su potencial y concluir el trabajo en curso más rápido y de forma más eficiente. Paso 9: Utilizar restricciones de columna En el paso 5 ya hemos comentado la importancia de limitar la cantidad de trabajo en curso. En este apartado nos centraremos con detalle en ese tema, especialmente porque los límites resaltan los cuellos de botella que el equipo puede encontrarse. Si se detectan a tiempo, el equipo puede volver a ordenar las prioridades y decidir un plan de acción realista. Puedes configurar las restricciones de columna de tu tablero en la sección Columnas de Configuración del tablero. Define aquí las restricciones máximas y mínimas de cada columna. Si tienes más de 10 incidencias en las columnas Seleccionado para desarrollo o En curso, la parte superior de las columnas se coloreará en rojo: Ten en cuenta que tu tablero puede tener un aspecto distinto si has activado el backlog de kanban para tu tablero. Dependiendo de las necesidades de tu equipo, puedes ir un paso más allá y configurar las restricciones de columna para excluir las subtareas del recuento. Para obtener más información sobre cómo hacerlo, ve a Configuración de columnas. Paso 10: Utilizar el diagrama de flujo acumulado El diagrama de flujo acumulado es uno de los informes importantes que puedes usar en las metodologías kanban. El diagrama de flujo acumulado permite al equipo visualizar su esfuerzo de forma rápida y compararlo con el progreso global del proyecto. En Jira Software, el Diagrama de flujo acumulado muestra los estados de las incidencias de tu equipo durante un periodo de tiempo: Los cuellos de botella aparecerán como un cambio repentino de los estados de las incidencias en el diagrama: tanto si el cambio es una subida como una bajada repentina, definitivamente merece la pena estudiar las incidencias implicadas. Al predecir posibles cuellos de botella, el Diagrama de flujo acumulado es una herramienta que tu equipo debería pensar en utilizar. Tutorial sobre épicas de Jira En este tutorial, te explicaremos cómo puedes utilizar los epics en la metodología ágil de desarrollo de software. Te enseñaremos cómo trabajar con epics en Jira Software, para ayudarte en tu próximo gran proyecto. Este tutorial se centrará en los epics de proyectos clásicos y proyectos de última generación. Si utilizas proyectos de última generación, haz clic aquí. Duración: Lectura de 10 minutos de duración. Completar unas 2 semanas o más. Público: Personas noveles en el desarrollo de software ágil o Jira Software Requisito previo: Has creado una cuenta y un proyecto de Jira Software (scrum o kanban). Pruébalo gratis ¿CUÁNDO DEBERÍA CREAR UNA ÉPICA? Crea una épica si dispones de una gran historia de usuario que quieras dividir en pequeños fragmentos. Asimismo, puedes crear una épica si adviertes un patrón en varias historias de usuario que hayas creado y quieres unirlas en un solo grupo. Paso 1: Crea una nueva épica en Jira Software Hay dos formas de crear una épica: Creación de una épica a partir de un nuevo tique 1. Botón de puntos suspensivosHaz clic en izquierda. 2. Selecciona Epic para el tipo de incidencia. > Issue (Tique) en la esquina superior Creación de una épica desde el panel de épicas 1. Ve al backlog. 2. Haz clic en el panel de épicas. 3. Pulsa Create epic (Crear épica). Si creas una épica, deberás introducir los siguientes detalles: Nombre de la épica: Un nombre identificativo de la épica. Este nombre se utilizará como etiqueta en los tiques pertenecientes a la épica. Resumen de la épica: Verás este resumen siempre que Jira muestre la épica. Paso 2: Añade y elimina historias Una vez creada la épica, deberás añadir historias. ¿CUÁL ES LA DIFERENCIA ENTRE LAS ÉPICAS Y OTROS TIPOS DE TIQUES? Las historias, los bugs y las tareas se utilizan para describir un solo trabajo. Las épicas sirven para describir un grupo de tiques relacionados. Asimismo, las épicas también pueden ser una gran historia de usuario que deba dividirse en fragmentos más pequeños y manejables. Consulta nuestra guía sobre sistemas vectores para obtener más información. Hay dos formas de añadir una historia a una épica: Desde la pantalla de creación de tiques 1. Botón de puntos suspensivosHaz clic en > Issue (Tique) en la esquina superior izquierda. 2. Selecciona un tipo de tique que no sea una épica. 3. Busca el campo Epic Link (Enlace de épica) y selecciona tu épica. 4. Completa cualquier otra información que desees y pulsa Create (Crear). Desde el panel de épicas 1. Ve al backlog. 2. Abre el panel de épicas. 3. Pulsa Create issue in epic (Crear tique en épica). Para quitar un tique de una épica Ve a Backlog o a Active sprints (Sprints activos): En el backlog, arrastra el tique a la sección Issues without epics (Tiques sin épicas) en la parte inferior del panel de épicas; o En Backlog o en Active sprints (Sprints activos), haz clic en el tique pertinente para mostrarlo en el lado derecho de la pantalla. Después, haz clic en la x junto al nombre de la épica (por ejemplo, "Apples" en la captura de pantalla 1 abajo). Paso 3: Visualiza las épicas Puedes ver información relacionada con todas tus épicas en el backlog. 1. Panel de épicas: Ve al backlog y abre el panel de épicas para visualizar y gestionar tus épicas. 2. Lista de épicas: El panel de épicas muestra una lista de todas las épicas de tu proyecto. 3. Visualización de tiques en épicas: Haz clic en el nombre de una épica para ver todos los tiques que pertenece a dicha épica, en todos los sprints. También puedes ver un tique de épica para consultar la lista de historias que este contiene: Paso 4: Configura carriles para las épicas en tu tablero Durante un sprint, puede que te resulte útil dividir un tablero en carriles para cada épica, para que el tablero se muestre visualmente más claro. A continuación, detallamos cómo puede configurarlo en Jira Software: 1. Ve al backlog (o al sprint activo). 2. Botón de puntos suspensivosSelecciona más ( ) > Board settings (Configuración del tablero). 3. Haz clic en Swimlanes (Carriles). 4. En Base swimlanes on (Carriles básicos activados), selecciona Epics (Épicas). Cuando inicies un sprint, tu tablero mostrará los tiques agrupados en sus respectivas épicas. Paso 5: Supervisa el progreso de la épica Puede que te parezca importante realizar un seguimiento de todos los tiques incompletos adjuntos a una épica. Por ejemplo, si tienes una épica que se extenderá por varios sprints, puede que te resulte útil hacer un seguimiento de la cantidad de trabajo restante con el tiempo, de modo que puedas estimar cuándo se completará la épica. En Jira Software, puedes utilizar el Epic Report (Informe de épicas) para obtener fácilmente esta información. Paso 6: Completa la épica Para completar una épica: 1. Ve al backlog. 2. Abre el panel de épicas. 3. Haz clic en la lista desplegable de tu épica y selecciona Mark as Done (Marcar como hecho). ¿CUÁNDO DEBERÍA MARCAR UNA ÉPICA COMO HECHA? Marca la épica como hecha siempre que se haya completado todo el trabajo de esta. Para facilitarte el trabajo, te recomendamos que des una definición clara de qué significa "hecho" en tu épica. Cualquier historia relacionada con la épica no tiene por qué estar completada para marcar una épica como hecha. ¿Quieres obtener más información? Para obtener más información sobre cómo trabajar con sprints en Jira Software, consulta nuestro tutorial sobre los sprints. ¿Tienes alguna pregunta? Pregunta a la comunidad de Atlassian. Cómo trabajar con epics en proyectos de software de última generación Justo acabamos de introducir los epics en los proyectos de software de última generación y, con ello, se ha presentado una nueva forma de gestionarlos: la hoja de ruta. Esto supone un cambio enorme y emocionante en la manera en la que se gestionan los epics en Jira Software Cloud. Estamos convencidos de que será una forma más fácil de ver y gestionar tus epics y nos encantaría conocer tu opinión. Este tutorial explica qué función cumplen los epics dentro del proceso de desarrollo ágil y muestra cómo trabajar con epics en proyectos de última generación para ayudarte en tu próximo gran proyecto. ¿CUÁL ES LA DIFERENCIA ENTRE LAS ÉPICAS Y OTROS TIPOS DE TIQUES? Las historias, los errores y las tareas se utilizan para describir una sola unidad de trabajo. Los epics se utilizan para describir un grupo de incidencias relacionadas con el mismo conjunto de trabajo de mayor tamaño. Los epics normalmente se completan a través de varios sprints o un periodo de tiempo superior si no utilizas los sprints. Consulta nuestra guía de sistemas de entrega para obtener más información. Paso 1: Crea epics en la hoja de ruta Los epics se crean y se gestionan en la hoja de ruta. La hoja de ruta es útil a la hora de visualizar y planificar trabajos de gran tamaño que pueden estar en curso en este mismo instante o que puedes priorizar en el futuro. ¿CUÁNDO DEBERÍA CREAR UNA ÉPICA? Crea un epic si dispones de un gran conjunto de trabajo que se deba completar en diversos sprints o a lo largo de un periodo de tiempo prolongado. Asimismo, puedes crear un epic si adviertes un patrón en varias historias de usuario que hayas creado y quieres unirlas en un solo grupo. 1. En el menú del proyecto, selecciona Hoja de ruta. 2. Pulsa el + en la primera columna para crear un epic. Si tu hoja de ruta está vacía, simplemente, puedes empezar a escribir para crear tu primer epic. Consejo de experto: fuera de la hoja de ruta, también puedes crear epics desde el menú general Paso 2: Modifica las fechas de inicio y de entrega Arrastra los bordes de la barra de un epic para modificar su fecha de inicio y de entrega. También puedes editar estas fechas si haces clic en un epic y abres sus datos. No tienes por qué establecer una fecha de inicio y de entrega, pero te recomendamos que lo hagas para facilitar la planificación a largo plazo. Paso 3: Añade y elimina incidencias Para añadir incidencias desde el tablero y el backlog: 1. Ve a tu tablero o backlog. 2. Pasa el ratón por encima de la incidencia y selecciona más (•••). 3. Selecciona Añadir a epic*. Las incidencias solo pueden estar relacionadas con un epic a la vez. Si una incidencia ya pertenece a otro epic, la opción Añadir epic se cambiará por Cambiar epic*. En el tablero En el backlog Para añadir incidencias a un epic desde la hoja de ruta: 1. Haz clic en un epic. 2. En el panel de detalles de la incidencia, selecciona Añadir una incidencia secundaria. Consejo de experto: puedes seleccionar varias incidencias mediante Comando + clic en Mac o Ctrl + clic en Windows y añadirlas todas a la vez a un epic. Paso 4: Visualiza los detalles de un epic Puedes ver los datos de un epic, como la fecha de inicio, la fecha de entrega y las incidencias secundarias, si lo seleccionas en la hoja de ruta. Paso 5: Configura carriles para tus epics Durante un sprint, es posible que te resulte útil dividir tu tablero en carriles para cada epic para poder ver más fácilmente tu progreso. Para configurarlo en tu proyecto de software de última generación: 1. Ve a tu tablero de última generación. 2. En la esquina superior derecha, selecciona el menú Agrupar por. 3. Selecciona Epic. Consejo de experto: puedes crear incidencias en el carril de un epic para añadir rápidamente una incidencia nueva a un epic. También funciona si has seleccionado un epic en tu filtro. Paso 6: Completa la épica Cuando hayas completado todo el trabajo de un epic, deberías marcarlo como completado en la hoja de ruta. Para completar una épica: 1. Ve a la hoja de ruta. 2. Selecciona el epic que quieras marcar como completado. 3. En Estado, selecciona Finalizado. ¿CUÁNDO DEBERÍA MARCAR UNA ÉPICA COMO HECHA? Marca tu epic como finalizado siempre que se haya completado todo el trabajo del epic. Para facilitar esta acción, te recomendamos que, al crear el epic, definas claramente cuándo se considerará como finalizado. Más información Para obtener más información acerca de la hoja de ruta, consulta la documentación acerca de la hoja de ruta. Para obtener más información acerca de la configuración de los tipos de incidencia, incluidos los epics, consulta nuestra documentación acerca de proyectos de última generación. Tutorial sobre el tablero ágil de Jira En este tutorial, explicaremos cómo trabajar con tableros en Jira Software. Tiempo: 10 minutos de lectura. Completar durante 2 semanas o más Público de destino: Jira Software es nuevo para ti. Has creado un proyecto (que incluso podría tener su propio tablero) y quieres aprender a crear un tablero desde cero Requisito previo: Has creado una cuenta de Jira Software Has creado un proyecto de Jira Software Pruébalo gratis ¿QUÉ ES UN TABLERO? Un tablero muestra las incidencias de uno o más proyectos en columnas que representan el proceso del equipo. Además, los tableros proporcionan al equipo una vista compartida de todo el trabajo que no se ha iniciado aún, el que está en curso y el que ya se ha completado. Paso 1: Crea un tablero Para crear un nuevo tablero: 1. Haz clic en Buscar () > Ver todos los tableros. 2. Haz clic en Crear tablero. 3. Selecciona un tipo de tablero (ya sea agility, scrum o kanban). 4. Selecciona cómo quieres crear tu tablero. Puedes crear un nuevo proyecto para tu nuevo tablero o añadir el tablero a uno o más proyectos existentes. ¿QUÉ TIPO DE TABLERO DEBERÍA ESCOGER? Los tres tipos de tablero existentes son los siguientes: Gestionan historias, tareas y errores en sprints Tableros de Están indicados para los equipos que entregan su trabajo scrum atendiendo a una programación periódica Tableros de Gestionan historias, tareas y errores en kanban continuo un flujo Tableros ágiles Están indicados para equipos que controlan el volumen de trabajo desde un backlog Gestionan tareas con un tablero flexible y sencillo Están indicados para equipos que son nuevos en la metodología ágil o para equipos que no deseen dedicar demasiado tiempo a tareas de configuración Si tu equipo tiene un conocimiento profundo de la metodología ágil, recomendamos elegir scrum o kanban (el que mejor se ajuste a los procesos de tu equipo). Si tu equipo es nuevo en la metodología ágil o si quieres comenzar a trabajar con ella sin necesidad de perder demasiado tiempo en tareas de configuración, te recomendamos que elijas el tablero ágil. Paso 2: Configura tu tablero ¿QUÉ AJUSTES DEBO CONFIGURAR PRIMERO? Te recomendamos que primero configures las columnas y los filtros rápidos. La configuración de las columnas es útil, porque puedes hacer que tu tablero refleje el proceso de tu equipo. Para los tableros de scrum o kanban, también recomendamos configurar los filtros rápidos, de modo que los miembros del equipo puedan centrarse en las incidencias que necesitan rápidamente. Por ejemplo, puedes configurar los filtros rápidos para que solo muestren las incidencias de versiones específicas. Tableros de scrum o kanban 1. Ve a tu tablero haciendo clic en Buscar ( tablero. 2. Haz clic en más ( ) > Ver todos los tableros y seleccionando tu ) > Configuración del tablero. Tableros ágiles Configurar los tableros ágiles es superfácil; las tareas básicas como añadir o eliminar columnas, añadir límites de WIP y cambiar el nombre se hace todo en el propio tablero, en lugar de tener que cambiar de pantalla. Para activar las funciones ágiles como Backlog y Sprints, ve a Configuración > Funciones. Seguimos trabajando en los tableros ágiles e iremos añadiendo nuevas funciones con el tiempo. Paso 3: Navega entre tableros Para navegar entre un tablero y otro, utiliza el conmutador de tableros situado en el menú de la izquierda, bajo el nombre del proyecto. ¿Quieres obtener más información? Para obtener más información sobre el uso de los tableros en Jira Software, consulta nuestra documentación sobre tableros. Tutorial sobre sprints de Jira Resumen: un sprint es un periodo de tiempo fijado en un ciclo de desarrollo continuo durante el cual los equipos completan tareas procedentes del backlog del producto. Normalmente, al final del sprint un equipo habrá compilado e implementado un incremento de producto funcional. Jira Software convierte el backlog en el centro de la reunión de planificación del sprint, de forma que podrás estimar historias, ajustar el alcance del sprint, comprobar la velocidad y cambiar las prioridades de las incidencias en tiempo real. En este tutorial, explicaremos cómo trabajar con sprints en Jira Software. Ten en cuenta que los rituales de equipo que practicas fuera de Jira Software, como las reuniones de planificación de sprints, las retrospectivas o las reuniones rápidas diarias, no se tratarán en este tutorial. Puedes leer más sobre esas cuestiones en el artículo Cómo utilizar scrum con Jira Software. Duración: Lectura de 10 minutos de duración. Completar unas 2 semanas o más. Público: Personas noveles en el desarrollo de software ágil o Jira Software Tienes permisos de administración para todos los proyectos de tu tablero de scrum. Consulta la sección sobre gestión de permisos de proyecto para obtener más información. Requisito previo: Has creado una cuenta de Jira Software. Has creado un proyecto de scrum en Jira Software. Has completado el backlog del proyecto con tiques. ¿QUÉ ES UN SPRINT? Un sprint es un periodo fijo en el que los equipos deben completar los trabajos del backlog de su producto. Los sprints suelen tener una duración de una, dos o cuatro semanas. Al final del sprint, un equipo debería haber creado e implementado un incremento de producto. Paso 1: Crea un sprint 1. Ve al backlog de tu proyecto de scrum. 2. Haz clic en el botón Create Sprint (Crear sprint) en la parte superior del backlog. Ten en cuenta que puedes crear más de un sprint, si quieres planificar el trabajo con varias semanas de antelación. Paso 2: Completa el sprint con historias desde el backlog Una vez que has creado tu sprint, deberás completarlo con tiques. Antes de hacerlo, no olvides sentarte con tu equipo y debatir con ellos qué trabajo te gustaría comprometerte a hacer. Asegúrate de que añades trabajo suficiente para todos en el equipo. ¿CUÁNTOS TIQUES DEBERÍA AÑADIR? La primera vez que lo haces, puede que no sepas cuántos tiques añadir. No pasa nada, eso es algo que averiguarás con el tiempo. Para ayudarte con esto, antes de que empieces a añadir tiques al sprint, pide al equipo que haga una estimación de sus tiques. Una vez concluido el sprint, podrás ver después cuánto esfuerzo dedicó el equipo al sprint en cuestión. Con el tiempo, lograrás averiguar la capacidad de trabajo del equipo, lo que te ayudará a planificar futuros sprints en consonancia. Obtén más información acerca de la estimación en nuestra guía Cómo utilizar scrum con Jira Software. Para añadir historias a tus sprints 1. Ve al backlog. 2. Arrastra tiques desde el backlog y suéltalos en tu sprint. Ten en cuenta que también puedes añadir un tique a tu sprint si editas el tique y actualizas el campo Sprint. Paso 3: Inicia el sprint Una vez que has añadido los tiques a tu sprint y el equipo está listo para ponerse a trabajar, debes iniciar el sprint. Ten en cuenta que solo puedes iniciar un sprint en los siguientes casos: Si todavía no has iniciado ningún sprint. Si quieres tener más de un sprint activo a la vez, prueba la funcionalidad de sprints paralelos ; y Si el sprint está en la parte superior del backlog. Si quieres iniciar un sprint planificado que está más abajo, deberás volver a ordenar tus sprints para moverlo a lo más alto de la lista. Para iniciar un sprint 1. Ve al backlog de tu proyecto de scrum. 2. Encuentra el sprint que quieres iniciar y haz clic en Start Sprint (Iniciar sprint). 3. Actualiza el campo Sprint name (Nombre de sprint) y, si lo deseas, añade información al campo Sprint goal (Objetivo de sprint), y a Start date (Fecha de inicio) y End date (Fecha de finalización). ¿QUÉ DURACIÓN DEBEN TENER NUESTROS SPRINTS? Si no estás seguro de la duración que deben tener tus sprints, te recomendamos que sean de dos semanas. Ese tiempo es suficiente para cumplir un objetivo, pero no es demasiado como para que el equipo no reciba feedback de forma periódica. Paso 4: Supervisa el progreso del equipo Durante el sprint, es posible que quieras supervisar el progreso de tu equipo. Una forma de hacerlo es mediante la visualización del informe de sprints. ¿QUÉ DEBERÍAMOS HACER DURANTE LOS SPRINTS? Durante los sprints, los equipos colaboran para completar juntos las historias a las que se comprometieron al inicio del sprint. Normalmente, esto requiere mucha colaboración, así que recomendamos celebrar reuniones rápidas diarias con los equipos, para que sepas en qué está trabajando cada uno de los miembros. Paso 5: Cierra el sprint Para cerrar un sprint 1. Ve a Active sprints (Sprints activos) de tu tablero de scrum. 2. Si fuera necesario, selecciona el sprint que deseas completar de la lista desplegable de sprints. Ten en cuenta que si tienes varios sprints en la sección Sprints activos de tu tablero, el botón "Terminar sprint" no aparecerá hasta que selecciones uno de los sprints. 3. Haz clic en Complete Sprint (Completar sprint). Todos los tiques completados se moverán fuera de los sprints activos. 4. Si el sprint tiene tiques sin completar, se te pedirá que los muevas a uno de estos lugares: El backlog; Cualquier sprint futuro; o Un nuevo sprint. ¿CUÁNDO DEBERÍA MARCAR UNA ÉPICA COMO HECHA? Marca la épica como hecha siempre que se haya completado todo el trabajo de esta. Para facilitarte el trabajo, te recomendamos que des una definición clara de qué significa "hecho" en tu épica. Cualquier historia relacionada con la épica no tiene por qué estar completada para marcar una épica como hecha. ¿Quieres obtener más información? Si quieres obtener más información sobre cómo adoptar scrum para tu equipo, consulta nuestra guía Cómo utilizar scrum con Jira Software. Para obtener más información sobre cómo trabajar con sprints en Jira Software, consulta nuestra documentación sobre sprints. Tutorial sobre versiones de Jira En este tutorial, explicaremos cómo trabajar con versiones en Jira Software. Tiempo: 10 minutos de lectura. Completar en 2 semanas o más. Público: Estás familiarizado con el trabajo de scrum o kanban en Jira Software Tienes permisos de administración para todos los proyectos de tu tablero de kanban o scrum. Consulta la sección sobre gestión de permisos de proyecto para obtener más información. Requisito previo: Haber creado una cuenta de Jira Software Haber creado un proyecto de Scrum o Kanban de Jira Software Haber rellenado tu proyecto con incidencias Pruébalo gratis ¿QUÉ ES UNA VERSIÓN EN JIRA SOFTWARE? En Jira Software, las versiones representan determinados momentos de un proyecto. Te ayudan a organizar tu trabajo proporcionándote hitos a los que aspirar. Puedes asignar incidencias en tu proyecto a una versión específica y organizar tus sprints en torno a la finalización del trabajo en dicha versión. Paso 1: Crea una versión en Jira Software 1. Desplázate a tu proyecto. 2. En el menú del proyecto, haz clic en Publicaciones. 3. Selecciona el cuadro de texto Nombre de versión, introduce un nombre y haz clic en Añadir. Los nombres de versión suelen ser numéricos, por ejemplo, 1.0 o 2.1.1. Asimismo, puedes utilizar un nombre clave interno. ¿CUÁNTAS VERSIONES DEBO CREAR? Puedes crear tantas versiones como creas necesarias. Por ejemplo, puedes crear varias versiones para planificar trabajo por adelantado. O bien puedes simplemente contar con una o dos versiones por ahora. Una vez que creas una versión, aparecerán disponibles en las incidencias los campos Versiones afectadas y Versión de corrección. Paso 2: Añade tiques a una versión Si tu proyecto tiene un backlog 1. Desplázate al backlog del proyecto. 2. Abre el panel Versiones que se encuentra a la izquierda. 3. Arrastra una incidencia a la versión a la que quieres añadirla. Si tu proyecto no tiene un backlog Abre la incidencia que quieres añadir a una versión. Busca el campo Versión de corrección e introduce la versión a la que quieres añadir la incidencia. ¿CUÁL ES LA AFECTADAS? DIFERENCIA ENTRE VERSIÓN DE CORRECCIÓN Y VERSIONES La versión afectada es aquella en la que se ha encontrado un error o problema. Aunque puede resultar útil para hacer un seguimiento de los problemas, no se utiliza con mucha frecuencia en Jira. La versión de corrección es aquella en la que planeas publicar una función o una corrección de error para los clientes. Este campo se emplea para la planificación de publicaciones, la supervisión del progreso y de la velocidad, y se utiliza ampliamente en la generación de informes. Este es, probablemente, el campo que deseas. Paso 3: Supervisa el progreso de una versión Jira Software te ofrece múltiples herramientas que puedes usar para comprobar el progreso de una versión. A continuación, hablaremos sobre algunas de ellas. Release Hub El Release Hub proporciona un lugar en el que puedes gestionar todas tus publicaciones. Asimismo, ofrece información sobre el estado de tus publicaciones y un resumen del número de incidencias de cada versión. Para acceder al Release Hub: 1. Ve a tu proyecto. 2. En el menú del proyecto, selecciona Publicaciones. 1. Filtros rápidos: Céntrate en versiones específicas filtrando y excluyendo aquellas que no te interesan. 2. Lista de versiones: Arrastra y suelta versiones para volver a ordenarlas. 3. Estado: Las versiones pueden tener uno de estos tres estados: sin publicar, publicada o archivada. 4. Progreso: Esta opción indica el número de incidencias que se han asignado a la versión y el estado en que se encuentra cada una. ¿QUIERES OBTENER MÁS INFORMACIÓN QUE TE AYUDE A SUPERVISAR TUS VERSIONES? Si integras Jira Software con tu repositorio de Bitbucket, verás también información sobre desarrollo relacionada con tus confirmaciones, ramas y solicitudes de incorporación de cambios. Diagrama de evolución de versiones (solo scrum) El diagrama de trabajos pendientes de publicaciones muestra cuánto trabajo se ha completado y el trabajo total restante. Los diagramas de trabajos pendientes se utilizan para predecir las probabilidades del equipo de completar su trabajo en el tiempo previsto. Asimismo, son la solución ideal para mantener al equipo informado sobre cualquier corrupción del alcance que se produzca. Ten en cuenta que para utilizar el diagrama de trabajos pendientes de publicaciones, deberás estimar tus incidencias. Para obtener más información, consulta nuestra guía sobre los diagramas de trabajos pendientes. Para ver el diagrama de trabajos pendientes de publicaciones: 1. Desplázate a tu proyecto. 2. En el menú del proyecto, selecciona Informes. 3. Selecciona el trabajo pendiente de publicación. 1. Menú de publicación: Selecciona para qué publicación ver los datos. 2. Trabajo añadido: El segmento azul oscuro muestra la cantidad de trabajo añadido a la publicación en cada sprint. En este ejemplo, el trabajo se mide en puntos de historia. 3. Trabajo restante: El segmento azul claro muestra la cantidad de trabajo restante en la publicación. 4. Trabajo completado: El segmento verde representa la cantidad de trabajo que se ha completado para la publicación en cada sprint. 5. Finalización planificada: El informe planifica cuántos sprints se tardará en completar la publicación, según la velocidad del equipo. Para obtener información más detallada, consulta nuestra documentación sobre los diagramas de trabajos pendientes de publicaciones. Paso 4: Completa una versión Es hora de convertir el duro trabajo de tu equipo en una publicación de software. A estas alturas, debes estar seguro de que tu versión está lista para publicarse, es decir, se han completado las incidencias, se ha comprobado, revisado y fusionado el código, se están pasando las compilaciones, etc. Para implementar una publicación, normalmente, publicarías la versión en Jira Software, compilarías la publicación y, después, la implementarías en el entorno requerido. Para completar una versión 1. Desplázate a tu proyecto. 2. En el menú del proyecto, selecciona Publicaciones. 3. Para la versión que quieres publicar, elige Acciones ( ) > Publicar. En los tableros de kanban, también puedes publicar todas las incidencias en la columna de finalizados como una nueva versión directamente desde el propio tablero. ¿Quieres obtener más información? Para obtener más información sobre cómo trabajar con versiones en Jira Software, Tutorial sobre tiques de Jira En este tutorial, explicaremos cómo trabajar con incidencias en Jira Software. Ten en cuenta que los rituales de equipo que practicas fuera de Jira Software, como las reuniones de planificación de sprints, las retrospectivas o las reuniones rápidas diarias, no se tratarán en este tutorial. Puedes leer más sobre esas cuestiones en el artículo Cómo utilizar scrum con Jira Software. Tiempo: 10 minutos de lectura. Audiencia: eres nuevo con Jira Software y no sabes realmente qué hacer con él Requisito previo: has creado una cuenta de Jira Software has creado un proyecto de Jira Software Pruébalo gratis ¿QUÉ ES UN TIQUE? En Jira, los equipos utilizan las incidencias para realizar un seguimiento del trabajo que debe completarse. En función de cómo tu equipo utilice Jira, una incidencia puede representar una tarea de proyecto, un ticket de asistencia técnica, un formulario de solicitud de vacaciones, etc. En Jira Software, las incidencias suelen representar cosas como funciones importantes, requisitos de los usuarios y errores de software. Crea un tique Existen diversas formas de crear incidencias: Desde el menú general, en cualquier parte de Jira En el backlog En tu tablero (solo tableros ágiles en Cloud) Opcional: Crea subtareas Las incidencias también pueden tener subtareas que se asignan y a las que se les hace un seguimiento individualmente. Puede crear subtareas por cualquiera de los siguientes motivos: Para dividir una incidencia en fragmentos aún más pequeños Para dejar que se asignen varios aspectos de una incidencia a diferentes personas Para crear una lista de tareas pendientes de una incidencia Para crear una subtarea: 1. Ve a una incidencia y selecciona más ( ••• ) > Crear subtarea. 2. Completa los detalles según corresponda y, después, haz clic en Crear. ESTIMA TUS TIQUES (SOLO SCRUM) La estimación de incidencias en tu backlog te ayuda a predecir cuánto se tardará en entregar algunas partes del backlog. ¿Por qué estimar incidencias? La estimación tiene que ver, principalmente, con la velocidad. El principal propósito de aplicar estimaciones a los elementos del backlog es utilizar dicha información para averiguar cuánto se tardará en entregar partes del backlog. En los equipos de desarrollo tradicionales, los gestores estimaban los elementos en "horas/hombre". A partir de ahí, podían contar las horas en el backlog, dividirlas por el número de personas del equipo y por las horas de la semana para llegar así a una fecha de pronóstico. Por supuesto, estas estimaciones a menudo demostraron ser muy inexactas porque no tenían en cuenta las características de estimación naturales del equipo (por una sobreestimación o una estimación insuficiente), las interrupciones inesperadas o el desarrollo del rendimiento del equipo a lo largo del tiempo. Así pues, en el mundo de scrum, la mayoría de los equipos no tratan de obtener una estimación exacta; en su lugar, tratan de alcanzar una velocidad fiable. La velocidad es una medición del número de unidades de estimación que un equipo tiende a completar de un sprint a otro. Tras los primeros sprints, la mayoría de los equipos alcanzará una velocidad razonablemente estable. Equipados con velocidad y estimaciones de las incidencias del backlog, los equipos pueden predecir cuánto tardarán en completarse las partes del backlog. Por ejemplo, si un equipo tiene capacidad de "hora/hombre" de 120 horas en cada sprint, pero una velocidad de 60 horas, dicha velocidad puede seguir utilizándose para estimar el número de sprints que tardarán en completarse las partes del backlog. Puede resultar tentador empezar a preguntarse dónde fueron "las otras 60 horas", dando a entender que algo va mal con la productividad del equipo. Sin embargo, normalmente, no tiene nada que ver con eso: las estimaciones de un equipo solo representan su visión de cómo de complicados serán los elementos, y las estimaciones siempre se verán afectadas por el comportamiento natural del equipo (por ejemplo, la sobreestimación o una estimación insuficiente), así como por sobrecarga organizativa. La velocidad es lo más importante desde el punto de vista de la planificación. La mayoría de los equipos estiman utilizando puntos de historia. Los puntos de historia miden la complejidad de una incidencia en relación con los demás. Esto es lógico porque las principales preguntas que debemos responder son: "¿Con cuánto trabajo podemos comprometernos de forma realista para completar este sprint?" y "¿Cuánto tardaremos en entregar esta parte del backlog?". Un enfoque de puntos de historia puede ofrecernos las respuestas a estas preguntas sin que los equipos sientan ansiedad por la "exactitud" cuando se les pide que realicen una estimación en horas. Para obtener más información sobre cómo puede realizarse un seguimiento de la estimación y la velocidad, consulta nuestro tutorial sobre trabajo pendiente. Para realizar una estimación de una incidencia: 1. En tu proyecto de scrum, selecciona una incidencia en tu tablero o en el backlog. 2. En los detalles de la incidencia, haz clic en el campo Estimación. 3. Introduce una estimación. ¿Puedo cambiar una estimación después de haberla introducido? En pocas palabras, sí, puedes. Pero si cambias el valor de estimación una vez iniciado un sprint, se mostrará como cambio de alcance en el diagrama de trabajo pendiente. Si te resulta complicado estimar las incidencias, no te preocupes, ¡es algo totalmente normal! Consulta nuestra guía de estimación para ver los consejos y trucos acerca de cómo realizar las estimaciones adecuadas de tus incidencias. Clasifica tus tiques por orden de prioridad Al clasificar tus incidencias por orden de prioridad permites que el equipo vea en qué incidencias deberá trabajar después. Para clasificar las incidencias, ve a tu backlog o al tablero y haz clic y arrastra las incidencias para ordenarlas en función de su prioridad. A continuación, incluimos algunos ejemplos de dónde puedes hacer esto: En un proyecto de scrum, cuando planifiques tu próximo sprint, puedes clasificar las incidencias en el backlog y, después, decidir poner las 10 primeras (o el número de incidencias que el equipo sea capaz de completar) en el sprint. En un proyecto de kanban o de metodología ágil, puedes clasificar las incidencias en la columna Por hacer y pedir a los miembros del equipo que escojan una incidencia de la parte superior de la lista cuando necesiten más trabajo. Con este método, la columna con todas las incidencias Por hacer necesitará atención constante a medida que cambian las prioridades. Nota: Debes disponer de los permisos Planificar incidencia y Editar incidencia para poder subir o bajar incidencias en tu tablero. Marca un tique Cuando trabajas en un tablero de kanban o en uno ágil, tienes la opción de marcar una incidencia. En los tableros ágiles, las incidencias marcadas se parecen un poco a esto: La marcación de incidencias resulta útil, porque fomenta la colaboración y la comunicación de todo el equipo. A continuación, detallamos algunos ejemplos: 1. Estás trabajando en una tarea, pero te das cuenta de que no tienes la capacidad de acabarla. Puedes marcar la incidencia y un miembro del equipo con capacidad disponible que consulte el tablero podrá intervenir y ayudarte. 2. Una incidencia en la que estás trabajando se bloquea. Puedes marcar la incidencia, añadir un comentario explicando el impedimento y pasar a la siguiente tarea. Cualquiera que consulte el tablero verá que se ha marcado la incidencia y sabrá lo que ocurre cuando la abra. Para marcar una incidencia: 1. Ve a tu tablero de kanban o al tablero de metodología ágil. 2. Haz clic con el botón derecho en una incidencia. 3. Pulsa Añadir marca. Tiques de transición Las incidencias de transición muestran el progreso de tu flujo de trabajo. Para cambiar el estado de una incidencia de una columna a otra, arrastra la incidencia y déjala en su nueva columna. Ten en cuenta que si ves que no puedes cambiar el estado de una incidencia a otra columna, puede que se deba a que el flujo de trabajo de tu proyecto te lo está impidiendo. Lo que convierte a Jira en una solución tan potente es que los administradores pueden forzar determinadas reglas en el flujo de trabajo del proyecto, como forzar los errores para que pasen a la columna de control de calidad o no dejar que las historias pasen directamente de la columna Pendiente a Finalizado. Para obtener más información, consulta nuestra documentación sobre flujos de trabajo. Filtra tiques Un filtro de incidencias te permite ocultar las incidencias que no quieres ver y centrarte en aquellas que sí te interesan. Jira Software cuenta con una opción de filtros rápidos, que te permite filtrar las incidencias de tu tablero. A continuación, tienes un ejemplo de cómo se ven en los tableros de scrum o kanban: 1. Barra de búsqueda: muestra las incidencias que contienen un término de búsqueda y oculta el resto. 2. Menú de filtros rápidos: de forma predeterminada, puedes filtrar por las incidencias que tienes asignadas y por las incidencias recientemente actualizadas. Cualquier filtro rápido que crees también se mostrará aquí. 3. Menú de persona asignada: solo muestra las incidencias asignadas a las personas que selecciones. Para crear tu propios filtros rápidos (en tableros de scrum y kanban): 1. Ve a tu tablero y, después, selecciona más ( ) > Configuración del tablero. 2. Haz clic en la pestaña Filtros rápidos. 3. Introduce un nombre, la consulta con lenguaje JQL y la descripción del filtro. Para obtener más información sobre el lenguaje JQL, consulta nuestra documentación sobre búsquedas avanzadas. 4. Haz clic en Añadir. ¿Quieres obtener más información? Para obtener más información sobre cómo trabajar con incidencias en Jira Software, consulta nuestra documentación sobre incidencias. Tutorial sobre el diagrama de evolución de Jira En este tutorial, explicaremos cómo supervisar los sprints y los epics utilizando diagramas de trabajo pendiente en Jira Software. Tiempo: 10 minutos de lectura. Audiencia: estás trabajando en un proyecto en Jira Software y quieres realizar un seguimiento del progreso de un sprint o de un epic. Requisito previo: has creado una cuenta y un proyecto de scrum de Jira Software. Estás familiarizado con los principios básicos de scrum y los epics. Pruébalo gratis ¿QUÉ ES UN DIAGRAMA DE EVOLUCIÓN? Un diagrama de trabajo pendiente muestra la cantidad de trabajo que se ha completado en un epic o un sprint, y el trabajo total restante. Los diagramas de trabajo pendiente se utilizan para predecir las probabilidades de tu equipo de completar su trabajo en el tiempo previsto. Asimismo, son la solución ideal para mantener al equipo informado sobre cualquier ampliación descontrolada del alcance que se produzca. Los diagramas de trabajo pendiente son útiles porque ofrecen información sobre cómo trabaja el equipo. Por ejemplo: Si notas que el equipo termina el trabajo antes de tiempo sistemáticamente, esto puede ser una señal de que no están asumiendo suficiente trabajo durante la planificación de sprints. Si no cumplen las previsiones constantemente, esto puede significar que se han comprometido con demasiado trabajo. Si el diagrama de trabajo pendiente muestra una drástica caída durante el sprint, esto puede significar que el trabajo no se ha estimado con exactitud o no se ha desglosado correctamente. Paso 1: Establece la estadística de estimación de tu equipo ¿QUÉ ES UNA ESTADÍSTICA DE ESTIMACIÓN? La estadística de estimación es la unidad de medición que tu equipo utilizará para estimar el trabajo. En Jira Software, puedes medir el trabajo utilizando puntos de historia, horas, o puedes definir tu propia estadística. La estadística de estimación es importante porque sirve para calcular la velocidad del equipo. Para cada sprint, la velocidad es la suma de la estadística de estimación para historias completadas. Si tu equipo tiene una velocidad constante, puedes utilizar ese valor para determinar cuánto trabajo puede realizar el equipo en cada sprint, lo cual resulta útil en la planificación de sprints. Para establecer una estadística de estimación: 1. Ve a tu tablero o backlog y, después, selecciona más ( tablero. 2. Haz clic en la pestaña Estimación. ) > Configuración del ¿QUÉ ESTADÍSTICA DE ESTIMACIÓN DEBERÍAMOS UTILIZAR? Tradicionalmente, los equipos de software estimaban su trabajo en un formato de tiempo utilizando días, semanas y meses. Sin embargo, muchos equipos ágiles se han pasado a los puntos de historia. Si esto de la metodología ágil es nuevo para ti o no estás seguro de qué opción elegir, te recomendamos que utilices los puntos de historia. Paso 2: Estima tus tiques ¿CUÁL ES LA DIFERENCIA ENTRE ESTIMACIÓN Y SUPERVISIÓN? En la metodología ágil, la estimación hace referencia a la medición del tamaño del backlog de un equipo o de un trabajo concreto. El seguimiento hace referencia al uso de dichas estimaciones para garantizar que el trabajo avanza según lo planeado para su finalización. Para realizar una estimación de un tique: 1. En tu proyecto de scrum, selecciona una incidencia en tu tablero o en el backlog. 2. En los detalles de la incidencia, haz clic en el campo Estimación. 3. Introduce una estimación. ¿PUEDO CAMBIAR UNA ESTIMACIÓN DESPUÉS DE HABERLA INTRODUCIDO? En pocas palabras, sí, puedes. Pero si cambias el valor de estimación una vez iniciado un sprint, se mostrará como cambio de alcance en el diagrama de trabajo pendiente. Si te resulta complicado estimar las incidencias, no te preocupes, ¡es algo totalmente normal! Consulta nuestra guía de estimación para ver los consejos y trucos acerca de cómo realizar las estimaciones adecuadas de tus incidencias. Paso 3: Realiza un seguimiento del progreso del equipo con diagramas de evolución Diagrama de evolución de sprints Este informe muestra la cantidad de trabajo que se realiza en un sprint. Se puede utilizar, además, para realizar un seguimiento de todo el trabajo restante del sprint y para prever la probabilidad de alcanzar el objetivo del sprint. Al realizar un seguimiento del trabajo restante del sprint, un equipo puede gestionar su progreso y responder de la forma correspondiente a las tendencias. Por ejemplo, si el diagrama de trabajo pendiente muestra que el equipo podría no alcanzar el objetivo del sprint, entonces podrán tomarse las medidas necesarias para mantener el rumbo. Para ver el diagrama de trabajo pendiente de sprints: 1. Ve a tu proyecto de scrum. 2. Selecciona Backlog o Sprint activo. 3. Haz clic en Informes y después selecciona Diagrama de trabajo pendiente. Comprensión del diagrama de trabajo pendiente de sprints 1. Estadística de estimación: el eje vertical representa la estadística de estimación que has seleccionado. 2. Valores restantes: la línea roja representa todo el trabajo restante en el sprint, según las estimaciones de tu equipo. 3. Directriz: la línea gris muestra una aproximación de dónde debería encontrarse el equipo, asumiendo que se da un progreso lineal. Si la línea roja está por debajo de esta línea, ¡enhorabuena!, tu equipo va por buen camino para completar todo su trabajo para el final del sprint. Pero esto no es infalible; sencillamente, es otro dato que utilizar mientras supervisas el progreso del equipo. Diagrama de evolución de épicas Este informe muestra cómo está progresando tu equipo respecto al trabajo de un epic. Esta opción está optimizada para los equipos de scrum que trabajan en sprints y facilita la supervisión. A continuación, se indican algunas formas en las que podrías usar un diagrama de trabajo pendiente de epics: Ver lo rápido que tu equipo está trabajando en un epic. Ver cómo el trabajo añadido o eliminado durante el sprint ha afectado al progreso general de tu equipo. Predecir cuántos sprints se tardará en completar el trabajo de un epic, según los anteriores sprints y los cambios realizados durante estos. Para ver el diagrama de trabajo pendiente de epics: 1. Ve a tu proyecto de scrum. 2. Selecciona Backlog o Sprint activo. 3. Haz clic en Informes y después selecciona Trabajo pendiente de epics. 4. Selecciona una épica de la lista desplegable junto al encabezado Trabajo pendiente de epics. Podrás elegir entre los epics de los proyectos configurados para tu tablero a través del filtro del tablero. Comprensión del diagrama de trabajo pendiente de epics 1. Menú de epics: selecciona el epic del que quieras ver datos. 2. Trabajo añadido: el segmento azul oscuro muestra la cantidad de trabajo añadido al epic en cada sprint. En este ejemplo, el trabajo se mide en puntos de historia. 3. Trabajo restante: el segmento azul claro muestra la cantidad de trabajo restante en el epic. 4. Trabajo completado: el segmento verde representa la cantidad de trabajo que se ha completado para el epic en cada sprint. 5. Finalización planificada: el informe planifica cuántos sprints se tardará en completar el epic, según la velocidad del equipo. ¿Quieres saber más? Si quieres obtener más información sobre cómo estimar el trabajo, consulta nuestra guía sobre los puntos de historia y la estimación ágil. Si deseas obtener más información sobre el diagrama de trabajo pendiente de publicaciones, consulta nuestra guía sobre versiones. Para obtener información más detallada sobre el diagrama de trabajo pendiente de sprints de Jira Software, consulta nuestra documentación sobre diagramas de trabajo pendiente. Para saber más sobre el diagrama de trabajo pendiente de epics, consulta nuestra documentación sobre diagramas de trabajo pendiente de epics. Para obtener más información sobre las métricas de tu equipo ágil, consulta nuestra guía sobre métricas. Para obtener más información sobre cómo dirigir un proyecto de scrum en Jira Software, consulta nuestra guía Cómo utilizar scrum con Jira Software.