سجل المنتج (Product Backlog): كيفية بنائه وترتيب أولوياته بفعالية

يُعد الـ product backlog بمثابة المحرك الأساسي للتطوير وفق منهجية agile. فكل ميزة (feature)، وإصلاح للأخطاء (bug fix)، وتحسين، ومهمة تقنية قد يتم بناؤها مستقبلاً توجد في الـ backlog — مرتبة حسب الأولوية، ومُقدّرة الحجم، وجاهزة ليتم سحبها إلى الـ sprint.

إن الـ backlog المُدار بشكل جيد هو أحد أوضح العلامات على نضج فريق agile. أما الـ backlog المُهمل — الذي يحتوي على مئات العناصر، والكثير منها غير ذي صلة، مع أولويات غير واضحة، وبدون تقديرات — فهو أحد أكثر العلامات تأكيداً على أن عملية الفريق تحتاج إلى اهتمام.

يغطي هذا الدليل كيفية بناء الـ product backlog من الصفر، وكيفية الحفاظ عليه، وكيفية ضمان أنه يقود عملية التطوير فعلياً بدلاً من أن يظل مجرد مستودع غير منظم للأفكار.

ما هو الـ Product Backlog؟

في منهجية Scrum، الـ product backlog هو قائمة مرتبة بكل ما قد يتم القيام به لتحسين المنتج. وهو مملوك لـ Product Owner ويُعد المصدر الوحيد للحقيقة فيما يتعلق بما سيعمل عليه الفريق.

يحتوي الـ backlog على:

User stories — ميزات موصوفة من منظور المستخدم.
Bug fixes — عيوب يجب حلها.
Technical debt — تحسينات على جودة الكود، أو البنية التحتية، أو الهندسة.
Spikes — مهام بحثية لتقليل عدم اليقين قبل الالتزام بميزة معينة.
Non-functional requirements — تحسينات الأداء، والأمان، وسهولة الوصول.

يجب أن يكون كل عنصر في الـ backlog موجوداً لسبب ما: فهو يمثل قيمة محتملة للمستخدمين أو للعمل. العناصر التي لم تعد تمثل قيمة يجب حذفها، وليس فقط خفض أولويتها.

دور الـ Product Owner

يتحمل الـ Product Owner (PO) مسؤولية الـ backlog. وهذا يعني:

إضافة عناصر جديدة فور تحديدها.
إزالة العناصر التي لم تعد ذات صلة.
الحفاظ على الـ backlog مرتباً حسب الأولوية في جميع الأوقات.
التأكد من أن الجزء العلوي من الـ backlog جاهز ليعمل عليه فريق التطوير.

لا يقوم الـ PO بإنشاء الـ backlog بمعزل عن الآخرين. فالمساهمات تأتي من المستخدمين، وأصحاب المصلحة، والمطورين، والبيانات. لكن الـ PO هو من يتخذ القرار النهائي بشأن الأولوية.

يُعد نموذج المالك الواحد هذا أحد أهم مبادئ agile. فالـ backlogs التي تُدار بواسطة لجنة أو عبر التصويت الجماعي تميل إلى الحلول الوسط بدلاً من الترتيب الواضح للأولويات، وينتهي الأمر بالفرق وهي تعمل على كل شيء في وقت واحد.

كتابة عناصر الـ Backlog بشكل جيد

Epic

"User can export data"

Story

"As a user I can filter"

Task

"Add pagination to list"

صيغة الـ User Story

الصيغة القياسية للـ user story هي:

بصفتي [نوع المستخدم]، أريد [إجراء معين] حتى [فائدة معينة].

مثال: “بصفتي مديراً للمشروع، أريد تصفية المهام حسب الشخص المسؤول حتى أتمكن من رؤية عبء عمل فريقي في لمحة.”

تُجبرك هذه الصيغة على توضيح من المستفيد، وما الذي يحتاجه، ولماذا — وهي ثلاث قطع من السياق تمنع بناء الميزات لسبب خاطئ.

معايير القبول (Acceptance Criteria)

يجب أن يحتوي كل عنصر في الـ backlog على معايير قبول: وهي شروط محددة وقابلة للاختبار يجب أن تكون صحيحة لكي يُعتبر العنصر “مكتملًا” (done).

