Руководство по scrum 2020

59 part series

This page provides a series of articles, blogs, videos and more that pertain to the 2020 version of the Scrum Guide released on November 18, 2020.

The Scrum Guide

Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland and is maintained independently of any company. The Scrum Guide is translated and available in over 30 languages.

The 2020 Scrum Guide Launch Event Recording

Ken Schwaber and Jeff Sutherland are joined by Dave West, JJ Sutherland, Don McGreal and Avi Schneier as they discuss the release of the updated Scrum Guide and celebrate 25 years of Scrum.

Scrum Guide 2020 Update — Scrum is Still Scrum

At Scrum.org we have used this update of the Scrum Guide as an opportunity to have some interesting discussions and our CEO Dave West has documented some of them for your review and attention. 

Update to the Scrum Guide — What it means to Scrum.org

Today, the 18th of November 2020 Ken Schwaber and Jeff Sutherland released an update to the Scrum Guide. If you are interested in an overview of what has changed, read about the seven main changes described with some context.

Scrum Guide 2020 Update — What has been removed

Scrum is described as a framework, not a methodology. The Scrum Guide provides just enough prescription to allow Scrum to work and encourages its ‘users’ to be smart, adding practices and other things specific to them on top of the framework as needed to form their process.

Scrum Guide 2020 Update — Introducing the Product Goal

With the 2020 update to the Scrum Guide, three commitments were added to the artifacts. The idea of a commitment is to provide additional quality to the artifact to improve transparency. In the case of Product Backlog, the commitment is to the Product Goal. 

Scrum Guide 2020 Update — Commitments

With the 2020 release of the Scrum Guide, Commitments were added for each artifact. The commitments provide a nice, structural way to describe some of the key characteristics of each artifact. The intent of this change was to provide clarity and make the Scrum Guide simpler to read and use.

Product Goal

One of the more challenging aspects of Product Management is to create a tangible relationship between the work we do today and the business strategy. Product Goals are an often overlooked mechanism that can help you in this area.

Scrum Guide 2020 — Product Goal

The Product Goal is now the commitment of the Product Backlog. This video with Professional Scrum Trainer Ralph Jocham explains the Product Goal. (2:26 Minutes)

Product Goal is a Commitment

There have been a few changes in Scrum Guide 2020, and I am really excited. These changes focus on ‘Values’ within the framework of Scrum…

Why, What, How — Sprint Planning

In the 2020 update of the Scrum Guide, the Sprint Planning section has had a very welcome update. Every part of Scrum has a purpose, a reason to why it’s included in the framework, and this update made the purpose — raison d’etre — of the Sprint Planning clearer. Let’s see how!

Scrum Guide 2020 — Sprint Planning

The Sprint Planning has been enriched with a third topic — Why. This video with Professional Scrum Trainer Ralph Jocham explains the change to the Sprint Planning event in Scrum. (2:24 Minutes)

A Home for Product Goal, Definition of Done, and Sprint Goal

In the 2020 Version of the Scrum Guide, the commitments were introduced for each artifact. These then became an element of Scrum; in that they need to be used to gain the maximum value that the Scrum Framework offers. They were always part of a Professional Scrum approach, now there is a clear connection of these commitments to the artifacts. They increase transparency, and the focussed delivery of Value. Each of the commitments now clearly support and sustain an artifact.

2020 Scrum Guide: Definition of Done Created By Scrum Team

In the 2020 Scrum Guide, the Definition of Done is created by the Scrum Team. In previous versions of the Scrum Guide, this responsibility was explicitly owned by the Development Team. I will explain the intention of the change and what it means for Scrum Teams.

Scrum Guide 2020 Update — Role to Accountabilities

With the 2020 release of the Scrum Guide, the term role was replaced with accountabilities. The purpose of this change was to place special emphasis that this is not a job description, but the bare minimum set of accountabilities necessary to execute Scrum. The blog describes how these accountabilities are split into 3 groups.

Accountabilities in Scrum: It’s A Complete Picture Now

What is up awesome people? I hope you had an awesome holiday break. As you may have noticed, there have been several changes introduced in Scrum Guide 2020. Scrum no longer emphasizes roles but instead accountabilities…

Scrum Guide 2020 — Accountabilities

The Scrum Guide 2020 defines Accountabilities within one team, Scrum Team. This video with Professional Scrum Trainer Ralph Jocham explains the Accountabilities. (3:21 Minutes)

Scrum Guide 2020: True Leadership is an Attitude

The readers going through this piece more or less know the definition of a Scrum Master. Co-Creators Ken & Jeff, in their Scrum Guide 2020, having introduced exclusively the framework for Scrum, have put it as: “Scrum Masters are true leaders who serve the Scrum Team and the larger organisation.” The article’s objective is introducing the shift in the mindset or attitude. This is a requisite to become a genuine leader, as far as my experience goes. 

[VLOG] What’s New in Scrum Guide 2020?

If you prefer watching a video to understand the updates in Scrum Guide 2020, which are also my favourite updates, enjoy watching this video I’ve made.

The Scrum Guide 2020 Reordered

The Scrum Guide Reordered 2020 is based on about 95 percent of the text of the Scrum Guide 2020, extending its original structure by adding additional categories, for example, on self-management, commitments, or accountability.

