Qué Es Un Sprint en Scrum

¿Qué es un Sprint en Scrum?
Descubre sus 5
grandes beneficios
Metodologías agile » ¿Qué es un Sprint en Scrum? Descubre sus 5 grandes beneficios
Tal y como lo define la Scrum Guide, el Sprint es el corazón de Scrum, un intervalo de tiempo de
máximo un mes, que comienza con el sprint Planning y finaliza con la sprint Retrospective.
Durante un sprint en Scrum se desarrolla el incremento de un producto, potencialmente

entregable. Esto quiere decir que, si el Product Owner lo solicita, se requiere un esfuerzo mínimo para
que el producto esté disponible para el usuario.
También podemos considerarlo como un mini-proyecto, en donde el equipo de desarrollo focaliza

todos sus esfuerzos en conseguir el objetivo definido en el Sprint planning.
En un Sprint de Scrum se incluye, básicamente, el Sprint Planning, los Daily meetings, el trabajo
del equipo de desarrollo, el Sprint Review y el Sprint Retrospective.
Tabla de Contenidos
 Consideraciones importantes
 Cancelando Sprints
 5 grandes beneficios de los sprints tanto para equipos como organizaciones.
o Foco
o Previsibilidad
o Control
o Libertad
o Oportunidad
 ¿Te ha gustado el post?
 ¿Nos ayudas a compartir?
 Te puede interesar...
Consideraciones importantes
 Cada fase del Sprint en Scrum tiene que ser cuidadosamente respetada por todo el equipo Scrum,
esto quiere decir, que no puede haber cambios durante el mismo, que pongan el peligro el
objetivo del mismo.
 Es recomendable no trabajar varios objetivos/requisitos al mismo tiempo, lo primero que hay que
terminar es lo más importante para el cliente. Si todo el Sprint Backlog no es entregado al final
del Sprint, entonces se analizará en la retrospectiva qué ha ocurrido, y se aplicarán los cambios
necesarios para que el próximo Sprint no tenga los mismos inconvenientes.
 Un Sprint empieza inmediatamente al finalizar el Sprint anterior, no existen tiempos
intermedios.
 Tienen un máximo de un mes de duración, si se hicieran Sprints más largos, puede que las
definiciones de lo que estamos haciendo cambien, poniendo en riesgo el éxito del proyecto.
 Los tiempos de los Sprints en Scrum no se deberían cambiar a lo largo de un proyecto, pero
esto no es restrictivo y, en caso muy necesario, se puede cambiar. Es importante diferenciar que lo
que no tenemos que hacer es ir cambiando los tiempos Sprint tras Sprint.
Cancelando Sprints
La única persona autorizada para cancelarlo antes de tiempo es el Product Owner. El resto del equipo
puede participar en la decisión, pero la última palabra la tiene siempre la tiene el/ella.
Las razones de una cancelación pueden ser las siguientes:
 El objetivo del Sprint se está obsoleto, siendo necesario cancelar lo que se está haciendo.
 Cambios de dirección en la empresa para la que estamos trabajando.
 El mercado hacia donde apuntamos tiene otras tendencias, que debemos seguir.
Es importante añadir que las cancelaciones de Sprints no son habituales, sobre todo en aquellos de muy
corta duración.
5 grandes beneficios de los sprints tanto para equipos como

organizaciones.
Foco
El propósito de cada sprint es crear un incremento de valor en un producto o proyecto.

El valor que se entrega se define como sprint goal, que nunca debe cambiar, la razón de esto,
básicamente, es dar foco al equipo scrum.
Trabajar día a día en un producto puede provocar caos, ya que es normal que nuevas ideas, nuevos retos
y nuevas oportunidades de negocio surjan en medio del desarrollo del mismo. Esta es la razón por la
que el sprint brinda foco al equipo de desarrollo, aislándole de toda posible distracción que pueda
resultar de nuevas ideas y prioridades.
Previsibilidad
Los sprints suelen ser constantes en el tiempo, esto ayuda mucho a la hora de hacer estimaciones y
poder predecir qué es lo que se puede hacer dentro del período de tiempo. En resumen, los sprints
ayudan a ser predictivos conforme pasa el tiempo.
Este beneficio depende mucho de los cambios de tiempos que hayan en el desarrollo de producto,
aunque sea válido cambiar los tiempos, se recomienda no hacerlo con mucha frecuencia.
Control
El sprint goal no cambia durante un sprint, esto ayuda al equipo de desarrollo a mantener una
estabilidad y control sobre el incremento que se tiene que desarrollar.
Además, tal y como se mencionó antes, el tiempo de un sprint ayuda a tener control sobre el coste y la
planificación. Esto es muy beneficioso para grandes organizaciones, que pueden tener muchos sprints en
paralelo, sabiendo exactamente qué costes tiene.
Libertad
El equipo de scrum trabaja bajo un objetivo común, dentro del tiempo establecido por el sprint, esto
repercute en la libertad para trabajar de manera auto-organizada, colaborativa, e incluso hasta
experimentar nuevas prácticas.
Un sprint, además, limita el impacto ante cualquier tipo de fallo o imprevisto que pueda ocurrir, teniendo
tanto control como libertad para poder solucionarlo en el siguiente.
Oportunidad
Scrum es una oportunidad de entregar valor al cliente de manera ágil.
Los sprints exitosos ayudan a las organizaciones a trabajar aun más con scrum. Por lo que la
oportunidad de ser ágiles en un entorno de trabajo empresarial es una gran motivación para los
profesionales.
Scrum Master, todo lo que necesitas saber.

Metodologías agile » Scrum Master, todo lo que necesitas saber.
4.6
(23)
El título de “Scrum Master” suena poderoso, ¿verdad? Pues aunque no lo creas, un Scrum Master no es
el líder de un proyecto y tampoco el responsable de los resultados, es el facilitador del equipo ágil, y un
líder al servicio de quien lo necesite.
El Scrum Master es un rol muy importante dentro de un equipo Scrum, su participación en cada uno
de los eventos de un Sprint y haciendo de líder al servicio de los demás, lo convierten en un componente
vital para la armonía del equipo.
Tabla de Contenidos
 ¿Qué es un Scrum Master?
 ¿Cuáles son sus responsabilidades?
 ¿Cuáles son sus funciones?
 ¿Es el Scrum Master un Project Manager?
 Claves para ser un buen Scrum Master
 Los errores más comunes del Scrum Master
 ¿Cómo puedo convertirme en Scrum Master?
¿Qué es un Scrum Master?

El Scrum Master no es lo mismo que el Product Owner. El product Owner tiene una visión más de
negocio, mientras que el Scrum Master se encarga de que todo el equipo entienda Scrum y lo aplique
correctamente.
Es uno de los roles dentro del equipo Scrum, se asegura de que el framework Scrum se desarrolle
correctamente. Es un líder al servicio de un equipo.
Elimina impedimentos, ayuda al equipo de desarrollo a ser más productivo y guía y enseña al Product
Owner en la gestión del product backlog.
Además, debe participar en las reuniones y asegurarse de que el equipo Scrum cumpla el tiempo y los
objetivos establecidos.
¿Cuáles son sus responsabilidades?

Es el responsable de que Scrum sea entendido y bien aplicado dentro de la organización.
Trabaja junto con el Product Owner y el equipo de desarrollo en la creación de valor en cada
sprint. Elimina impedimentos y ayuda a ser más productivo al Equipo de desarrollo.
¿Cuáles son sus funciones?

Entre otras, un Scrum Master debe:
 Planificar la implantación de Scrum junto con la organización.

 Ayudar a la organización a entender que interacciones con el equipo aportan valor y cuales no.
 Ayudar al Product Owner a saber cómo organizar el product backlog y maximizar el valor.
 Asegurarse de que haya una definición de done.
 Comprender y practicar la agilidad.
 Ayudar al equipo a crear productos de valor.
 Eliminar cualquier impedimento del equipo.
 Facilitar los eventos Scrum.
 Trabajar con otros Scrum Masters para aumentar la efectividad de Scrum en la organización.
 Junto con el equipo Scrum, actualizar el burndown chart.
¿Es el Scrum Master un Project Manager?

El Scrum Master es un líder al servicio del equipo Scrum. En Scrum no existen los project managers,
sin embargo ejerce como el manager de Scrum, por la razón de que enseña y evangeliza Scrum dentro
de la organización.
Claves para ser un buen Scrum Master

 Liderar con el ejemplo.
 Fomentar el debate y apoyarlo.
 Ser paciente.
 Dejar que el equipo actúe.
Los errores más comunes del Scrum Master
A veces se cometen errores a la hora de empezar como Scrum Masters, es por ello, que revisaremos
algunos puntos que consideramos incorrectos para que los Scrum Masters puedan desarrollar un mejor
trabajo en su día a día.
1. No debe organizar el trabajo del Equipo de Desarrollo, existen muchos Scrum Masters que,
según su experiencia pasada, le dicen al Product Owner y al Equipo de Desarrollo las historias de
usuario que pueden realizar en un Sprint, calculando su capacidad, y creando un mal clima de
trabajo.
2. Nunca debe organizar los eventos de un Sprint. En muchas casos, en los Daily meetings, el
Scrum Master se encarga de hacer las tres preguntas, y además de controlar el trabajo de un
desarrollador, que se había comprometido con una historia de usuario el día anterior. El Scrum
Master debe asegurarse que los eventos se realizan, y que se realizan dentro de los tiempos
establecidos.
3. No debe categorizar a los miembros del equipo de desarrollo en roles, no debe asignar
“Programadores” o “Testers”, esto es trabajo interno del mismo equipo, que debe ser
multidisciplinar.
4. No debe proteger al equipo, aislandolo de reuniones importantes como el refinamiento del
Product Backlog, por estar con mucha carga de trabajo. Esto suele terminar en un refinamiento
hecho solo por el Product Owner y el Scrum Master. El objetivo de estos eventos es que
participen todos los miembros del equipo Scrum.
5. No debe obligar a esperar al Sprint Review para la inspección del incremento de
producto. Ni tampoco obligar al equipo de desarrollo a no mostrar nada de lo desarrollado en
medio de un Sprint. Su trabajo es encargarse de que esta labor de inspección no se convierta en
un día a día.
6. No divide los Sprints en “Sprints de incremento” y “Sprints de testing”. Tampoco trabaja con
“Sprints cero” para la creación de la infraestructura de código.
7. No debe cambiar por si mismo Scrum por “Agilidad”, tampoco eliminar eventos que considere
innecesarios por falta de tiempo.
8. No debe obligar a que el Product Owner sea el exclusivo responsable de crear las historias
de usuario del Product Backlog, así como de que sea el Product Owner el único que de los
detalles de cada historia de usuario. El Product Backlog es responsabilidad del Product Owner
pero su organización puede ser realizada de manera colaborativa si así se considera necesario.
Este tipo de acciones aísla la presión a una sola persona, creando un mal clima de trabajo.
Product Owner, Qué es y Cuáles son sus

