• обговорити, що ти зробив/-ла вчора, що плануєш робити сьогодні і ЧИ з'явилися якісь блокери під час виконання завдання
  
  

• декомпозувати завдання беклогу, які перед тим були створені власником продукту або проектним менеджером у порядку пріоритетності
  
  

• додати опис user story і за необхідності acceptance criteria; якщо завдання технічне і не несе прямої бізнес цінності для user story, додається опис кроків реалізації
• обговорити гіпотетичні блокери та ризики (наприклад, бракує інформації для виконання, є залежність із іншим невиконаним завданням (finish-to-start dependancy), вперше стикаємось із таким функціоналом, вже мали негативний досвід роботи із вказаним функціоналом, і т.п.)
• оцінити завдання
• доповнити беклог додатковими необхідними завданнями, які команда виявила під час обговорення

• спланувати наступний спринт, беручи завдання, які вже декомпозовані та описані
  • визначити ціль спринта
  • спланувати навантаження на спринт на основі швидкості команди і оцінки завдань
  • призначити виконавця завдання

Суть планування - реалістично оцінити завдання і взяти в роботу тільки те, що команда встигне зробити за спринт, слідуючи Definition of Done.

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

• проаналізувати спринт, а саме:

  • продемонструвати команді виконаний результат (що відповідає Definition of Done) - кожен презентує свою роботу

  • проаналізувати capacity і velocity команди (чи все встигли зробити із запланованого, і на основі цих висновків планувати наступний спринт)
  • провести ретроспективу:
    • що було зроблено добре
    • що було зроблено недобре
    • ідеї для покращення
    • action items

завдання, яке описує потребу користувача і як її втілити, і написане доступною мовою зрозумілою мовою. Оскільки наші продукти технічні, і кінцевим користувачем є QA (Testlum) і розробники (JBT, Profile API), наші user stories мають технічний характер і не завжди будуть зрозумілими нетехнічним спеціалістам, однак у суті своїй кожному тіммейту має бути ясно, що ми хочемо досягнути тою чи іншою user story.

Як писати user story?

1. Обовʼязкова цінність для продукту: щоб виявити бізнес цінність у технічних user story, можна поставити собі наступні запитання:

   1. Як виконання цього технічного завдання сприяє досягненню наших загальних бізнес-цілей?
   2. Які можливі негативні наслідки для бізнесу, якщо це технічне завдання не буде виконано?
   3. Як невиконання цього завдання може вплинути на продуктивність або ефективність команди або процесів?
   4. Які ризики або вразливі місця для безпеки, конфіденційності чи цілісності даних можуть виникнути, якщо не вирішити це завдання?
   5. Чи невирішення цього завдання не завадить масштабуванню чи майбутньому зростанню бізнесу?
   6. Які залежності можуть виникнути для інших проектів, якщо це технічне завдання залишиться невирішеним?

2. Обов'язкові ознаки user story (за моделлю INVEST):

   1. 1. • Independent: The user story should be independent of all others. Because they are not connected, they can be worked on in any order.
         • Negotiable: A user story should be flexible enough to allow for negotiation between the customer and product owner.
         • Valuable: What value does the user story bring? If you cannot find any value, the story should not be completed.
         • Estimable: You should be able to estimate how long a user story will take so that you can effectively manage your time.
         • Small: The story must be small enough to be completed within a single sprint.
         • Testable: You must be able to test your user story in line with quality assurance standards.

3. Формат

   1. Three-part user story: As a [end user], I want [feature] so that [benefit]” = role, goal, and reason.
      Example: As a customer, I want to be able to easily track the status of my online order, so that I can stay informed about its progress and anticipate delivery.

   2. Gherkin user story: Scenario -> Given -> When -> Then
      Example: 
      Scenario: Jeff returns a faulty microwave
      Given Jeff has bought a microwave for $100
      And he has a receipt
      When he returns the microwave
      Then Jeff should be refunded $100

4. До User story рекомендовано додавати acceptance criteria (в ідеалі, додає QA, бо саме він/вона приймає завдання)

   1. Наприклад:
      As a QA professional, I want to easily create and manage test scenarios using an automated testing tool, so that I can efficiently design and execute tests.
      1. As a QA professional, I want to define test scenarios using a user-friendly syntax, so that I can easily create and maintain test cases.
      2. As a QA professional, I want to be able to specify preconditions and setup steps in my test scenarios, ensuring that the test environment is properly configured.
      3. As a QA professional, I want to have access to a wide range of predefined test steps and actions within the automated testing tool, reducing the need for custom implementation.
      4. As a QA professional, I want the tool to provide autocomplete and suggestions while writing test scenarios, helping me avoid errors and ensuring consistency.
      5. As a QA professional, I want the ability to organize and categorize test scenarios into meaningful groups or test suites, facilitating test management and execution.
      6. As a QA professional, I want the automated testing tool to generate readable and comprehensive test reports that highlight test coverage, execution status, and any failures encountered.

використовується як найменша одиниця декомпозиції завдання; створюється розробником, якщо є потреба виділити якийсь крок технічної реалізації.