What has NOT changed in the game of Scrum?

The 2020 version of Scrum Guide was released recently and everyone is talking about the changes been made in it and how it is going to impact their current ways of working as compared to its previous version.

The Agile Wire — Scrum Guide Updates

In this episode of the Agile Wire podcast — Professional Scrum Trainers Jeff Bubolz, Jeff Maleski and Chad Beier discuss the Scrum Guide 2020 changes. 

Scrum.org 2020 Update by the Scrum Facilitators

In this podcast Scrum Facilitators from the Netherlands Sjoerd Kranendonk and Jasper Alblas discuss the new Scrum Guide (version 2020) with Scrum Coaches Steve Trapps and Andy Hiles from the UK.

Mis comentarios iniciales sobre la Scrum Guide 2020

Hoy ha salido la nueva Scrum Guide 2020. 

Aún estoy digiriendo los cambios que he ido viendo mientras reviso la nueva guía scrum. 

Estoy analizando y no descarto todas las grandes o pequeñas consideraciones.

Was ist neu im Scrum Guide 2020 Update? (7 Dinge, die Du unbedingt wissen solltest)

Heute, am 18. November 2020, pünktlich zum 25. Geburtstag von Scrum, haben Ken Schwaber und Jeff Sutherland den Scrum Guide aktualisiert. 

Um eines gleich vorwegzunehmen: Scrum bleibt Scrum. Ein einfaches Rahmenwerk, welches es Teams ermöglicht, mit der Arbeit an komplexen Problemen zu beginnen. Und der Scrum Guide 2020 ändert daran nichts. 

Einige Dinge sind jedoch neu und denen widmen wir uns jetzt. 

Scrum Guide 2020 : Ce qui change

Pour le 25ème anniversaire de Scrum, ses co-créateurs, Jeff Sutherland et Ken Schwaber nous livrent le millésime 2020 du Guide Scrum.

Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.

В документе описан порядок проектной работы в команде: как поставить цель и спланировать работу над продуктом, выстраивать отношения между разработчиками, контролировать прогресс и так далее. Правилa Scrum периодически обновляются — их рекомендуют всем скрам-командам. Сейчас вышла пятая версия — мы рассмотрим её основные положения.

Справка о Scrum ↓

Справка о Scrum

Представьте жилой дом. Стены, крыша, фундамент — это каркас, на котором всё держится. Без каркаса не получится сделать ремонт и жить в квартире.

Командный проект похож на жилой дом. Чтобы получить результат, нужно сначала установить правила, по которым будет работать команда.

Scrum — набор правил для управления проектами. От них желательно не отклоняться — нарушение часто приводит к управленческим ошибкам и снижению эффективности. Если компания выбирает Scrum, ей важно следить за обновлением руководства. Ниже — вебинар по основам внедрения Scrum-подхода.

Подробный обзор нового руководства

• Scrum Guide 2020 на русском и английском языке.
• Презентация Кена Швабера и Джеффа Сазерленда — авторы гайда проводят двухчасовой стрим и рассказывают про новое руководство.
• Статьи и комментарии к новому руководству сообщества scrum.org.

Старое руководство часто провоцировало конфликты интересов между владельцем продукта и командой разработчиков. Владелец продукта ставил в приоритет цели бизнеса и заказчиков, а разработчики старались не завалить срок или снять с себя ответственность за некачественный результат.

Было: Scrum 2017

Владелец продукта встречается с заказчиком и соглашается за два месяца выпустить сайт вместе с мобильными приложениями под iOS и Android.

После встречи он проводит командное совещание, перечисляет технические требования и игнорирует возражения разработчиков о нереалистичности цели.

Команда приступает к работе и смещает акцент с качества на скорость разработки. В итоге все в проигрыше: заказчик не получил нужный продукт, владелец продукта потерял заказчика, а разработчики лишились работодателя.

Новое руководство решает проблему противостояния разработчиков и владельцев продукта. Последние отвечают за результат, а разработчики помогают с планированием: предупреждают о завышенных ожиданиях, проблемах и помогают выпустить продукт без потери качества.

Владелец продукта может делегировать свои обязанности кому-то из членов команды, но это не освобождает его от ответственности. Если что-то пойдёт не так, он не сможет перекинуть вину на другого сотрудника.

Стало: Scrum 2020

Владелец продукта встречается с заказчиком и получает предложение: за два месяца нужно выпустить сайт и приложения под iOS и Android.

После встречи он проводит командное совещание, перечисляет технические требования и выслушивает возражения разработчиков. Владелец продукта и разработчики составляют альтернативный план, который позволяет достичь цели. Например, договариваются увеличить срок и вместо двух месяцев поставить шесть.

Затем владелец продукта назначает новую встречу с заказчиком и пробует договориться о других условиях с учётом возможностей команды. Все в выигрыше: заказчик получает качественный продукт, владелец продукта укрепляет доверие заказчика, а у команды появляется стабильная работа.

Если договориться не получается, то всё равно все в выигрыше: заказчик экономит время, владелец продукта не тратит ресурсы на заранее убыточную сделку, а команде не нужно жертвовать качеством и делать плохую работу.