funciones
Metodologías agile » Product Owner, Qué es y Cuáles son sus funciones
El propietario del producto, a partir de ahora Product Owner o PO, es el responsable de la gestión de la
cartera de productos, a partir de ahora Product Backlog con el fin de lograr el resultado deseado de un
producto.
En Scrum, el Product Owner es el responsable de maximizar el valor del producto desarrollado por el
Equipo de Desarrollo (equipo Scrum). De esto se deduce que gran parte del éxito del producto depende
de cómo se maximice lo que se desarrolla.
El PO trabaja codo con codo con los clientes y el equipo Scrum para maximizar el valor del trabajo
entregado.
Tabla de Contenidos
 ¿Qué es un Product Owner?
 ¿Responsabilidades del product owner?
 ¿Rol del product owner?
 ¿Quién debería ser el Product Owner?
 Cualidades de un Product Owner
o Visión
o Mentalidad MVP
o Comprensión de la competencia
o Comunicador y colaborador
o Negociador
o Empoderamiento
o Siempre disponible
 Claves para ser un buen Product Owner
 ¿Cómo puedo convertirme en Product Owner?
¿Qué es un Product Owner?

Es uno de los roles dentro del equipo Scrum, encargado de, como acabamos de comentar, maximizar el
valor de trabajo entregado y del retorno de inversión. Es el representante del cliente dentro del equipo,
su voz, representa a las partes interesadas internas y es responsable de entregar el valor más alto posible
al negocio.
¿Responsabilidades del product owner?

La responsabilidad principal del Product Owner es representar las necesidades del
cliente manteniendo las capacidades clave y los resultados deseados.
Entre otras, el Product Owner es responsable de:
 El retorno de inversión del proyecto.

 Gestionar el Product Backlog en su totalidad, ordenando y priorizando las tareas para alcanzar los
objetivos de la mejor forma.
 Optimizar el valor del trabajo del Equipo.
 Asegurarse de que el Product Backlog sea visible, transparente y claro para todos.
¿Rol del product owner?

 Recoger y conocer los requisitos.
 Decidir qué desarrollar y qué no.
 Definir buenas historias de usuario.
 Ordenar y priorizar el product backlog y hacer que éste sea visible para todo el mundo.
 Definir el producto mínimo viable (MVP)
 Acordar junto con el equipo una “definición de hecho”.
¿Quién debería ser el Product Owner?

Product managers, managers de equipos de desarrollo, desarrolladores de negocio o, en resumen,
personas responsables del final del producto (o servicio), están bien situadas para ser Product Owners.
Cualidades de un Product Owner

En nuestra opinión, estos son los principales atributos que debe tener un Product Owner para que un
proyecto ágil tenga éxito.
Visión
Debe tener una visión sólida de lo que se desea entregar a los stakeholders. Esto hace que se necesiten
conocimientos de negocio y condiciones del mercado para poder sopesar riesgos y oportunidades.
Sin este atributo, siempre se tendrán dificultades para poder imaginar el producto que se quiere
construir para el cliente.
Mentalidad MVP
Hay que concentrarse en entregar las funcionalidades más valiosas. En muchos casos, los Product
Owners caen en la tentación de entregar “más” de lo que se debería, bien sea porque se quiere deleitar
al cliente, o bien porque “aun queda presupuesto para más”. Estudios indican que más del 65% de las
características de un producto nunca se utilizan, por lo que tener una mentalidad MVP es muy
importante.
Comprensión de la competencia
Esto se explica casi por sí solo, en un mercado donde se lanzan nuevos productos constantemente, tener
los ojos y oídos en el suelo para detectar oportunidades y tomar rápidas decisiones es vital para el éxito
de un proyecto.
Comunicador y colaborador
El Product Owner, al ser el “propietario del producto”, debe comunicarse con diferentes perfiles en
distintas áreas. Ser un buen comunicador de la visión, y colaborador para construir el camino son skills
básicos que todo aspirante a Product Owner debería tener.
Negociador
Estas habilidades de negociación son sobre todo necesarias para evitar retrasos en la toma de
decisiones. La colaboración de distintas partes con distintos intereses hace que la negociación sea
fundamental en momentos críticos del proyecto.
Empoderamiento
Tener la última palabra en el producto que se está desarrollando es fundamental para que un proyecto
Scrum tenga éxito. Sin esta autoridad, el Equipo de Desarrollo debería de esperar a que “la verdadera
autoridad” tome decisiones. Esto es un problema común dentro de Scrum, y es la razón por la que los
proyectos ágiles pierden fuerza con el paso del tiempo.
Siempre disponible
El Product Owner siempre debe estar disponible para el Equipo de Desarrollo. En general, tiene tareas
que realmente no están relacionadas con Scrum, por lo que es vital encontrar un equilibrio entre estas
tareas y las responsabilidades propias de un dueño de producto. Esto se vuelve más desafiante cuando
hay equipos en remoto, con distintas zonas horarias, o cuando hay que escalar el proyecto a múltiples
proyectos Scrum.
La recomendación es poner un “horario de atención del Product Owner”, para poder estar siempre
disponible para comunicarse con el Equipo de Scrum.
Claves para ser un buen Product Owner

 Participar en las reuniones.
 No dar órdenes al equipo.
 Ser receptivo y estar disponible y accesible para el equipo.
 Estar dispuesto a aprender cosas nuevas.
 No hacer asunciones.
¿Qué es el refinamiento (Refinement) del

Product Backlog?
Metodologías agile » ¿Qué es el refinamiento (Refinement) del Product Backlog?
El refinamiento del Product Backlog es un evento dedicado a agregar detalles, estimar y ordenar
las historias de usuario que haya dentro del Product Backlog.
Es normal que los equipos Scrum tengan problemas a la hora de refinar el Product Backlog, ya que no
existe una forma predeterminada de hacer este tipo de acciones dentro de un Sprint.
Esto tiene su justificación, ya que el refinement es un proceso continuo, que es único dentro de cada
proyecto y de cada Equipo Scrum. Por eso cada equipo tiene que descubrir la frecuencia y la forma de
poder agregar detalles y estimar tareas del Product Backlog.
Beneficios de refinar el Product Backlog.
Tabla de Contenidos
 🚀 Incrementar transparencia
 💎 Agregar valor a los items
 💣 Reducir dependencias
 🔑 Predictividad
 💊 Empirismo
🚀 Incrementar transparencia
El Product Backlog, al ser un artefacto que incrementa la transparencia dentro del Equipo Scrum, cuanto
más detallado esté, más claridad transmitirá al equipo de desarrollo.
💎 Agregar valor a los items
Agregar valor a los items del Product Backlog, el equipo de desarrollo desarrollará las cosas mejor, y sus
estimaciones serán más acertadas. Además, ayudará al Product Owner a tener un mejor orden de
prioridades.
💣 Reducir dependencias
Tener dependencias dentro de los items del Product Backlog puede provocar impedimentos y retrasos
en los proyectos. Reducir y dividir las historias de usuario en el refinamiento del Product Backlog se
puede hacer de muchas formas, como por ejemplo trabajar con otros equipos colaborativamente.
Dependerá del proyecto en el que trabajes.
🔑 Predictividad
Un Product Backlog refinado, junto con un historial de Sprints y Retrospectivas acerca de los procesos
de Scrum, ayudará a predecir posibles inconvenientes en historias de usuario y prioridades.
En medio de un Sprint, refinar el Product Backlog permitirá predecir cómo irán los incrementos de
futuros Sprints, prediciendo los posibles inconvenientes.
💊 Empirismo
El empirismo consiste en incorporar el aprendizaje que obtienes a medida que construyes el producto, a
medida que entiendes mejor cómo realizar la visión del producto, a medida que ves los cambios que
suceden en tu entorno. Todo esto se reafirma gracias al refinamiento del Product Backlog.
Retrospectiva – ¿Qué es el Sprint Retrospective?

Metodologías agile » Retrospectiva – ¿Qué es el Sprint Retrospective?
5
(10)
El sprint retrospective meeting (retrospectiva) es el último evento en un Sprint en Scrum. Es una

oportunidad para el equipo de inspeccionarse a sí mismo, y crear un plan de mejora que se pondrá en
marcha inmediatamente, en el siguiente Sprint.
Este evento se realiza después del Sprint Review, tiene un tiempo máximo de duración de 3 horas
para Sprints de 1 mes, por supuesto para Sprints más pequeños su tiempo de duración será
proporcionalmente menor.
Tabla de Contenidos
 ¿Cuál es el objetivo de la retrospectiva?
 ¿En qué consiste?
 ¿Quiénes deben participar?
 ¿Cada cuánto debe realizarse el Sprint Retrospective?
 Beneficios
¿Cuál es el objetivo de la retrospectiva?

El objetivo de un sprint retrospective meeting es, básicamente, mejorar: mejorar la productividad,
mejorar las habilidades del equipo, mejorar la calidad del producto. En resumen, el objetivo es mejorar la
aplicación de Scrum.
Otro objetivo es hacer foco en el equipo, analizando cómo trabajamos y cómo nos relacionamos, para
buscar posibles mejoras que el mismo equipo aplicará.
¿En qué consiste?

Previo a la sesión, cada miembro del equipo debe hablar de los siguientes puntos:
 Qué ha funcionado bien en el último Sprint.

 Cuáles cosas hay que mejorar de cara al siguiente Sprint.
 Problemas que haya tenido para poder progresar correctamente en el último Sprint.
 Recomendaciones a aplicar en el siguiente Sprint.
Al realizarse después del Sprint Review, podemos incorporar el feedback que hayamos obtenido dentro
de los puntos a hablar.
¿Quiénes deben participar?

Debe participar el equipo completo de Scrum, no existen distinciones entre todos los miembros
del equipo.
El Scrum Master es el encargado de que esta sesión se realice dentro de los tiempos y de que cada
miembro del equipo entiende cuál es el objetivo del evento. Cuando se detecta un punto de mejora
dentro del proceso de Scrum, el Scrum Master se encarga de hacer los cambios pertinentes para
mantener las buenas prácticas ágiles.
¿Cada cuánto debe realizarse el Sprint Retrospective?

En cada Sprint, todos los Sprints terminan con el Sprint Retrospective, sin excepción.
Beneficios
El sprint retrospective incrementa la calidad del producto, además de aumentar
considerablemente el aprendizaje dentro de los miembros del equipo.
El feedback siempre motiva al equipo a hacer las cosas bien, el hacer cambios para bien gracias a la
recomendación de un miembro del equipo invita a que los demás también lo hagan, consiguiendo una
mejora colaborativa.
Por último, los cambios siempre se aplicarán en el siguiente Sprint, por lo que cada mejora se verá
reflejada a corto plazo, mejorando la productividad.
¿Qué es el Product Backlog?

