Me preguntaba si es una buena idea nombrar los Sprints con nombres fáciles de usar en lugar de usar números como Sprint 1, Sprint 2, etc. ¿Existen mejores prácticas o estándares para nombrar el Sprint según temas o hitos importantes para el proyecto?
Me preguntaba si es una buena idea nombrar los Sprints con nombres fáciles de usar en lugar de usar números como Sprint 1, Sprint 2, etc.
No, no es una buena idea.
Un sprint es un contenedor donde los elementos del Product Backlog se almacenan temporalmente por un breve período. Un sprint puede producir algunos artefactos del proyecto, pero el sprint en sí tiene valor solo como un cuadro de tiempo. Incluso si puede encontrar un caso de uso para realizar un seguimiento de los sprints por nombre, asignar etiquetas no ordinales a los sprints reduce la facilidad de comunicación y la cantidad de información transmitida por el nombre.
Un sprint es el nombre que el marco Scrum le da a una iteración de tiempo limitado. Si bien cada sprint tiene un Sprint Goal definido, el sprint en sí no es un artefacto del proyecto que deba conservarse para registros históricos o mejora de procesos.
Los sprints a menudo dan como resultado varios resultados que son relevantes para el proyecto, como mediciones de velocidad, funciones terminadas, nuevas historias de usuarios para la cartera de productos o mejoras de procesos, pero el cuadro de tiempo en sí no tiene valor duradero una vez que ha expirado. Independientemente de si se cumplió o no el objetivo del Sprint, el cuadro de tiempo anterior desaparece para siempre y se reemplaza por un nuevo cuadro de tiempo para el próximo Sprint.
Por lo tanto, dar nombres en clave o identificadores a un sprint tiene poco sentido, ya que cualquier sprint dado no debería tener ninguna utilidad como referente histórico. Intentar mapear cuadros de tiempo efímeros en eventos con nombre suele ser un olor de proyecto que indica que el modelo de desarrollo no es realmente iterativo.
Si bien cada sprint tiene un Sprint Goal y un conjunto de elementos extraídos del Product Backlog, ninguna de estas cosas es necesariamente un hito del proyecto. Los objetivos no siempre son elementos únicos y, a veces, las historias se vuelven a colocar en el Product Backlog (modificadas o sin modificar) para futuros sprints. Por lo tanto, no hay garantía de que un sprint sea realmente único.
Por ejemplo, si su sprint actual no cumple con su Sprint Goal y el propietario del producto decide tener otro sprint con el mismo objetivo, ¿podría nombrar los sprints de la misma manera? Si no, ¿"Sprint Fuschia" después de "Sprint Aquamarine" realmente le diría a alguien algo útil sobre el sprint, el proyecto o el equipo?
En el mundo de las bases de datos, el problema de las filas (potencialmente) no únicas generalmente se resuelve mediante la asignación de claves primarias de incremento automático a cada fila. Esta es una de las razones por las que Scrum generalmente usa números enteros incrementados en lugar de nombres de código o identificadores para etiquetar los sprints.
En Scrum, el principio rector es "inspeccionar y adaptar". Si bien un proyecto puede tener un cronograma con fechas de envío definidas, se espera que el contenido de cualquier sprint cambie a lo largo del proyecto. Dado que el resultado de un Sprint afecta el contenido de los Sprints subsiguientes, no tendría sentido asignar nombres de código significativos a cada Sprint en el cronograma del proyecto con anticipación, ya que el objetivo o las historias del Sprint 23 pueden cambiar para cuando el equipo termine. saca los primeros 22 sprints del camino.
Alternativamente, si usa nombres coloridos pero sin sentido, ¿qué valor ha agregado? Al menos los nombres secuenciales le brindan información de secuencia; si nombras tus carreras con nombres de árboles, mamíferos en peligro de extinción o exoplanetas, ¿qué información útil transmite eso realmente a alguien?
Dado que ya hemos establecido que los sprints son efímeros y no tienen un significado histórico (aparte de tal vez como puntos de datos de velocidad), ¿qué es lo que le gustaría comunicar sobre Sprint Koala (que fue hace tres sprints) a otra persona durante Sprint Wallaby? ? Además de como un referente abstracto, ¿cómo agregará su nombre valor a la comunicación?
A menos que esté asignando nombres de sprint en una secuencia de todos modos, y sepa que Sprint Koala fue el Sprint 23 y que Sprint Wallaby es realmente el 26, ni siquiera puede transmitir información ordinal o de tiempo sin una carga cognitiva adicional. Eso me parece lo contrario de "fácil de usar".
Si bien el nombre del sprint rara vez es útil, la cantidad de sprints en el plan del proyecto actual o el progreso actual del equipo a lo largo del eje ordinal del plan brindan cierta utilidad. Por ejemplo, se puede estimar que un plan con 25 sprints de dos semanas durará 50 semanas. Del mismo modo, es muy probable que un proyecto que tenga menos del 30 % del Product Backlog restante completado después de consumir el 50 % de las iteraciones planificadas esté fuera de tolerancia.
No sé cómo dividir una manada de gansos entre dos koalas y un lémur, por lo que estoy bastante seguro de que este tipo de nombres no brindan ningún valor en la gestión de métricas de proyectos o incluso porcentajes simples. Por el contrario, la asignación de números ordinales como etiquetas proporciona algunas funciones matemáticas útiles para monitorear y comunicar sobre su proyecto, incluso si los contenidos de los sprints pasados y futuros no se conocen ni se rastrean.
Si desea nombrar un Sprint, estoy de acuerdo con la respuesta aceptada en el hilo programmers.stackexchange.com de que debe nombrarlo después del Sprint Goal. Como Scrum Master, sigo presionando a los Product Owners para que presenten un Sprint Goal bien articulado. Siempre empiezo mis sesiones de Planificación de Sprint invitando al Propietario del Producto a declarar el Objetivo del Sprint.
Sin embargo, llegar a un Sprint Goal es la parte más difícil. Estos son algunos consejos de Roman Pichler sobre cómo identificar un Sprint Goal. Una vez que haya identificado el Sprint Goal, puede intentar extraer una versión más corta para el Sprint Name.
Hay diferentes convenciones que he visto usar. En mi opinión, incluso tener uno es completamente irrelevante, además de brindarle algo a lo que referirse en las discusiones (¡lo que puede ser algo bueno o no!)
Utilice una convención de «Sprint N» o «Iteration N»:
Pro : Generado fácilmente
Contra : ¿Alguien va a recordar lo que hizo en la iteración 23? Es casi como no nombrarlos, ya que cada sprint ya tiene un número ordinal .
Ejemplo notable : corchetes .
Use una plantilla «Sprint of dd of mmm»:
Pro : Generado fácilmente, para algunas personas el anclaje de fecha les ayuda a recordar en qué sprint se hizo algo
Contra : Es casi como no nombrarlos ya que cada sprint ya tiene una fecha de inicio
Ejemplo notable : No que se me ocurre, pero parece bastante usado
Dé a los sprints un nombre basado en el objetivo:
Pro : Hace que sea trivial recordar cuándo se hizo algo
Contra : Difícil de generar, difícil de recordar ( nombre los primeros 20 sprints de memoria )
Ejemplo notable : No que se me ocurra
Cualquier combinación de las anteriores
Con todo, este es mi mejor consejo:
Consulte también: https://softwareengineering.stackexchange.com/questions/82732/how-do-you-name-sprints-in-your-projects
No estoy seguro de cómo llegó a ser, pero en mis dos últimas empresas usamos el siguiente formato de nomenclatura de Sprint: Year+StartWeekNumber+Teamname . Dando como resultado algo como " 2016W10 Team Blue " para nuestro sprint actual.
Pero en los últimos 7 años de hacer Scrum, nunca sentí la necesidad de usar los números de Sprint después de que se completó el Sprint. Aunque a veces puede ser útil ver en qué período de tiempo se desarrolló una función en Jira.
En lugar de nombrar un sprint, definiría un objetivo de sprint claro y mantendría el nombre del sprint muy simple: http://wall-skills.com/2015/sprint-goal-focus-for-the-scrum-team/
Tengo una opinión ligeramente diferente sobre esto. Nuestro equipo ha desarrollado un enfoque (modelo de ramificación, estructura organizativa, enfoque general) que nos permite ejecutar múltiples sprints en paralelo; esto es especialmente útil para garantizar una alta utilización, de modo que nadie se quede inactivo esperando que el control de calidad termine su tarea.
La desventaja es que, en un momento dado, no sabemos qué sprint saldrá primero, por lo que la asignación de nombres ordinal o basada en fechas es inútil.
Por lo tanto, optamos por el enfoque 'colorido pero sin sentido' y nombramos nuestros sprints en honor a las lunas del sistema solar (¡hay bastantes!). Los nombres en sí mismos no transmiten nada, pero es una forma muy útil de poder hablar sobre una colección de características, mejoras y correcciones de una manera con la que todos los involucrados puedan identificarse. No estoy de acuerdo con la afirmación de que el nombre de su sprint TIENE que significar algo; en nuestro caso, es simplemente una agrupación lógica.
Hemos utilizado este sistema durante más de dos años, más de cincuenta puntos de lanzamiento, y funciona muy, muy bien.
Por ejemplo, actualmente tenemos los sprints 'Phoebe' y 'Ceres' en desarrollo: el plan del proyecto exige que Phoebe se convierta en el próximo lanzamiento puntual (1.80.0), pero no hay garantías y seguimos siendo lo suficientemente ágiles como para cambiar el orden planificado. de lanzamientos, con un impacto mínimo en la entrega. Por lo tanto, podemos encontrar problemas con Phoebe en el ciclo de control de calidad que lo retrase, y Ceres saldrá como 1.80.0 y Phoebe (¡probablemente!) se convertirá en 1.81.0.
Haciendo eco un poco de CodeGnome, también diría que nombrar los sprints es una mala idea. Son efímeros. Una vez que se ha completado un sprint, es posible que desee recopilar las historias completas en un registro para su uso posterior en la documentación del usuario, pero aparte de eso, no se gana nada al recordar un sprint en particular, y nombrarlos les daría demasiada importancia.
Lo que puede funcionar de manera más efectiva y ser un mejor enfoque para su equipo es observar los objetivos del lanzamiento del que forma parte el sprint y tener esos objetivos en mente. Tener un nombre de lanzamiento es una tradición consagrada desde antes de los métodos ágiles. Renuncia a vincular las historias de cualquier sprint a cualquier significado, sin embargo, enfatiza que todas las historias en la lista de espera para el lanzamiento son necesarias antes de declarar la victoria.
El nombre del Sprint no tiene ningún impacto o diferencia en su proceso. Pero se recomiendan números de usuario como Sprint 1, Sprint 2, etc. porque para facilitar el seguimiento.
Para un proyecto grande, puede tener 30,40 sprints. En ese caso, será difícil identificar el proyecto si le da algunos nombres elegantes. Por lo tanto, es mejor nombrarlo usando números (Sprint 1, Sprint 2, etc.).
Aunque no hay una respuesta correcta o incorrecta a esta pregunta, me ha resultado útil usar el último día del sprint como identificador único para el nombre del sprint.
Como ejemplo, si un sprint finaliza el 28/03/2016, nombraría el sprint como: Sprint 20160328
Descubrí que esto funciona muy bien para los propósitos de: (1) darle al sprint un nombre que proporcione información útil sobre el sprint en lugar de un número arbitrario (2) el uso de una fecha garantiza la singularidad dentro del contexto de un proyecto individual
Nota: Nunca entreno elementos incrustados del nombre del programa o del proyecto en el nombre del sprint en sí. Topológicamente, es más limpio dejar que el proyecto y/o programa exista en un nivel muy por encima de la etiqueta del cuadro de tiempo de trabajo.
Si tiene un proyecto dividido en hitos (1, 2 ... 5), puede nombrar los sprints dentro de cada hito para que se correspondan con el hito en el que está trabajando y el número de sprint en ese hito.
Por ejemplo, si está trabajando en el Hito 1, sus sprints pueden llamarse Sprint 1.1; Sprint 1.2; para Hito 2 - Sprint 2.1; Carrera 2.2
De esta manera, tiene un punto de referencia para un hito y la funcionalidad ejecutada.
Aconsejo no preocuparse por detalles tan pequeños. La idea de SCRUM es reducir el desperdicio y ser ágil . Encuentre una manera más simple y apéguese a ella. Utilizo el siguiente formato para no tener que pensar en nombrar.
Sprint X - De a A
dónde
Uso "Sprint N: Sprint Goal", reiniciando el conteo después de cada lanzamiento.
En la práctica, a menudo usamos solo el número, pero el número + objetivo es útil cuando se informa en una escala más larga o cuando se mira hacia atrás en los últimos meses para ver dónde hemos puesto nuestro esfuerzo al priorizar para futuros sprints.
Acabamos de comenzar con un nuevo tipo de nombre de sprint que se parece a 'YYYY-QX-X/6'.
2018-Q4-5/6.
Estamos estableciendo metas trimestrales del equipo. Este tipo de nombramiento hace sentir una fecha límite.
Trabajo con diferentes equipos y tenemos sprints paralelos para diferentes aplicaciones. Se volvió muy difícil diferenciar varios Sprints con diferentes números.
Así que implementamos la siguiente estructura para nuestros nombres de Sprint:
< Sprint > < Año > < Mes > < (Versión) >
La "(Versión)" es opcional porque aunque hacemos sprints mensuales hacemos un Release cada 3 Meses. En este caso, 3 Sprints pueden pertenecer a un Lanzamiento.
Si fuera de ayuda, también podría usar el Sprint Goal o el nombre del producto . No uso el objetivo o el nombre del producto porque mis Sprints pertenecen a un producto y eso ya está mapeado en el sistema.
Creo que un "nombre común" entre paréntesis detrás de cualquier sistema numérico no memorable que utilice está bien y es beneficioso, si no divertido. Incluso podrían correlacionarse con el número. antes: 2021W31 después: 2021W31 (Reggie)
No nombre los sprints en Scrum, ¡no tiene sentido!
¿Cuál es el valor de hacerlo? NINGUNO ¿La guía de Scrum lo recomienda o lo sugiere de algún modo? NO ¿Es parte de algún artefacto? NO
Los sprints tienen nombres porque el maldito Jira agregó esa funcionalidad, pero ciertamente y para evitar confusiones, el nombre del sprint debe ser autogenerado, 1, 2, 3, etc...
La información importante sobre el sprint ya forma parte de él y una vez que finaliza, esa información aún persiste, como el objetivo, la duración, la fecha de inicio, la fecha de finalización, etc.
Si quiero encontrar un sprint, lo haría por fecha de inicio o por meta. En definitiva, podemos comprobar una tarea de la que nos interese el sprint y comprobar el campo Sprints (en Jira), y lo podéis encontrar...
Ni el Product Owner, ni el Scrum Master, ni los desarrolladores, a nadie le importa el nombre del Sprint... ¡SOLO JIRA LO HACE!
Bijay Rungta
Tiago Cardoso
Geoff quema