¿Deben las historias de usuario entregarse oralmente?

Con Agile, es una buena idea pensar primero en términos de los resultados que desea y luego pensar en los métodos que puede usar para lograr esos resultados.

Al seguir un enfoque ágil, queremos ofrecer un excelente software, pero también estar preparados para manejar los cambios que puedan surgir. Una cosa que puede ayudar con esto es no invertir demasiado tiempo agregando detalles a los requisitos hasta que estén cerca de ser trabajados. También reconocemos que para responder bien al cambio necesitamos una buena comunicación y un buen entendimiento compartido.

La idea de las historias de usuario es ayudar a lograr estos resultados. Podemos crear una historia de usuario con una sola línea de texto. Esto hace que la historia del usuario sea liviana y fácil de entender (por el propietario del producto, las partes interesadas, etc.). Sin embargo, en algún momento queremos que el equipo de desarrollo cree la característica y necesitarán más información.

Aquí es donde entra en juego el enfoque ágil justo a tiempo : agregamos detalles a la historia justo antes de comenzar a construir la función. El tiempo es algo con lo que el equipo experimenta hasta que siente que tiene un equilibrio cómodo entre ser capaz de adaptarse al cambio y garantizar que el desarrollo de características funcione sin problemas.

Una forma típica de agregar detalles a una historia es tener una o más conversaciones entre el propietario del producto y el equipo de desarrollo. Este proceso bien puede incluir agregar detalles escritos (por ejemplo, criterios de aceptación, diseños de UX, etc.).

Sin embargo, la gerencia cree que somos un brillante ejemplo de práctica ágil.

Su equipo de gestión cree que al adoptar métodos ágiles se vuelven ágiles. Han leído que una historia de usuario es solo una línea de texto y que las conversaciones son más importantes que la documentación detallada. Sin embargo, no han pensado en por qué estas cosas son importantes o no estarían usando su enfoque actual.

Entonces, ¿qué puedo pedir razonablemente en el mundo real de las empresas que siguen las mejores prácticas ágiles?

Hay empresas ágiles de alto perfil (como Spotify y Salesforce) y numerosas empresas menos conocidas que siguen un enfoque ágil genuino.

Tiene la opción de buscar estas empresas o intentar fomentar un enfoque más ágil en su empresa actual. Si elige quedarse, me concentraría en hacer que piensen (y midan) los resultados, en lugar de seguir ciegamente métodos ágiles.

Una historia de usuario es una promesa de una conversación.

Esta famosa frase fue dicha por uno de los autores del Manifiesto Ágil, Alistair Cockburn*. Entonces, sí, una historia de usuario puede ser de una sola línea .

Pero, ¿no se supone que las historias deben ser específicas y de alcance, refinadas junto con los desarrolladores (listas para trabajar, para abordar la ambigüedad) y tener criterios de aceptación claramente definidos (definición de hecho)? ¿Y tal vez una especificación de UX/capturas de pantalla/dibujos de bocetos?

Estos no son argumentos mutuamente excluyentes. La clave es cuando en el tiempo sucede cada uno. El gerente de producto puede escribir una sola línea, como una promesa de conversación , tener esta conversación con el equipo y luego, juntos , expandir esta línea en una lista de criterios de aceptación acordados.

Los marcos ágiles, en general, no son prescriptivos a propósito . Permite que cada equipo explore la mejor manera de implementarlo. Es triste que la mayoría de los lugares traten de imitar lo que hacen otros lugares, olvidándose de que cada empresa, cada contexto, cada persona es única.

Leí en alguna parte que el 95% de las empresas utilizan un enfoque ágil de bricolaje "híbrido", lo que parece una buena manera de decir que "hacemos las reglas sobre la marcha". Nuestras prácticas actuales no funcionan para mí, y me pregunto si el problema es mío o si las prácticas no siguen las recomendaciones.

Esto es cierto y sucede más de lo que debería. Sin embargo, es importante saber que esto sucede porque las personas pueden pasar a personalizar el marco sin entender completamente por qué el marco sugiere algunas prácticas. Comprender ShuHaRi puede ayudar a comprender el problema que enfrentan varios equipos: se mueven hacia Ha, antes de obtener el Shu.