Metodologías agile » ¿Qué es el Product Backlog?
4.5
(8)
En SCRUM, gracias al product backlog, tendremos una lista de los requisitos/expectativas del
cliente la cual usaremos para describir el próximo trabajo sobre el producto
Para empezar a trabajar, no es necesario que el product backlog esté completo, ni siquiera que TODOS
los requisitos estén detallados, solo necesitamos el suficiente detalle para los requisitos más prioritarios
con los que el equipo pueda empezar a trabajar.
Tabla de Contenidos
 ¿Qué es el Product Backlog?
 ¿Qué debería haber en el Product Backlog?
 ¿Quién crea el Product Backlog?
 ¿Cada cuánto debo actualizar el Product Backlog?

Es una lista priorizada y ordenada de requisitos del cliente (llamados Product Backlog items) de un
proyecto. Es gestionado por el product owner, incluyendo su contenido, disponibilidad y peticiones,
además es él (el product owner) quien ordena el Product Backlog en base al valor, riesgos, dependencias
y necesidades de negocio.
¿Qué debería haber en el Product Backlog?
Todos los requerimientos, funcionales y no funcionales, tareas y bugs deben ir en el Product Backlog. Su
contenido refleja todo el trabajo que el equipo de desarrollo tiene que hacer. En otras palabras, el
equipo de desarrollo no hace absolutamente nada que no se encuentre en este listado.
¿Quién crea el Product Backlog?

El Product Owner define la visión y dirección que el producto toma, por norma general, siempre se
establecen antes los requisitos conocidos y mejor entendidos. Cualquier miembro del equipo puede
agregar items en el Product Backlog. Sin embargo, es el Product Owner quién se encarga de gestionarlo.
¿Cada cuánto debo actualizar el Product Backlog?

El Product Backlog nunca se completa, además, evoluciona constantemente, puede cambiar en
todo momento, por lo que se actualiza cada vez que sea necesario. En cambio, recuerda que en el
Sprint Backlog (los items que se escogen para desarrollar en un Sprint) no pueden cambiar.
Equipo SCRUM, Guía Completa [ACTUALIZADA

2019]
Metodologías agile » Equipo SCRUM, Guía Completa [ACTUALIZADA 2019]
4.5
(14)
El equipo Scrum es un equipo multidisciplinar. Consiste en un grupo de personas con las habilidades
necesarias para transformar todos los items del product backlog en incrementos de desarrollo.
El equipo de desarrollo Scrum consiste en profesionales responsables de desarrollar incrementos de

producto en cada Sprint. La responsabilidad es exclusivamente de ellos ya que son los únicos que
pueden crear estos incrementos.
Es un equipo estructurado y empoderado dentro de la organización para auto-organizarse y

gestionar su propio trabajo. Esto se traduce en un equipo óptimo tanto en eficiencia como en
productividad.
Tabla de Contenidos
 Características del equipo de desarrollo Scrum
 Responsabilidades del equipo Scrum
 ¿Cuál es el tamaño recomendado de un Equipo Scrum?
 ¿Puedo trabajar Scrum aunque mi equipo trabaje en remoto?
 ¿Quién debería estar en el Equipo de Desarrollo Scrum?
 ¿Quién es el manager del Equipo Scrum?
 ¿Cuántos proyectos simultáneos puede trabajar un Equipo?
 ¿Qué es la velocidad en el Equipo?
Características del equipo de desarrollo Scrum

El equipo de desarrollo tiene las siguientes características:
 Multifuncional: Es capaz de realizar cada una de las historias de usuario del product backlog de
principio a fin, siguiendo el definition of done.
 Auto-organizado: Nadie, ni siquiera el Scrum Master, tiene que decirle al equipo de desarrollo
cómo tiene que convertir cada elemento del product backlog en incremento de producto.
 Se recomienda que no existan “títulos” dentro del equipo, para evitar responsabilidades únicas en
elementos del product backlog.
 No existen sub-equipos dentro del equipo de desarrollo.
 Cada miembro del equipo puede ser especialista en un área en la cual se enfoque, pero la
responsabilidad de cualquier fallo recae en todo el equipo.
Responsabilidades del equipo Scrum

El equipo de desarrollo Scrum es responsable de su propio trabajo, y por ello debe seguir a pie de
letra lo siguiente:
 Son responsables íntegros de convertir los elementos del product backlog en incrementos de
producto. Nadie debe decirles cómo hacer este trabajo.
 Son responsables de realizar las estimaciones de cada elemento del product backlog.
 Son responsables del sprint backlog, no así del product backlog, responsabilidad del product
owner.
 Son responsables de solucionar cualquier problema interno dentro del equipo.
 Son responsables de asistir a cada daily meeting, es el único rol dentro de Scrum que tiene que
asistir sí o sí a este evento.
¿Cuál es el tamaño recomendado de un Equipo Scrum?

El tamaño de un equipo de desarrollo Scrum debe ser lo suficientemente bajo como para mantener la
agilidad, y lo suficientemente alto como para poder completar un incremento de producto aceptable en
el contexto del proyecto.
El tamaño recomendado es entre 3 y 9 personas. Menos de 3 difícilmente pueda ser llamado un

equipo de desarrollo Scrum. En caso de ser más de 9 personas, termina siendo muy difícil poder
gestionar todos los eventos de Scrum: Sprint planning, review y retrospectiva. Equipos grandes
encuentran difícil tomar decisiones dentro de los tiempos que duran los eventos.
El Scrum master y el product owner no están incluidos en este número de personas, aunque ellos
también participen en el desarrollo de producto.
¿Puedo trabajar Scrum aunque mi equipo trabaje en remoto?

Existen muchos estudios que demuestran que los equipos que no trabajan en remoto son más
productivos que los que están en distintas ubicaciones. Se sufre en comunicación, muy necesaria en los
eventos Scrum. De todos modos, la tendencia de trabajo ágil en remoto está en tendencia de
crecimiento.
¿Quién debería estar en el Equipo de Desarrollo Scrum?

Deberían estar todos los perfiles con conocimientos y habilidades necesarias para poder transformar los
items del product backlog en incrementos de desarrollo. Normalmente consiste en programadores,
testers, business analysts, especialistas en marketing, etc.
¿Quién es el manager del Equipo Scrum?

El equipo de desarrollo es auto-gestionado. El Product Owner define la dirección que el equipo debe
tomar ordenando el Product Backlog, pero el equipo se encarga tanto de estimar las tareas, como de
definir la manera en que se va a desarrollar. El Scrum Master es el encargado de remover impedimentos
dentro del equipo de desarrollo, pero cualquier conflicto interno que haya se resuelve entre los
miembros del equipo.
¿Cuántos proyectos simultáneos puede trabajar un Equipo?

El equipo de desarrollo es más productivo si solo trabaja en un proyecto a la vez. No hay un requisito
obligatorio dentro de Scrum que indique que siempre sea así, por lo que se pueden trabajar en más de
un proyecto simultáneamente, siempre garantizando que los objetivos se cumplirán.
¿Qué es la velocidad en el Equipo?

El total de trabajo que el equipo de desarrollo es capaz de completar en un Sprint es llamado velocidad.
Cuando el equipo de desarrollo está planificando el primer Sprint, ellos estiman su velocidad. Para
futuros Sprints, la velocidad será el total de trabajo realizado por el equipo en el anterior sprint.
¿Qué es un daily meeting en scrum?

Metodologías agile » ¿Qué es un daily meeting en scrum?
5
(4)
El daily en scrum es una reunión de 15 minutos de duración, del equipo de desarrollo scrum, en el que
se sincronizan las actividades que están ocurriendo en el sprint, y la planificación de las actividades de
las próximas 24 horas. Se realiza con la intención de inspeccionar el trabajo realizado desde el anterior
daily y también poder predecir el trabajo que se hará antes del siguiente.
Tabla de Contenidos
 ¿De qué se habla en un daily?
 ¿Quiénes deben estar presentes en el daily?
 Beneficios de hacer el daily
 Recomendaciones
¿De qué se habla en un daily?

Durante la reunión, cada miembro del equipo de desarrollo explica lo siguiente:
 ¿Qué he hecho desde el último daily scrum para ayudar al equipo de desarrollo a cumplir el
objetivo del sprint?
 ¿Qué haré durante el día de hoy para ayudar al equipo a cumplir el objetivo del sprint?
 ¿He visto o encontrado algún impedimento que me impida a mi, o al equipo, a cumplir el
Esto optimiza las posibilidades del equipo de desarrollo scrum a cumplir el objetivo marcado para este
sprint.
El daily scrum tiene una duración máxima de 15 minutos, pero eso no evita que puedan haber reuniones
inmediatamente después para hablar sobre detalles, replanificar o adaptarse al resto del sprint.
¿Quiénes deben estar presentes en el daily?

Obligatoriamente debe estar el equipo de desarrollo, que son los encargados del sprint backlog. Ellos se
encargan de la inspección de trabajo para conseguir cumplir el sprint goal.
Opcionalmente, pueden estar tanto el Scrum Master y el Product Owner. El Scrum Master se asegura que
el equipo de desarrollo tiene el daily scrum, de que el mismo tiene una duración máxima de 15 minutos,
y que la regla de que el equipo de desarrollo scrum es el que conduce estas reuniones.
El Product Owner puede presenciar las reuniones de manera opcional, siempre teniendo en cuenta de
que su participación es simplemente de oyente.
Beneficios de hacer el daily

 Mejora las comunicaciones dentro del equipo de desarrollo, gracias a las 3 preguntas que se
responden.
 Ayuda a evitar otro tipo de reuniones, todo se centraliza en el Daily.
 Identifica problemas o impedimentos que el equipo de desarrollo tiene que corregir cuanto antes.
 Destaca y promueve la toma de decisiones rápida.
 Ayuda a aumentar el conocimiento general del equipo de desarrollo.
 Mejora la inspección y adaptación. El daily scrum meeting es la principal reunión sobre inspección
y adaptación.
Recomendaciones
Se recomienda hacer esta reunión de pie. Esta buena práctica ayuda a los miembros del equipo de
desarrollo a estar enfocados en la reunión, evitar distracciones y extenderse en los detalles al responder
las 3 preguntas.
Hacer las reuniones siempre a la misma hora y en la misma ubicación, esto ayuda a reducir
complejidad y enfoca al equipo de desarrollo a responder a las 3 preguntas.
¿Qué es un daily meeting en scrum?

Metodologías agile » ¿Qué es un daily meeting en scrum?
5
(4)
El daily en scrum es una reunión de 15 minutos de duración, del equipo de desarrollo scrum, en el que
se sincronizan las actividades que están ocurriendo en el sprint, y la planificación de las actividades de
las próximas 24 horas. Se realiza con la intención de inspeccionar el trabajo realizado desde el anterior
daily y también poder predecir el trabajo que se hará antes del siguiente.
Tabla de Contenidos
 ¿De qué se habla en un daily?
 ¿Quiénes deben estar presentes en el daily?
 Beneficios de hacer el daily
 Recomendaciones
