КИЇВСЬКИЙ УНІВЕРСИТЕТ

ІМЕНІ БОРИСА ГРІНЧЕНКА

Фреймворк Scrum
 Scrum
Скрам (Scrum) це простий фреймворк який допомагає
людям, командам та організаціям генерувати цінність
через адаптивні рішення складних проблем

В цілому, Скрам вимагає від Скрам Масйтра (Scrum Master) створення середовища в якому:
1. Власник Продукту (Product Owner) додає у певному порядку роботу для вирішення складної
проблеми у Беклог Продукту (Product Backlog).
2. Скрам Команда (Scrum Team) протягом Спринта (Sprint) перетворює вибірку робіт в Інкремент
(Increment), який додає цінність продукту.
3. Скрам Команда (Scrum Team) та зацікавлені сторони інспектують (Review) результати роботи та
коректують наступний Спринт.
4. Повторення.
 Scrum команда

● Згуртована група професіоналів, орієнтованих на одну ціль - Ціль Продукту (Product Goal)
● Немає підгруп або ієрархій
● Команда є крос‐функціональною, тобто члени команди мають усі навички, які необхідні для
створення цінності кожного Спринту
● Команда самокерована, тобто члени команди самостійно вирішують хто що, коли і як робить.
● Складається з десяти або менше людей
● Несе відповідальність за все пов'язане з продуктом
( співпраця із зацікавленими сторонами, верифікація, технічне обслуговування, експлуатація,
експерименти/дослідження, розробку)
● Несе відповідальність за створення цінного, корисного приросту кожного Спринту
T-shaped persons
 Cфери відповідальності у
рамках Scrum команди
● Product Owner (Власник Продукту)

● Scrum Master (Scrum Майстер )

● Developers (Команда Розробки)

Developers:

Scrum
 Product Owner

Щоб краще дізнатись про діяльність

Product Owner перегляньте ролик від
Хенрика Книберга «Agile Product
Ownership in a nutshell»

англійською
 Product Owner

• Визначає мету створення продукту (Product Goal)

• Визначає, які функції матиме продукт
• Пріоритизує backlog продукту у відповідності з
цінністю для бізнесу
• Коригує пріоритети на кожному спринті
• Визначає дату релізу та обсяг продукту
• Відповідає за окупність інвестицій (Return on
investment)
 Scrum Master
Scrum Master організує роботу команди
• Стежить за коректним проєкту, але не втручається в її роботу
застосуванням принципів Agile і
процесів (ритуалів) Scrum Тобто:

• Організовує роботу команди і Scrum Master не призначає людей на

забезпечує її всім необхідним
• Захищає команду, несе
відповідальність за її ефективність
завдання
Це робить сама команда
Scrum Master не змушує людей робити
роботу
Це відповідальність команди
Scrum Master не вказує Product Owner які
вимоги він повинен написати
Це робота власника продукту
 Developers Team

● Створює продукт
● Самоорганізується для досягнення мети
● Пропонує ідеї для поліпшення процесу

При плануванні спринту визначає:

• тривалість спринту
• трудомісткість вимог, які будуть реалізовані в спринті
• черговість виконання завдань
РОЛІ ТА ОБОВ’ЯЗКИ
 Артифакти Scrum

● Product Backlog (Беклог

продукту) з Product Goal
(Ціллю Продукту)
.
● Sprint Backlog (Беклог
спринту) з Sprint Goal (Ціллю
Спринту)
● Increment (Інкремент) з
Definition of Done, DoD
(Критеріями Готовності)
 Product Backlog
• Це список всіх вимог/функціональності, які потрібно
реалізувати у проєкті

• Ці вимоги/функціональності записані на зрозумілій мові.

.
• З вимог має бути зрозумілим, яку цінність кожна з них має
для користувача

• Вимоги відсортовані за пріоритетами, які переглядаються

кожен спринт
 Product Backlog
ID Назва Важливість Початкова Як продемонструвати
оцінка

1 Я користувач я 45 13 1. Зайти на сторінку Товару, додати товар у корзину..

хочу відкласти 2. Зайти у корзину, показати, що товар додано.
вибрані. товари у 3. Перейти на другий товар, додати його у корзину, та
кошик, а потім продемонструвати, що у корзині додані два товари.
переглянути що 4. Перевірити, що у корзині відображено ціну кожного
я відклав та товару та загальну суму
загальну суму 5. ….
товарів.

2 Я клієнт банку 30 21 Сплатити за товари з корзину з використанням