Los profesionales y autores sugieren expandirse sobre los marcos conocidos . Ya no estarás haciendo Scrum, por supuesto. Pero aún puede ser ágil a su manera.

*También hay un tweet de él hablando de eso, pero el enlace está roto.

Sumario rápido

Mi empresa actual tiene todas las historias de usuarios y tareas escritas en una sola línea de texto. Todos los detalles son entregados oralmente por Scrum Master / Team Lead, quien tiene discusiones separadas con el Product Owner sin los desarrolladores.

Pero, ¿no se supone que las historias deben ser específicas y de alcance, refinadas junto con los desarrolladores (listas para trabajar, para abordar la ambigüedad) y tener criterios de aceptación claramente definidos (definición de hecho)?

Para responder al núcleo de su pregunta, las historias de usuario (si se usan) no deben consistir únicamente en títulos de una sola línea, a menos que se expliquen por sí mismos y los detalles adicionales no sean necesarios para una comunicación efectiva sobre el elemento de trabajo. Gran parte del resto de su pregunta huele a un antipatrón de implementación de marco, ya que implica una falta de colaboración y comunicación de todo el equipo, pero enfoco la mayor parte de mi respuesta en sus preguntas sobre cómo formatear, refinar, hablar y (lo que es más importante) utilizar los elementos pendientes.

Metodología para esta respuesta

Dado que su pregunta se etiquetó específicamente como scrum , proporciono una respuesta Scrum canónica junto con algunas prácticas efectivas basadas en mi propia experiencia profesional. También abordé el uso de elementos del Backlog del Sprint y del Producto, las historias de usuarios como una forma de representar los elementos del Backlog y la intención detrás del uso de las historias de los usuarios (a diferencia de las especificaciones u otros formatos) para crear marcadores de posición de conversación que aumenten la efectividad del Los fundamentos de control empírico del marco, como el diseño emergente, la planificación justo a tiempo y los bucles de retroalimentación de inspección y adaptación.

Los marcos "ágiles" de otras franjas a menudo aprovechan Scrum o prácticas similares a Scrum, por lo que esto también debería ser aplicable a esos marcos. Sin embargo, los marcos que no sean Scrum pueden usar una definición diferente de historias de usuario o manejar los retrasos y el refinamiento de manera diferente. En tales casos, su millaje puede variar.

Historias de usuarios

Scrum no requiere "historias de usuario" en absoluto. Requiere elementos de Product Backlog (PBI), aunque en la práctica la mayoría de los equipos de Scrum usan historias de usuario como las define Mike Cohn en su libro User Stories Defined o en el formato Connextra de uso común . Sin embargo, el Equipo Scrum (y más específicamente el Product Owner) puede usar cualquier formato deseado y útil para el Product Backlog.

Según la Guía Scrum 2020 :

Los elementos de la Lista de Producto que puede realizar el Equipo Scrum dentro de un Sprint se consideran listos para la selección en un evento de Planificación de Sprint. Suelen adquirir este grado de transparencia después de las actividades de refinación. El refinamiento de la cartera de productos es el acto de desglosar y definir aún más los elementos de la cartera de productos en elementos más pequeños y precisos. Esta es una actividad continua para agregar detalles, como una descripción, orden y tamaño. Los atributos a menudo varían con el dominio del trabajo.

Los Desarrolladores que estarán haciendo el trabajo son responsables del dimensionamiento. El propietario del producto puede influir en los desarrolladores ayudándolos a comprender y seleccionar compensaciones.

En lo que respecta al marco Scrum , eso es todo lo que hay que decir sobre el tema. Por supuesto, años de implementación han llevado a algunas consideraciones adicionales.

Los PBI deberían descomponerse antes de la planificación de Sprint

Un PBI simplemente debe ser un elemento almacenado en el Product Backlog. El Dueño del Producto administra el Product Backlog, aunque puede recibir aportes de las partes interesadas u otros miembros del Equipo Scrum.