¿De qué se habla en un daily?
Durante la reunión, cada miembro del equipo de desarrollo explica lo siguiente:
 ¿Qué he hecho desde el último daily scrum para ayudar al equipo de desarrollo a cumplir el
 ¿Qué haré durante el día de hoy para ayudar al equipo a cumplir el objetivo del sprint?
 ¿He visto o encontrado algún impedimento que me impida a mi, o al equipo, a cumplir el
Esto optimiza las posibilidades del equipo de desarrollo scrum a cumplir el objetivo marcado para este
sprint.
El daily scrum tiene una duración máxima de 15 minutos, pero eso no evita que puedan haber reuniones
inmediatamente después para hablar sobre detalles, replanificar o adaptarse al resto del sprint.
¿Quiénes deben estar presentes en el daily?

Obligatoriamente debe estar el equipo de desarrollo, que son los encargados del sprint backlog. Ellos se
encargan de la inspección de trabajo para conseguir cumplir el sprint goal.
Opcionalmente, pueden estar tanto el Scrum Master y el Product Owner. El Scrum Master se asegura que
el equipo de desarrollo tiene el daily scrum, de que el mismo tiene una duración máxima de 15 minutos,
y que la regla de que el equipo de desarrollo scrum es el que conduce estas reuniones.
El Product Owner puede presenciar las reuniones de manera opcional, siempre teniendo en cuenta de
que su participación es simplemente de oyente.
Beneficios de hacer el daily

 Mejora las comunicaciones dentro del equipo de desarrollo, gracias a las 3 preguntas que se
responden.
 Ayuda a evitar otro tipo de reuniones, todo se centraliza en el Daily.
 Identifica problemas o impedimentos que el equipo de desarrollo tiene que corregir cuanto antes.
 Destaca y promueve la toma de decisiones rápida.
 Ayuda a aumentar el conocimiento general del equipo de desarrollo.
 Mejora la inspección y adaptación. El daily scrum meeting es la principal reunión sobre inspección
y adaptación.
Recomendaciones
Se recomienda hacer esta reunión de pie. Esta buena práctica ayuda a los miembros del equipo de
desarrollo a estar enfocados en la reunión, evitar distracciones y extenderse en los detalles al responder
las 3 preguntas.
Hacer las reuniones siempre a la misma hora y en la misma ubicación, esto ayuda a reducir
complejidad y enfoca al equipo de desarrollo a responder a las 3 preguntas.
¿Qué es el refinamiento (Refinement) del

Product Backlog?
Metodologías agile » ¿Qué es el refinamiento (Refinement) del Product Backlog?
4.5
(13)
El refinamiento del Product Backlog es un evento dedicado a agregar detalles, estimar y ordenar
las historias de usuario que haya dentro del Product Backlog.
Es normal que los equipos Scrum tengan problemas a la hora de refinar el Product Backlog, ya que no
existe una forma predeterminada de hacer este tipo de acciones dentro de un Sprint.
Esto tiene su justificación, ya que el refinement es un proceso continuo, que es único dentro de cada
proyecto y de cada Equipo Scrum. Por eso cada equipo tiene que descubrir la frecuencia y la forma de
poder agregar detalles y estimar tareas del Product Backlog.
Beneficios de refinar el Product Backlog.
Tabla de Contenidos
 🚀 Incrementar transparencia
 💎 Agregar valor a los items
 💣 Reducir dependencias
 🔑 Predictividad
 💊 Empirismo
🚀 Incrementar transparencia
El Product Backlog, al ser un artefacto que incrementa la transparencia dentro del Equipo Scrum, cuanto
más detallado esté, más claridad transmitirá al equipo de desarrollo.
💎 Agregar valor a los items

Agregar valor a los items del Product Backlog, el equipo de desarrollo desarrollará las cosas mejor, y sus
estimaciones serán más acertadas. Además, ayudará al Product Owner a tener un mejor orden de
prioridades.
💣 Reducir dependencias
Tener dependencias dentro de los items del Product Backlog puede provocar impedimentos y retrasos
en los proyectos. Reducir y dividir las historias de usuario en el refinamiento del Product Backlog se
puede hacer de muchas formas, como por ejemplo trabajar con otros equipos colaborativamente.
Dependerá del proyecto en el que trabajes.
🔑 Predictividad
Un Product Backlog refinado, junto con un historial de Sprints y Retrospectivas acerca de los procesos
de Scrum, ayudará a predecir posibles inconvenientes en historias de usuario y prioridades.
En medio de un Sprint, refinar el Product Backlog permitirá predecir cómo irán los incrementos de
futuros Sprints, prediciendo los posibles inconvenientes.
💊 Empirismo
El empirismo consiste en incorporar el aprendizaje que obtienes a medida que construyes el producto, a
medida que entiendes mejor cómo realizar la visión del producto, a medida que ves los cambios que
suceden en tu entorno. Todo esto se reafirma gracias al refinamiento del Product Backlog.

Metodologías agile » ¿Qué es el Product Backlog?
4.5
(8)
En SCRUM, gracias al product backlog, tendremos una lista de los requisitos/expectativas del
cliente la cual usaremos para describir el próximo trabajo sobre el producto
Para empezar a trabajar, no es necesario que el product backlog esté completo, ni siquiera que TODOS
los requisitos estén detallados, solo necesitamos el suficiente detalle para los requisitos más prioritarios
con los que el equipo pueda empezar a trabajar.
Tabla de Contenidos
 ¿Qué es el Product Backlog?
 ¿Qué debería haber en el Product Backlog?
 ¿Quién crea el Product Backlog?
 ¿Cada cuánto debo actualizar el Product Backlog?

Es una lista priorizada y ordenada de requisitos del cliente (llamados Product Backlog items) de un
proyecto. Es gestionado por el product owner, incluyendo su contenido, disponibilidad y peticiones,
además es él (el product owner) quien ordena el Product Backlog en base al valor, riesgos, dependencias
y necesidades de negocio.
¿Qué debería haber en el Product Backlog?

Todos los requerimientos, funcionales y no funcionales, tareas y bugs deben ir en el Product Backlog. Su
contenido refleja todo el trabajo que el equipo de desarrollo tiene que hacer. En otras palabras, el
equipo de desarrollo no hace absolutamente nada que no se encuentre en este listado.
¿Quién crea el Product Backlog?

El Product Owner define la visión y dirección que el producto toma, por norma general, siempre se
establecen antes los requisitos conocidos y mejor entendidos. Cualquier miembro del equipo puede
agregar items en el Product Backlog. Sin embargo, es el Product Owner quién se encarga de gestionarlo.
¿Cada cuánto debo actualizar el Product Backlog?

El Product Backlog nunca se completa, además, evoluciona constantemente, puede cambiar en
todo momento, por lo que se actualiza cada vez que sea necesario. En cambio, recuerda que en el
Sprint Backlog (los items que se escogen para desarrollar en un Sprint) no pueden cambiar.
Qué es SCRUM
Metodologías agile » Qué es SCRUM
4.9
(14)
Scrum es ligero, simple de entender pero muy difícil de dominar.

Scrum no es un proceso o una técnica para desarrollar/construir productos, realmente es un marco de
trabajo donde podemos emplear un conjunto de diferentes procesos y técnicas.
Tabla de Contenidos
 Definición de Scrum
 Orígenes de Scrum
 Componentes de Scrum
o Los roles de Scrum
 El Product Owner
 El Scrum Master
 El equipo Scrum
o Eventos Scrum
 El Sprint
 La planificación del Sprint
 El daily
 La revisión del Sprint
 La retrospectiva
o Artefactos Scrum
 El product backlog
 El sprint backlog
 Un incremento
 Pensamiento Scrum
 Conclusión
Definición de Scrum
Scrum es una de las Metodologías Ágiles más populares y conocidas en la actualidad. Se trata de
una herramienta muy útil en espacios donde los grupos de trabajo tienen dificultades para hacer las
acciones u operaciones que les lleven a objetivos en común. Dicho de otro modo, Scrum sirve para que
equipos multidisciplinares trabajen en entornos complejos, donde los requisitos son muy cambiantes, y
los resultados se tienen que obtener en un plazo corto de tiempo.
El marco de trabajo de Scrum se compone del Equipo Scrum, sus Roles, Eventos, Artefactos y Reglas
asociadas. Cada uno de ellos tiene su objetivo propio, y es esencial para el éxito de Scrum y para su uso.
Orígenes de Scrum
Scrum apareció entre nosotros por primera vez en 1986, en un artículo de la Harvard Business Review “El
nuevo nuevo juego para el desarrollo de productos”. El artículo describe cómo empresas como Canon u
Honda producen nuevos productos utilizando un enfoque escalable, basado en equipos integrales, para
el desarrollo de productos. El mismo hace hincapié en dar poder a los equipos auto-organizados. Este
artículo fue una influencia para el desarrollo de muchos de los conceptos que ayudaron a que naciera
Scrum.
Scrum es un término extraído del Rugby, se refiere a la formación fija cuya función es disputar el balón y
volver a ponerla en juego, luego de una falta menor. Mirándolo desde el punto de vista del Rugby, en
un Scrum, el equipo intenta avanzar como equipo, enviando el balón hacia atrás y luego avanzar. Esto
sirve mejor para los desarrollos competitivos de hoy en día.
Componentes de Scrum
El framework Scrum está compuesto por los roles de equipo, los eventos, los artefactos y las reglas.
Los roles de Scrum
El Product Owner
Es el portavoz del cliente y es responsable de gestionar el product backlog.
El Scrum Master
Es un líder al servicio del equipo Scrum. No tiene autoridad jerárquica sobre el equipo, es más bien un
facilitador que protege al equipo y hace todo lo posible para ayudar al equipo eliminando
impedimentos, facilitando las reuniones y ayudando al product a priorizar el product backlog.
El equipo Scrum
Normalmente se componen de 3 a 9 miembros y debe ser capaz de abordar las tareas como unidad.
Debe ser un equipo autoorganizado y multidisciplinar, o lo que es lo mismo, cada miembro debe
confiar en el resto del equipo, compartir toda la información y tener las habilidades necesarias para
ejecutar todas las tareas acordadas en el sprint.
Eventos Scrum
El Sprint
Es un período de tiempo “limitado” normalmente de 1 a 4 semanas de duración durante el cual el