Приват, я хочу Приват24
сплачувати
через Приват24
 Product Backlog
• ID - унікальний ідентифікатор
• Назва - стислий опис вимоги/функціональності/користувацької історії
• Важливість - ступінь важливості вимоги/функціональності/користувацької
історії на думку Власника Продукту (PO)
• Попередня оцінка - початкова відносна оцінка трудоємкості
• Як продемонструвати - стисле пояснення того, як завершена
вимога/функциональность/користувацька історія може бути продемонстрована.
Product Backlog
 Product Goal

Ціль продукту (Product Goal) - це ключове уявлення вас і вашої

команди про те, що:
● буде являти собою продукт,
● для кого він буде створений,
● які у нього мають бути ключові функції/функціональності
● які завдання продукт має вирішувати
Sprint Backlog
Це список усіх вимог, які потрібно зробити
в найближчий спринт
Протягом спринту, нові вимоги не можуть
з'явиться в Sprint backlog
Всі вимоги повинні бути розділені на завдання
і оцінені
Sprint Backlog - це зобов'язання команди, тобто
те що команда має виконати за найближчу
ітерацію тижні
PRODUCT BACKLOG і
SPRINT BACKLOG
 Sprint Goal
Це стислий опис того, заради чого виконується даний спринт

Мета спринту допомагає команді приймати обґрунтовані рішення

Цей артефакт необхідний для того, щоб команда проєкту могла самостійно
приймати рішення в разі появи альтернативних шляхів вирішення завдання

Щоб рішення команди були усвідомленими, Product Owner визначає мету спринту
 Increment
Інкремент (Increment) — це конкретна сходинка до Цілі Продукту

Кожен Інкремент додається до всіх попередніх Інкрементів та ретельно

перевіряється, щоб гарантувати, що всі Інкременти працюють разом

Для забезпечення цінності, Інкремент повинен бути придатним для

використання

У Спринті можна створити багато Інкрементів

Сума Інкрементів представляється на Рев'ю Спринта (Sprint Review)

 Increment

Щоб краще зрозуміти, що таке Increment перегляньте це:

Scrum команда
 Sprints
Спринти (Sprints) - це події з фіксованою тривалістю близько
одного місяця чи менше.

Новий Спринт починається після завершення попереднього

Спринту.

Вся робота, необхідна для досягнення Цілі Продукту (Product

Goal), включаючи Планування Спринту (Sprint Planning),
Щоденні Скрами (Daily Scrums), Рев'ю Спринту (Sprint Review)
та Спринт Ретроспективу (Sprint Retrospective), відбувається під
час Спринтів.
 Події в Scrum
У Скрамі проводять чітко визначені типи нарад
що дозволяє систематизувати процес розробки та
звести до мінімуму потребу в нарадах, не
передбачених Скрамом.

Це:

• Sprint Planning Meeting

• Daily Meeting
• Sprint Review
• Retrospective
 Sprint Planning Meeting
(Зустріч з планування спринту)
Один з найважливіших заходів у методології Scrum. Виконується перед початком
спринту
Складається з:

• Визначення мети спринту (Sprint Goal)

• Відбір вимог з Product Backlog, необхідних для досягнення мети спринту та

формування списку вимог, які будуть реалізовані у поточному спринті (Sprint
Backlog)

• Декомпозиції вимог на завдання (Tasks)

• Оцінку кожного завдання (Task) у трудовитратах або універсальних одиницях.

 Sprint Planning Meeting
(Зустріч з планування спринту)
Підсумком планування:
• Мета спринту (Sprint Goal)
• Список учасників команди (і ступінь їх зайнятості, якщо вона не
стовідсоткова)
• Sprint backlog (список історій/вимог/функціональностей які увійшли в
спринт)
• Дата демонстрації (тобто визначення довжини спринту)
• Місце і час проведення щоденного Scrum'а
 Sprint Planning Meeting
(Зустріч з планування спринту)
Власнику продукту (Product Owner) та Команді Розробки
(Developers) потрібно працювати над плануванням спринту
(Sprint Planning) разом, тому що кожна
історя/вимога/функціональність має три параметри: Обсяг роботи
Обсяг робіт і важливість завдань
визначаються Product Owner'ом. Оцінка
трудовитрат - це прерогатива команди
розробки
Завдяки взаємодії команди розробки і Оцінка Важливість
product owner'а в ході планування спринту
виробляється оптимальне співвідношення
всіх трьох параметрів
 Sprint Planning Meeting