Ещё в руководстве сделали акцент на кросс-функциональности скрам-команд — условии, что у всех участников достаточно квалификации для решения поставленных задач. Некомпетентные люди затягивают разработку на неопределённый срок, и это мешает планировать работу над продуктом.

Скрам-команда состоит из профессионалов, поэтому в коллективе не должно быть сотрудников, которые не уважают коллег или критикуют их работу. Конфликты мешают разработчикам взаимодействовать и создавать устойчивые командные связи: переходить в неизменном составе в новый проект, не тратить время на адаптацию и точнее прогнозировать результат.

Раньше, чтобы спланировать спринт, команда задавала два вопроса: что нужно сделать и как. Ответы превращались в задачи, которые в произвольном порядке распределяли между разработчиками. В таком планировании цель спринта не всегда учитывала цель продукта, команда могла затягивать разработку из-за ненужных действий.

Было: Scrum 2017

Есть задача: за шесть месяцев выпустить сайт с приложениями под iOS и Android. Шесть месяцев — крайний срок, после которого заказчик запускает рекламу и планирует продавать свои услуги через мобильные приложения.

Команда делит задачу на шесть спринтов и выбирает такой порядок:

1-й спринт: разработка сайта.

2-й спринт: тестирование сайта.

3-й спринт: разработка iOS-приложения.

4-й спринт: тестирование iOS-приложения.

5-й спринт: разработка Android-приложения.

6-й спринт: тестирование Android-приложения.

На первый взгляд, проблемы нет и не будет, если разработчики с первого раза всё сделают хорошо. Но если разработка любого мобильного приложения затянется, заказчик не получит результата.

В новом руководстве на первом месте стоит вопрос: «Почему или в чём ценность спринта?» Каждый спринт должен соответствовать цели продукта:

• Если цель продукта ясна, то команда может переходить к планированию и думать над списком задач для каждого спринта.
• Если цель неясна, то команде нужно уточнить задачу и собрать дополнительную информацию о продукте.
• Если цель спринта не совпадает с целью продукта, то такой спринт не нужен — это лишняя работа, которую можно не делать.

После того как команда сформулировала цели, нужно определить первый шаг. Важно всегда начинать с задач, которые несут наибольшую ценность для продукта.

Стало: Scrum 2020

Задача: за шесть месяцев выпустить сайт с приложениями под iOS и Android. Шесть месяцев — крайний срок, после которого заказчик запускает рекламу и планирует продавать свои услуги через мобильные приложения.

Определяем цели, которых можно достичь в рамках одного спринта:

1-й спринт: разработка сайта.

2-й спринт: тестирование сайта.

3-й спринт: разработка iOS-приложения.

4-й спринт: тестирование iOS-приложения.

5-й спринт: разработка Android-приложения.

6-й спринт: разработка Android-приложения.

В задаче заказчик акцентировал внимание на мобильных приложениях — это повод собрать дополнительную информацию о продукте. Узнаём следующее: бизнес не сможет работать без мобильных приложений. Сайт важен, но у него второстепенные функции: это ресурс с информацией о компании и дополнительная площадка для скачивания мобильных приложений.

Учитываем цель продукта, расставляем приоритеты и получаем такой план:

1-й спринт: разработка iOS-приложения.

2-й спринт: тестирование iOS-приложения.

3-й спринт: разработка Android-приложения.

4-й спринт: тестирование Android-приложения.

5-й спринт: разработка и тестирование сайта.

6-й спринт: резервное время на доработку мобильных приложений.

Понимание цели продукта позволило скорректировать цели спринтов: мы вынесли на первое место создание мобильных приложений и заложили время на их доработку, то есть сосредоточили усилия команды на главной задаче.

Второстепенную задачу по разработке сайта мы сократили по времени и поставили на последнее место. Бизнес может обойтись без сайта, а сайт без хорошо проработанных мобильных приложений — бесполезная трата усилий.

Фокус на цели продукта избавляет команду от постоянной занятости, когда все разработчики пишут какой-то код, находятся полный день в офисе и не создают ничего ценного. Принципы Scrum не допускают лишней работы.

Авторы руководства считают, что хороший продукт сложно выпустить с первого раза. Поэтому вместо лишних действий рекомендуют закладывать время на доработку основных функций. Лучше выпустить и протестировать несколько версий приложения с пятью основными функциями, чем надеяться на одну идеальную версию с десятью.

Предыдущее руководство напоминало неточную инструкцию. Если команда пробовала внедрить Scrum без сертифицированного скрам-мастера, то рисковала неправильно трактовать отдельные положения руководства. Так появлялись формальные ритуалы, которые не помогали, а мешали работе.

Было: Scrum 2017

Что предлагало руководство: команда должна ежедневно собираться на 15-минутную встречу, чтобы синхронизироваться и обсудить цели спринта.

На встрече каждый участник отвечает на три вопроса: что он сделал вчера, что планирует делать сегодня и какие проблемы мешают реализовать составленный план.

Под этим подразумевалось, что команда должна ежедневно контактировать, не отставать от графика и совместно решать проблемы.

Как это превратилось в ритуал: команда ежедневно собиралась на встречу и вместо обсуждения рабочих задач делала акцент на том, чтобы не выйти за рамки 15-минутного лимита, — времени, прописанного в руководстве.

Чтобы успеть провести совещание, один из участников по кругу задавал остальным одинаковые вопросы и получал краткие механические ответы:

— Что сделано: задача 15 и 20.

— Что запланировано: задача 25 и 30.

— Какие проблемы: никаких, или проблема находится в процессе решения.

Результат: команда ежедневно теряла время и не получала никакой пользы. Разработчики оставались наедине со своими проблемами, а у руководителей создавалось ложное ощущение, что работа над продуктом проходит по плану.

Новое руководство отменяет все формальные процедуры и разрешает команде использовать любые полезные в работе инструменты. Их можно подбирать самостоятельно, исходя из задачи.

Стало: Scrum 2020

Команда договаривается ежедневно собираться на утренние совещания и в свободной форме обсуждать проблемы продукта. Совещания не ограничены по времени и длятся по необходимости от пяти минут до нескольких часов. На встрече каждый участник говорит о проблемах и вместе с командой ищет решения. Если проблем нет, все идут работать.

Результат: команда концентрируется на решении проблем и использует совещания для ускорения разработки.

Скрам-команда может как угодно организовать работу над продуктом и отслеживать прогресс. Главное — чтобы принятые правила никто не нарушал.

Мы попросили практиков прокомментировать Scrum Guide 2020 и объяснить, какие изменения им понравились, что ухудшилось и могут ли IT-команды использовать обновлённый Scrum без помощи сертифицированного скрам-мастера.

Начнём с того, стоит ли нанимать скрам-мастера для внедрения нового Руководства. Ответ зависит от того, как команда работает сейчас:

• Если в команде классический Waterfall, люди по 30 лет работают в проекте и никто не хочет ничего менять, то самостоятельно перейти на гибкие методики работы с проектами вряд ли получится. В этом случае важно своевременно пригласить скрам-мастера, способного изменить систему.
• Если речь идёт о только что сформировавшемся коллективе, который готов пробовать и экспериментировать, то скрам-мастера может заменить тимлид или кто-то из руководителей.

Скрам-мастер — это роль, которая по силам кому-то из участников команды. Но такой подход сработает только в случае, если выбранный участник будет разбираться в Scrum: как минимум прочитает несколько книг, изучит новую версию Руководства и посетит несколько тренингов. По-другому не получится.

Самое сложное — наладить Scrum-процесс с нуля. Если команда готовится к большим изменениям, я бы советовала нанимать скрам-мастера. В начале должен быть человек, который понимает Scrum и точно знает, что и для чего делать. Он сможет аргументировано донести и объяснить идеи Scrum каждому участнику команды.

Если изменения небольшие, команда новая, а руководитель разбирается в Scrum, то можно попробовать обойтись своими силами. Если после внедрения Scrum управлять проектами стало проще и эффективнее — это успех. Результатом должен стать работающий процесс и готовый продукт, а не соблюдение правил ради самих правил.

Виктория Писаренко

Scrum Master / Agile Project Manager, Мюнхен; работает в проектах автоиндустрии, основатель Victoria’s Business Secrets Academy.

Scrum родился из практики: наблюдений, проб и опыта команд. Здорово, что Руководство обновляется. И хотя эти изменения кажутся небольшими, за счёт них можно лучше понимать и применять фреймворк.

Наверняка многие обратили внимание, что в новом Руководстве появилась Цель Продукта и что из Ежедневного Скрама убрали три вопроса, слепое следование которым превратило многие команды в зомби.

Я бы хотела выделить три неочевидных изменения:

• Scrum официально вышел за пределы разработки софта: в Руководстве убрали специфическую терминологию. Здорово, что больше команд могут увидеть для себя возможности в том, чтобы попробовать Scrum.
• Скрам-мастер теперь не лидер-слуга. Этот термин в русском переводе звучит странно в связи с тонкими различиями между «служить» и «обслуживать». Теперь скрам-мастер — «настоящий лидер, который служит скрам-команде и всей организации».
• Также скрам-мастер больше не фасилитирует События Скрама, а «убеждается в том, что они происходят, позитивны, продуктивны и не выходят за рамки ограничений по времени». Это очень важное изменение, которое корректирует неправильную трактовку ответственности скрам-мастера как «ведущего» встреч».

В целом новое Руководство побуждает команды и лидеров свериться с первоисточником и спросить себя: насколько в нас жив дух игры?

Юлия Аникеева

Скрам-мастер, Scrumband. Работала с «Альфа-банк», «АльфаСтрахование», «Ростелеком», «Крок»

Во время подготовки материала меня не покидало ощущение, что Scrum Guide 2020 появился с подачи маркетологов — в документ добавили несколько полезных изменений, но основная часть связана с популяризацией Scrum. Приведу несколько аргументов, с которыми не обязательно соглашаться.

Scrum для всех. Новое руководство написали простым языком, чтобы привлечь широкую аудиторию. Авторы убрали IT-терминологию и позиционируют Scrum как удобный инструмент для всех компаний, где работу над продуктом можно разделить на этапы и распределить между небольшими командами.

Scrum стал более гибким. Вместе с простым языком руководство предлагает вольное истолкование всех положений Scrum. Например, в предыдущем разделе мы разобрали ситуацию с ежедневным собранием, когда вместо пятнадцати минут и трёх стандартных вопросов команда общается сколько нужно и на любые темы.