equipo debe abordar las tareas planificadas.
La planificación del Sprint
En inglés “sprint planning” son reuniones de equipo que sirven para determinar qué tareas se realizarán
y se entregarán en el próximo sprint.
El daily
Es una reunión de no más de 15 minutos en la que cada miembro del equipo cubre de forma rápida y
transparente qué hizo ayer, qué hará hoy y qué impedimentos están bloqueando su progreso.
La revisión del Sprint
Es el evento en el que el equipo presenta el trabajo completado durante el Sprint al product owner,
quien comprueba el trabajo y lo acepta o rechaza según el definiton of done (DoD). Además los clientes
dan retroalimentación para asegurar que las tareas entregadas (incremento) cumplen con las
necesidades del negocio.
La retrospectiva
Es la reunión final del equipo en el Sprint y ayuda determinar lo que fue bien, lo que no y en qué puede
mejorar el equipo. Es el mejor momento para identificar estrategias y establecer un plan para la mejora
continua.
Artefactos Scrum
El product backlog
Es una lista de tareas que describen todos los requisitos del proyecto. El orden natural del product
backlog es en términos de valor de negocio.
El sprint backlog
Es la lista específica de elementos cogidos del product backlog que se deben completar en un Sprint.
Un incremento
Es la suma de todas las tareas que se han completado desde la última versión de producto entregada. Es
responsabilidad del equipo asegurarse de que todo lo que se incluye en un incremento funciona y está
listo para ser entregado o “ponerse en producción” aunque depende del product owner decidir cuándo
se hace.
Pensamiento Scrum
Solemos pensar en Scrum para el desarrollo de software, pero sus principios y valores pueden y son
utilizados para el desarrollo de distintos tipos de productos o para organizar el flujo de varios equipos
de trabajo.
Scrum proporciona calidad, rapidez en la entrega y bajos costes, evita la burocracia y la documentación,
de manera que los primeros resultados lleguen muy rápidamente.
Prácticamente en cualquier proyecto se puede implementar Scrum, desde el desarrollo de hardware,

como organizar un equipo de marketing o en iniciativas de equipos de ventas.
Conclusión
Scrum propone una metodología donde el equipo debe trabajar en equipo, debe avanzar de manera
conjunta. De nada sirve tener partes de un software terminada, si no tenemos el software entero
terminado.
La filosofía Scrum resalta e impulsa el trabajo en equipo, el aprendizaje constante y una estructura que
es flexible a los cambios que van sucediendo en la fase de desarrollo.
¿Qué es el Sprint Planning? +🔥 Bonus: Cómo

planificar
Metodologías agile » ¿Qué es el Sprint Planning? +🔥 Bonus: Cómo planificar
4.7
(33)
El Sprint Planning es el primer evento de Scrum en dónde se planifican las tareas a realizar en
el Sprint en curso. En esta reunión participan, de manera colaborativa, todo el equipo Scrum: Scrum
Master, Product Owner y Equipo de Desarrollo.
Tabla de Contenidos
 Características del Sprint Planning
 ¿Qué se puede hacer en este Sprint?
 ¿Cómo haremos el trabajo elegido?
 🔥 Bonus: ¿Cómo planificar un Sprint en Scrum?
Características del Sprint Planning
El tiempo de esta reunión es de máximo 8 horas para Sprints de 4 semanas de duración. Para Sprints de
menor duración, esta reunión debe proporcionalmente ser más corta. El Scrum Master es el encargado
de asegurar que esta reunión se realice, se enseñe la importancia de la misma, y además debe
asegurarse de que se realiza en el tiempo establecido.
La labor del Product Owner es la de describir las tareas con mayor prioridad al resto del equipo, estas
tareas deben ser las que aparezcan en la parte superior del Product Backlog. El Equipo de Desarrollo
pregunta todo lo necesario para convertir estas historias de usuario en tareas más específicas.
El Product Owner no debe explicar el 100% de los ítems del Product Backlog, es una buena práctica que
los dueños de producto se presenten a esta reunión preparados para hablar sobre ítems
correspondientes a 2 Sprints.
El Sprint Planning responde a las dos siguientes preguntas:
 ¿Qué se puede hacer en este Sprint?

 ¿Cómo haremos el trabajo elegido?
¿Qué se puede hacer en este Sprint?

En esta parte, el Equipo de desarrollo pronostica su capacidad de desarrollo en el Sprint. El Product
Owner explica el objetivo de la iteración, y los ítems del Backlog que se deberían hacer para conseguir el
objetivo final. Todo el equipo trabaja de manera colaborativa para comprender el trabajo a realizar.
Entra en importancia el Product Backlog, el último incremento desarrollado, la capacidad del equipo de
desarrollo y el rendimiento en el Sprint anterior. Todos los items que se seleccionen del Product Backlog
son decisión exclusiva del Equipo de desarrollo.
Durante el Sprint Planning se define el Sprint Goal, que es objetivo que el equipo Scrum debe conseguir
para una correcta evolución del proyecto.
¿Cómo haremos el trabajo elegido?

Con el Sprint Goal y los ítems del Product Backlog seleccionados, el equipo de desarrollo decide cómo
convertir estas historias de usuario en incremento de producto. Los items seleccionados del Product
Backlog reciben el nombre de Sprint Backlog.
Cabe destacar que no es necesario que se planifique el desarrollo del 100% de las historias de usuario, es
buena práctica planificar el trabajo de los primeros 2 días, y descomponer esta planificación en varias
reuniones, con esto se gana agilidad y productividad.
Al final de la reunión, el equipo de desarrollo debe ser capaz de explicar tanto al Product Owner como al
Scrum Master como van a trabajar de manera auto-organizada para conseguir desarrollar todos los
items del Sprint Backlog, y conseguir el objetivo definido en el Sprint Goal.
🔥 Bonus: ¿Cómo planificar un Sprint en Scrum?
Si recordáis la película, “Atrapado en el Tiempo”, protagonizada por Bill Murray, consistía en una
repetición temporal del mismo día. Casualmente era el día de la marmota, famoso en Estados Unidos
porque sirve para prever si el invierno va a durar mas o menos tiempo, en función de lo que haga una
marmota.
Si la marmota al salir de su madriguera no ve su sombra, dejará la madriguera, lo cual significa que el

invierno terminará pronto. Si por el contrario, la marmota ve su sombra y se mete de nuevo en la
madriguera, significa que el invierno durará seis semanas más.
El día amanece con un objetivo que es desvelado cuando la marmota ve o no ve su sombra.
Cuando ejecutamos un sprint en scrum, podría asemejarse al día de la marmota, donde el comienzo del
sprint se produce cuando suena el despertador y donde el conjunto de acontecimientos que van
sucediendo depende de las acciones que el protagonista realiza durante el “sprint”.
Se va adaptando a los nuevos cambios, y orientando todo a su objetivo final que es el de conseguir que
la chica se enamore de él, y salir del bucle.
Si asemejamos la ejecución de un sprint a la película, podemos encontrar algunas similitudes.
 Ambos se repiten en el tiempo como un bucle.

 Las acciones principales se repiten día a día si no hay un acontecimiento importante que lo
impida.
 El día y el sprint comienzan y acaban en un determinado momento, suceda lo que suceda.
 Ambos nacen con un objetivo, y se llevan acciones para conseguirlo. (Phill quiere enamorar a
Rita – En nuestro sprint trabajamos por un incremental de valor del producto)
La planificación del sprint debemos hacerla teniendo en cuenta que una serie de acontecimientos
deben repetirse en el tiempo, puesto que son los que nos garantizan una entrega incremental de valor.
Pero debemos adaptarnos a los cambios surgidos en el sprint en scrum.
Si por ejemplo necesitamos hacer estimaciones de tareas que nos requieren mas de 1 hora de reunión,
podemos hacer 2 reuniones de refinamiento de 1 hora cada una, en vez de una sola por sprint. O si
vemos carencias en el detalle funcional de las tareas, podemos incluir alguna reunión previa al
refinamiento del PO (Product Owner) y el SM (Scrum Master) para que se detalle a nivel funcional con
mayor profundidad estas tareas.
Es decir, nos vamos adaptando continuamente al cambio, para conseguir un objetivo que es el de
conseguir el objetivo del sprint o que Rita se enamore de Phill como en la película que hemos
comentado.
Otro punto importante es controlar los tiempos y puntualidad de comienzo y fin de las reuniones. Si
observamos que este punto no se cumple, debemos incluirlo en el orden de la retrospectiva para revisar
por que esta pasando y adaptarnos. Nos comprometemos con un objetivo considerando un trabajo
asumible en el sprint. Si disminuimos el tiempo que podemos dedicar al trabajo no podemos asegurar la
entrega.
Si tenemos certeza de la entrega de producto incremental, debemos convocar con suficiente antelación
a los interesados principales de negocio que decida el PO, enviándoles una convocatoria de la Review
del sprint. En realidad si todos los sprints entregamos valor, los interesados deberían ir cada sprint a la
Review. Este es un punto complicado de conseguir, pero clave para conseguir un alineamiento real del
desarrollo del producto con las necesidades de nuestros clientes. Comentaremos este tema con mas
detalle en otra entrada.
La reunión retrospectiva debe ser variada, para que el equipo no piense que esta repitiendo el día de
la marmota cada sprint, dándole dinamismo e incentivando la participación. Podemos encontrar mas
detalle en la entrada de como planificar una retrospectiva.
En definitiva, el sprint en scrum debe regirse por unas bases que deben repetirse en el tiempo pero
adaptándolas a las propias necesidades del momento en el que nos encontremos.
Las Mejores Historias de Usuario INVEST &

SMART
Metodologías agile » Las Mejores Historias de Usuario INVEST & SMART
4.7
(7)
Una historia de usuario es una definición a muy alto nivel de un requisito. Contiene la suficiente
información para que los desarrolladores puedan estimar el esfuerzo para implementar dicho requisito.
Una buena historia de usuario debe describir la tarea que nuestro usuario quiere realizar y su
finalidad (para qué), para alcanzar el nivel correcto de detalle para satisfacer estos criterios debemos
usar la metodología INVEST.
Tabla de Contenidos
 Qué es INVEST
 Qué es SMART
 Ejemplos de buenas Historias de Usuario
 Mal ejemplo de una Historia de Usuario
Qué es INVEST
Es una metodología desarrollada por Bill Wake y nos ayuda a garantizar que las historias de usuario
ofrecen valor a negocio aunque se desarrollen en un sola iteración. Las siglas “Invest” nos ayudan a
recordar que las buenas historias deben ser: I – Independent, N – Negotiable, V – Valuable, E –
Estimable, S – Small, T – Testable.
 Independent (Independiente): la historia del usuario debe ser auto-explicable, no debe depender
de otras historias de usuario.
 Negotiable (Negociable): evita incluir demasiado detalle, para que las historias de usuario sean
flexibles y puedan ser modificadas.
 Valuable (Valiosa): las historias de usuario deben aportar algún valor al usuario final.
 Estimable: debes ser capaz de estimar los recursos necesarios para completar cada historia de
usuario.
 Scalable (Escalable): haz simples las historias de usuario, para que puedan ser encargadas y
priorizadas.
 Testable (Comprobable): explica los criterios de verificación y aprobación, para que el equipo los