De manera pragmática, las historias cerca de la parte superior de un Product Backlog ordenado deben cumplir con alguna "Definición de Listo" antes de la Planificación de Sprint. Este es el elemento principal de la agenda para el Refinamiento del Backlog, que no es un evento formal en la Guía Scrum 2020, pero que, sin embargo, es una práctica extremadamente común. Durante el refinamiento de la cartera de pedidos, todo el equipo de Scrum trabaja en conjunto para ayudar a desglosar las épicas y los temas de los elementos de la cartera de productos a corto plazo en elementos más adecuados para la planificación de Sprint. Eso generalmente incluye descomponerlos en elementos más pequeños, más comprobables y mejor definidos de acuerdo con los principios de la regla nemotécnica INVEST .

Las historias de usuario son marcadores de posición de conversación

Independientemente del formato, los PBI, los elementos de Sprint Backlog y las historias de usuarios están destinados a ser informativos , pero en realidad siguen siendo solo marcadores de posición de conversación.

Por ejemplo, normalmente les digo a los equipos que una buena historia de usuario debe identificar:

1. Qué se debe hacer (en un nivel orientado a objetivos) para contribuir a un Incremento cohesivo según lo definido por el Sprint Goal actual. Según la Guía Scrum 2020:

   El Sprint Goal es el único objetivo del Sprint. Aunque el Sprint Goal es un compromiso de los desarrolladores, brinda flexibilidad en términos del trabajo exacto necesario para lograrlo. El Sprint Goal también crea coherencia y enfoque, alentando al Equipo Scrum a trabajar en conjunto en lugar de en iniciativas separadas.

2. Los desarrolladores construyen un Sprint Backlog a partir de los PBI y determinan cómo cumplirán el Sprint Goal.

   • El objetivo del Sprint, los elementos del Product Backlog seleccionados para el Sprint, más el plan para entregarlos, se denominan juntos Sprint Backlog.

   • El Sprint Backlog se compone del Sprint Goal (por qué), el conjunto de elementos del Product Backlog seleccionados para el Sprint (qué), así como un plan procesable para entregar el Incremento (cómo).

   • Aunque el Sprint Goal es un compromiso de los desarrolladores, brinda flexibilidad en términos del trabajo exacto necesario para lograrlo. El Sprint Goal también crea coherencia y enfoque, alentando al Equipo Scrum a trabajar en conjunto en lugar de en iniciativas separadas.

Los marcadores de posición admiten flujos de trabajo de diseño emergente y justo a tiempo (JIT)

Tenga en cuenta que, aunque Sprint Backlog contiene un plan sobre cómo los desarrolladores planean cumplir con Sprint Goal, Scrum es un marco empírico que se basa en gran medida en el diseño emergente y la planificación JIT. Como resultado, el plan no tiene que contener especificaciones detalladas o detalles exhaustivos. En cambio, las buenas historias de usuario suelen contener:

1. Una definición clara de Terminado para el elemento de trabajo que cubre todo lo que no forma parte de la Definición más amplia de Terminado que se aplica a todo lo que entrega el Equipo Scrum.
2. Un conjunto bien definido de consumidores de valor y colaboradores, cuando sea posible. Los suplentes comunes, como roles, personas u otros identificadores similares, ayudan a los desarrolladores a planificar y coordinar el trabajo, y les permiten comunicarse con el trabajo en progreso para garantizar que lo que se está construyendo durante la iteración tenga las entradas correctas, recursos externos, y finalmente es apto para su uso. Además de la colaboración continua con el Equipo Scrum, estas son las conversaciones que los elementos del Backlog deben identificar claramente como marcadores de posición para conversaciones adicionales justo a tiempo a lo largo del Sprint.
3. Una declaración de valor clara para proporcionar pautas, alcance e intención a los desarrolladores a medida que planifican el trabajo. Sin la parte de por qué , a menudo hay docenas de formas de implementar una función determinada. La declaración de valor (en formato Connextra, esta es la declaración "para que...") ayuda al equipo a elegir entre varias rutas de implementación para cumplir con el objetivo definido de la manera más eficaz y eficiente.

Dado que estos tipos de elementos pendientes son realmente marcadores de posición, el nivel de detalle puede variar. Si todos en el equipo ya saben lo que implica "ampliar el widget", no tiene mucho valor escribir una historia de usuario larga para documentar los detalles. Por otro lado, "hacer que el frobnicator sea más fácil de usar" realmente no dice lo suficiente sobre lo que eso significa, quién se ve afectado (¿amigable para quién , exactamente?), o cuál es el problema con el frobnicator actual o cómo los desarrolladores saben que han cumplido el objetivo de la iteración actual .

