Разбивка User Story - Техническое задание + User Feature

Моя команда создает веб-приложение со следующей пользовательской историей высокого уровня:

Как пользователь, я хотел бы иметь возможность массово исключать компоненты из определенной страны.

Работа распадается на две отдельные задачи.

  1. Создайте функцию веб-приложения, исключающую компоненты по странам.
  2. Компонент Fetch - данные об ассоциации страны на ежедневной основе

Сначала я начал разбивать это на две пользовательские истории. Однако вторая задача не совсем вписывается в типичный формат пользовательской истории. Я начал писать что-то вроде этого:

В качестве системы я буду анализировать данные о странах из фида XYZ.

С одной стороны, эта задача не ориентирована на пользователя. С другой стороны, возможность извлечения данных по компонентам и странам — это четко определенная задача с вертикальными срезами, которую можно проверить независимо.

Какова правильная разбивка пользовательской истории для этого типа сценария? Неуместно ли иметь пользовательскую историю, ориентированную на систему?

Зачем вообще нужно разделять? Похоже, что получение данных о стране будет частью действия по их исключению.
@Daniel Я подумываю разделить его на части, потому что каждый элемент представляет собой хорошо инкапсулированную часть функциональности, и любая оценка требует отдельного обзора каждой независимой функции.

Ответы (3)

Обратите внимание на букву «V» в мнемонике INVEST .

PBI должен приносить пользу заинтересованным сторонам.

Спросите себя: сама по себе возможность анализировать данные о стране из фида XYZ представляет какую-либо ценность для заинтересованных сторон проекта?

Если да: хорошо, разделите его. Если нет: нет, оставьте его как есть (или, возможно, разделите его каким-либо другим способом, который не сделает INVEST недействительным.

Примечание: «Система», вероятно, не является заинтересованной стороной проекта.

Стоит отметить, что Саров использует термин PBI, а не user story. Компьютер ничего не хочет, поэтому он не должен быть «кто» в пользовательской истории. Либо выясните, кто на самом деле этого хочет, либо не используйте пользовательскую историю. Scrum не говорит, что все PBI должны быть пользовательскими историями. Это может показаться догмой, но такая практика действительно снижает ценность пользовательских историй.

Задачи Sprint Backlog не являются пользовательскими историями по своей сути

Вы путаете пользовательские истории и задачи. Элементы Бэклога Продукта часто начинаются как пользовательские истории в Бэклоге Продукта, но Scrum не требует формата пользовательской истории. Эти Элементы Бэклога Продукта импортируются в Бэклог Спринта во время Планирования Спринта. На этом этапе истории часто дорабатываются, а дополнительные истории и задачи, связанные с запланированной работой, часто генерируются на протяжении всего спринта.

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

  1. Потребителем ценности часто является команда, потому что детали реализации служат команде или системе, а не пользователю.
  2. Вне команды не может быть разговора, потому что команда является потребителем задачи.
  3. Часто разговор вообще невозможен. Обычно к тому времени, когда что-то декомпозируется до уровня «Я разберу X из Y», команда уже провела обсуждение планирования и дизайна вокруг реализации и разработала тесты для запланированной работы.

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

Я согласен с тем, что ежедневная выборка БД может быть задачей, которая является частью запрошенной пользовательской истории.

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

Задача выборки из БД не приносит никакой пользы пользователю, но приносит пользу покупателю за счет снижения стоимости реализации пользовательской истории.

Разбивка User Story - Техническое задание + User Feature
СпросиСетьПолитика конфиденциальности1y, 0v