Scrum попал в зависимость от скрам-мастера. Простой язык и вольное истолкование годятся, если команда умеет работать со Scrum. В этом случае она берёт лучшее из нового руководства, заменяет устаревшие правила и продолжает двигаться к цели. Когда команда только знакомится с методологией, возникает проблема: участники понимают, какой нужен результат, но не знают, как к нему прийти. Появляется зависимость от скрам-мастеров — людей, которые, по мнению авторов руководства, должны отвечать за внедрение и правильное использование принципов Scrum в командах.

Вот неполный список обязанностей скрам-мастера:

• Отвечать за эффективность команды: организовать коучинг, налаживать самоуправление, следить за кросс-функциональностью разработчиков, устранять организационные препятствия.
• Делать так, чтобы работа над проектом не выбивалась из срока, не распылялась на лишние задачи, не теряла в качестве и соответствовала цели продукта.
• Помогать владельцам продукта определить главную цель, подготовить список задач для каждого спринта и наладить общение с заказчиками.
• Налаживать связь между несколькими командами.
• Популяризовать Scrum.

Скрам-мастер — новая профессия, в которой пока мало хороших специалистов. Как правило, для отдельной команды их приглашать дорого. Поэтому возникает проблема: если компания не планирует переводить все подразделения на Scrum и не может позволить себе скрам-мастера, то ей сложно правильно трактовать положения нового руководства. Без этого Scrum превращается в набор бесполезных формальных ритуалов.

На мой взгляд, авторы специально сделали руководство абстрактным, чтобы заработать на переаттестации действующих скрам-мастеров и аттестовать новых. Это плохо тем, что тимлиды многих IT-команд останутся без помощи скрам-мастеров и не смогут внедрить методологию, даже если захотят.

Scrum — эффективная методология, которая требует индивидуальной настройки под каждую компанию и команду. Если есть задача с нуля перейти на Scrum, то изучением нового руководства не обойтись — понадобится опытный скрам-мастер, способный адаптировать методологию под цели команды.

Ситуация меняется, если не нужно переходить на Scrum с нуля. В этом случае даже частичное внедрение скрам-технологий поможет повысить эффективность любой IT-команды. Поэтому призываю тимлидов, текущих и будущих руководителей не зависеть от скрам-мастеров, а изучить Scrum и оценить его преимущества в работе над собственными проектами.

Как зарабатывать больше с помощью нейросетей?
Бесплатный вебинар: 15 экспертов, 7 топ-нейросетей. Научитесь использовать ИИ в своей работе и увеличьте доход.
Узнать больше

The refined Scrum Guide 2020 – launched on November 18 – includes some small, yet significant changes. The co-creators, Dr. Jeff Sutherland and Ken Schwaber, highlight the changes mentioned below from 2017 to 2020.

Our perspective on the updated Scrum Guide

Overall, we welcome the changes. We believe they take the guide back to its roots of being not too prescriptive and a real framework. This also results in the guide being easier applicable to industries outside of software development. There are some further changes we would like to see… but who knows what the next iteration will bring.

Changes from 2017 Scrum Guide to 2020 Scrum Guide
Next we will describe the changes between the Scrum Guide 2020 and previous versions. We will rate all changes as Scrum Academy an agile Training Provider.

Even Less Prescriptive

Over the years, the Scrum Guide started getting a bit more prescriptive. The 2020 version aimed to bring Scrum back to being a minimally sufficient framework by removing or softening prescriptive language. e.g. removed Daily Scrum questions, soften language around PBI attributes, soften language around retro items in Sprint Backlog, shortened Sprint cancellation section, and more.

Scrum Academy perspective:We like this change as this is a move back to being a framework rather than a body of knowledge (BoK) similar to the PMBOK® from PMI. The beauty of Scrum lies in its simplicity and universality. We have applied Scrum in software, hardware, pharma, and all types of services. A move back to the roots, makes the concepts more tangible for people outside of the software development world.

One Team, Focused on One Product

The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or “us and them” behavior between the Product Owner and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: Product Owner, Scrum Master, and Developers.

Scrum Academy perspective:
We love this change. The concept of a team within the team regularly resulted in confusion – be it in a training or later during implementation. The “us” vs. “them” mentality is really dangerous for any team and agile teams in particular. Still, there is an emphasis that accountabilities in the teams are clearly assigned. 

We also like the emphasis that there are no formal hierarchies within the Scrum Team – just different accountabilities. We truly hope this small, yet important change in terminology will result in more and more people interpreting the roles in Scrum similar to us.

The one thing we would like to see change going forward is the name “Developers”. Too often do we see people assuming this means Software Developers – which is not the case.

Introduction of Product Goal

The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal.

Scrum Academy perspective:
In general, we like the introduction of the Product Goal and the emphasis that every sprint should bring the product closer to the overall Product Goal. But to be honest, we would have preferred the term Product Vision as this is a term many people have been using in the past. There are even tools build around this e.g. the Product Vision Board from Roman Pichler.

One aspect that we find helpful to add is a systematic approach to think about the Product Goal i.e. what does the Product Goal need to cover. At the same time, this could make the framework again too prescriptive… so maybe it is ok to keep it the way it is now.