مثال على معايير القبول لمهمة التصفية:

يمكن للمستخدمين التصفية حسب شخص واحد أو أكثر من المسؤولين في وقت واحد.
يتم تحديث العرض المصفى في الوقت الفعلي دون إعادة تحميل الصفحة.
يتم حفظ حالة التصفية عندما ينتقل المستخدم بعيداً ثم يعود.
تظهر المهام غير المسندة عند اختيار “Unassigned”.

بدون معايير القبول، يظل تعريف “مكتمل” غير محدد. ومع وجودها، يعرف كل من المطور والمختبر بالضبط ما يجب التحقق منه.

معايير INVEST

تستوفي الـ user stories الجيدة معايير INVEST:

الحرف	المعنى
I	Independent (مستقلة) — يمكن تطويرها دون الاعتماد على قصة أخرى
N	Negotiable (قابلة للتفاوض) — يمكن تعديل التفاصيل في النقاش
V	Valuable (ذات قيمة) — تقدم قيمة للمستخدمين أو للعمل
E	Estimable (قابلة للتقدير) — يمكن للفريق تقدير الجهد المطلوب
S	Small (صغيرة) — يمكن إكمالها في sprint واحد
T	Testable (قابلة للاختبار) — لها معايير قبول واضحة

القصص التي تفشل في استيفاء هذه المعايير — عادةً لأنها كبيرة جداً، أو غامضة جداً، أو لا يمكن تسليمها بشكل مستقل — تحتاج إلى تنقيح قبل أن تدخل في الـ sprint.

تقنيات ترتيب أولويات الـ Backlog

Prioritization Methods

MoSCoW: Must/Should/Could/Won't

RICE: Reach x Impact / Effort

Weighted shortest job first

ترتيب الأولويات هو المكان الذي تتقاطع فيه رؤية المنتج مع البيانات. توفر العديد من الأطر هيكلاً لاتخاذ قرارات ترتيب الأولويات.

طريقة MoSCoW

صنّف كل عنصر إلى: Must have (يجب توفره)، Should have (ينبغي توفره)، Could have (يمكن توفره)، أو Won’t have (لن يتوفر في هذا الإصدار). هذا يخلق نظام أولويات بسيطاً من أربع درجات يمكن لأصحاب المصلحة فهمه والتفاعل معه.

نظام تسجيل RICE

يرمز RICE إلى Reach (الوصول)، Impact (التأثير)، Confidence (الثقة)، Effort (الجهد). يتم تسجيل كل عنصر بناءً على هذه الأبعاد وترتيبه حسب نتيجة RICE: (الوصول × التأثير × الثقة) / الجهد.

هذا هو ترتيب الأولويات الكمي — وهو يعمل بشكل جيد عندما يكون لديك بيانات حول الوصول والتأثير وتريد ترتيباً أكثر قابلية للدفاع عنه من مجرد الحدس.

مصفوفة القيمة مقابل الجهد (Value vs. Effort Matrix)

ضع كل عنصر من عناصر الـ backlog على مصفوفة 2x2: القيمة على محور، والجهد على المحور الآخر. العناصر الموجودة في مربع القيمة العالية والجهد المنخفض هي مكاسب سريعة ويجب إعطاؤها الأولوية. أما العناصر في مربع القيمة المنخفضة والجهد العالي فهي مرشحة للإزالة.

نموذج Kano

يصنف نموذج Kano الميزات حسب كيفية تأثيرها على رضا المستخدم:

الاحتياجات الأساسية — غيابها يسبب عدم الرضا؛ وجودها متوقع (must-haves).
احتياجات الأداء — المزيد منها أفضل (الميزات الأساسية).
المُبهِجات (Delighters) — ميزات غير متوقعة تزيد من الرضا بشكل كبير.

يساعد هذا الإطار في الموازنة بين ما يجب توفره وبين الابتكار.

تنقيح الـ Backlog (Backlog Grooming)

تنقيح الـ backlog — ويسمى أيضاً backlog refinement — هو العملية المتكررة لمراجعة وتحديث وتحسين عناصر الـ backlog. في Scrum، يحدث هذا عادةً مرة واحدة في كل sprint كاجتماع مستقل.

تتضمن جلسة التنقيح ما يلي:

مراجعة العناصر الجديدة — العناصر التي تمت إضافتها منذ آخر تنقيح. هل كُتبت بوضوح؟ هل لديها معايير قبول؟
تقدير العناصر — يقوم الفريق بتقدير الجهد للعناصر الموجودة في أعلى الـ backlog لتكون جاهزة لتخطيط الـ sprint.
تفكيك العناصر الكبيرة — يتم تفكيك الـ epics والقصص الكبيرة إلى عناصر أصغر بحجم الـ sprint.
التقليم (Pruning) — إزالة العناصر التي لم تعد ذات صلة، أو قديمة، أو مكررة.
إعادة ترتيب الأولويات — تعديل الترتيب بناءً على معلومات جديدة، أو ملاحظات أصحاب المصلحة، أو تغير أولويات العمل.

يعني إيقاع التنقيح الصحي أن الجزء العلوي من الـ backlog الخاص بك جاهز دائماً — مكتوب، ومُقدّر، ومرتب — للـ sprint القادم.

الحفاظ على صحة الـ Backlog

الـ backlog الذي ينمو إلى ما لا نهاية دون تقليم يصبح عبئاً. تتوقف الفرق عن الوثوق به لأنها تعلم أنه مليء بالعناصر التي لا ينوي أحد بناءها. إليك علامات الـ backlog الصحي وكيفية الحفاظ عليه.

علامات الـ Backlog الصحي

العناصر العشرة إلى الخمسة عشر الأولى منقحة وجاهزة للـ sprint.
جميع العناصر لها عناوين واضحة ومعايير قبول.
لا يحتوي الـ backlog على عناصر أقدم من ستة أشهر لم يتم إعطاؤها أولوية بالقرب من الأعلى.
قرأ الجميع في الفريق الجزء العلوي من الـ backlog مؤخراً.
يتم إزالة العناصر بانتظام، وليس فقط إضافتها.

قاعدة “إذا لم يتم بناؤها خلال ستة أشهر، احذفها”

تحمل العديد من الفرق مئات العناصر في الـ backlog التي لا نية لديهم لبنائها في الأشهر الستة المقبلة. هذا يخلق ضجيجاً يجعل الأولويات الحقيقية أصعب في الرؤية. قاعدة مفيدة: إذا كان العنصر في الثلث السفلي من الـ backlog لمدة ستة أشهر، قم بأرشفته أو حذفه. إذا كان مهماً، فسيظهر مرة أخرى.

فصل الـ Icebox

تحتفظ بعض الفرق بـ “icebox” — وهي مجموعة منفصلة من الأفكار والعمل المستقبلي المحتمل الذي ليس جزءاً صريحاً من الـ backlog النشط. العناصر الموجودة في الـ icebox ليست مرتبة، وليست منقحة، وليست مُقدّرة. يتم التقاطها فقط للنظر فيها مستقبلاً.

هذا يمنع الـ icebox من تلويث الـ backlog النشط ويجعل الـ backlog النشط أصغر، وأنظف، وأكثر جدارة بالثقة.

الـ Product Backlog مقابل الـ Sprint Backlog

الـ product backlog والـ sprint backlog مرتبطان ولكنهما متميزان:

	Product Backlog	Sprint Backlog
النطاق	كل ما قد يتم بناؤه	ما يلتزم الفريق به في هذا الـ sprint
المالك	Product Owner	فريق التطوير
المدة	مستمرة، متطورة	sprint واحد (1–4 أسابيع)
مستوى التفاصيل	متفاوت (الأعلى = مفصل، الأسفل = تقريبي)	جميع العناصر منقحة بالكامل
الحجم	مئات العناصر محتملة	عادة 10–20 عنصراً

في تخطيط الـ sprint، يسحب الفريق العناصر من أعلى الـ product backlog إلى الـ sprint backlog. ولهذا السبب يجب أن يكون الجزء العلوي من الـ product backlog جاهزاً دائماً: لا يمكن لاجتماع تخطيط الـ sprint تنقيح القصص في الوقت الفعلي للـ sprint بأكمله.

أدوات لإدارة الـ Product Backlog

Kanban

Backlog

Sprints