(Зустріч з планування спринту):
розклад
Планування спринту: з 13:00 до 17:00 (після кожної години перерву на 10 хвилин)
• 13:00 - 13:30. Product owner роз'яснює мету спринту і розповідає про
найважливіші елементи (історії/функціональності/вимоги) з product backlog'а.
Обговорюється час і місце проведення демо.
• 13:30 - 15:00. Команда проводить оцінку часу, який буде потрібно на розробку
елементів з product backlog'а і, при необхідності дробить їх на більш дрібні. У
деяких випадках product owner може змінити пріоритет їх виконання. З'ясовуємо
все що нас цікавить та заповнюємо поле «Як продемонструвати».
• 15:00 - 16:00. Команда визначає набір елементів з product backlog'а, які увійдуть в
наступний спринт. Тобто форумємо sprint backlog.
• 16:00 - 17:00. Домовляємося про час і місце проведення щоденного Scrum'а.
Після чого приступаємо до розбиття елементів на завдання.
 Sprint Planning Meeting
(Зустріч з планування спринту):
розклад
Планування спринту: з 13:00 до 17:00 (після кожної години перерву на 10 хвилин)
• 13:00 - 13:30. Product owner роз'яснює мету спринту і розповідає про
найважливіші елементи (історії/функціональності/вимоги) з product backlog'а.
Обговорюється час і місце проведення демо.
• 13:30 - 15:00. Команда проводить оцінку часу, який буде потрібно на розробку
Краще зробити окрему зустріч з впорядкування та уточнення
елементів з product backlog'а і, при необхідності дробить їх на більш дрібні. У
елементів backlogу - Product Backlog Refinishment
деяких випадках product owner може змінити пріоритет їх виконання. З'ясовуємо все
що нас цікавить та заповнюємо поле «Як продемонструвати».
• 15:00 - 16:00. Команда визначає набір елементів з product backlog'а, які увійдуть в
наступний спринт. Тобто форумємо sprint backlog.
• 16:00 - 17:00. Домовляємося про час і місце проведення щоденного Scrum'а.
Після чого приступаємо до розбиття елементів на завдання.
 Sprint Planning Meeting:
Визначення Довжини Спринту
Одна з основних завдань планування спринту - це визначення дати демо. А це
означає, що вам доведеться визначитися з довжиною спринту.

Переваги коротких спринтів:

Дозволяють компанії бути максимально "гнучкою", а значить готової
часто коригувати свої плани
Короткий спринт = короткий цикл зворотного зв'язку = часті релізи =
швидкі відгуки від клієнтів = менше часу витрачається на роботу в неправильному
напрямку = швидке навчання, вдосконалення і т.д.

Переваги більш довгих спринтів:

Залишається більше часу, щоб набрати темп, більше простору для маневрів, щоб
вирішити виниклі проблеми, а також більше часу для досягнення мети спринту,
менше накладних витрат, таких як планування спринту, демо і т.д.
 Sprint Planning Meeting: Визначення
Довжини Спринту
Більшість команд використовують або тритижневий спринт, або двотижневий
спринт

Експериментувати з довжиною спринту потрібно на початковому етапі. Виберіть

відповідну довжину і використовуйте її на
протягом одного або двох спринтів. Якщо довжина не задовольняє, то можете
вибрати нову

Як тільки ви знайдете довжину, яка вашій коменді підходить, зафіксуйте її

Після фіксації, довжина спринту залишається незмінною

 Вибір елементів, які
увійдуть у спринт

Sprint backlog - це вибірка елементів з product backlog'a, щодо яких команда

взяла на зобов'язання виконати протягом спринту

Саме команда вирішує, скільки елементів увійде в спринт

У зв'язку з цим, виникають два питання:

1. Яким чином команда вирішує, які елементи потрапляють в спринт?

2. Як product owner може вплинути на їх рішення?
 Вибір елементів, які
увійдуть у спринт
Як product owner може вплинути на те, які історії увійдуть
у спринт:

Product owner хоче, щоб історія "Г"

попала в спринт. Що він може зробити
в ході наради?
 Вибір елементів, які увійдуть у
спринт
Варіант 1 - Зміна пріоритетів

Варіант 2 - Зміна обсягу робіт

Варіант 3 - Розбиття історії

 Вибір елементів, які
увійдуть у спринт

Яким чином команда вирішує, які елементи

потрапляють в спринт?

