4️⃣ Оцениваемая



История должна быть доступной для оценки затрачиваемых для неё ресурсов: усилий проектной команды в человекочасах.



❗️Не рекомендуется, чтобы одна пользовательская история превышала 80 часов разработки — большие и трудозатратные истории менее гибкие к изменениям.



Их границы могут со временем расширяться засчёт добавления новых требований, влияния изменений других процессов и так далее.





Проектной команде будет сложно оценить размер истории, если:

🔹ей не хватает знаний о предметной области или технологиях проектирования;

🔹история слишком объёмная.



Отслеживайте, чтобы в историях, которые вы описываете, не было «слепых пятен» или длинных конструкций.





👎 Как пользователь администраторского ПО, я хочу указывать статьи ДДС, проводки, а также коррекспондирующие счета в разделе «Бухгалтерия» для грамотного проведения оплат внутри системы.



👍 Как пользователь администраторского ПО, я хочу фиксировать движение денежных средств внутри компании, согласно Федеральному закону о бухгалтерском учёте.





В первой истории указана специализированная терминология. По сути, каждую указанную единицу нужно описывать отдельной историей. Но вторая история даёт ссылку на законодательство, в котором указаны все правила и сущности, на основании которых следует реализовать историю.



🤖Кстати, часть истории с указанием цели в этом случае можно опустить, ведь соблюдение законодательства уже является целью.