Без чего бэклог не будет работать?
Прежде чем пытаться "чинить" процессы управления бэклогом продукта, нужно поработать над тем, что бэклог содержит.
Сегодня хочу рассказать о ключевом моменте, который применим и необходим для любого элемента бэклога. А именно... Каждый элемент бэклоге должен иметь в описании критерии приемки.
Что значит "критерии приемки"? Это НЕ список задач и НЕ набор тест-кейсов. Это образ конечного результата, сравнение с которым, поможет понять, сделано ли необходимое.
Что-то вроде "пользователь может найти Х, введя в строку название или его часть".
То есть описание того, как изменится что-то в способе взаимодействия с продуктом.
Разумеется, мы предполагаем, что в этом месте не будет "игр" в сделать ровно как написано. При этом, конечно, считаем, что таким описанием дело не ограничится.
Но это будут уже детали реализации, а не новые элементы бэклога. То есть не решение владельца продукта, а результат проработки команды.
Тут, правда, есть риск, что такие элементы бэклога будут гигантами на месяцы работы. И, как с любым риском, с ним надо работать. Как?
Учить владельца продукта декомпозиции и помогать в этом всеми способами.
Помогать! А не вот это вот "пусть они...". Делать какую-то часть этой работы, например, предлагать варианты на основе последовательности реализации. Или подсвечивать пограничные случаи. Да много всего, что знают люди с опытом разработки, чего уж скромничать...
И вот таким образом бэклог начнет работать, пусть и не будучи полностью управляемым.
Вдохновляйтесь и пробуйте!