Marcadores de posición de conversación Crear aceptación y colaboración

Debido a que Scrum es iterativo e incremental, construir lo que se solicitó pero no lo que se necesita es menos común que los marcos que se basan en un gran diseño inicial con especificaciones detalladas. Aún así, sin una colaboración continua dentro del equipo y con las partes interesadas o los usuarios finales, el objetivo debe ser aprovechar los marcadores de posición de conversación para que suceda con menos frecuencia y ayude a garantizar que todos sepan que participaron en lo que se entregó en esta iteración . Si resulta que no es adecuado para su propósito, o necesita reelaboración o refinamiento, entonces eso sale en las Revisiones de Sprint y otras conversaciones fuera del marco, y vuelve al proceso de Product Backlog.

Para eso están los bucles de retroalimentación del marco. Los marcadores de posición de conversación solo ayudan a reducir el radio de explosión de los errores cometidos al tratar las "historias de usuarios" como especificaciones grabadas en piedra.

Con diversos grados, todas las empresas son disfuncionales de una forma u otra (y algunas más que otras), pero todos piensan que lo están haciendo bien y elegante. Por supuesto que no lo son.

Lo mismo aplica para Agile. Todos ahora están "haciendo" Agile (principalmente la variante Scrum , o SAFe si está "haciendo" Agile a escala) y todos piensan que lo están haciendo bien y elegante. Por supuesto que no lo son.

Agile no es algo que haces, es una forma de pensar, es algo que eres . No es una norma ISO que establece una fórmula para que la apliques, o un proceso con pasos bien definidos que debes seguir... y listo, resultado garantizado.

Para ser ágil, tienes que pensar. Y muchos no quieren pensar.

Para ser ágil, tienes que cambiar. Y muchos no quieren cambiar.

Buscan alguna solución enlatada (por ejemplo, Scrum, SAFe) y la siguen como zombis que se arrastran tras el olor a sangre. No piensan en lo que están haciendo y no se ven a sí mismos haciéndolo.

Agile se trata de "inspeccionar y adaptar", pero rara vez veo personas inspeccionando o adaptando.

Para que Agile tenga éxito, la alta dirección debe respaldar la adopción y crear un entorno propicio para Agile. Pero no lo hacen. Porque no quieren cambiar (siguen planificando anualmente, o quieren una hoja de ruta detallada de seis meses en forma de diagrama de Gantt , o documentos de requisitos de 100 páginas cada uno firmados por tres gerentes diferentes para su aprobación, y plazos establecidos en un fecha en el futuro por alguien que ni siquiera está involucrado en el desarrollo del producto, etc.) y no quieren pensar (¿Está funcionando lo que estamos haciendo? ¿Sí? ¿No? ¿Qué estamos haciendo bien? ¿Qué estamos haciendo? ¿no tan bien?, ¿cómo sabemos distinguir entre los dos, etc.).

Desafortunadamente, Agile se ha convertido en una palabra de moda y ahora todos usan esta palabra (junto con muchos otros cambios en el vocabulario con palabras nuevas como Scrum Master, Product Owner, Squad, Chapter, Epic, User Story, Story points, etc.). Pero eso significa ponerse en cuclillas si está atrapado en una mentalidad rígida y realmente no quiere cambiar.

Entonces, lo que estás describiendo me parece disfuncional. Y no importa qué palabras quiera usar la empresa para describir lo que está haciendo, eso no lo hace menos disfuncional.

No estás describiendo Scrum, o Agile para el caso. Y no, las historias de usuarios no deben entregarse oralmente.

Puede iniciar una conversación oralmente, pero luego necesita capturar más detalles de una forma u otra para compartir con otros (usted dio algunos ejemplos) simplemente porque las personas olvidan o entienden las cosas de manera diferente. Y si todo sucede de boca en boca, incluso si por algún milagro construyes lo que se necesita, el código será la única fuente de información escrita y no muchos podrán leer el código (especialmente porque mencionas al 50% de los gerentes dentro del equipo, que es otro configuración extraña para algo considerado Agile).

