Scrum се използва за разработване и създаване на продукти. Подходът на Scrum е итеративен и инкрементален, за да се увеличи предвидимостта и да се контролира риска [2]. Той може да се използва за всякакви продукти, при които е възможно итеративно разработване или създаване и съответно – не може да се приложи при продукти, които не могат да бъдат разработени или създадени чрез итерации.

Под „продукт“ трябва да се разбира услуга, физически продукт или нещо по-абстрактно [3].

При итеративното (повтарящо се) разработване се създават последователни версии на продукта. Всяка версия преминава през всички фази на процеса на разработка. При инкременталния (добавящия) подход, продуктът се надгражда постепенно с нови функции и характеристики. Когато двата подхода се съчетаят, всяка следваща версия на продукта е по-пълна и по-добра от предишната.

Създателите на Scrum - Ken Schwaber и Jeff Sutherland, го представят за пръв път през 1995 г., като обобщение на опита в разработването на софтуер, който са натрупали през предходните години.

Scrum е част от подходите за гъвкаво разработване на софтуер, които възникват през 90-те години на 20-ти век и които доразвиват еволюционните и адаптивни подходи, които започват да се прилагат от 50-те години на 20-ти век в противовес на тежките методи, залагащи на подробно първоначално планиране и цялостно еднократно разработване в последователни фази.

В ръгбито, scrum e екипна формация, в която играчите са събрани непосредствено един до друг и работят заедно за постигане на обща цел.

В контекста на разработването на продукти, терминът „Scrum“ се появява в статията „Новата игра за разработване на нови продукти“ на Hirotaka Takeuchi и Ikujiro Nonaka през 1986 г. [4]. Те описват цялостния или „ръгби“ подход за разработване на продукти, при който екипът работи като едно цяло, за да преодолее дистанцията, подавайки си топката напред и назад. В тази статия са описани някои от най-важните характеристики, които залягат в основата на гъвкавото (agile) разработване на продукти: самоорганизиращи се проектни екипи, застъпващи се фази на разработване, непрекъснато учене и фин управленски контрол. 

Scrum for software was directly modeled after "The New New Product Development Game" by Hirotaka Takeuchi and Ikujiro Nonaka published in the Harvard Business Review in 1986.

- Jeff Sutherland [5]

"Чувствах, че сме късметлии да изберем техния модел за софтуерна реализация на Scrum", споделя Jeff Sutherland за Takeuchi и Nonaka [6].

Собственикът на продукта (Product Owner) е отговорен за максимизирането на стойността на продукта. За целта, той управлява бизнес и функционалните изисквания за продукта и ги изразява пред разработчиците. Той поръчва работата за решаване на комплексен проблем (чрез продукт) в така наречения Product Backlog – подреден по приоритет списък на работата, която трябва да бъде извършена, за да се създаде, поддържа и използва продуктът. [9]

Екипът (Scrum Team) избира част от тази работа, която да бъде свършена в съответната итерация. Резултатът от всяка итерация (която в Scrum се нарича Sprint) e инкремент – това е завършената и стойностна работа, извършена от разработчиците по време на спринта. Сумата от всички инкременти (от всички итерации), формира продукта.

Екипът и заинтересованите страни проверяват резултатите от спринта и извършват пренастройване за следващия спринт.

Човек, играещ ролята на Scrum Master, има задачата да създаде условия за осигуряването на стойност по най-добрия начин. Този човек е отговорен за правилното разбиране и използване на Scrum чрез даване на насоки, обучение и подпомагане на екипа и чрез осигуряване на подходяща среда за извършване на работата.

Целият екип е отговорен за създаването на полезен и използваем инкремент (или инкременти) на продукта във всеки спринт.

„Scrum екипите са многофункционални, което означава, че членовете имат всички необходими умения, за да създадат стойност във всеки спринт. Те също са самоуправляващи се, което означава, че вътрешно решават кой какво прави, кога и как.“ 

The Scrum Guide (2020)

Спринтът (итерацията) в Scrum e с фиксирана продължителност от не повече от един месец и той съдържа всички други събития и дейности, включително планирането на спринта, ежедневните срещи за преглед на напредъка, адаптиране и пренастройка (Daily Scrums), прегледа на спринта (Sprint Review) и ретроспекцията на спринта (Sprint Retrospective).

Например, популярни Agile техники за приоритизиране на изискванията, за оценка на обема на работата, за проследяване на напредъка и други, често се приписват на Scrum. Всъщност, в The Scrum Guide не са посочени конкретни техники, но е отбелязано, че той „работи добре като контейнер за други техники, методологии и практики“ [10].

Проблем в разбирането на Scrum са и антимоделите (antipatterns) - често използвани практики, които са неефективни или направо вредни. Те също се приписват на Scrum, но произтичат от неговото неправилно разбиране, формалистично прилагане или свободната му интерпретация.

Съществуват голям брой антимодели във всеки отделен елемент на Scrum.

Само няколко примера за такива антимодели са:

• Съвместяване на ролите на Scrum Master и Product Owner
• Включване на Scrum Master като технически експерт в екипа
• Използване на „итерации“, в които не се създава завършен инкремент на продукта, като Hardening Sprint, Deployment Sprint, Release Sprint, Testing Sprint и други

Съществува и друг феномен - да се поставя знак за равенство между Scrum и Agile и по този начин Agile да се ограничава до конкретна рамка. Въпреки че Scrum е изключително важна и популярна част от подходите за гъвкаво разработване на продукти, Agile e начин на мислене, който включва по-широк кръг методи за разработване на продукти и за адаптивно управление на проекти. Вижте повече по този въпрос на www.agile.bg.