[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"general-list":3,"footer-feature-tags":4,"slate-glossary-term-planning-poker":66},true,[5,14,20,29,34,40,46,52,56,62],{"id":6,"name":7,"hex":8,"translations":9,"count_pages":13},8,"Компания","#f40925",{"ru":10,"en":11},{"name":7},{"name":12},"Company",9,{"id":15,"name":16,"hex":17,"translations":18,"count_pages":6},26,"Главная страница",null,{"ru":19},{"name":16},{"id":21,"name":22,"hex":23,"translations":24,"count_pages":28},2,"Проекты","#3027ff",{"ru":25,"en":26},{"name":22},{"name":27},"Project",15,{"id":30,"name":31,"hex":17,"translations":32,"count_pages":21},33,"ИИ",{"ru":33},{"name":31},{"id":35,"name":36,"hex":17,"translations":37,"count_pages":39},34,"Комментарии",{"ru":38},{"name":36},4,{"id":41,"name":42,"hex":17,"translations":43,"count_pages":45},25,"Задачи",{"ru":44},{"name":42},24,{"id":47,"name":48,"hex":17,"translations":49,"count_pages":51},27,"Рабочие пространства",{"ru":50},{"name":48},3,{"id":45,"name":53,"hex":17,"translations":54,"count_pages":6},"Kanban-доска",{"ru":55},{"name":53},{"id":57,"name":58,"hex":17,"translations":59,"count_pages":61},23,"Диаграмма Ганта",{"ru":60},{"name":58},1,{"id":28,"name":63,"hex":17,"translations":64,"count_pages":61},"Календарь",{"ru":65},{"name":63},{"detail":67,"more":217},{"id":68,"slug":69,"translations":70,"category":83,"tags":90,"letter":114,"og_image":17,"cover":17,"author_name":17,"author_position":17,"author_avatar":17,"faqs":115,"related":147,"views_count":213,"helpful_yes_count":118,"helpful_no_count":118,"created_at":214,"updated_at":215,"published_at":216},409,"planning-poker",{"ru":71},{"title":72,"short_definition":73,"tldr":74,"full_explanation":75,"when_to_apply":76,"when_not_to_apply":77,"examples":78,"tips":79,"synonyms":80,"translation_en":72,"seo_title":81,"seo_description":82},"Planning Poker","Техника групповой оценки задач в agile-командах: участники одновременно показывают карты с числами, обсуждают расхождения и приходят к консенсусу.","Каждый участник независимо выбирает карту с оценкой — вскрытие одновременное, чтобы исключить эффект якорения.\nРасхождения в оценках — повод для обсуждения: именно здесь выявляются скрытые риски и разное понимание задачи.\nПо точности Planning Poker сопоставим с Bucket System и Affinity Estimation, но выигрывает за счёт выравнивания понимания в команде.\nЭффективная сессия: 4–7 участников, 30–45 минут; если сессии регулярно растягиваются — сигнал к пересмотру формата или декомпозиции задач.\nФибоначчи-колода — стандарт для story-level оценки; T-shirt sizes лучше подходят для ранней оценки эпиков.","\u003Ch2>Что такое Planning Poker и как он работает\u003C\u002Fh2>\u003Cp>Planning Poker — техника групповой оценки трудоёмкости пользовательских историй и задач. Каждый участник держит колоду карт с числами (чаще всего ряд Фибоначчи: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89) и дополнительными картами «?» и «∞». Фасилитатор зачитывает или показывает задачу, команда задаёт уточняющие вопросы, затем каждый \u003Cem>одновременно\u003C\u002Fem> кладёт карту на стол рубашкой вверх. По команде все карты переворачиваются.\u003C\u002Fp>\u003Cp>Ключевое отличие от открытого обсуждения — одновременное вскрытие. Оно устраняет \u003Cstrong>эффект якорения\u003C\u002Fstrong>: никто не слышит чужую цифру до того, как сделал собственный выбор. Если оценки совпали или близки, команда фиксирует результат и переходит к следующей задаче. Если разброс велик — участники с крайними оценками объясняют свою позицию, после чего проводится повторное голосование. Итерации продолжаются до консенсуса.\u003C\u002Fp>\u003Cp>Метод описан Майком Коном в книге «\u003Ca href=\"\u002Fglossary\u002Fagile\u002F\" data-term-slug=\"agile\">Agile\u003C\u002Fa> Estimating and Planning» (2005) и с тех пор стал стандартом де-факто в \u003Ca href=\"\u002Fglossary\u002Fscrum\u002F\" data-term-slug=\"scrum\">Scrum\u003C\u002Fa>-командах. Agile Alliance включает Planning Poker в официальный глоссарий как наиболее распространённый способ назначения \u003Ca href=\"\u002Fglossary\u002Fstory-point\u002F\" data-term-slug=\"story-point\">story points\u003C\u002Fa>.\u003C\u002Fp>\u003Ch2>Почему главная ценность — не точность, а согласованность\u003C\u002Fh2>\u003Cp>Распространённое заблуждение: Planning Poker нужен, чтобы точно предсказать сроки. Исследование Molokken-Ostvold и Haugen «An Empirical Study of Using Planning Poker for \u003Ca href=\"\u002Fglossary\u002Fuser-story\u002F\" data-term-slug=\"user-story\">User Story\u003C\u002Fa> Estimation» (AGILE 2006, ACM DL) на 101 пользовательской истории XP-команды показало, что Planning Poker улучшает точность оценки в большинстве случаев по сравнению с неструктурированной групповой оценкой — при этом ошибки росли лишь на задачах с экстремально большим или малым объёмом.\u003C\u002Fp>\u003Cp>Академическое сравнение Planning Poker, Bucket System и Affinity Estimation (Stensrud et al., опубликовано в серии работ по agile effort estimation) показывает: после адаптации участников к методам \u003Cstrong>статистически значимой разницы по точности между тремя техниками нет\u003C\u002Fstrong>. При этом Bucket System и Affinity в среднем занимают вдвое меньше времени на большом бэклоге.\u003C\u002Fp>\u003Cp>Реальная сила Planning Poker — в другом. Принудительное обсуждение расхождений выравнивает понимание задачи: разработчик, тестировщик и аналитик нередко оценивают одну историю в 2 и в 13 — не потому что один из них ошибается, а потому что видят разный объём работы. Именно это расхождение нужно обнаружить \u003Cem>до\u003C\u002Fem> спринта, а не в середине него.\u003C\u002Fp>\u003Cp>По данным State of Agile Report (Digital.ai), около 81% agile-практиков используют story points как основную единицу оценки, а Planning Poker — самый распространённый способ их назначения. Команды со структурированными техниками оценки стабильно сообщают о более высокой уверенности в спринтовых обязательствах по сравнению с командами без формализованного процесса.\u003C\u002Fp>\u003Cp>Промышленное исследование Jørgensen и Shepperd «A Systematic Review of Software Development Cost Estimation Studies» (IEEE TSE, 2007) относит Planning Poker к методам, снижающим индивидуальные смещения оценок за счёт структурированного группового взаимодействия — эффект, который не достигается ни индивидуальной экспертной оценкой, ни простым усреднением.\u003C\u002Fp>\u003Ch2>Оптимальный формат сессии: участники, длительность, частота\u003C\u002Fh2>\u003Cp>Практические рекомендации Майка Кона и данные из открытых отчётов по использованию инструментов planning poker сходятся на следующем \u003Cstrong>эффективном формате\u003C\u002Fstrong>:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Участники:\u003C\u002Fstrong> 4–7 человек — достаточно для разнообразия перспектив, не слишком много для управляемой дискуссии. При большем числе участников время на обсуждение расхождений растёт нелинейно.\u003C\u002Fli>\u003Cli>\u003Cstrong>Длительность:\u003C\u002Fstrong> 30–45 минут на сессию. Сессии длиннее 60 минут — сигнал: либо задачи недостаточно декомпозированы, либо команда обсуждает решение вместо оценки объёма работы.\u003C\u002Fli>\u003Cli>\u003Cstrong>Частота:\u003C\u002Fstrong> 3–4 раза в месяц, как правило в середине спринта — для оценки бэклога следующего спринта.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>Если сессии регулярно выходят за 60 минут, рассмотрите асинхронный режим: участники выставляют оценки заранее в онлайн-инструменте, синхронная встреча нужна только для обсуждения расхождений. Это особенно актуально для распределённых команд.\u003C\u002Fp>\u003Ch2>Шкалы и колоды: Фибоначчи, T-shirt sizes, степени двойки\u003C\u002Fh2>\u003Cp>Колоды на основе Фибоначчи — стандарт де-факто в большинстве команд. Возрастающие интервалы отражают нарастающую неопределённость: разница между 1 и 2 значима, разница между 20 и 21 — нет. Это вынуждает команду делать реальный выбор, а не искать «среднее».\u003C\u002Fp>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Шкала\u003C\u002Fth>\u003Cth>Когда подходит\u003C\u002Fth>\u003Cth>Ограничения\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Фибоначчи (1–89)\u003C\u002Ftd>\u003Ctd>Story-level оценка в зрелых командах\u003C\u002Ftd>\u003Ctd>Может пугать новичков большими числами\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>T-shirt sizes (XS–XXL)\u003C\u002Ftd>\u003Ctd>Ранняя оценка эпиков, \u003Ca href=\"\u002Fglossary\u002Froadmap\u002F\" data-term-slug=\"roadmap\">roadmap\u003C\u002Fa>-планирование\u003C\u002Ftd>\u003Ctd>Сложнее агрегировать в \u003Ca href=\"\u002Fglossary\u002Fvelocity\u002F\" data-term-slug=\"velocity\">velocity\u003C\u002Fa>\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Степени двойки (1, 2, 4, 8, 16…)\u003C\u002Ftd>\u003Ctd>Команды с техническим бэкграундом\u003C\u002Ftd>\u003Ctd>Меньше градаций в малом диапазоне\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Линейная (1–10)\u003C\u002Ftd>\u003Ctd>Простые задачи с низкой неопределённостью\u003C\u002Ftd>\u003Ctd>Провоцирует «усреднение» оценок\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003Cp>Карты с низкими значениями (1–5) составляют подавляющее большинство оценок в типичных командах — это нормально: хорошо декомпозированный бэклог состоит преимущественно из небольших историй. Высокие оценки (13 и выше) — сигнал к дополнительной декомпозиции задачи перед спринтом.\u003C\u002Fp>\u003Ch2>Planning Poker vs. альтернативы: когда переключаться\u003C\u002Fh2>\u003Cp>Planning Poker — не единственный инструмент, и не всегда лучший. Вот сравнение с основными альтернативами:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cstrong>Bucket System:\u003C\u002Fstrong> задачи распределяются по «вёдрам» (числа Фибоначчи на столе), команда быстро раскладывает истории. Сопоставимая точность при значительно меньших затратах времени — особенно эффективен при оценке 30+ элементов за сессию.\u003C\u002Fli>\u003Cli>\u003Cstrong>Affinity Estimation:\u003C\u002Fstrong> задачи группируются по относительному размеру без явного голосования. Быстрее Planning Poker, хорошо работает для первичной оценки большого бэклога на старте проекта.\u003C\u002Fli>\u003Cli>\u003Cstrong>Wideband Delphi:\u003C\u002Fstrong> итеративная экспертная оценка с анонимными раундами. Исследование по промышленным кейсам (Jørgensen, 2004) показывает, что Planning Poker даёт более точные оценки затрат, чем Wideband Delphi, при сопоставимых временных затратах на небольших бэклогах.\u003C\u002Fli>\u003Cli>\u003Cstrong>Индивидуальная экспертная оценка:\u003C\u002Fstrong> быстрее всего, но подвержена систематическим смещениям и не создаёт общего понимания задачи в команде.\u003C\u002Fli>\u003C\u002Ful>\u003Cp>\u003Cstrong>Практическое правило:\u003C\u002Fstrong> Planning Poker оправдан при малом бэклоге (до 15–20 историй за сессию) и особенно ценен для новых команд или при работе с незнакомой предметной областью. При оценке 30+ элементов или зрелой команде с устойчивой velocity — рассмотрите Bucket System или Affinity Estimation.\u003C\u002Fp>","\u003Cul>\u003Cli>Команда оценивает бэклог перед спринтом и нужно выровнять понимание объёма задач между разработчиками, тестировщиками и аналитиками.\u003C\u002Fli>\u003Cli>Задачи новые или нетипичные — высок риск, что участники видят разный объём работы.\u003C\u002Fli>\u003Cli>Команда только формируется или работает с незнакомой предметной областью: структурированное обсуждение расхождений ускоряет выработку общего языка оценки.\u003C\u002Fli>\u003Cli>Бэклог сессии небольшой — до 15–20 историй; при большем объёме сессия затянется.\u003C\u002Fli>\u003Cli>Важно зафиксировать не только оценку, но и аргументы: Planning Poker создаёт естественный повод для обсуждения рисков и допущений по каждой задаче.\u003C\u002Fli>\u003C\u002Ful>","\u003Cul>\u003Cli>Бэклог содержит 30+ элементов за одну сессию — Bucket System или Affinity Estimation дадут сопоставимую точность за вдвое меньшее время.\u003C\u002Fli>\u003Cli>Команда зрелая, работает в одной предметной области давно и оценки стабильно совпадают — накладные расходы на голосование не оправданы.\u003C\u002Fli>\u003Cli>Задачи технически однородны и хорошо известны команде (например, типовые баг-фиксы с понятным объёмом) — достаточно индивидуальной оценки или референсных историй.\u003C\u002Fli>\u003Cli>Нет времени на синхронную встречу: Planning Poker требует одновременного участия, асинхронный формат работает хуже без дополнительной фасилитации.\u003C\u002Fli>\u003Cli>Команда использует #NoEstimates или flow-метрики (cycle time, throughput) вместо story points — метод теряет смысл без целевой единицы измерения.\u003C\u002Fli>\u003C\u002Ful>","\u003Cp>\u003Cstrong>Кейс 1. XP-команда, система заказа домашнего broadband\u003C\u002Fstrong>\u003Cbr>Контекст: команда перешла от неструктурированной групповой оценки к Planning Poker. Исследователи Molokken-Ostvold и Haugen проанализировали 101 пользовательскую историю до и после перехода (AGILE 2006, ACM Digital Library). Что сделали: ввели стандартную процедуру Planning Poker с колодой Фибоначчи, одновременным вскрытием и обязательным обсуждением расхождений. Результат: точность оценки улучшилась в большинстве случаев; ошибки выросли лишь на задачах с экстремально большим или малым объёмом. Дополнительный эффект — команда стала задавать больше уточняющих вопросов по требованиям до начала разработки.\u003C\u002Fp>\u003Cp>\u003Cstrong>Кейс 2. Две компании из телеком- и финансовой отрасли, оценка стоимости проектов разработки ПО\u003C\u002Fstrong>\u003Cbr>Контекст: исследование Jørgensen (2004) сравнивало экспертную оценку, Planning Poker и Wideband Delphi на проектах по разработке заказного программного обеспечения в двух промышленных компаниях — телекоммуникационной и финансовой. Что сделали: в обеих компаниях применили структурированные техники групповой оценки вместо неформальной экспертной оценки на реальных проектах. Результат: Planning Poker показал более точные оценки затрат, чем Wideband Delphi, и снизил финансовые риски проектов. Авторы отмечают, что ключевой механизм — принудительная независимость первичных оценок, которая снижает групповое смещение.\u003C\u002Fp>","\u003Cp>\u003Cstrong>Совет от Shtab:\u003C\u002Fstrong> перед сессией Planning Poker создайте в Shtab представление бэклога с фильтром по полю «Story Points» — оставьте только задачи, где это поле пустое. Во время сессии открывайте каждую задачу, вносите согласованную оценку прямо в поле Story Points карточки и переводите задачу в статус «Готово к спринту». Так результаты оценки не теряются в заметках фасилитатора, а сразу становятся частью планирования спринта — и следующая сессия начнётся с актуального незаоценённого остатка.\u003C\u002Fp>","покер планирования, scrum poker, estimation poker, poker planning","Planning Poker: что это и как проводить сессию","Planning Poker — техника групповой оценки задач в agile. Механика, шкалы, оптимальный формат сессии и сравнение с Bucket System и Affinity Estimation.",{"id":61,"slug":84,"hex":85,"icon":17,"order":61,"translations":86},"agile","#5e79ec",{"ru":87},{"title":88,"description":89},"Agile","Гибкие методологии разработки и управления проектами: Scrum, Kanban, XP и их элементы — спринты, бэклоги, церемонии, роли.",[91,99,107],{"id":92,"slug":93,"kind":94,"hex":95,"order":92,"translations":96},5,"ceremony","phase","#3a5fff",{"ru":97},{"title":98},"Церемония",{"id":100,"slug":101,"kind":102,"hex":103,"order":100,"translations":104},7,"estimation","tool","#cc5649",{"ru":105},{"title":106},"Оценка",{"id":108,"slug":109,"kind":94,"hex":85,"order":110,"translations":111},11,"planning",12,{"ru":112},{"title":113},"Планирование","P",[116,123,129,135,141],{"id":117,"order":118,"translations":119},2043,0,{"ru":120},{"question":121,"answer":122},"Какие карты используются в Planning Poker и почему именно числа Фибоначчи?","\u003Cp>Стандартная колода включает числа Фибоначчи (1, 2, 3, 5, 8, 13, 21, 34, 55, 89), карту «?» (неопределённость) и «∞» (задача слишком большая для оценки). Фибоначчи выбран не случайно: возрастающие интервалы отражают нарастающую неопределённость при оценке сложных задач. Разница между 1 и 2 значима и обсуждаема, разница между 20 и 21 — нет. Это вынуждает команду делать реальный выбор вместо поиска «среднего» и снижает иллюзию точности на больших задачах.\u003C\u002Fp>",{"id":124,"order":61,"translations":125},2044,{"ru":126},{"question":127,"answer":128},"Сколько времени должна занимать сессия Planning Poker?","\u003Cp>Практические рекомендации Майка Кона и данные по реальному использованию инструментов сходятся на 30–45 минутах для сессии из 4–7 участников с бэклогом до 15–20 историй. Если сессии регулярно выходят за 60 минут — это сигнал: либо задачи недостаточно декомпозированы, либо команда обсуждает техническое решение вместо оценки объёма. В таких случаях помогает ограничение времени на обсуждение каждой задачи (таймбокс 5–7 минут) или переход к Bucket System для первичной сортировки.\u003C\u002Fp>",{"id":130,"order":21,"translations":131},2045,{"ru":132},{"question":133,"answer":134},"Можно ли проводить Planning Poker онлайн и асинхронно?","\u003Cp>Онлайн — да, и это стандартная практика для распределённых команд: инструменты вроде PlanningPoker.com, Scrumpoker-online или встроенные модули в Jira воспроизводят механику одновременного вскрытия в браузере. Асинхронный режим работает хуже: главная ценность метода — живое обсуждение расхождений, которое теряется при разнесении голосования и дискуссии во времени. Компромисс: асинхронное голосование плюс короткая синхронная встреча только для задач с большим разбросом оценок.\u003C\u002Fp>",{"id":136,"order":51,"translations":137},2046,{"ru":138},{"question":139,"answer":140},"Чем Planning Poker отличается от Wideband Delphi?","\u003Cp>Оба метода используют итеративное анонимное голосование для снижения группового смещения, но есть принципиальные различия. В Wideband Delphi оценки собираются письменно и анонимно между раундами, фасилитатор агрегирует их без прямой дискуссии — это снижает социальное давление, но замедляет процесс. Planning Poker предполагает немедленное публичное обсуждение расхождений после вскрытия карт. Исследование Jørgensen (2004) показало, что Planning Poker даёт более точные оценки затрат, чем Wideband Delphi, на промышленных проектах — предположительно за счёт более богатого обмена информацией в ходе дискуссии.\u003C\u002Fp>",{"id":142,"order":39,"translations":143},2047,{"ru":144},{"question":145,"answer":146},"Что делать, если оценки участников сильно расходятся раунд за раундом?","\u003Cp>Устойчивый разброс — диагностический сигнал, а не сбой метода. Чаще всего он означает одно из трёх: задача недостаточно описана (нет acceptance criteria), участники оценивают разные вещи (один — разработку, другой — разработку плюс тестирование плюс деплой), или задача слишком большая и требует декомпозиции. Правильная реакция — не усреднять и не давить авторитетом, а выяснить, что именно каждый включает в свою оценку. Если после двух раундов консенсуса нет — зафиксируйте задачу как требующую уточнения и вернитесь к ней после доработки описания.\u003C\u002Fp>",{"related":148,"parent":195},[149,155,162,168,175,182,188],{"id":110,"slug":150,"translations":151},"story-point",{"ru":152},{"title":153,"short_definition":154},"Story Point (стори-поинт, очки сложности)","Относительная единица оценки сложности и трудоёмкости пользовательской истории.",{"id":156,"slug":157,"translations":158},28,"refinement",{"ru":159},{"title":160,"short_definition":161},"Backlog Refinement (уточнение бэклога)","Регулярная встреча команды для уточнения, оценки и дробления историй в бэклоге продукта.",{"id":13,"slug":163,"translations":164},"velocity",{"ru":165},{"title":166,"short_definition":167},"Velocity (скорость команды)","Среднее число Story Points, которое команда закрывает за один спринт.",{"id":169,"slug":170,"translations":171},6,"user-story",{"ru":172},{"title":173,"short_definition":174},"Пользовательская история (User Story)","Краткое описание требования глазами пользователя по формуле «как [роль], я хочу [действие], чтобы [польза]».",{"id":176,"slug":177,"translations":178},176,"delegation-poker",{"ru":179},{"title":180,"short_definition":181},"Delegation Poker (7 уровней делегирования)","Игра-инструмент Йоргена Аппело для прозрачного обсуждения уровня делегирования между руководителем и командой.",{"id":100,"slug":183,"translations":184},"product-backlog",{"ru":185},{"title":186,"short_definition":187},"Product Backlog (бэклог продукта)","Упорядоченный по приоритету список всего, что может появиться в продукте.",{"id":189,"slug":190,"translations":191},21,"definition-of-ready",{"ru":192},{"title":193,"short_definition":194},"Definition of Ready (критерии готовности к спринту)","Перечень условий, при выполнении которых задачу можно брать в спринт.",[196,203,209],{"id":197,"slug":198,"translations":199},14,"sprint-planning",{"ru":200},{"title":201,"short_definition":202},"Sprint Planning (планирование спринта)","Встреча в начале спринта, на которой команда выбирает задачи и собирает бэклог спринта.",{"id":21,"slug":204,"translations":205},"scrum",{"ru":206},{"title":207,"short_definition":208},"Scrum","Гибкий фреймворк разработки продуктов короткими итерациями — спринтами — с фиксированными ролями, артефактами и встречами.",{"id":61,"slug":84,"translations":210},{"ru":211},{"title":88,"short_definition":212},"Семейство гибких подходов к разработке продуктов и управлению проектами, основанное на коротких итерациях и быстрой адаптации к изменениям.",16,"2026-09-03T21:20:44.157321+03:00","2026-09-03T21:20:44.157358+03:00","2026-09-03T21:20:44.295499+03:00",[218,239,258],{"id":61,"slug":84,"translations":219,"category":221,"tags":224,"letter":237,"cover":17,"updated_at":238,"published_at":17},{"ru":220},{"title":88,"short_definition":212,"translation_en":88},{"id":61,"slug":84,"hex":85,"icon":17,"order":61,"translations":222},{"ru":223},{"title":88,"description":89},[225,230],{"id":61,"slug":226,"kind":226,"hex":85,"order":61,"translations":227},"methodology",{"ru":228},{"title":229},"Методология",{"id":6,"slug":231,"kind":232,"hex":233,"order":6,"translations":234},"concept","other","#4b5370",{"ru":235},{"title":236},"Концепция","A","2026-04-25T22:42:14.793028+03:00",{"id":240,"slug":241,"translations":242,"category":247,"tags":250,"letter":237,"cover":17,"updated_at":257,"published_at":17},22,"acceptance-criteria",{"ru":243},{"title":244,"short_definition":245,"translation_en":246},"Acceptance Criteria (критерии приёмки)","Конкретные проверяемые условия, которым должна соответствовать пользовательская история, чтобы её приняли как выполненную.","Acceptance Criteria",{"id":61,"slug":84,"hex":85,"icon":17,"order":61,"translations":248},{"ru":249},{"title":88,"description":89},[251],{"id":39,"slug":252,"kind":232,"hex":253,"order":39,"translations":254},"artifact","#888ca0",{"ru":255},{"title":256},"Артефакт","2026-04-25T22:42:15.380450+03:00",{"id":259,"slug":260,"translations":261,"category":266,"tags":269,"letter":279,"cover":17,"updated_at":280,"published_at":17},10,"burndown-chart",{"ru":262},{"title":263,"short_definition":264,"translation_en":265},"Burndown chart (диаграмма сгорания)","График, который показывает, сколько работы осталось в спринте или релизе по дням.","Burndown chart",{"id":61,"slug":84,"hex":85,"icon":17,"order":61,"translations":267},{"ru":268},{"title":88,"description":89},[270,273],{"id":39,"slug":252,"kind":232,"hex":253,"order":39,"translations":271},{"ru":272},{"title":256},{"id":169,"slug":274,"kind":274,"hex":275,"order":169,"translations":276},"metric","#0F9488",{"ru":277},{"title":278},"Метрика","B","2026-04-25T22:42:15.056246+03:00"]