Como dije, en un grado u otro, todas las empresas son disfuncionales en su implementación Agile. Solo tienes que trabajar para aquellos que lo son menos que otros. A veces puedes descubrir cuán disfuncionales son en la entrevista, haciendo las preguntas correctas. Pero lamentablemente, muchas veces solo descubres lo disfuncionales que son después de haber trabajado allí por un tiempo.

EDITAR: después de que se actualizó la pregunta.

¿Cuánto detalle debe ser escrito y explícito? ¿O es completamente razonable que todos los detalles permanezcan implícitos, almacenados en la memoria colectiva del equipo?

Depende de la historia. Algo como "Como usuario, quiero iniciar sesión en la aplicación..." probablemente quedará como una sola línea, donde los detalles pueden ser algo como "usar los mejores estándares de la industria". Por otro lado, una característica que requiere calcular primas de seguro con descuentos y bonificaciones de lealtad probablemente necesitará especificaciones muy detalladas, en las que dedique algo de tiempo por adelantado para aclarar las cosas, escribirlas y asegurarse de que se entiendan correctamente incluso antes de escribirlas. una línea de código.

Agile dice : "Software de trabajo sobre documentación completa", por lo que la documentación en Agile se crea según sea necesario (o justo a tiempo) y con los detalles suficientes para respaldar la comprensión compartida de lo que se necesita construir. Algunas características necesitan menos detalles antes de construirlas, otras necesitarán más. No hay una regla donde trazar la línea. Pero ten en cuenta que producir más de lo necesario puede generar desperdicio, ya que o bien abandonas la documentación una vez que ha cumplido su propósito, por lo que querrás invertir menos en este tipo de actividad si la tiras a la basura; o tiene que mantenerlo actualizado mientras construye el producto, y si hay mucho, requerirá mucho esfuerzo para mantenerlo actualizado). Así que mucho sentido común necesita estar involucrado aquí; necesitas pensar, experimentar con las cosas, inspeccionar y adaptarte.

Los tableros de Scrum a menudo se representan con solo notas adhesivas. Y, presumiblemente, esas notas adhesivas se desechan cuando finaliza el sprint. Entonces, ¿estos equipos mantienen la documentación por separado o no tienen ninguna?

Esos son "marcadores de posición" para rastrear y administrar las actividades en el Sprint actual. Las notas adhesivas se tiran al final del Sprint, pero no retienen toda la conversación que tuvo lugar, o todos los detalles y el material recopilado o construido para respaldar esa conversación y el entendimiento compartido. Entonces sí, la documentación se almacena por separado. Muchos equipos usan herramientas como Jira o Confluence que retienen los detalles y realizan un seguimiento de ellos. Incluso si tiene un tablero físico, las notas adhesivas generalmente contienen solo un título breve y una identificación para el problema de Jira que puede usar para averiguar todos los demás detalles.

Entonces, ¿qué puedo pedir razonablemente en el mundo real de las empresas que siguen las mejores prácticas ágiles?

Primero, tienes razón. Lo que describes no es Scrum. Ni siquiera por las pocas reglas que tiene Scrum. Como jugar al fútbol con doce personas y una motosierra por equipo, está cerca , pero también terriblemente mal . No eres tú, son ellos.

Hay suficientes empresas haciendo Scrum correctamente. O no hacer Scrum en absoluto y encontrar su propia manera de hacerlo. Lo cual está bien, también. Scrum no es una panacea. Scrum no pretende serlo. Lo único que pide Scrum es no llamarlo Scrum si no sigues las reglas. E incluso esa simple regla parece no haber sido seguida en su empresa.

En su próxima entrevista de trabajo, haga preguntas . Deje que le describan su "Scrum". No tomará a la República Popular Democrática de Corea como una república democrática o para su gente, así que no crea ciegamente lo que una empresa le dice sobre "Scrum". Que lo describan. Hacer preguntas. Una entrevista es una calle de doble sentido. Ellos deciden si quieren contratarte, tú decides si vale la pena trabajar para ellos . Usa ese poder. No trabajes para una empresa en la que no quieras trabajar.

Esas empresas existen. Necesitas encontrarlos.