Як обговорювати Sprint Carryover англійською мовою

Перенесення спринту — робота, яка не була закінчена і переноситься в наступний спринт — це нормально, але те, як це обговорюється, формує, чи команда виглядає, як вона бореться, чи просто пристосовується до реальної інформації. Неясні пояснення («у нас просто закінчився час») заохочують скептицизм, тоді як конкретні пояснення будують довіру, навіть коли новини не дуже хороші. Цей підручник містить англійську мову для обговорення перенесення.

Ключовий словник

** Перенесення елемента ** — певна частина роботи, яку не було завершено у рамках спринту і яку переносять до наступного, відрізняється від роботи, яку було повністю скорочено. “Це перенесення, а не скорочення — це зроблено на 80% і ми очікуємо завершити його в перші два дні наступного спринту.”

** Вивчення обсягу ** — нова інформація, отримана під час спринту, яка виявила, що робота була більшою, ніж спочатку очікувалося, що є поширеною і законною причиною перенесення. “Перенесення не пов’ язане з повільним виконанням — це виявлення обсягу. Ми виявили, що міграція потрібна для обробки трьох застарілих форматів даних, про які ми не знали на час планування. ”

** Заблокований час ** — час під час спринту, коли елемент не міг просунутися через зовнішню залежність, відмінний від часу, витраченого на активну роботу над ним. “Два з п’яти днів на цей пункт були заблоковані, очікуючи на перегляд безпеки від іншої команди - фактичний час інженерії був ближче до трьох днів.”

** Переоцінка ** — оновлена оцінка залишкової роботи, надана з користю того, що було вивчено під час спринту, замість повторення початкового числа. “Засновано на том, что мы теперь знаем, переоценка для оставшейся работы составляет два дня, ниже нашей первоначальной оценки в пять дней для всего элемента.”

** Переприоритизація ** — рішення про те, чи має перенесення елемента бути першим пріоритетом наступного спринту, чи має поступитися місцем чомусь більш невідкладному, що з’ явилося з того часу.

• « Зважаючи на перенесення, нам потрібна розмова щодо зміни пріоритету — чи має ця розмова перевагу перед новим запитом від команди підтримки? » *

Звичайні фрази

• Це перенесення пункту — ось конкретно чому він не закінчився
• «Це була не проблема швидкості, це було відкриття обсягу — ми дізналися [конкретну річ] посередині»
• «Частина цього часу була заблокована, чекаючи на [спеціальну залежність]»
• «Засноване на тому, що ми знаємо зараз, переоцінка є [специфічною новою оцінкою]»
• «Чи цей перенесений елемент все ще має пріоритет у наступному спринті, або з’явилося щось більш невідкладне?»

Приклади висловлювань

Пояснюючи перенесення, не звучачи оборонно:

• “Цей пункт перенесено, і я хочу вказати, чому: під час реалізації ми виявили, що сторонній API не підтримує пакетні запити, як це передбачено у документації, що призвело до двох днів незапланованої роботи. Наразі це 70% зроблено.»*

Відрізняти заблокований час від повільного прогресу: “Це не тому, що команда була повільною в цьому - два повних дні були заблоковані в очікуванні на юридичний підпис для політики зберігання даних, яку ми не передбачали потреби в часі планування. Активний інженерний час був на шляху.»

Відкриття розмови щодо зміни пріоритету:

• “Оскільки це перенесення, я хочу перевірити, чи це все ще має бути найвищим пріоритетом наступного спринту — інцидент з минулого тижня викрив пов’ язану проблему, яку, можливо, слід вирішити першою.” *

Професійні поради

• Назвемо ** конкретну причину ** для перенесення (обсяг відкриття, заблокований час, недооцінка), а не нечітке «ми закінчилися часом» - конкретні причини будують більше надійності, ніж загальне виправдання.
• Розрізняйте заблокований час від активний робочий час, коли пояснюєте затримку — завдання, яке було заблоковано на два дні з п’ яти, є зовсім іншим завданням, ніж завдання, яке було виконано за п’ ять днів активних зусиль і яке досі не виконано.
• Надати ** переоцінку ** на основі нової інформації, а не повторювати початкову оцінку — це показує, що ви дійсно включили те, що було вивчено, а не просто сподіватися, що те саме число зберігається.
• Використовувати перенесення як тригер для розмови щодо ** зміни пріоритету **, а не припущення, що елемент автоматично залишається найвищим пріоритетом — пріоритети можуть змінюватися між спринтами з гідних причин.

