Qué son los sprints

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.