Должны ли задачи дизайна быть пользовательскими историями?

Но прежде чем их можно будет реализовать, необходимо спроектировать систему: необходимо спроектировать архитектуру, спроектировать базу данных, выбрать технологии для графического интерфейса пользователя и бизнес-логики.

Не совсем согласен с этим. Поскольку история — это функция, которая затрагивает почти каждый уровень вашей архитектуры, реализация истории одновременно создает архитектуру. Посмотрите определение ходячего скелета Алистера Кокберна.

О вопросе

Большинство историй, которые вы можете определить как «Как пользователь…», как особенность истории, также могут работать с пользовательским интерфейсом. Поэтому, чтобы было понятно, вы можете разделить историю на подзадачи. Хотя некоторые работы было бы сложно представить в пользовательских историях INVEST. Например, ошибки, тех. отдел и так далее. Они по-прежнему представляются как истории особого типа (ошибки, технические истории). вы не можете показать их на демо, как бы вы ни упоминали.

(...) before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic. (...)

Не совсем. Например, вам не нужно получать всю базу данных, предназначенную для реализации функций для спринта, конкретного выпуска или любого другого времени. Что вам может понадобиться, так это найти общий язык.

Именно здесь живет одна из красавиц Agile (в отличие от водопада), приветствующая перемены.

Теперь, отвечая на ваш вопрос: поймите, что роль в пользовательской истории не обязательно является ролью конечного потребителя. Это могут быть ваши разработчики, ваши системные администраторы и т. д. Таким образом:

AS A server administrator,
I WANT to upgrade our webserver
SO THAT it will handle better the memory consumption

Таким образом, вы можете спросить убедить своего почтового оператора в том, что добавить или расставить приоритеты в бэклоге пользовательскую историю (или несколько), чтобы заложить основу для будущего развития. Но, опять же, при создании таких историй помните о ценности Agile Реакция на изменения.

P.S.

Также важно, чтобы Бэклог Продукта был ясным и доступным, а также обеспечивалось надлежащее взаимодействие между P.O. и команда разработчиков. Этим должен руководить Скрам-мастер.

Таким образом, команда могла бы дать лучшую обратную связь/предупредить PO, с технической точки зрения, как одна история влияет друг на друга и почему история X должна быть сделана до истории Y.