الأداة	الأفضل لـ	ميزات الـ Backlog	السعر
Jira	فرق الهندسة الكبيرة	Epics، قصص، sprints، تقارير	$7.75/مستخدم/شهر
Linear	فرق هندسة المنتجات	واجهة نظيفة، دورات، خرائط طريق	مجاني / $8/شهر
TasksBoard	فرق Google Workspace	Kanban، قوائم مهام مشتركة	مجاني / Premium
Notion	الفرق المرنة	قواعد بيانات مخصصة، طرق عرض	مجاني / $8/شهر
Trello	الفرق الصغيرة	بطاقات، قوائم، تسميات	مجاني / $5/شهر
Asana	الفرق متعددة الوظائف	محافظ، جداول زمنية، عبء عمل	مجاني / $10.99/شهر

بالنسبة للفرق التي تستخدم Google Workspace، توفر TasksBoard طريقة مباشرة لإدارة عناصر الـ backlog كقوائم Google Tasks مشتركة مع عرض لوحة kanban — دون تعقيدات منصة إدارة مشاريع مخصصة.

الأسئلة الشائعة

من يملك الـ product backlog؟

يملك الـ Product Owner الـ backlog وهو المسؤول عن محتواه، وترتيبه، وتوفره. يساهم فريق التطوير بالتقديرات والمدخلات التقنية، لكن الـ PO يتخذ قرارات ترتيب الأولويات النهائية.

كم مرة يجب تنقيح الـ backlog؟

تقوم معظم فرق Scrum بالتنقيح مرة واحدة في كل sprint، حيث تقضي حوالي 10% من سعة الـ sprint الخاصة بها في التنقيح. بالنسبة لـ sprint مدته أسبوعان، فهذا يعادل حوالي 90 دقيقة في الأسبوع.

ما مدى حجم الـ product backlog؟

لا توجد إجابة عالمية، ولكن الـ backlog الذي يحتوي على أكثر من 100 عنصر غالباً ما يكون علامة على عدم تقليم العناصر القديمة. ركز على إبقاء العناصر العشرين إلى الثلاثين الأولى منقحة وجاهزة؛ أما الباقي فيمكن أن يكون أقل تفصيلاً.

ما هو الـ epic في سياق الـ product backlog؟

الـ epic هو user story كبيرة جداً بحيث لا يمكن إكمالها في sprint واحد. يتم تفكيك الـ epics إلى قصص أصغر أثناء تنقيح الـ backlog. وهي تعمل كحاويات تنظيمية للميزات ذات الصلة.

كيف تتعامل مع الأخطاء (bugs) في الـ product backlog؟

تُعامل الأخطاء كعناصر backlog وتُرتب أولوياتها مقابل الميزات. عادةً ما تقفز الأخطاء الحرجة إلى الأعلى؛ بينما قد تظل الأخطاء التجميلية البسيطة تحت العديد من الميزات. تحتفظ بعض الفرق بقائمة أخطاء منفصلة وتدمجها مع الـ backlog فقط في وقت ترتيب الأولويات.

ما الفرق بين الـ product backlog وخارطة الطريق (roadmap)؟

تُوصل خارطة الطريق الميزات المخطط لها والجداول الزمنية لأصحاب المصلحة على مستوى عالٍ. الـ backlog هو القائمة التشغيلية الداخلية للعمل المرتب حسب الأولوية للتطوير. تُشتق خرائط الطريق من الـ backlogs ولكنها تقدم عرضاً مبسطاً ومقيداً زمنياً مناسباً للجماهير الخارجية.

أدر الـ Backlog الخاص بك باستخدام TasksBoard

الـ product backlog مفيد فقط إذا كان الفريق يستطيع رؤيته، وتحديثه، والوثوق به. تحول TasksBoard قوائم Google Tasks المشتركة إلى لوحة kanban مرئية — مما يمنح فريقك طريقة بسيطة وتعاونية لإدارة عناصر الـ backlog دون إعداد معقد.

أنشئ قوائم لمراحل الـ backlog الخاصة بك (Icebox، Backlog، In Progress، Done)، وأضف مهاماً مع أوصاف وتواريخ استحقاق، وشارك اللوحة مع الجميع في الفريق. إنه أقصر طريق من “ما الذي سنبنيه بعد ذلك؟” إلى إجابة واضحة ومشتركة.