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.