In order to help teams systematically create a great Product Goal, we have created the Product Goal Canvas – see below. This simple tool helps teams to systematically think and create the Product Goal. You can learn more about how to use the Product Goal Canvas here.

The 2020 Scrum Guide contains numerous updates and changes that make it the best guide yet. If you haven’t done so already, you can find pdf’s, translations, and an online version of the 2020 Scrum Guide here. 

You can also learn more about the changes by watching the official 2020 Scrum Guide Launch event.

This latest iteration is cleaner, clearer, and more universal. The updates in the 2020 Scrum Guide are intended to drive the culture, focus, and alignment needed to innovate, create, and succeed. 

Each day tens of millions of people, the world over, gather for their 15-minute Daily Scrum. A fact that is humbling to think about.  We want to thank everyone, and there were many of you, who helped provide the insights, data, and real-world experiences that helped inform the 2020 Scrum Guide updates.

Why We Updated The Scrum Guide

Since first being published in 2010, the Scrum Guide has always been a living document. We use empiricism to periodically Scrum the Scrum Guide. As the guide itself states: 

Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.

In a very real way, Scrum hasn’t changed at all, our description of it simply gets better as we get feedback on how people are using it. Iterating to a better outcome.   

The 2020 Scrum Guide addresses the common misinterpretations and misunderstandings we and many others have observed as the use of the framework continues to grow. 

2020 Scrum Guide: Overview of Changes

Below you’ll find sections explaining the ‘what’ and ‘why’ behind specific changes and updates in the 2020 Scrum Guide. But let’s start with this high-level overview of what you’ll find in the guide:

Less Prescriptive Language

At just 13 pages, the updated 2020 Scrum Guide is even less prescriptive than before while maintaining the standard of a minimally viable framework. The purpose here is to empower Scrum Teams and organizations to use the guide as it was intended; a rule book and not a playbook. This less prescriptive approach leads to more innovation and adaptations in how Scrum is implemented while keeping true to the framework. 

A Clearer, More Universal Scrum Guide

Scrum is easiest when Scrum Teams and organizations see how the framework works for them, no matter their industry, domain, product, or function. This is why we’ve made the updated 2020 Scrum Guide more accessible and understandable for everyone, far beyond the technology business. 

The Scrum Artifacts And Their Corresponding Commitments

Each of the three Artifacts now has a corresponding ‘commitment’. They exist to bring transparency and focus against which progress can be measured. The commitment for the Product Backlog is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done.

The 2020 Scrum Guide introduces the concept of a Product Goal to provide a long-term focus for the Scrum Team. Each Sprint should bring the product closer to the overall Product Goal. Both the Sprint Goal and Definition of Done were in previous Scrum Guides. Now they have a clearer home and purpose. 

Scrum Master: From ‘Servant Leader’ To ‘A Leader Who Serves’

This change will undoubtedly catch many by surprise. But don’t be fooled, the reordering of these words better captures the purpose and accountabilities the Scrum Master has always had. 

A Unified Team Focused On One Product

Earlier Scrum Guides referred to two teams, the ‘development team’ meaning those who did the work and the ‘Scrum Team’ which included the development team as well as the Scrum Master and the Product Owner. This concept of a separate team within a team has sometimes led to an “us and them” relationship between the Product Owner and Development Team. There is now just one team, the Scrum Team, focused on the same objective, with different sets of accountabilities for the Product Owner, Scrum Master, and Developers.

Self-Managing over Self-Organizing

Previous Scrum Guides referred to Development Teams as self-organizing, meaning they chose who performed the work and how. With more of a focus on the Scrum Team, the 2020 version emphasizes a self-managing Scrum Team, which chooses what to work on, who is going to do it, and how it will get done. 

Three Sprint Planning Topics

In addition to the Sprint Planning topics of “What” and “How”, the 2020 Scrum Guide introduces a new topic, “Why”, referring to the Sprint Goal.

What’s No Longer In The Scrum Guide

In order to keep to the standard of a minimally viable framework, some things have been removed from the 2020 Scrum Guide. This, however, does not mean they have no place in Scrum or should not be used. Like Yesterday’s Weather and other Scrum Patterns not explicitly included in the Scrum Guide, they are optional practices that can help lead to high-performing Scrum Teams.

Here are the major concepts no longer included in the 2020 Scrum Guide and why: 

The Three Questions Answered At The Daily Scrum:

You likely know these by heart; what you did yesterday to help the Development Team meet the Sprint Goal, what you’ll do today to help the Development Team meet the Sprint Goal, and do you see any impediments that prevent me or the Development Team from meeting the Sprint Goal? While effective, these three questions were overly prescriptive and limiting. As the 2020 Scrum Guide states: 

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

There are many ways to achieve that purpose. 

‘Parking Lot’ After Daily Scrum

Sometimes the Daily Scrum identifies conversations that need to take place beyond the event’s 15-minute timebox.  The prior guide stated these conversations, often called a ‘parking lot’ take place immediately after the Daily Scrum. The 2020 Scrum Guide lets the Scrum Team decide when these important conversations take place. 

The Word ‘Roles’ When Describing The Scrum Master, Product Owner, and Developers

The word ‘roles’ was being misunderstood in some situations. Scrum has never been about creating a taxonomy of titles. Roles were never intended to be a title. What matters is clearly defining who is accountable for what. Therefore the 2020 Scrum Guide includes this passage: 

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.

