قصص المستخدم

قصة المستخدم (User Story) وصف قصير لحاجة من وجهة نظر من سيستفيد منها، وتُكتب عادة بهذه الصيغة: "بصفتي [نوع المستخدم]، أريد [شيئاً ما]، حتى [أحقق فائدة]". الجزء الأخير هو الأهم، لأنه يشرح لماذا نبني هذه الميزة أصلاً. والقصة ليست وثيقة كاملة، بل تذكير بحوار يجري بين الفريق ومالك المنتج.

لكل قصة معايير قبول (Acceptance Criteria): شروط محددة تقول متى تُعتبر هذه القصة بالذات منجزة كما يريد المستخدم. ويختلف ذلك عن "تعريف الإنجاز" (Definition of Done)، وهو قائمة جودة مشتركة تنطبق على كل القصص، مثل: الكود مُراجَع، والاختبارات ناجحة، والتوثيق محدّث. القصة لا تكتمل إلا إذا حققت الاثنين معاً.

القصة الجيدة تتبع معيار INVEST: مستقلة (Independent) قدر الإمكان، وقابلة للتفاوض (Negotiable)، وذات قيمة (Valuable) للمستخدم، وقابلة للتقدير (Estimable)، وصغيرة (Small) تكفي لسبرنت واحد، وقابلة للاختبار (Testable). وإذا كانت القصة كبيرة جداً، وتسمى أحياناً "ملحمة" (Epic)، نقسمها إلى قصص أصغر يقدّم كل منها قيمة، مثلاً حسب نوع المستخدم أو طريقة الدفع أو المسار البسيط أولاً ثم الحالات الخاصة.

تنقيح قائمة المنتج (Backlog Refinement) نشاط مستمر يجتمع فيه مالك المنتج والفريق لتوضيح القصص القادمة، وإضافة معايير القبول، وتقسيم الكبيرة منها، وتقديرها. الهدف أن تكون القصص في أعلى القائمة جاهزة قبل تخطيط السبرنت، فلا يضيع وقت التخطيط في أسئلة كان يمكن حلها مسبقاً.