conozca y aplique cuando una historia esté completa.
Qué es SMART
Cuando descompongamos nuestras historias de usuario en tareas, usaremos el método SMART, un
método que nos ayuda a evaluar si nuestras tareas están correctamente definidas.
SMART es el acrónimo de: S – Specific, M – Measurable, A – Achievable, R – Relevant, T – Time-boxed
 Specific (Específico): Una tarea debe ser lo suficientemente específica para que todos puedan
entenderla.
 Measurable (Medible): ¿Hace lo que se pretende? Es el equipo quien debe ponerse de acuerdo
sobre lo que esto significa.
 Achievable (Alcanzable): ¿Es razonable la meta? Consejo: Es bueno establecer metas que
representen un desafío, pero puede ser contraproducente no alcanzarlas.
 Relevant (Relevante): Cada tarea debe ser relevante, contribuyendo a la historia en cuestión.
 Time-Boxed (A tiempo): Una tarea debe estar limitada a una duración específica. No
necesariamente debe ser una estimación formal en horas o días, pero debe haber una expectativa
para que la gente sepa cuándo debe buscar ayuda.
Ejemplos de buenas Historias de Usuario

Una forma sencilla de realizar buenas historias de usuario es mediante el siguiente esquema: “Como X,
quiero Y para poder Z”
 COMO cliente de la cadena de hoteles xxxxx, QUIERO recibir ofertas en mi correo

electrónico PARA planificar mis próximas vacaciones.
 COMO usuario registrado QUIERO hacer log in PARA acceder a mis reservas.
Mal ejemplo de una Historia de Usuario

 Los clientes necesitan completar un formulario de registro hecho con jQuery para registrarse
online y activar la cláusula de LOPD para el envío de correos.
Como se podrá apreciar, esa segunda historia de usuario demasiado específica y se centra en detalles
técnicos, más que en pensar en cómo los usuarios pueden cumplir sus objetivos.
Estimación de historias de usuario con Planning

Poker
Metodologías agile » Estimación de historias de usuario con Planning Poker
5
(1)
Una técnica colaborativa, sencilla, divertida y efectiva de poder estimar historias de usuario es la de
Planning Poker. En ella todos los miembros del Equipo de Desarrollo participan activa y
colaborativamente para calcular el esfuerzo de cada item del Product Backlog.
Tabla de Contenidos
 Qué es el Planning Poker
 En qué consiste el Planning Poker
 Material necesario
 Beneficios
Qué es el Planning Poker

Planning Poker es una técnica de estimación puesta en marcha por primera vez por James
Grenning en un equipo Ágil utilizando XP en 2002.
Desde luego no tiene relación alguna con el Poker. Se utiliza una baraja de cartas con una distribución
de números muy parecida a la secuencia de Fibonacci (0, 1/2, 1, 2, 3, 5, 8, 13, etc). Existen valores muy
grandes como 20 o 40, usados para estimar historias de usuarios muy grandes, cuando en la sesión
aparezcan estos valores, la historia de usuario debería ser partida en sub-historias más pequeñas.
Se utiliza en Scrum, pero puede ser aplicado en otros contextos. Favorece la participación y
comunicación, esto último indispensable en Scrum. Además de que los miembros del equipo aprendan
unos de otros, y del producto que están desarrollando.
En qué consiste el Planning Poker

Antes de nada, es indispensable saber que se estiman historias de usuario completas. Podemos dividir
las historias de usuario en tareas más pequeñas, pero la suma del esfuerzo de las tareas es igual al de la
historia de usuario entera.
Además, hay que tener en común en qué medida se estima: Horas, puntos, o lo que se esté utilizando.
Para realizar una sesión de planning poker hay que seguir los siguientes pasos:
1. Juntar a todo el equipo en una sala (para estar aislados) y repartir las barajas a cada miembro del
equipo.
2. El product owner, o moderador, lee una historia de usuario, y responde cualquier duda que
tengan los miembros del equipo de desarrollo. Esto sirve para que todos tengan una
comprensión en común de lo que hay que desarrollar.
3. Cada miembro del equipo de desarrollo selecciona una carta, equivalente a la estimación, y la
pone boca abajo, cuando todos tengan seleccionada una carta, se ponen boca arriba todas a la
vez.
4. Una vez mostradas las cartas, nos quedamos con la estimación media más elegida, o se debate
hasta conseguir la unanimidad.
Esto se repite con cada historia de usuario que haya que estimar.
Material necesario
Para una sesión de estimación ágil es necesario lo siguiente:
 Una bajara de planning poker para cada miembro del equipo de desarrollo.
 Un “moderador”. Lo ideal es que esta persona sea el product owner, ya que se encargará de
responder cualquier duda que haya en las historias de usuario que estimemos.
 Una sala de reuniones, en donde se realizará la sesión, con una mesa redonda para que todos los
participantes estén cómodos.
El scrum master no tiene la obligación de estar en esta sesión, pero de él es responsabilidad de que
estas sesiones se realicen, y que esta práctica se expanda dentro de la organización.
Beneficios
El principal beneficio es la colaboración y comunicación dentro del equipo de desarrollo, a la hora de
estimar tareas (algo bastante tedioso, sobre todo cuando te piden que lo hagas rápido). Tener distintos
puntos de vista acerca de algo es mejor que se si hace de manera solitaria.
Poder estimar colaborativamente ayuda a detectar riesgos, que se pueden ir solventando antes de
comenzar la historia de usuario.
Estimar de manera realista es difícil según el producto y contexto, por lo que estimar entre varias
personas nos acerca al máximo a la realidad, evitando márgenes de error muy grandes que afecten al
desarrollo de producto.
Experto en Scrum, las áreas que debes trabajar

Metodologías agile » Experto en Scrum, las áreas que debes trabajar
5
(1)
Ser un experto en Scrum, y tener un equipo ágil de éxito, no es una tarea fácil. Tal y como dice Ken
Schwaber, “Scrum toma dos días de aprendizaje pero una vida para aplicarlo de manera efectiva”.
En este post vamos a analizar 4 áreas que debes trabajar cuidadosamente para poder ser un maestro en
Scrum. En resumen, debes conseguir que todo sea fácil (keep it simple), conseguir que tu equipo cambie
el chip y que tenga un mindset más ágil a la hora de introducirse en un proyecto.
Tabla de Contenidos
 Identidad del equipo
 Procesos
 Valor del producto
 Organización
Identidad del equipo

Recuerda esto: Scrum no resuelve problemas, las personas son las encargadas de eso. Lo que hace
Scrum es hacer transparentes estos problemas, para que los equipos puedan resolverlos de manera más
creativa.
Empoderar a un equipo Scrum consiste en juntar a un grupo de individuos, y convertirlos en un

conjunto, este conjunto debe tener una identidad a lo largo del tiempo.
Tener una buena identidad y personalidad en tu equipo da como resultado una auto-organización y una
colaboración muy necesaria dentro de Scrum.
Procesos
El punto anterior habla sobre la creación de un equipo, este punto habla sobre cómo deben trabajar
juntos.
Recuerda esto: Scrum no es un proceso ni una metodología, realmente es un marco de trabajo. Scrum es
un framework que brinda transparencia con sus artefactos, y oportunidades de inspección y adaptación
gracias a sus eventos. La identidad del equipo está muy relacionada en qué prácticas siguen para aplicar
este framework.
La clave está en que haya transparencia en estos procesos. El equipo debe entender cómo afecta en el
rendimiento la aplicación de estos procesos. La inspección, feedback y adaptación son claves para el
éxito dentro de un proyecto Scrum.
Valor del producto

Toda la aplicación de los procesos en un equipo con identidad se da por una razón: Construir un
producto utilizando metodologías ágiles. El producto es la razón por la que se crean equipos y por la
que harás Scrum. Por esta razón, crear un producto con valor es el foco que debe tener tu equipo.
Tienes que entender las necesidades del usuario y del cliente. Debes saber qué es lo que aporta valor, y
sobre todo cómo poder medir ese valor dentro de tu producto. Parece sencillo, pero requiere una
identidad muy trabajada el conseguir esto.
Organización
La organización es vital para construir equipos con identidad, que construyen productos de valor
siguiendo procesos ágiles. Esto se puede resumir como cultura de trabajo.
La cultura es la forma de ver las cosas, consiste en poder adaptarse a los cambios y a la evolución del
proyecto. Y esto es un pilar fundamental en Scrum.
Maximizar los beneficios de Scrum, en la mayoría de los casos, resulta en una cultura ágil de trabajo que
es muy fácil poder expandir y escalar en otras áreas. Recuerda: aplicar Scrum requiere un equipo ágil, un
cliente ágil, y sobre todo, una organización ágil.
Incremento de Producto: ¿Sprint 0, Technical

Sprint, Hardening Sprint?
Metodologías agile » Incremento de Producto: ¿Sprint 0, Technical Sprint, Hardening Sprint?
Uno de los principales problemas de no tener aprendido Scrum y su esencia al 100% es realizar Sprints
que no produzcan un incremento de producto. Un sprint debe producir un incremento
potencialmente desplegable a producción.
La Guía de Scrum define un Sprint de la siguiente manera: “El corazón de Scrum es el Sprint, es un
evento de un mes de máxima duración, donde se crea un incremento de producto, usable y
potencialmente liberable a producción”.
Muchos equipos de desarrollo piensan que un primer Sprint, de configuración de entorno de
desarrollo, es correcto de realizar. Realmente no es así, no se respeta la naturaleza de Scrum ya que
no se entrega ningún incremento de producto.
En este post revisaremos 3 de los principales problemas que tenemos al implementar Sprints sin respetar
la naturaleza de Scrum al 100%.
Tabla de Contenidos
 Sprint 0
 Technical Sprint
 Hardening Sprint
 Conclusiones
Sprint 0
El Sprint cero es comúnmente llamado al pequeño intervalo de tiempo en el que se crea la visión y una
primera versión del Product Backlog, para estimar cuándo se podría lanzar una primera release del
producto.
Desde luego esta definición no respeta Scrum y su naturaleza. Es importante tener en cuenta de que es
correcto hacer esto con el Product Backlog, el Product Owner debería hacer esto desde el momento 1.
¿Pero es necesario ponerlo dentro de un Sprint, y que forme parte del Sprint Goal?.
Technical Sprint
Este Sprint responde a un intervalo de tiempo en el que se dedica a crear el entorno de desarrollo, la
arquitectura de código para tener una guía a la hora de liberar el producto a producción en las
siguientes iteraciones.
Este es un caso aún más grave que el anterior, puesto que, además de no entregar ningún incremento
de producto, se está dedicando tiempo de un Sprint a generar un entorno de desarrollo que,
probablemente, no utilicemos en los primeros Sprints. ¿Por qué trabajar en diseñar una arquitectura para
algo que no usaremos en las primeras iteraciones?
La solución a esto es generar la arquitectura de desarrollo dentro del Sprint, pero solo de lo que se
ha definido en el Sprint Goal. Esto nos permitirá entregar un incremento de producto, que será cada
vez mayor en los siguientes Sprints, con nuestra arquitectura ya definida.
Hardening Sprint
El objetivo de este tipo de Sprint es la de estabilizar el sistema para poder hacer una release de
producto.
Es una forma muy extraña de realizar Sprints, en donde, lamentablemente, el equipo de desarrollo pierde
el foco de desarrollo de incremento, y se centra en estabilizar el sistema, dedicando una iteración
completa a solucionar problemas de lanzamiento de productos.
En casos extremos esto se tiene que realizar si o si, ya que necesitamos una arquitectura de desarrollo
estable. Sin embargo, hay que tener en cuenta de que el foco debe estar en entregar incrementos de
producto, y si hay algún problema de arquitectura, esto se debe hablar con antelación, por ejemplo en
los Daily meetings, y dedicar recursos para solucionar cualquier problema que haya. Perderemos
velocidad de desarrollo, pero nunca el foco que es entregar incremento.
Conclusiones
Estos 3 tipos de Sprints son muy comunes dentro de equipos con un nivel de madurez bajo/medio
implementando Scrum.
Es recomendable no realizarlos, ya que no respetan la naturaleza de Scrum, recordar que siempre hay
que entregar un incremento de producto, es mejor perder velocidad de desarrollo que perder el foco
del incremento.
Comunicación en equipos ágiles