This change puts the emphasis where it belongs, on specific accountabilities. You can still refer to them as ‘roles’ if you like. We are. But we too will emphasize these are roles with defined accountabilities.

A Sprint Review Led Only By The Product Owner

The prior guide gave the Product Owner the lead during the Sprint Review. The rest of the Scrum Team acted in a more supporting role. The 2020 Scrum Guide now has the entire Scrum Team, along with customers and stakeholders, at the center of this Event.

No Team-Within-A-Team

As stated above, the concept of a ‘Development Team’ inside the Scrum Team has been resolved. 

Overly Prescriptive Language For The Sprint Retrospective

The overall description of this Scrum Event has been shortened to focus on what’s really important — process improvements and team happiness and cohesion. This gives individual Scrum Teams more flexibility in how they approach the Sprint Retrospective.

Timebox For Backlog Refinement

The prior guide stated that ‘usually no more than 10-percent of a team’s capacity’ should be spent on refining the Product Backlog. Removing the number empowers Scrum Teams to decide how much time is needed to refine and understand Product Backlog Items. 

Now, let’s examine the major updates and changes found in the 2020 Scrum Guide in detail.  

2020 Scrum Guide Update: Scrum Artifacts And Commitments

Arguably, the biggest change in the 2020 Scrum Guide can be found in the section on the Scrum Artifacts. There are still just three Artifacts in Scrum, the Product Backlog, the Sprint Backlog, and the Increment. Each represents work or value and is designed to maximize the transparency of key information. 

Now each of these Artifacts has a new corresponding commitment. 

• The commitment for the Product Backlog is the Product Goal
• For the Sprint Backlog, it is the Sprint Goal
• For the Increment, it is the Definition of Done

As stated in the 2020 Scrum Guide: 

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

Commitment is, of course, one of the Scrum Values. The decision to use the word here, in concert with each of the Artifacts, is a deliberate one. 

To learn more about these new commitments and how they drive focus, alignment, and value delivery read Scrum Guide 2020 insights by Scrum Inc.‘s CEO, JJ Sutherland.  

Why This Update Was Made: It started with feedback from trainers and our own observations. Both showed there needed to be more of a focus on goals in the Scrum Guide. Specifically, how to align teams on the goals and the concrete steps needed to make them a reality. 

Additionally, we’ve long known that teams that are focused on clear and specific goals do a much better job. 

The Sprint Goal is not new to the Scrum Guide. However, this iteration gives the Sprint Goal a home and a more clearly defined purpose. Here’s how the Sprint Goal is defined in the 2020 Scrum Guide:

The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

The Product Goal is new to the 2020 Scrum Guide. Added because we wanted to introduce a higher level of focus and alignment. The Product Goal is a concrete step towards achieving the desired future state of the product. Here’s how the 2020 Scrum Guide describes it: 

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

The final new commitment is the Definition of Done. Like the Sprint Goal, it is not new to the Scrum Guide. Rather we have given the Definition of Done a home and a more clearly defined purpose. But there is a slight change in the term’s meaning in this context. Here is how the 2020 Scrum Guide describes it: 

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. The moment a Product Backlog item meets the Definition of Done, an Increment is born.

2020 Scrum Guide Update: Elevating Scrum Master From A ‘Servant Leader’ To  ‘Leaders Who Serves’

Another important change to note deals with the description and accountabilities of the Scrum Master. 

From the beginning, the primary purpose of the Scrum Master has been to significantly improve team performance. That is not just a team-centered activity. Which is why the Scrum Master section in the 2020 Scrum Guides opens with this paragraph:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.

The 2020 Scrum Guide advances this broader view of the Scrum Master’s role by spelling out some of the ways the Scrum Master serves the organization. This includes:

Leading, training, and coaching the organization in its Scrum adoption

Understanding this expanded role of the Scrum Master is key to understanding why we replaced ‘servant leader’ with the term ‘leader who serves’. 

By going from ‘servant leader’ to ‘leaders who serve’, we’ve emphasized the leadership aspects of a Scrum Master. We have no intention of creating a hierarchy inside the Scrum Team. Nor are we saying the Scrum Master is now a manager. 

What we are saying is that effective Scrum Masters do more than just facilitate Scrum Events and surface impediments. They are active, not passive. Great Scrum Masters do what must be done to help the Scrum Team and organization achieve great results. 

Why This Update Was Made: It was time to clarify a misunderstanding. One that led many organizations to question why a Scrum Master was needed at all. 

In 1986, the Harvard Business Review published The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka. This paper is a major reason they’re often referred to as the grandfathers of Scrum.

In this seminal work, Takeuchi and Nonaka describe how a facilitative team leader manages up and down. The organization and the team. This is how they manage the process. This was effectively the prototype of a Scrum Master. Someone who is getting management aligned with helping and supporting the Scrum Teams to do good work. 

Some have misinterpreted the term servant leader in a way that has led us away from real leadership. So we changed the term to ‘leaders who serve’.

2020 Scrum Guide Update: From Self-Organizing To Self-Managing Scrum Teams

This is a subtle but important change that further empowers Scrum Teams while simultaneously making clear they are accountable for achieving their goals. 

The previous Scrum Guide stated, “Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”

