Я всегда не любил стори поинты, как и оценки для задач и проектов. Если только задуматься, насколько целая индустрия полагается на умение (точнее неумение) угадывать будущее, то сразу отчаяние накатывает. Про движение #NoEstimates и то, как оно немного сдвинуло моё сознание в отношении эстимейтов, я расскажу отдельно. Сегодня хочу поделиться замечательной статьёй про стори поинты от их непосредственного создателя.

В статье прекрасно всё с первого предложения: “I like to say that I may have invented story points, and if I did, I’m sorry now”.

Рон Джеффрис рассказывает, как концепт родился в их тусовке XP из идеальных дней, которые домножали на коэффициент, чтобы не путать стейкхолдеров. Как он должен был восстановить равновесие силы, а не ввергнуть её во мрак. Как неплохая идея в итоге чаще всего используется неправильно.

Ключевые моменты:

  • стори поинты нельзя использовать, чтобы предсказать, когда что-то будет сделано
  • трекать, насколько оценка в стори поинтах, соотнеслась с затратами времени бесполезно
  • сравнивать команды на основе умения делать оценки вредно
  • эстимейты чаще всего являются попыткой угадать, нельзя воспринимать их как обещание и коммит
  • важнее определять самые важные и приоритетные вещи для работы и делать их быстро
  • чтобы это было возможно надо резать задачи на кусочки, каждый из которых несёт ценность; стори поинты и оценки в этом не помогают
  • Рон идет дальше и говорит, что идеи итераций и спринтов также вторичны и не особо нужны перед знанием, какие следующие фичи принесут наибольшую ценность
  • честный ответ на «когда это будет сделано?» при фиксации списка фич «никто на самом деле не знает»
  • гораздо лучше идти от обратного: выбрать дату релиза пользователям и до неё сделать как можно больше полезного; оценки и стори поинты тут опять не помогают

Несколько цитат

The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.

I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.

It is common practice to make a list of essential features, think about them for a while, and then decide that they define the next release of our product. The next question, of course, is “when will all this be done?” The answer is that no one knows.

It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.