¿Se permiten "historias técnicas de usuarios" en Scrum?

¿Se permiten historias técnicas de usuarios en Scrum? Si es así, ¿cuál es la plantilla estándar para escribir historias técnicas de usuarios en Scrum? ¿Es lo mismo As a <user> I want to do <task> so that I can <goal>?

He leído en algunos blogs que como un desarrollador no es una historia de usuario , pero también he leído que Scrum no exige esto. Hay pocos blogs donde han compartido historias de usuarios con el sistema como usuario , es similar as a <user who is not end user> i want to <system functionality> so that <some techinical thing>. Entonces, ¿cuál es el estándar?

Por ejemplo, hay historias de usuarios como:

Como crítico, quiero subir fotos de cualquier hotel / comida para que otros usuarios puedan verlas y darles Me gusta.

Como usuario, quiero agregar comentarios de fotos para poder explicar mejor mi vista

Ahora, para ambas historias de usuarios, hay un gran elemento técnico: guardar y recuperar la imagen

Entonces, ¿puedo agregar una historia técnica titulada "Mecanismo de almacenamiento y recuperación de imágenes", con la siguiente descripción?

Como desarrollador, quiero desarrollar un mecanismo para almacenar y recuperar imágenes para que los usuarios puedan agregar / ver imágenes donde sea necesario

Las historias técnicas están permitidas, pero le aconsejaría que trate de evitarlas tanto como pueda.

Por ejemplo, su historia para guardar y recuperar imágenes se puede escribir fácilmente como dos historias de usuario normales

1. Como revisor, quiero que mis fotos cargadas se almacenen de forma persistente, para que otros usuarios puedan verlas en cualquier momento.
   (Tenga en cuenta que esto supone que en su historia de carga original, la imagen no se almacenará de forma persistente después de la carga. Aunque esto puede parecer extraño, es una forma válida de dividir las historias para hacerlas manejables).
2. Como usuario, quiero ver las imágenes cargadas en un momento que sea conveniente para mí.
   (Esto implica que las imágenes almacenadas se pueden recuperar más tarde).

Las historias técnicas deben reservarse para el trabajo que es importante para la organización, pero no directamente visible como una característica / funcionalidad para los usuarios. Por ejemplo, agregar equilibrio de carga para manejar un mayor número o solicitudes.

La pregunta, dado su ejemplo particular, sería ¿por qué un desarrollador desea desarrollar un mecanismo para almacenar y recuperar imágenes para que los usuarios puedan agregar / ver imágenes donde sea necesario, a menos que un usuario quiera agregar o ver imágenes?

Es decir, si bien su pregunta es buena, el ejemplo no lo es. Esta es una característica del usuario y debe tener una historia de usuario. Y si el usuario realmente no necesita esa funcionalidad, entonces el desarrollador no debería querer hacerlo.

Una historia técnica es más "Como desarrollador, quiero reducir la duplicación en los módulos de archivo de datos, para no tener que hacer todos los cambios en 6 lugares".

La cuestión de si estos deben incluirse en el sprint es difícil y depende un poco de a quién consideres que es tu cliente. ¿Es el usuario final, o la empresa que lo emplea, o la empresa que emplea la empresa que lo emplea?

Las personas que trabajan para empresas de consultoría realizan una gran cantidad de opiniones de la industria. Desde esa perspectiva, puedo ver el argumento de que las historias de desarrolladores son malas. Deberían ser parte de lo que haces, día a día, invisible para la empresa que lo paga. Esas compañías saben instintivamente que aumentar las facturas demasiado alto asegura que su trabajo se agote, por lo que cada desarrollador trabaja con el principio de hacer solo un desarrollo técnico que mejore su tiempo de desarrollo o su capacidad para liberar software libre de errores.

Mi experiencia es más trabajando en equipos internos, proporcionando software directamente a la empresa que paga mi salario. En muchas de esas compañías, existe una barrera de confianza entre el negocio y el ala técnica del negocio. En todos ellos, existe una mentalidad diferente, en la que la disminución de los costos es igual al aumento de los ingresos.