The 2020 Scrum Guide now says this of Scrum Teams:

They are also self-managing, meaning they internally decide who does what, when, and how.

The team self-manages to deliver on the commitments and to meet the goals.

Why This Update Was Made: Scrum terms and concepts can be, in effect, weaponized in the workplace. Sometimes by management. Sometimes by the Scrum Team itself. 

There are many Agile developers who view self-organizing as meaning they can do whatever they want. That’s a misconception that needed to be addressed. Self-organization occurs when an intelligent system finds the best way in an environment to achieve a goal. 

So the 2020 Scrum Guide now uses the term self-managing to bring clarity to the concept and stop the weaponizing of self-organization as an excuse to avoid meeting goals or commitments. 

You can learn more about why this and other changes were made in Dr. Jeff Sutherland‘s post about cells and teams as it relates to the new Scrum guide. 

2020 Scrum Guide Update: One Scrum Team Focused On One Product

As we stated above, earlier Scrum Guides referred to two teams, the ‘development team’ meaning those who did the work, and the ‘Scrum Team’ which included the development team as well as the Scrum Master and the Product Owner. 

This concept of a separate team within a team has sometimes led to an «us and them” relationship between the Product Owner and Development Team. There is now just one team, the Scrum Team, focused on the same objective, with different sets of accountabilities for the Product Owner, Scrum Master, and Developers.

Why This Update Was Made: We’ve pretty much covered it. However, there is one additional reason worth noting; making Scrum more accessible and understandable. 

Scrum is easiest when Scrum Teams and organizations see how the framework works for them, no matter their industry, domain, product, or function. The team within a team concept could be confusing to many who were starting to implement the framework.

2020 Scrum Guide Update: Changes To The Five Scrum Events 

The 2020 Scrum Guide includes at least minor changes to each of the five Scrum Events. So we’ll go through each one individually. 

Sprint Planning: The previous Scrum Guide listed two topics the Scrum Team should discuss in this Event. What can be delivered in the Increment in the upcoming Sprint, and how the work will be achieved. Discussions of these two topics yield important information and a shared understanding that helps the Scrum Team achieve their Sprint Goal. And though reworded for clarity, they remain in the 2020 Scrum Guide. However, a Scrum Team doesn’t get the full picture by just understanding what and how. They must also understand why. So a new topic for discussion has been added to Sprint Planning. Here’s how the 2020 Scrum Guide describes it:

Topic One: Why is this Sprint valuable?

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.

Discussion of the why gives the Scrum Team the context that may otherwise have been lacking. We’ve found that Scrum Teams who understand the intent of the Product Owner deliver better results and higher quality. 

The Sprint: The 2020 Scrum Guide now explicitly states that only the Product Owner can abort a Sprint. This really represents more of a clarification than a change since it has long been an established practice.

Daily Scrum: The purpose of the Daily Scrum remains the same; to inspect progress toward the Sprint Goal, and adapt and replan the Sprint Backlog as necessary. What has changed in the 2020 Scrum Guide is the method. Gone are the three questions listed in previous guides, replaced with this less prescriptive description: 

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.

Indeed, there are many ways to achieve the purpose of the Daily Scum. 

For example, a Scrum Coach in Europe began holding Daily Scrums where just one question was asked, why isn’t the story at the top of the Backlog done? That focus lead to an increase in performance of 500-percent. 

We wanted to give all Scrum Teams the flexibility to use the approach that best works for them. 

Sprint Review: In Scrum, the work is accomplished by the team. We wanted the Sprint Review to be as inclusive as the work itself. In the 2020 Scrum Guide the Sprint Review is no longer lead by the Product Owner, but by the Scrum Team as a whole: 

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the venue for customers, stakeholders, and the Scrum Team to discuss how they achieved the Sprint Goal, progress towards the Product Goal, and what problems have been overcome and what remains in their way. 

Sprint Retrospective: Every Sprint Retrospective is really about just two things; respect for people and continuous improvement. Retrospectives are successful if the conversations are open, honest, and focus on improving processes and interactions. There are many ways to achieve this. 

So we’ve removed the overly prescriptive language to encourage the Scrum Master and the whole Scrum Team to be flexible in finding creative ways to solve problems by first find their root cause. Sometimes these solutions are the removal of impediments. Others are potential process improvements identified by the Scrum Team. As the 2020 Scrum Guide states: 

The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

This is also a change from previous guides which stated these improvements will be implemented next Sprint. And while we believe this is still a leading practice, it is not a must. So we erred on the side of flexibility. 

Closing Thoughts

We spend enormous amounts of our lives going to work. And for a lot of people, work sucks. In the creation of Scrum, our vision has always been to make work fast, easy, and fun. If it’s not fun, you’re doing it wrong. 

With this latest iteration of the Scrum Guide, we’ve tried to clarify terms that have been misinterpreted. Simplify where it was too complicated. And make the framework more accessible so that any team in any organization, whether they are a sales team or an H.R. team, one that does marketing or finance, development or strategy, can pick up the Scrum Guide and begin.

That has always been the point. Scrum is open source for a reason. We want its use to spread. We want to help empower people to solve complex problems, to achieve big things. 

We look forward to seeing what the Scrum community achieves next. And we’re proud of what we have already accomplished together.