Описание должно быть необходимым и достаточным.
- Необходимым — не должно быть пересечений между задачами в описании. Разработчик должен понимать, какую именно часть задачи ему сейчас реализовывать.
- Достаточным — у разработчика не только не должно появиться дополнительных вопросов, но и возможности понять что-то не так. Избегайте двусмысленности в задачах.
Текст задачи должен понять любой новый разработчик на проекте. Нужно осознавать, что разработчики хуже понимают контекст проекта, чем менеджеры, вряд ли присутствовали при формировании ТЗ, разработки дизайна и т.д., а впервые видят описание необходимого обновления. Полезно написать, зачем вообще добавляется эта фича и почему она нужна пользователю - тогда у разработчика появятся понимание, что он делает, и, возможно, предложения для улучшения пользовательского опыта.
Не забудьте описать:
● как попасть в раздел, в который вносится доработка, если это не очевидно;
● что необходимо сделать с учетом специальных обработок для крайних кейсов, если таковые есть;
● указать, было ли ранее в приложении реализована схожая функциональность для переиспользования;
● указать, планируется ли в будущем переиспользование, что нужно предусмотреть для этого;
● что требуется для реализации — макеты, ключи доступа, инвайты и т.д.;
● указать, какие данные используются, откуда они получаются, как обрабатываются.
Если данные получаются при каком-то условии, то его надо обязательно указать
● какие запросы будут дергаться;
● как будет использоваться результат задачи, в том числе, как его сохранить и передать для другой задачи;
● есть ли задачи, которые следует связать с текущей;
● надо ли добавить аналитику по этой функции;
Описание должно учитывать платформенные особенности, не допустите ошибочных расхождений в одинаковой функциональности.