The post has been translated automatically. Original language: Russian
One of the first questions a new project manager faces is: what methodology should I use? The answer "Scrum, because everyone does it" is the most common and most expensive mistake. A methodology is a tool for a specific task, not a universal standard. This article contains the selection criteria and an analysis of when something really works.
Why is the choice of methodology important at all
An incorrectly chosen methodology does not kill the project instantly, but creates constant friction: the team spends time on rituals that are not useful, the manager reports on metrics that do not reflect reality, and stakeholders do not understand when to expect results.
Three questions to ask before choosing:
- How predictable is the task flow?
- How often do priorities change?
- Is there a need for a fixed supply rhythm, or is continuous flow more important?
Scrum: when work goes in iterations
Scrum is built around sprints — fixed time periods (usually 1-2 weeks), at the end of which the team shows the finished product increment.
It is well suited when:
- The product is being developed from scratch, and there is a clear backlog of features.
- Stakeholders want regular demos and feedback points.
- The team is stable in composition and can keep a constant rhythm.
- Priorities do not change more often than once per sprint
It doesn't fit well when:
- There are a lot of unpredictable tasks from the outside (bugs, urgent requests from other departments) — they break the sprint
- The team is engaged in product support, not the development of new features.
- Priorities change daily, so planning for 2 weeks becomes meaningless.
The key metric of Scrum is velocity (the team's speed in story points per sprint). It is useful for predicting deadlines, but it is dangerous if it turns into KPIs: the team begins to overestimate estimates so that velocity looks steadily growing.
Kanban: When continuous flow is important
Kanban does not divide work into iterations. Instead, there is a board with columns (To Do → In Progress → Review → Done) and a limit on the number of tasks in operation at the same time (WIP limit).
It is well suited when:
- The team handles support, bugfixes, and operational tasks
- Tasks come unpredictably, and you need to respond quickly to them.
- The speed of completing a single task (lead time) is more important than the predictability of delivery in batches.
- The team is unstable or the tasks require different specialists at different times.
It doesn't fit well when:
- We need regular demos for stakeholders with a fixed rhythm.
- The project requires detailed planning for several weeks ahead
- The team is just forming and it needs a ritual structure to develop the habit of working together.
The key metrics of Kanban are lead time (how long a task takes from start to completion) and cycle time (time in active work). The WIP limit is not a bureaucracy, but a way to expose bottlenecks: if the limit constantly rests on the review, then the problem lies in the review process, not in the developers.
Hybrid: Scrumban and adapted approaches
In practice, most teams use something in between. A typical hybrid is Scrumban: the rhythm of sprints is preserved for planning and retrospectives, but the board and WIP limits are taken from Kanban to control the flow within the sprint.
An example of how this works: a product team that simultaneously develops new features (requires rhythm and predictability) and supports production (requires flexibility for urgent bugs). The solution is to allocate a percentage of the team's capacity (for example, 20%) for unpredictable tasks right in the sprint planning, instead of breaking the sprint with every incident.
Another frequent hybrid is Scrum rituals (daily, retro, planning) without hard sprints, with a continuous stream of tasks like in Kanban. This is suitable for mature teams that know how to prioritize themselves, but stakeholders still need a predictable synchronization rhythm.
How to make a decision in practice
A simple checklist to choose from:
| Criteria | Closer to Scrum | Closer to Kanban |
| Type of work | New development | Support, bugs |
| Predictability of tasks | High | Low |
| We need a fixed demo rhythm | Yes | No |
| Priorities are changing | Every 1-2 weeks | Daily |
| Maturity of the team | Being formed | Stable, self-organized |
If the answers are mixed on most points, this is a normal signal in favor of a hybrid, and not a reason to painfully choose one thing.
A common mistake: changing methodology as a solution to all problems
When something goes wrong in a team - deadlines are falling short, motivation is falling, technical debt is growing — the temptation to change the methodology is great: "maybe if you switch to Kanban, it will become easier." In most cases, the problem is not with the framework, but with how it is applied: there is no real prioritization of the backlog, retrospectives are formal, and WIP limits are not met.
Before changing the methodology, it is worth honestly assessing whether the current tools have been used as intended.
Conclusion
Methodology is a way to make the flow of work visible and manageable, not ritual for ritual's sake. Scrum provides predictability and structure where work is broken down into understandable iterations. Kanban provides flexibility where the flow of tasks is unpredictable. Hybrid approaches are often closer to the reality of most IT teams than the pure forms of any of the frameworks.
У продакт-менеджера почти всегда бэклог больше, чем ресурсов команды. Вопрос не в том, что делать, а в том, что делать в первую очередь — и от ответа зависит, вырастет ли продукт или команда полгода потратит на фичи, которые никто не заметит.
Интуитивная приоритизация («это выглядит важным») работает плохо: она подвержена искажению в пользу того, кто громче попросил — обычно это последний разговорившийся стейкхолдер или самый настойчивый клиент. Фреймворки приоритизации существуют, чтобы сделать процесс воспроизводимым и объяснимым, а не для того чтобы заменить суждение продакта математикой.
RICE: когда нужно сравнивать разнородные идеи числом
RICE расшифровывается как Reach, Impact, Confidence, Effort — и даёт единый скор для сравнения идей между собой.
RICE score = (Reach × Impact × Confidence) / Effort
- Reach — сколько пользователей затронет фича за период (например, за квартал)
- Impact — насколько сильно повлияет на каждого затронутого пользователя (обычно шкала 0.25 / 0.5 / 1 / 2 / 3)
- Confidence — насколько команда уверена в оценках Reach и Impact (в процентах: 50% / 80% / 100%)
- Effort — сколько человеко-месяцев потребует разработка
Хорошо подходит, когда:
- Нужно сравнить десятки разнородных идей (новая фича, техдолг, улучшение онбординга) в одном списке
- В команде есть хоть какие-то данные — аналитика, воронки, число активных пользователей
- Приоритизация происходит регулярно (например, раз в квартал) и нужна повторяемая процедура
Слабое место: Confidence легко превращается в способ подогнать скор под желаемый результат — если фича нравится, ей ставят Confidence 100%, если нет — 50%. Без явного проговаривания, на основе чего выставлена оценка, RICE превращается в театр объективности поверх субъективного решения.
MoSCoW: когда нужно зафиксировать границы релиза
MoSCoW делит требования на четыре категории:
- Must have — без этого релиз не имеет смысла
- Should have — важно, но не блокер
- Could have — приятно, если время останется
- Won't have (this time) — явно исключено из текущего скоупа
Хорошо подходит, когда:
- Есть жёсткий дедлайн релиза, и нужно явно провести границу «входит / не входит»
- Идёт переговоры со стейкхолдерами о скоупе, и нужен язык, на котором проще договориться, чем в терминах баллов и формул
- Проект в духе fixed-scope/fixed-date (например, регуляторный дедлайн, интеграция к конкретной дате партнёра)
Слабое место: MoSCoW не даёт способа сравнивать две вещи внутри одной категории — если пять фич попали в Must have, а ресурсов хватает на три, фреймворк сам по себе не подскажет, какие три выбрать. На практике «Must have» имеет свойство расширяться, если нет дисциплины ограничивать эту категорию.
Kano: когда важно понять, что реально радует пользователей
Модель Kano классифицирует фичи по тому, как они влияют на удовлетворённость пользователя:
- Base (must-be) — отсутствие вызывает недовольство, наличие не радует (например, работающий логин)
- Performance — чем больше, тем лучше, линейная зависимость удовлетворённости (скорость загрузки, точность поиска)
- Delighters (excitement) — отсутствие не замечают, наличие вызывает восторг (неожиданно удобная фича, которую не просили)
- Indifferent — пользователю всё равно, есть фича или нет
Категории определяются через опрос пользователей: для каждой фичи задают два вопроса — «как вы отреагируете, если фича есть?» и «как вы отреагируете, если её нет?» — и по комбинации ответов фича попадает в одну из категорий.
Хорошо подходит, когда:
- Продукт зрелый, базовые ожидания пользователей уже закрыты, и нужно понять, куда инвестировать для роста удовлетворённости
- Есть возможность провести опрос пользователей (даже небольшой выборки)
- Стоит вопрос не «что делать», а «на что делать акцент» — на устранение раздражителей или на создание восторга
Слабое место: Kano требует данных от реальных пользователей и времени на опрос — это не инструмент для быстрого еженедельного приоритетного списка, а скорее периодическое стратегическое упражнение.
Как выбрать: не фреймворк ради фреймворка
Три фреймворка решают разные задачи, и путаница чаще всего возникает, когда пытаются одним инструментом ответить на вопрос, для которого он не предназначен.
| Вопрос, на который нужен ответ | Подходящий фреймворк |
| Что из длинного списка идей делать в первую очередь | RICE |
| Что точно должно быть в релизе к дате X | MoSCoW |
| На какую категорию фич делать ставку для роста удовлетворённости | Kano |
На практике многие команды комбинируют: RICE — для ежеквартальной приоритизации бэклога, MoSCoW — для финальной фиксации скоупа релиза, Kano — как периодическое исследование раз в полгода-год, чтобы откалибровать интуицию команды о том, что пользователи считают базовым, а что — вау-эффектом.
Частая ошибка: фреймворк как замена решению
Ни один из этих инструментов не принимает решение за продакта. RICE-скор — это структурированный вход для обсуждения, а не автоматический вывод, которому нужно слепо следовать. Если после расчёта RICE топ списка выглядит контринтуитивно — это повод перепроверить оценки Reach/Impact/Confidence, а не повод игнорировать здравый смысл или, наоборот, слепо следовать числу вопреки ему.
Фреймворк даёт язык для разговора со стейкхолдерами — «эта фича набрала более высокий RICE-скор, потому что затрагивает всех пользователей, а не только premium-сегмент» звучит убедительнее, чем «мне так кажется». Но финальное суждение остаётся за продактом, который видит контекст, не помещающийся в формулу: стратегические договорённости, технические ограничения, политику компании.
Вывод
RICE, MoSCoW и Kano — не конкурирующие подходы, а инструменты для разных моментов жизни продукта: сравнение идей, фиксация скоупа релиза и понимание эмоционального отклика пользователей. Выбор фреймворка начинается не с вопроса «какой лучше», а с вопроса «на какой вопрос мне сейчас нужен ответ».
Share