Практичні вправи

1. Напишіть пояснення у два речення щодо перенесення елемента, у якому буде вказано причину, з якої його не було завершено.
2. Напишіть одне речення, у якому буде показано відмінність між блокованим часом і активним робочим часом для завдання з відстрочкою.
3. Напишіть речення, яке відкриває розмову про зміну пріоритету щодо перенесення елемента.

Навігація Nuance: Специфічна мова для перенесення запитів

Будьмо чесними - “перенесення” може відчувати себе як технічний термін, який закриває справжню причину того, що щось не було завершено в спринті. Для людей, для яких англійська мова не є рідною, точна мова навколо нього є особливо важливою, оскільки вона безпосередньо впливає на те, як приймаються ваші ідеї і запити. Це не тільки про те, що ви кажете, але і як ви це формулюєте - зосереджуючись на спільному вирішенні проблем, а не просто вказуючи на те, що не було зроблено. Ключовим зсувом є відхід від тверджень, які можуть звучати обвинувачуючими («Ми не змогли закінчити X») і до рішень, зосереджених на майбутньому плануванні («Щоб переконатися, що ми доставляємо основні функції в цьому спринті, чи можемо ми дослідити перенесення [спеціфічного завдання]?»).

Розглянемо такий сценарій: ви відповідаєте на коментар перегляду коду щодо можливості, яку ще не було завершено. Замість відповіді « У мене не було часу », яка може звучати відверто, спробуйте щось на зразок « Дякую за відгук! Я усвідомлюю, що реалізація [назва можливості] трохи відстала від розкладу. Щоб забезпечити його завершення в наступному спринті, я пропоную присвятити йому два дні, зосередившись на [конкретних завданнях, визначених в огляді]. Це дозволить мені вирішити поставлені питання і надати повністю функціональну версію. ” Зауважте, що це пояснення включає визнання затримки, надання конкретного рішення з визначеною хронологією і демонстрацію розуміння перспективи рецензента. Використання фраз на кшталт «незначно відстає від плану» часто більш смачне, ніж заява про пряму невдачу.

Інша поширена ситуація виникає в каналах Slack під час обговорення майбутніх спринтів. Припустимо, що вам потрібно запитати про перенесення завдання з попереднього спринту. Просте «Чи можемо ми перенести це?» не має контексту і може викликати питання про те, чому воно не було завершено спочатку. Замість цього, створіть повідомлення на зразок: « Привіт, команда, я дивлюся на наступний спринт і усвідомлюю, що у нас є значне перекриття з [назва завдання] з минулого тижня. Щоб оптимізувати наш робочий процес і переконатися, що ми визначаємо пріоритети найважливіших пунктів, чи можемо ми обговорити перенесення [назва завдання] приблизно на пів дня, щоб зосередитися на [новий пріоритет]? Це дозволить нам повністю розв’ язати [спеціфічний виклик, пов’ язаний з завданням]. » Ключовим тут є те, щоб розглядати це як рішення щодо * оптимізації *, а не як скаргу на минулу продуктивність.

Нарешті, коли ви пишете описи PR, запитуючи перенесення, будьте винятково чіткими. Не просто скажіть « Перенести на наступний спринт ». Замість цього, описайте, * чому * це завдання переноситься і що ви плануєте з ним робити: « Запит на перенесення [назва завдання] з спринту 3 через непередбачені складності інтеграції з [зовнішньою системою]. » Ця робота буде пріоритизована під час Спринту 4, зосереджуючись на [спеціальних завданнях], і буде робити безпосередній внесок у завершення [загальної мети]. “Цей рівень деталізації демонструє професіоналізм і прихильність до надання цінності.