Metodologías agile » Comunicación en equipos ágiles
Muchos de los problemas que pueden surgir en Scrum parten de la mala comunicación en equipos
ágiles.
Algo tan simple como girar la silla y preguntarle al compañero, evitaría que demos por supuesto algo y
tengamos que rehacer el código desarrollado por una mala interpretación de los requerimientos
funcionales o de aspectos técnicos del desarrollo.
En el Daily aprovechamos para comentar lo que hicimos el día anterior, lo que tenemos planificado para
hoy, y los bloqueos que tenemos, pero esa comunicación puede resultar insuficiente.
Ante cualquier duda debemos de preguntar a un compañero, al Producto Owner o al Scrum Master.
Si una tarea está para validar, no debemos esperar al Daily del día siguiente para avisar al validador, y si
hay duda con la priorización de tareas, conviene hacérselo saber al PO o el analista para que nos ayude.
Tabla de Contenidos
 Como podemos detectar problemas en la comunicación en un equipo Scrum
 Que podemos hacer para mejorar la comunicación en los equipos Scrum
Como podemos detectar problemas en la comunicación en un

equipo Scrum
Algunas de las alertas que nos pueden ayudar a detectar una falta de comunicación en el equipo ágil
pueden ser las siguientes:
 En el daily, los miembros del equipo no están coordinados con las tareas o no se tiene clara la
situación real.
 Las validaciones se retrasan y los validadores tienen tiempo disponible para validar.
 Las tareas realizadas no sigue la priorización establecidas con el PO.
 Se pierde mas tiempo del habitual en hacer el merge de varias tareas.
 El alcance de las tareas no se adecua a lo indicado en las mismas.
Que podemos hacer para mejorar la comunicación en los equipos

Scrum
Para mejora la comunicación en los equipos Scrum podemos realizar alguna de las siguientes acciones.
 Dinámicas para descubrir aficiones o intereses de otros miembros del equipo. Estas actividades
fomentan conocer nuevas cosas de otros miembros del equipo, lo que permite abrir el ámbito de
los temas de conversación e intereses.
 Programación en pareja (Pair Programming). Establecer varias tareas donde se sienten juntos 2
miembros del equipo para ejecutarlas.
 Actividad outsourcing. Para fomentar la comunicación. Actividades de voluntariado suelen ser
buenas en este sentido.
 Rotar los puestos de trabajo. Cambiar a los miembros del equipo de mesa, sentándolos juntos a
otros miembros del equipo ayuda a fomentar la comunicación y evitar caer en la rutina y el
temido “silencio”.
Si detectamos problemas de comunicación, debemos actuar cuanto antes. Cuanto mas tiempo pase, mas
se enquistará el problema y mas difícil será resolver los problemas causados por la falta de
comunicación.
Fomentar la comunicación ayuda al equipo a estar al día, sentirse parte de él, y anticiparse a los
problemas que puedan surgir.
Cómo gestionar la deuda técnica en Scrum

Metodologías agile » Cómo gestionar la deuda técnica en Scrum
El concepto de deuda técnica en Scrum es complejo de explicar, puesto que es algo que no se ve, pero
se siente, se sabe que está ahí, acumulándose y, desde las sombras, convirtiéndose en un problema que
puede acarrear sobreestimación, sobrecostes y muchos problemas en el equipo de desarrollo.
Tabla de Contenidos
 Un poco de historia
 Principales causas de la deuda técnica en Scrum
 Soluciones ágiles
Un poco de historia
El término surge de una analogía utilizada por Ward Cunningham, en 1992, en la que realiza una
comparación entre un desarrollo de software que presenta carencias a nivel técnico por entregarlo de
manera temprana, con la petición de un crédito financiero.
Así como el crédito permite obtener liquidez a corto plazo, a costa de generar unos intereses a liquidar
en un período de tiempo prolongado, las carencias en el desarrollo de software nos dan un entregable a
corto plazo, pero tarde o temprano requerirán gastar el tiempo inicialmente ahorrado, sumando un
esfuerzo extra (los intereses).
En resumen, las carencias en el desarrollo de software generan una deuda técnica igual a los intereses
que genera un crédito bancario.
Principales causas de la deuda técnica en Scrum

La principal causa de la deuda técnica son las presiones en fecha y planes. En muchos casos, el equipo
de desarrollo toma “atajos” para poder llegar en plazos dentro del Sprint.
Las siguientes son otras causas comunes de deuda técnica:
 Falta de colaboración, no compartir conocimientos hace que el software desarrollado no sea de

calidad.
 Falta de documentación, por no disponer de tiempo se puede perder una forma común de
desarrollar.
 Falta de comprensión, si la organización no conoce el concepto de deuda técnica, no podrá
conocer las consecuencias de desarrollar un software de mala calidad.
Soluciones ágiles
Scrum se basa en tres pilares: Transparencia, inspección y adaptabilidad. Estos pilares están presente en
todos los Sprints, y por este motivo tendremos el control sobre la deuda técnica y sus consecuencias si
seguimos algunas de estas pautas:
 Aprovechar al máximo el Daily meeting, cada día el equipo de desarrollo puede detectar de
manera rápida los posibles errores y decidir de manera ágil para evitar cualquier carencia en el
software.
 Incluir dentro de las estimaciones tareas relevantes como testeo, documentación y refactorización.
 En caso de sospechas de deuda técnica, utilizar futuros Sprints para refactorizar y no seguir
heredando problemas en el desarrollo.
 Involucrar a la organización, la mejor manera de hacer entender a directivos es con números.
Estimar las horas extras que se harían en caso de duda técnica, multiplicado por su precio en
horas funciona mucho mejor que simplemente queriendo convencer con palabras a alguien que,
de normal, solo entiende de beneficios o pérdidas económicas.
 Involucrar al Scrum Master, es la persona que se encargará de evitar la deuda técnica, y defenderá
al equipo de eventos o fechas que puedan dañar la calidad de los entregables.
 Cuidar el definition of done, cualquier factor que elimine la deuda técnica debe estar incluído, y
nunca olvidar que el DOD debe estar siempre actualizado.
Pasos para una Review exitosa en Scrum

Metodologías agile » Pasos para una Review exitosa en Scrum
No hay nada mas satisfactorio que entregar valor cuando estamos aplicando metodologías ágiles. Esto
es lo que ocurre cuando hacemos la Review del Sprint. Es en esa reunión cuando el equipo scrum
presenta la entrega del incremental de valor del producto trabajada en ese sprint a los principales
interesados.
En esa misma reunión se recibe un feedback por parte del cliente, que nos va a ayudar a ir adaptando el
producto a lo que realmente necesita. Nos vamos adaptando continuamente al cambio, orientando el
desarrollo a lo que nuestro cliente quiere.
Tabla de Contenidos
 ¿Quien debe convocar la Review en Scrum?
 ¿Cuánto debe durar la Scrum Review?
 ¿Quiénes deben asistir a la Review?
 ¿Cómo plantear una Review efectiva?
¿Quien debe convocar la Review en Scrum?

La responsabilidad de convocar a los stakeholders que son necesarios en esa Review recae en el Product
Owner, que en previsión a lo que se esta desarrollando en el sprint, convocará la reunión con suficiente
antelación.
Esta reunión se convocara el ultimo día del sprint, justo antes de su cierre.
¿Cuánto debe durar la Scrum Review?
Dependiendo de la duración del sprint, y del valor incremental del producto a entregar, se decidirá su
duración, que debería estar comprendida entre 20min-1h:30min normalmente.
Según la Guía de Scrum, para sprints de un mes, podría alargarse 4 horas, pero habría que evitar
reuniones tan largas, por la perdida de atención que puede provocar por parte de los asistentes, lo que
provocará un feedback deficiente, debido al cansancio generado por una reunión tan larga.
¿Quiénes deben asistir a la Review?

El Product Owner, que es el encargado de explicar a alto nivel cual es el incremental de valor entregado
o no entregado en el sprint y los futuros desarrollos a trabajar en los siguientes sprints.
También deben asistir los miembros del equipo de desarrollo scrum, que son los encargados de
contar y mostrar a mayor nivel el incremental de valor entregado en ese sprint del producto sobre
el que se esta trabajando y los problemas que se han encontrado.
Por parte de los clientes asistirán los interesados clave estimados por el Product Owner, que aportarán
su opinión sobre el desarrollo.
Con todo esto, se abre un pequeño debate sobre la satisfacción de los desarrollos entregados y los
entregables futuros, para alinear las necesidades del clientes al trabajo del equipo.
¿Cómo plantear una Review efectiva?

Cuanto mas original seas, y generes el mejor ambiente para la reunión, mejores resultados obtendrás.
Un Review en un sala de reuniones cerrada con todo el mundo mirando a la pantalla proyectada, y una
persona hablando, a parte de monótona, no van a ayudar a generar un entorno de confianza donde los
intervinientes se expresen con transparencia y claridad.
Para ello te recomendamos algunas de estas prácticas:
 Cambia frecuentemente el lugar de la presentación. No elijas siempre la misma sala, ni el

mismo entorno.
 Deja interactuar a los interesados que asistan a la reunión. Prepara ordenadores o dispositivos
móviles que los interesados puedan puedan manejar, para recibir opiniones de experiencia de uso
en primera persona.
 Ofrece “refrigerios” en la reunión, sobre todo si es de larga duración, para generar un entorno
distendido y de confianza.
 Haz que las diferentes reviews la hagan diferentes miembro del equipo de desarrollo, para que
todos ellos se sientan participes, y los interesados interactuen con todo el equipo, lo que ayudara
a estrechar lazos.
 Intercalar posiciones en sillas entre miembros del equipo scrum y los interesados, para generar un