En esos entornos, puede ser bueno definir historias significativas para desarrolladores. Aumenta la visibilidad, genera confianza y alienta a los desarrolladores y a la administración por igual a pensar en el valor de tales tareas para el negocio y priorizar en consecuencia.

En última instancia, te sugiero que lo pruebes. Y, si no ofrece valor, deja de hacerlo.

Pero mi instinto dice que si estuvieras considerando el valor de este desarrollo para el negocio, ni siquiera hubieras tratado de convertirlo en una historia para desarrolladores. Es bueno para el usuario final o no lo es. Si no es así, no hay valor para el negocio.

Esta es una buena pregunta. No tengo una respuesta oficial, pero donde trabajo agregamos historias técnicas de usuarios y las llamamos deudas técnicas. Si no se les permitiera, encontraría alguna otra forma de agregarlos con el solo propósito de que mi trabajo sea registrado y comunicado al negocio. Del mismo modo, tener esta documentación nos recuerda lo que se necesita para futuros proyectos.

Como ejemplo, la desconexión en una nueva aplicación, si no se nos permite agregar historias técnicas, es que estaré tarareando durante una semana después del inicio de un sprint creando modelos de bases de datos y esperando que mi modelador de datos apruebe ellos, itere con el modelador y cuando termine envíe los scripts al dba y espere a que creen los objetos db. Mientras tanto, crearé un nuevo proyecto de código, algunas funciones básicas de ORM y mi diseño de control de fuente y, cuando todo esté dicho y hecho, tendré tiempo para crear una página de inicio en blanco y desplegarla.

Día a día, mientras esto sucede, si no registro la información, la empresa está afirmando que nuestro equipo no está trabajando en el proyecto cuando de hecho lo estamos haciendo. Tener estos elementos en las historias significa que podemos marcar nuestro trabajo, documentar el trabajo y comunicarle al negocio que estamos progresando.

Si hay una mejor práctica para hacer esto, soy todo oídos.

Mi sensación personal es que los equipos no deberían estar demasiado obsesionados con lo que permite el scrum y estar más preocupados por lo que funciona para el equipo. Parte de la razón por la cual el scrum ha tenido una mala reputación es que los profesionales pueden enfocarse en el proceso, lo que es antitético a las ideas detrás de la gestión ágil de proyectos.

Saldré de mi caja de jabón ahora, pero si preguntas si lo siguiente es realmente 'scrum', por favor (re) lee lo anterior.

Es importante separar las "características" que definen las historias de los usuarios y los "resultados" que el equipo técnico debe ofrecer para admitir esas características. En este caso, la necesidad de guardar y recuperar imágenes es una entrega técnica que usted (como el equipo técnico) necesita implementar. Casi todas las historias necesitarán algunos resultados técnicos.

La razón por la que esto es importante es que una entrega técnica (por sí misma) no es algo que produzca valor desde la perspectiva del usuario. Si comienza a rastrear entregas técnicas como historias de usuarios, puede caer fácilmente en la trampa de tratar la producción técnica como un valor comercial. Al ensuciar las aguas de esta manera, se confundirá el trabajo que respalda los objetivos comerciales (es decir, las cosas que cuestan dinero) con los objetivos comerciales reales (es decir, las cosas que hacen dinero).

Todas las respuestas anteriores no hacen referencia al documento fuente autorizado para el marco de Scrum: la Guía de Scrum .

El Backlog del producto enumera todas las características, funciones, requisitos, mejoras y correcciones que constituyen los cambios que se realizarán en el producto en futuras versiones.

El foco debe estar en producir valor. A veces, ese valor proviene del trabajo técnico, como la actualización de la infraestructura. ¡No excluyas esos artículos!

El término historia de usuario nunca aparece en The Scrum Guide porque

Es un marco dentro del cual puede emplear diversos procesos y técnicas.

Usar una historia de usuario es solo una técnica posible para grabar los PBI. Aunque es común ver el formato "As a, I want, So that", puede ser contrario a su intención original . Este formato problemático también se abordó en Agile 2017 .

Comprender y utilizar el corte vertical será útil para reducir el tamaño de los elementos de la Lista de Producto (PBI). Considere rebanar que solo guardar y recuperar elemento en Guardar y recuperar elemento s .