Два підходи:

1. на основі інтуїції
2. на основі підрахунку продуктивності у попередні
спринти
 Вибір елементів, які увійдуть у
спринт: На основі інтуїції
ScrumMaster: "Хлопці, ми закінчимо" А "в цьому спринті?" (Показує на
найважливішу історію в product backlog)
Ліза: "Звичайно, закінчимо. У нас є три тижні, а це досить тривіальна
функціональність ".
ScrumMaster: "Добре. А як на рахунок "Б"? " (Показує на другу за
важливістю історію)
Том і Ліза одночасно: "Легко!"
ScrumMaster: "Добре. Як на рахунок історій "А", "Б" і "В"? "
Сем (звертаючись до product owner): "Чи потрібно реалізовувати
розширену обробку помилок для "В"? "
Product owner: "Ні. Поки вистачить базової ".
Сем: "У такому випадку " В "ми теж закінчимо".
ScrumMaster: "Добре, як на рахунок історії" Г "?"
Ліза: "Хмм ..."
Том: "Думаю, що зробимо".
ScrumMaster: "Вірогідність 90% або 50%?"
Ліза і Том: "швидше 90%."
Вибір елементів, які увійдуть у
спринт: На основі інтуїції
ScrumMaster: "Добре, значить, включаємо історію" Г "в цей
спринт.
Що скажете на рахунок історії "Д"? "
Сем: "Можливо".
ScrumMaster: "90%? 50%? "
Сем: "Ближче до 50%".
Ліза: "Сумніваюся".
ScrumMaster: "У такому випадку, не включаємо історію" Д ".
Зобов'язуємося реалізувати історії "А", "Б", "В" і "Г".
Звичайно, якщо встигнемо, то реалізуємо і історію "Д", однак не
варто на це розраховувати. Тому історію "Д" виключаємо з плану
спринту.
Чи згодні? "
Всі згодні".
 Вибір елементів, які увійдуть
у спринт: На основі
підрахунку продуктивності у
попередні спринти
Цей підхід включає в себе два етапи:

1. Визначити прогнозовану продуктивність.

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

Продуктивність розраховується як сума первинних оцінок всіх елементів зі sprint backlog, які
дійсно були реалізовані протягом спринту
 Вибір елементів, які увійдуть у
спринт: На основі підрахунку
продуктивності у попередні
спринти
.

А що, якщо елемент був майже закінченим?

Чому ми його не врахували?

Тому, що Scrum орієнтований на те, щоб створювати закінчений, готовий

до постачання продукт!
Цінність у реалізованому наполовину елементі немає
 Вибір елементів, які увійдуть у
спринт: На основі підрахунку
продуктивності у попередні
спринти
.

Підхід відомий під назвою вчорашня погода

1. Аналізується попередні результати команди за декількох останніх спринтів.

2. Підраховують середнє арифметичне.

Цей Він виправданий для тих команд, які вже провели кілька спринтів (тобто є
статистичні дані) і планують наступний спринт без
істотних змін, тобто той же склад команди, робочі умови
 Облікові картки та стіна кращі
інструменти для Sprint Planning Meeting
Облікові картки та стіна виграють в порівнянні з комп'ютером і проєктором, з наступних
причин:
• Люди змушені вставати і ходити, тому вони більш сконцентровані і не засинають
• Кожен відчуває себе причетним до процесу (а не тільки хлопець за клавіатурою)
• Можна редагувати кілька історій одночасно.
• Змінити пріоритети дуже просто - достатньо поміняти місцями облікові картки
• Після закінчення зустрічі облікові картки можна забрати в кімнату, де працює команда, і
використовувати їх на дошці завдань

Елемент з backlog зазвичай можна оцінити легше і точніше, якщо він

розбита на задачі (task).
На нашій дошці ми відображаємо задачі у вигляді маленьких стікерів під
кожним елементов backlogу
 Критерії готовності
Важливо, щоб і product owner, і команда спільними зусиллями
визначили критерій готовності. Тобто коли робота над елементом
вважається завершеною
 Оцінка трудовитрат за
допомогою Planning Poker
Story Points— це відносні оцінки обсягу роботи
Для оцінки кожного завдання використовують техніку
для завдання. Немає способу оцінити одне-єдине
Покер Планування. завдання у story points, ви завжди порівнюєте
завдання з іншими через story points.

Є кілька варіантів колод карт, які використовуються у цій техніці:

• Колода з послідовністю
чисел Фібоначчі: 0, 1, 2, 3,
5, 8, 13, 21, 34, 55, 89.

• Колода зі значеннями: 0,?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?»,

«Чашка кави».

Знак питання - “Не можу оцінити”, “Бракує інформації або

досвіду”
Чашка кави - «Я втомився, давайте відпочинемо».
 Оцінка трудовитрат за
допомогою Planning Poker
1. Кожному учаснику обговорення видається по одній колоді карт.
2. На обговорення виносяться по черзі завдання або user story, які необхідно оцінити.
3. Кожне завдання можливо обговорити без оцінювання
4. Після цього кожен член команди вибирає карту, що на його думку відповідає трудовитратам на
завдання, і кладе її сорочкою вгору.
5. Коли всі участники поклали карти, то іх перегортають
6. У відкритих картах будуть карти з найменшим та найбільшим значенням.
7. Учасники, які вибрали карти з найменшим та найбільшим значенням дають пояснення щодо
своєї оцінки.
8. Інші учасники отримують додаткову інформації з цих пояснень для своєї оцінки.
9. Після цього оцінка повторюється знову.
10. У ідеалі досягнуті близькі оцінки всіма учасниками. Якщо цього не сталось, то перевага
віддається оцінці того, хто буде безпосередньо буде виконувати завдання.
 Уточнення описів елементів backlogу
Немає нічого жахливіше, ніж ситуація, коли команда з демонструє нову
функціональність продукту, а product owner тяжко зітхає і каже: "ну да - все не те,
що я просив! "

Як переконатися, що product owner і команда розуміють історію однаково?

Або що всі члени команди розуміють всі історії однаково?

Найбільш проста практика - завжди заповнювати всі поля для кожного елементу
backlogу, які можуть потрапити в поточний спринт.
Обговорюйте всі деталі.
 Уточнення описів
елементів backlogу
Наприклад,
Scrum master: "Хвилиночку! Ось тут у нас є елемент "додати користувача" ... Як вона
може бути продемонстрована? ".
Член команди розробки: "ну, для початку треба залогінитися на сайт, потім ... "
Рroduct owner:" залогінитися на сайт ?! Ні ... ця
функція взагалі до сайту не повинна мати ніякого відношення - це буде просто
маленький SQL-скрипт, тільки для адміністраторів ").
 Daily Meeting
Щоденна зустріч команди
Проходить щодня і тільки в один і той же час;
Зустріч проходить тільки стоячи;
Тривалість зустрічі не більше 15 хвилин;
Кожен учасник повинен відповісти на 3 питання:

1. Що я робив вчора?
2. Чим я займаюся сьогодні?
3. Які є проблеми?

Перед або на зустрічі оновлюється

дошка задач
 Sprint Review
Здача спринту власнику продукту
Після завершення кожного спринту команда зобов'язана провести демонстрацію
досягнутого результату

Цінність Scrum для звичайного замовника багато в чому полягає в тому, що

результат робіти буде продемонстровано в будь-якому випадку. Це знає
команда, власник продукту і інші зацікавлені особи
Якщо команда не проводить демонстрацію (інша назва Sprint Review), то це
дискредитує всі переваги гнучкої розробки
 Sprint Review
Здача спринту власнику продукту
На здачі спринту власнику продукту:

1. Команда зачитує вимоги з Sprint Backlog

2. У кожної з вимог є критерії приймання
3. За кожним критерієм приймання відбувається демонстрація отриманих
результатів
4. Команда отримає зворотній зв’язок від Власника Продукту
5. Кожне питання з боку Product Owner'а записується, щоб мати
можливість відповісти на них пізніше
6. Кожна нова вимога Product Owner'a виписується, щоб пізніше включити
її до Product Backlogу.
 Retrospective
Ретроспектива це процес обговорення роботи з метою поліпшення з результатів в
майбутньому

Зустріч проводиться після Sprint Review.

На зустрічі присутні вся команда,Scrum Master. На зустрічі може бути присутнім

Product Owner, якщо вважає за потрібне.
При Ретроспективі повинні бути озвучені відповіді на
наступні запитання:

Які зробити процес більш передбачуванним?

Які проблеми заважають команді виконувати взяті
на себе зобов'язання?
Як поліпшити взаємодію з Product Owner'ом?
Які помилки робить команда і чому?
 Retrospective
Три колонки:

• Добре: Якщо потрібно було б

