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.
«Сколько это займёт времени?» — вопрос, на который менеджер проекта отвечает чаще всего и ошибается чаще всего. Исследования индустрии год за годом показывают одно и то же: большинство IT-проектов выходят за изначальные сроки. Проблема не в том, что разработчики плохо оценивают, а в том, что сама природа оценки в IT работает не так, как кажется на первый взгляд.
В этой статье — почему классические подходы к оценке сроков дают сбой и что делать вместо этого.
Почему оценки почти всегда оптимистичны
Есть когнитивное искажение, которое называется planning fallacy — склонность недооценивать время на задачу, даже когда у человека есть опыт похожих задач в прошлом. Разработчик, которого просят оценить фичу, мысленно представляет себе идеальный сценарий выполнения: код пишется без багов, тесты проходят с первого раза, требования не меняются. На практике так не бывает почти никогда.
К этому добавляется эффект скрытой работы: код-ревью, доработки после ревью, интеграция с другими частями системы, документация, деплой, фикс багов, которые всплывают после релиза. Разработчик оценивает время написания кода, а не всего цикла до момента, когда фича реально работает в проде.
Ошибка №1: точечная оценка вместо диапазона
«Сделаю за 3 дня» — это не оценка, а точка на графике вероятностей, причём чаще всего не самая вероятная точка, а самая оптимистичная. Правильнее просить не одно число, а диапазон или три сценария:
- Оптимистичный — если всё пойдёт по плану
- Реалистичный — с учётом типичных задержек
- Пессимистичный — если что-то пойдёт не так
Это основа метода PERT (Program Evaluation and Review Technique), где итоговая оценка считается по формуле:
Оценка = (Оптимистичная + 4 × Реалистичная + Пессимистичная) / 6Такой подход не убирает неопределённость, но делает её видимой — и стейкхолдеры получают не ложное чувство точности, а честный диапазон.
Ошибка №2: оценка в часах вместо относительных единиц
Просьба «оцени в часах» заставляет разработчика делать двойную работу: оценивать сложность задачи и одновременно переводить её в абсолютное время, которое зависит от десятков факторов — насколько он отвлекается, сколько встреч в календаре, насколько задача знакома.
Относительная оценка (story points, T-shirt sizes: S/M/L/XL) отделяет вопрос «насколько это сложно относительно других задач» от вопроса «сколько календарного времени это займёт». Второй вопрос решается на уровне команды через историческую скорость (velocity) — сколько story points команда стабильно закрывает за спринт, а не через попытку каждого разработчика угадать точное число часов.
Ошибка №3: игнорирование variance между задачами
Если у команды пять задач, каждая оценена «плюс-минус 20%», интуиция подсказывает, что итоговая оценка проекта тоже будет плюс-минус 20%. На практике неопределённости не усредняются, а накапливаются, и чаще всего в невыгодную сторону — потому что вероятность того, что все пять задач пойдут по оптимистичному сценарию одновременно, крайне мала.
Практический вывод: чем больше задач в оценке, тем шире должен быть закладываемый буфер на проект в целом, а не просто сумма буферов по отдельным задачам.
Что реально помогает
1. Оценивать декомпозированные задачи, а не эпики целиком
Задача крупнее 2-3 дней почти всегда оценивается хуже, чем сумма её декомпозированных частей. Если задача не декомпозируется — это сигнал, что команда сама ещё не до конца понимает объём работы.
2. Считать буфер на уровне проекта, а не каждой задачи
Вместо того чтобы просить каждого разработчика «заложить запас» в свою оценку (что размывает ответственность и искажает данные о реальной скорости), лучше держать единый буфер на уровне всего проекта — например, 15-20% от суммарной оценки — и явно показывать его стейкхолдерам как буфер, а не прятать внутри отдельных оценок задач.
3. Использовать историческую скорость, а не веру в улучшение процессов
Частая ошибка — планировать следующий спринт исходя из того, «сколько команда должна успевать», а не из того, сколько она успевала в последних 3-4 спринтах. Historical velocity — куда более надёжный предиктор, чем оптимистичные ожидания менеджера.
4. Пересматривать оценку по мере появления новой информации
Оценка, сделанная на старте проекта при минимуме информации, — это гипотеза, а не обязательство. Хорошая практика — пересматривать оценку на ключевых точках (после дизайн-ревью, после первого спринта, после интеграции с внешним API) и явно коммуницировать стейкхолдерам, если диапазон сместился.
5. Разделять коммуникацию оценки и коммуникацию обязательства
Стейкхолдеры часто слышат оценку («скорее всего 6 недель») как обязательство («значит, через 6 недель будет готово»). Один из самых недооценённых навыков менеджера проекта — явно проговаривать разницу: «это наш текущий лучший прогноз, я обновлю его после первого спринта» звучит иначе, чем молчаливое согласие с датой.
Пример: как это выглядит на практике
Команда оценивает фичу в 20 story points при исторической скорости 15 points за спринт. Прямое деление даёт «чуть больше спринта», но это точечная оценка без учёта разброса. Более честный ответ: «при текущей скорости — от 1.5 до 2.5 спринтов, ориентируемся на 2, обновим прогноз после первой недели разработки».
Такая формулировка передаёт реальную неопределённость, не создавая ложного ощущения точности, и даёт стейкхолдерам возможность спланировать риски заранее, а не узнать о срыве дедлайна за два дня до него.
Вывод
Точная оценка сроков в IT — это не про более точные вычисления, а про честное признание неопределённости и разговор о ней открытым текстом. Диапазоны вместо точек, относительные единицы вместо часов, буфер на уровне проекта, историческая скорость вместо веры в лучшее — вместе эти практики не гарантируют попадание в дедлайн, но резко снижают вероятность неприятного сюрприза в последнюю неделю проекта.
Share