entorno de equipo, no con bandos diferenciados.
 Promueve la participación de los interesados, mostrando que queremos saber su opinión.
Los 3 pilares para implantar la agilidad en

cualquier entorno empresarial
Metodologías agile » Los 3 pilares para implantar la agilidad en cualquier entorno empresarial
4.9
(8)
Que la agilidad esta aquí para quedarse es algo de lo cual nadie duda. Cada vez son más las empresas
que tratan de implantar el marco conceptual de la agilidad en su empresa, implantando marcos de
trabajo como Scrum, Kanban o Scrumban entre otros.
Los 4 pilares básicos de la agilidad son:
 Individuos e interacciones sobre procesos y herramientas.

 Software funcionando sobre documentación extensiva.
 Colaboración con el cliente sobre negociación contractual.
 Respuesta ante el cambio sobre seguir un plan.
El problema radica en adaptar estos pilares en entornos donde no hay un desarrollo de software, si no
en departamentos que ofrecen servicio a la empresa, como Recursos Humanos, Financiero, Marketing,
etc…
Es ahí donde hay que tratar de sin olvidar los pilares de la agilidad, seleccionar los principios básicos que
se pueden aplicar en esa forma de trabajo.
Pero para que todo pueda llegar a aplicarse de la forma más eficiente posible hay que trabajar 3
aspectos básicos: Planificación, Comunicación y Confianza. Si no contamos con alguno de estos factores,
la implantación del marco de trabajo ágil, corre un serio peligro de implantarse.
Vemos como puede afectar esto.
Tabla de Contenidos
 ¿Cómo afecta la planificación a la agilidad?
 ¿Es posible implantar la agilidad sin que exista comunicación?
 ¿Por qué la confianza es importante en la implantación de una metodología ágil?
¿Cómo afecta la planificación a la agilidad?

Que la agilidad tenga como pilar la respuesta ante el cambio, no quiere decir que no debamos seguir un
plan. Todo departamento debe tener una planificación a corto y medio plazo y una visión a largo plazo.
Sin esto no sabemos a donde queremos llegar, ni los medios planteados para conseguirlo. La adaptación
de esa planificación, permitiendo variar el rumbo en función de los cambios que se produzcan nos
ayudara a conseguir el objetivo marcado en nuestra planificación.
Si una empresa va “a salto de mata”, hará muy difícil conseguir establecer un plan y que este se adapte
al cambio. Debe existir un mínimo de planificación, un saber a dónde vamos, para saber qué camino
debemos tomar. Ya habrá tiempo de ir adaptándonos, iterando, y mejorando, pero sin un rumbo, el
barco va a la deriva.
¿Es posible implantar la agilidad sin que exista comunicación?

En los últimos años, se está adaptando la estructura horizontal en las empresas, con espacios amplios,
sin despachos, donde se facilita la comunicación entre equipos y con los líderes. Si en una empresa,
tenemos los departamentos separados por plantas, en habitaciones cerradas, o separados físicamente,
puede darse el caso de que existan problemas de comunicación.
Hoy en día disponemos de medios digitales, para mantener en comunicación continua a equipos
separados miles de km de distancia. Pero esa comunicación hay que alimentarla, hay que provocarla,
para evitar caer en el aislamiento de los equipos. Un equipo ágil no es un equipo aislado de la empresa,
sino una parte de la misma que participa con el resto en conseguir los objetivos empresariales.
Si es una empresa hay problema de comunicación, casi seguro que la implantación de una metodología
ágil esta avocada al fracaso.
¿Por qué la confianza es importante en la implantación de una

metodología ágil?
¿Alguien es capaz de pensar que sin confianza podemos tener equipos autosuficientes y auto
organizados? Es una de las bases fundamentales de la agilidad, la confianza en las personas, como
principio básico de los acuerdos de trabajo dentro de un equipo que practica la agilidad.
Si no somos capaces de delegar, transmitiendo confianza al equipo o a nuestros compañeros, nunca

podremos llegar a vivir una experiencia ágil plena. Las personas son la base, y sus interacciones, y si no
hay confianza, esto muy difícil va a ser posible.
Por lo tanto, antes de implantar la agilidad debemos de tratar de conseguir que en esa empresa, exista
previamente planificación, comunicación y sobre todo confianza.
Cómo definir los acuerdos de trabajo en Scrum

Metodologías agile » Cómo definir los acuerdos de trabajo en Scrum
¿Alguna vez habéis ido a la reunión de la comunidad de vecinos de vuestro edificio? Es divertido ver
como se discuten cosas que fuera de ese contexto parecerían absurdas pero que en el contexto en el
que se tratan son de relevada importancia.
Siempre y cuando no se parezcan a las de “Aquí no hay quien viva”, se acaban esas reuniones con unos
acuerdos votados y aprobados por la mayoría de los miembros de la comunidad.
Dentro de la metodología ágil ocurre algo parecido, uno de los primeros puntos a detallar son los
acuerdos de trabajo (Working agreements) para empezar esa convivencia en nuestra comunidad.
Tabla de Contenidos
 ¿Como empezamos a definir los acuerdos de trabajo?
 ¿Cuales son los acuerdos de trabajo mas comunes?
 ¿Cada cuanto debemos revisar los acuerdos de trabajo?
 Los acuerdos de trabajo, ¿son de obligado cumplimiento?
¿Como empezamos a definir los acuerdos de trabajo?

En primer lugar debemos decidir la duración del sprint. Un sprint debe durar de 1 semana a 1 mes, para
garantizar una entrega continua de producto incremental.
Es recomendable que cuando el equipo comienza con Scrum, la duración del sprint sea mas corta, y a
medida que el equipo madura y si se cree conveniente es posible que se aumente la duración del sprint.
La razón principal es que al principio viene bien revisar el trabajo del equipo de forma frecuente para ir
detectando los problemas que nos vamos encontrando e ir resolviéndolos lo antes posible, para reducir
riesgos y mejorar el desempeño del equipo.
Una vez el equipo esta maduro, podemos mantener la duración del sprint pero alargar a 2 sprints la
repetición de la reunión Retrospectiva por poner un ejemplo.
¿Cuales son los acuerdos de trabajo mas comunes?

 Duración del Sprint.
 Fechas,Hora y duración de los Eventos del Sprint (Planning, Daily, Refinamiento, Review,
Retrospectiva).
 Composición del tablón del equipo. (TO DO, WIP, DONE…)
 Software para la gestión digital del trabajo (JIRA…)
 Tipificación de las peticiones (Estratégico, Táctico, Incidencias…)
 Resto de herramientas de comunicación.
 Resto de acuerdos de trabajo (puntualidad, comunicación fluida…)
¿Cada cuanto debemos revisar los acuerdos de trabajo?
Cuando comenzamos con Scrum, los acuerdos de trabajo deben establecerse inicialmente antes de
empezar a trabajar e ir adaptándolos en los primeros 10 sprints.
Si por el desempeño del equipo o por el resultado de alguna retrospectiva es necesario modificarlos,
procederemos a ello, realizando una revisión de los cambios introducidos en los siguientes sprints para
confirmar que el cambio produjo el efecto deseado.
Los acuerdos de trabajo, ¿son de obligado cumplimiento?

Una vez definidos los acuerdos de trabajo, deben respetarse con la máxima voluntad. Suele suceder que,
por inercia, y sobre todo al principio tendemos a mover los eventos del sprint, por considerar otras
reuniones más prioritarias.
Si queremos de verdad que funcione la metodología, debemos darles el máximo valor a las reuniones,
respetar los tiempos y generar esa inercia de trabajo continuo.

Qué Es Un Sprint en Scrum

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Qué Es Un Sprint en Scrum

Загружено:

Авторское право:

Доступные форматы

¿Qué es un Sprint en Scrum?

Durante un sprint en Scrum se desarrolla el incremento de un producto, potencialmente

También podemos considerarlo como un mini-proyecto, en donde el equipo de desarrollo focaliza

Las razones de una cancelación pueden ser las siguientes:

5 grandes beneficios de los sprints tanto para equipos como

El propósito de cada sprint es crear un incremento de valor en un producto o proyecto.

Scrum es una oportunidad de entregar valor al cliente de manera ágil.

Scrum Master, todo lo que necesitas saber.

¿Qué es un Scrum Master?

¿Cuáles son sus responsabilidades?

¿Cuáles son sus funciones?

 Planificar la implantación de Scrum junto con la organización.

¿Es el Scrum Master un Project Manager?

Claves para ser un buen Scrum Master

Los errores más comunes del Scrum Master

Product Owner, Qué es y Cuáles son sus

¿Qué es un Product Owner?

¿Responsabilidades del product owner?

Entre otras, el Product Owner es responsable de:

 El retorno de inversión del proyecto.

¿Rol del product owner?

¿Quién debería ser el Product Owner?

Cualidades de un Product Owner

Claves para ser un buen Product Owner

¿Qué es el refinamiento (Refinement) del

Beneficios de refinar el Product Backlog.

Retrospectiva – ¿Qué es el Sprint Retrospective?

El sprint retrospective meeting (retrospectiva) es el último evento en un Sprint en Scrum. Es una

¿Cuál es el objetivo de la retrospectiva?

¿En qué consiste?

 Qué ha funcionado bien en el último Sprint.

¿Quiénes deben participar?

¿Cada cuánto debe realizarse el Sprint Retrospective?

¿Qué es el Product Backlog?

¿Qué es el Product Backlog?

¿Quién crea el Product Backlog?

¿Cada cuánto debo actualizar el Product Backlog?

Equipo SCRUM, Guía Completa [ACTUALIZADA

El equipo de desarrollo Scrum consiste en profesionales responsables de desarrollar incrementos de

Es un equipo estructurado y empoderado dentro de la organización para auto-organizarse y

Características del equipo de desarrollo Scrum

Responsabilidades del equipo Scrum

¿Cuál es el tamaño recomendado de un Equipo Scrum?

El tamaño recomendado es entre 3 y 9 personas. Menos de 3 difícilmente pueda ser llamado un

¿Puedo trabajar Scrum aunque mi equipo trabaje en remoto?

¿Quién debería estar en el Equipo de Desarrollo Scrum?

¿Quién es el manager del Equipo Scrum?

¿Cuántos proyectos simultáneos puede trabajar un Equipo?

¿Qué es la velocidad en el Equipo?

¿Qué es un daily meeting en scrum?

¿De qué se habla en un daily?

¿Quiénes deben estar presentes en el daily?

Beneficios de hacer el daily

¿Qué es un daily meeting en scrum?

¿Quiénes deben estar presentes en el daily?

Beneficios de hacer el daily

¿Qué es el refinamiento (Refinement) del

Beneficios de refinar el Product Backlog.

💎 Agregar valor a los items

¿Qué es el Product Backlog?

¿Qué es el Product Backlog?

¿Qué debería haber en el Product Backlog?

¿Quién crea el Product Backlog?

¿Cada cuánto debo actualizar el Product Backlog?