повторити цей спринт ще раз, то ми
б зробили це точно так же.
• Чи могло б бути і краще: Якщо
потрібно було б повторити цей
спринт ще раз, то ми б зробили
це по-іншому.
• Покращення: Конкретні ідеї про
те, як в майбутньому можна щось
поліпшити.
 Retrospective
"Точкове голосування" для визначення поліпшень, яким слід приділити
особливу увагу в ході
наступного спринту.

● У кожного члена команди є три магніта для голосування.

● Кожен член команди може ліпити магнітики як йому заманеться
● За результатами голосуванні вибираємо 5 поліпшень, які ми спробуємо
впровадити в наступному спринті
● На наступній ретроспективі ми перевіримо, що у нас вийшло.
 Ваша команда точно працює за
Scrum?
Для перевірки використовується:

● Scrumbutt Test (aka the Nokia Test)

http://jeffsutherland.com/scrum/ScrumButtTest.pdf
http://www.sierra-charlie.com/download/SB023-The%20Nokia%20Test.pdf

● Crisp Scrum Checklist ( від Хенріка Кніберга)

https://www.crisp.se/gratis-material-och-guider/scrum-checklist
https://www.crisp.se/wp-content/uploads/2012/05/Scrum-checklist.pdf
 Основні положення SCRUMBUTT
TEST (aka the Nokia Test)
Ви дійсно займаєтесь ітеративной розробкою?

● Ітерації повинні бути обмежені за часом менше 6 тижнів.

● Програмні функції повинні тестуватися і працювати в кінці кожної ітерації.
● Ітерація повинна початися до завершення специфікації

Ви дійсно робите за SCRUMом (на думку Nokia)?

● Команда знає свого власника продукту (product owner)
● Є пріоритезований backlog, що враховує бізнес цінність
● Команда сама оцінює завдання з backlogу
● Команда формує burndown діаграму і знає швидкість своєї роботи
● Немає проєктного менеджера, що втручається в роботу команди
 Основні положення Crisp
Scrum Checklist
● 1. Досягнення цілей командної роботи:

● Постачання працюючого протестованого програмного

забезпечення кожні 4 або менше тижнів
● Продукт містить те, що найбільше потрібно бізнесу
● Процес постійно вдосконалюється
 Основні положення Crisp
Scrum Checklist
● Чітко визначений Власник продукту (Product Owner, PO)
○ PO уповноважений розставляти пріоритети
○ PO має знання у пріоритизації
○ PO контактує з командою безпосередньо
○ РО контактує з зацікавленими лицями безпосередньо
○ РО розмовляє у один голос
● У команди є sprint backlog
○ Його добре бачать
○ Оновлюється щодня
○ Належить виключно команді
● Проводимо щоденний скрам (daily scrum)
○ Приймає участь вся команда
○ Виявляємо проблеми та перешкоди
 Основні положення Crisp
Scrum Checklist
● Демонстрація в кінці кожного спринту
○ Показуємо працюючий та перевірений софт
○ Отримуємо зворотній зв’язок від PO та зацікавлених осіб

○ Визначені критерії готовності (Definition of Done, DoD)

○ DoD досяжні
○ Команда поважає DoD
● Ретроспектива після кожного спринту
○ Результат ретроспективи є конкретні пропозиції щодо поліпшення
○ Деякі пропозиції дійсно впроваджуємо
○ Приймає участь вся команда та PO
 Основні положення Crisp
Scrum Checklist
● PO веде backlog продукту
○ Верхні елементи backlogу продукту впорядковані за цінністю для бізнесу
○ Верхні елементи backlogу оцінені
○ Оцінки дані безпосередньо командою
○ Верхній елементів достатньо мало, щоб встигнути за один спринт
○ PO розуміє мету кожного елементу backlogу
● Проводиться зустріч з планування спринту (sprint planning meeting)
○ PO бере участь
○ Участь бере вся команда
○ Результати - sprint backlog
○ Вся команда вважає, що sprint backlog є досяжним
○ РО задоволений пріоритетами
○ PO надає актуальний Product Backlog
 Основні положення Crisp
Scrum Checklist
● Обмеження за часом ітерації
○ Тривалість ітерації 4 тижні або менше
○ Завжди закінчується вчасно
○ У роботу команди не втручаються сторонні
● Члени команди сидять разом
○ Не більше 9 членів у команді
Scrum - це не серія міні
“водоспадів”
 Література

1. http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-
from-the-trenches-rus-final.pdf
2. https://scrumguides.org/
Дякую за увагу!