Хорошая, ставшая уже почти классикой, книжка по теории и практике проведения глубинных интервью с пользователями - одной из основ Customer Development. Написано (переведено?) бодро и доходчиво, воды мало, примеры из жизни почти все к месту.

Основные тезисы книги собрал в отдельном посте

Уже довольно старая, но не утратившая актуальности, электронная книжка с общим обзором основных agile-методологий и принципов. Как я люблю: коротко, ёмко, минимум воды, концентрат знаний. Отличный вариант, чтобы освежить память.

Что характерно, она практически по пунктам отвечает на все претензии к scrum, высказанные Селиховкиным в "Черной книге скрам".

Забавная холивар-книга в стиле дневника менеджера, драматически прошедшегося по всем граблаям и слабостям (настоящим и мнимым) скрам при его внедрении в компании. Вызвала небольшую бурю в профильных agile-сообществах.

User story (пользовательская история) - это краткое описании функции, выполняемой продуктом, с точки зрения персоны (пользователя с определенными характеристиками). Записывается по формуле "Как (персона пользователя) я (действие/цель), чтобы (результат)".

Job story - это описание функции, выполняемой продуктом, с точки зрения контекста ситуации, в которой оказался пользователь, и его мотивации, а не персоны. Записывается по формуле "Когда (описание ситуации), я (мотивация), чтобы (результат).

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

См. также Use case vs. user story

Дополняя свой пост 3-летней давности тезисами из публикации Alexander Tvar "Как писать User Story".

У хорошей юзер стори как правило:
- один actor
- одно действие
- одна ценность (value / impact)

При написании user story имеет смысл перейти с понятия ценности (value) на влияние (impact). История не обязательна должна иметь ценность, но обязательно должна оказывать влияние на актора, указанного в истории.

Классический INVEST-критерий оценки удачной юзер стори:
- Independent. Reduced dependencies = easier to plan
- Negotiable. Details added via collaboration
- Valuable
- Estimable. Too big or too vague = not estimable
- Small. Can be done in less than a week by the team
- Testable. Good acceptance criteria