برنامهریزی هفتگی نتیجهمحور یعنی پیش از پرکردن تقویم، تصمیم بگیرید آخر هفته چه شاهدی باید وجود داشته باشد. یک برنامهٔ قابلدفاع پنج چیز را کنار هم میگذارد: هدف فعال، نتیجهٔ هفتگی، معیار پذیرش، ظرفیت واقعی و قاعدهٔ تغییر. «روی پروژه فروش کار کنم» برنامه نیست؛ «نسخه قیمتگذاری با سه سناریو تا چهارشنبه برای تصمیم مدیر آماده و پذیرفته شود» یک تعهد قابلبررسی است.
این مقاله چکلیست پاکسازی هفتهٔ گذشته را تکرار نمیکند. آن فرایند در راهنمای مرور هفتگی آمده است. اینجا خروجی مرور را میگیریم و آن را به یک سبد تعهد محدود تبدیل میکنیم؛ بهطوریکه کار نگهداری، وابستگی، عدمقطعیت و فضای اتفاقهای واقعی نیز در برنامه جا داشته باشند.
پاسخ کوتاه: صفحهٔ برنامهٔ هفتگی چه اجزایی دارد؟
- هدف دوره: این هفته به کدام هدف یا الزام فعال خدمت میکند؟
- نتیجهٔ محوری هفته: یک جمله که ارزش مورد انتظار را توضیح دهد.
- شواهد پایان: چه artifact، تصمیم، پذیرش یا تغییر مشاهدهپذیری وجود خواهد داشت؟
- سبد تعهد: کار پیشرفت، نگهداری، الزام ثابت و فضای تطبیقی از هم جدا باشند.
- ظرفیت قابلتعهد: پس از کسر کار ثابت، هماهنگی، مراقبت، وقفه و بازیابی.
- وابستگی و مالک: چه چیزی از چه کسی و تا چه زمانی لازم است؟
- بلوک اجرا: نزدیکترین اقدامها چه زمانی در تقویم جا میگیرند؟
- قاعدهٔ اگر–آنگاه: اگر فرض مهم شکست خورد، چه تصمیمی فعال میشود؟
- معیار بازبینی: چه چیزی در پایان هفته پذیرفته، منتقل، متوقف یا دوباره برآورد میشود؟
این صفحه باید آنقدر کوتاه باشد که هر روز خوانده شود و آنقدر دقیق باشد که بتوان با آن به درخواست تازه «بله، بهجای کدام تعهد؟» گفت.
مرزبندی خوشه: مرور هفتگی با برنامهریزی هفتگی فرق دارد
| فرایند | پرسش اصلی | خروجی |
|---|---|---|
| مرور هفتگی | چه رخ داد و سیستم چه چیزی را باید روشن کند؟ | ورودی پاک، وضعیت پروژه، کار انتقالی و درس |
| برنامهریزی هفتگی | با ظرفیت موجود، این هفته به چه شاهدی متعهد میشویم؟ | نتیجه، Done، سبد تعهد، تقویم و trigger |
| برنامهریزی روزانه | امروز کدام اقدام نزدیک اجرا میشود؟ | ترتیب و بلوک همان روز |
| مدیریت پروژه | کل تحویل، dependency، WIP و پذیرش چگونه اداره میشوند؟ | سیستم چندهفتهای پروژه |
یک جلسه میتواند مرور و برنامهریزی را پشتسرهم انجام دهد، اما خروجیها نباید مخلوط شوند. فهرست «چه شد» هنوز تعهد هفتهٔ بعد نیست و تقویم هفتگی نیز جای status واقعی پروژه را نمیگیرد.
گام اول: از هدف مبهم به نردبان شواهد برسید
هدف بلندتر فقط جهت میدهد؛ برای یک هفته باید آن را تا شاهد قابلپذیرش پایین بیاورید:
- جهت: چه وضعیت ارزشمندی میخواهیم ایجاد کنیم؟
- هدف فعال: کدام نتیجه چندهفتهای اکنون واقعاً در جریان است؟
- milestone: چه نقطه پذیرش یا تصمیم، پیشرفت را اثبات میکند؟
- نتیجه هفتگی: تا پایان این هفته کدام بخش مستقل قابلبررسی است؟
- شاهد: فایل، نسخه، تصمیم، تأیید، آزمون یا تحویل چیست؟
- اقدام بعدی: کوچکترین کار فیزیکی و قابلشروع چیست؟
اگر خود هدف هنوز مبهم است، ابتدا آن را با معیارهای هدف SMART روشن کنید. اما SMART بهتنهایی وابستگی، ظرفیت و مسیر پذیرش را نمیسازد؛ اینها در برنامهٔ هفتگی افزوده میشوند.
هدف، نتیجه، خروجی و کار را یکی نگیرید
| سطح | نمونه | آزمون |
|---|---|---|
| هدف | کاهش ابهام قیمتگذاری خدمت | چرا ارزش دارد؟ |
| نتیجه هفتگی | مدیر بتواند میان سه سناریوی قیمت تصمیم بگیرد | چه تغییری برای ذینفع ممکن میشود؟ |
| خروجی/شاهد | یادداشت تصمیم با سه سناریو، فرضها و پیشنهاد | چه چیز قابلدیدن و پذیرش است؟ |
| کار | جمعآوری هزینه، ساخت مدل، نوشتن یادداشت | چه فعالیتی خروجی را میسازد؟ |
شمردن کارهای انجامشده بدون اتصال به شاهد، مشغله را تقویت میکند. از طرف دیگر، نتیجهای که هیچ خروجی قابلبررسی ندارد به سلیقه و حافظه وابسته میماند.
گام دوم: یک هدف هفتگی منسجم بنویسید
جملهٔ هدف هفته باید «چرا» را بگوید و چند خروجی را زیر یک جهت جمع کند. مرور ۳۵ سال پژوهش Locke و Latham نشان میدهد اثر هدف به عواملی مانند وضوح، دشواری، تعهد، بازخورد، توانایی و پیچیدگی کار مشروط است؛ یک هدف بلندپروازانه بهتنهایی نتیجه را تضمین نمیکند. دامنه و محدودیتهای نظریه در مرور goal-setting theory آمده است.
قالب هدف هفته: «تا [زمان بازبینی]، [ذینفع] بتواند [تصمیم/استفاده/تغییر] را با اتکا به [شاهد قابلپذیرش] انجام دهد؛ بدون نقض [محافظ کیفیت/ایمنی/تعهد].»
نمونه: «تا چهارشنبه ساعت ۱۵، مدیر محصول بتواند درباره انتشار آزمایشی تصمیم بگیرد؛ با نسخه قابلآزمون، نتیجه آزمون اصلی و فهرست ریسک باز، بدون حذف کنترل امنیت.»
یک هدف به معنی یک کار نیست
هدف هفتگی میتواند چند خروجی هماهنگ داشته باشد، اما همه باید به یک تصمیم یا ارزش مشترک خدمت کنند. منطق «یک هدف منسجم با دامنه قابلمذاکره» در Scrum نیز دیده میشود: Sprint Goal یک objective است و جزئیات کار با یادگیری تغییر میکنند. Scrum Guide 2020 چارچوب کامل تیم محصول است، نه نسخهٔ علمی یا الزامی برای برنامه شخصی؛ اینجا فقط تمایز هدف پایدار از فهرست کار منعطف را وام میگیریم.
گام سوم: سبد تعهد هفته را پیش از تقویم بسازید
همه ظرفیت برای پیشرفت هدف آزاد نیست. یک سبد واقعبینانه چهار نوع کار را جدا میکند:
- الزام ثابت: کلاس، شیفت، جلسه ضروری، موعد قراردادی، مراقبت و رفتوآمد؛
- نگهداری: پشتیبانی، پاسخ، امور اداری، سلامت سیستم و کارهای تکراری؛
- پیشرفت: خروجیهایی که هدف فعال را جلو میبرند؛
- تطبیقی: فضایی برای تغییر، حادثه، انتظار، اصلاح و فرصت ارزشمند.
نگهداری «اتلاف» نیست و مراقبت نیز رقیب اخلاقی هدف نیست. اگر این بارها را صفر بگیرید، برنامه فقط هزینه واقعی را پنهان میکند. برای تعارض کار، خانواده، سلامت و تعهدهای غیرقابلمذاکره از سیستم اولویتبندی زندگی شخصی استفاده کنید.
گام چهارم: ظرفیت قابلتعهد را با بازه برآورد کنید
یک تقریب عملی:
ظرفیت قابلتعهد ≈ زمان در دسترس − الزام ثابت − نگهداری − هماهنگی/گذار − فضای تطبیقی
هر جزء را بهصورت بازه کم/محتمل/زیاد بنویسید؛ دقیقه دقیق معمولاً توهم کنترل میسازد. از داده چند هفته مشابه کمک بگیرید و تفاوت هفته عادی، موعد سنگین، تعطیلی، سفر یا مراقبت را حفظ کنید. هیچ درصد جهانی برای buffer یا کار پروژهای وجود ندارد.
| جزء | بازه نمونه | منبع برآورد |
|---|---|---|
| زمان حضور واقعی | ۲۸ تا ۳۲ ساعت | تقویم و محدودیت هفته |
| الزام ثابت | ۹ تا ۱۱ ساعت | رویدادهای قطعی |
| نگهداری | ۵ تا ۷ ساعت | میانه هفتههای مشابه |
| هماهنگی و گذار | ۳ تا ۵ ساعت | جلسه، آمادهسازی و follow-up |
| فضای تطبیقی | ۲ تا ۴ ساعت | نوسان و ریسک شناختهشده |
| باقیمانده برای تعهد پیشرفت | بازه، نه عدد واحد | سناریوی ترکیبی |
این اعداد فقط نمایش روشاند. اگر شکاف ظرفیت ساختاری است، با تکنیک هفتگی پنهانش نکنید؛ پروتکل ترمیم برنامه زمانی فشرده برای کنترل ورود کار، WIP و service level مناسبتر است.
گام پنجم: نتیجههای هفته را commitment، target و option کنید
- Commitment: نتیجهای که بر مبنای ظرفیت موجود پذیرفتهاید و تغییر آن نیازمند trade-off آشکار است.
- Target: نتیجه مطلوبی که احتمال تحویل دارد، اما به فرض یا ظرفیت حلنشده وابسته است.
- Option: کار مفیدی که فقط با آزادشدن ظرفیت آغاز میشود و تعهد پنهان نیست.
این سه واژه برای شفافیت forecast هستند، نه درجه اهمیت انسانها یا اهداف. Option نباید در تقویم به شکل تعهد جا بگیرد. اگر commitment بیش از ظرفیت است، حذف برچسب «target» مشکل را حل نمیکند؛ دامنه، تاریخ، کیفیت مجاز، منبع یا اولویت باید مذاکره شود.
گام ششم: برای هر نتیجه کارت تعهد بسازید
| فیلد | پرسش |
|---|---|
| نتیجه | در پایان چه تصمیم یا استفادهای ممکن میشود؟ |
| شاهد | کدام artifact یا رفتار مشاهدهپذیر وجود دارد؟ |
| پذیرش | چه کسی با چه معیار و تا چه زمانی میپذیرد؟ |
| محافظ کیفیت | چه چیزی برای سرعت حذف نمیشود؟ |
| برآورد | دامنه effort و waiting چیست؟ |
| پیشنیاز | کدام دسترسی، تصمیم یا داده لازم است؟ |
| مالک | چه کسی پاسخگو و چه کسانی همکارند؟ |
| اقدام بعدی | نخستین حرکت قابلشروع چیست؟ |
| trigger | در چه وضعی scope/date/owner باید تغییر کند؟ |
اگر خروجی چندمرحلهای و موعد ثابت دارد، کارت پایان و وابستگیها را با برنامهریزی معکوس بسازید. هفته فقط برشی از آن شبکه است؛ نباید پیشنیاز آینده را با فهرست فعالیت امروز جایگزین کند.
گام هفتم: dependency و Waiting را از کار فعال جدا کنید
«منتظر پاسخ مشتری» وضعیت است، نه فعالیت. هر Waiting باید موضوع، مالک بیرونی، آخرین تماس، تاریخ پیگیری، اثر تأخیر و اقدام جایگزین داشته باشد. اگر پذیرش یا داده تا زمان مشخص نرسید، برنامه از قبل میداند کدام نتیجه کوچک میشود یا چه گزینهای کشیده میشود.
برای کار شخصی چندهفتهای، جریان ساده Ready / Doing / Waiting / Review / Done و Definition of Done در سیستم مدیریت پروژه شخصی توضیح داده شده است. برنامه هفتگی فقط اقلام مناسب را از آن سیستم میکشد.
گام هشتم: WIP را محدود و پایان را بر شروع مقدم کنید
شروعکردن پنج خروجی، پیشرفت پنجبرابری نیست. برای هر نوع کار یک حد WIP آزمایشی تعیین کنید و استثنا را مکتوب نگه دارید. وقتی یک قلم blocked است، خودکار پروژه دیگری را فعال نکنید؛ ابتدا امکان رفع مانع، کوچککردن دامنه یا تکمیل قلم نزدیک Done را بررسی کنید.
Kanban Guide 2025 تعریف workflow، کنترل WIP، مدیریت سن کار و استفاده از داده تاریخی برای forecast را در سیستم جریان دانش توضیح میدهد. این راهنما قانون تعداد کار شخصی یا تضمین بهرهوری نیست؛ منطق آن کمک میکند commitment را با ظرفیت و pull پیوند دهید.
گام نهم: اقدام نزدیک را در تقویم جا دهید
کارت نتیجه بدون زمان شروع، همچنان نیت است. فقط کارهای آماده را با مدت بازهای در تقویم قرار دهید و برای گذار، آمادهسازی و follow-up جا بگذارید. روش ساخت بلوک انعطافپذیر، buffer و نسخه روز در راهنمای Time Blocking آمده است.
- بلوک را با نام خروجی بنویسید، نه «کار روی پروژه»؛
- برای شروع، فایل/brief/دسترسی باید از قبل آماده باشد؛
- زمان بازبینی و پذیرش را جدا از تولید ببینید؛
- کار تکراری را در پنجره نگهداری بگذارید؛
- فضای تطبیقی را پیشاپیش به Option نفروشید.
گام دهم: برای ریسکهای واقعی برنامه اگر–آنگاه بنویسید
جمله «اگر وقت شد انجام میدهم» trigger نیست. برنامهٔ اجرایی باید نشانه قابلمشاهده و پاسخ مشخص داشته باشد:
- اگر داده مشتری تا سهشنبه ساعت ۱۲ نرسید، نسخه تحلیل با داده نمونه ساخته و موعد تصمیم دوباره تأیید میشود.
- اگر کار نگهداری از سقف سناریوی زیاد عبور کرد، Optionها متوقف و مالک تعهد محوری مطلع میشود.
- اگر آزمون امنیت رد شد، انتشار متوقف و کیفیت برای حفظ تاریخ حذف نمیشود.
فراتحلیل Gollwitzer و Sheeran روی ۹۴ آزمون، برنامههای implementation intention را برای عبور از فاصله نیت تا عمل بررسی کرد؛ اثر متوسط کلی به معنی تضمین هر if–then یا اعتبار این قالب هفتگی نیست و دامنه مطالعهها ناهمگون است. مشخصات و متن مقاله در صفحه دانشگاه Konstanz در دسترس است. trigger باید به مانع واقعی وصل شود، نه دهها سناریوی خیالی.
سه نمونه برنامه هفتگی نتیجهمحور
فریلنسر: تصمیم روی نسخه فرود فروش
- هدف هفته: مشتری بتواند نسخه نخست را روی موبایل و دسکتاپ ارزیابی کند.
- Commitment: لینک staging، چکلیست معیار پذیرش و فهرست issueهای باز.
- نگهداری: پشتیبانی دو مشتری جاری و صدور فاکتور.
- Dependency: تأیید متن hero تا دوشنبه؛ در غیر این صورت placeholder علامتدار.
- محافظ: دسترسپذیری پایه و نسخه پشتیبان حذف نمیشوند.
دانشجو: کاهش ریسک فصل پایاننامه
- هدف هفته: استاد بتواند درباره ساختار فصل روش تصمیم بگیرد.
- Commitment: طرح سهبخشی با سؤال هر بخش و پنج منبع کلیدی.
- Target: پیشنویس ۸۰۰ واژه، فقط پس از روشنشدن ساختار.
- Dependency: زمان بازخورد استاد و الزامات اخلاق پژوهش.
- trigger: اگر جلسه جابهجا شد، سؤالهای تصمیم مکتوب ارسال میشوند؛ فرض پذیرش ساخته نمیشود.
مدیر تیم: یک تصمیم، نه سه پروژه نیمهکاره
- هدف هفته: تصمیم تخصیص ظرفیت فصل با دیدن سه trade-off ممکن شود.
- Commitment: یادداشت تصمیم با بار نگهداری، ظرفیت آزاد، ریسک و پیشنهاد.
- Option: شروع پایلوت فقط پس از تصمیم؛ پیشاپیش WIP نمیشود.
- مالکیت: عملیات داده ظرفیت، مالی هزینه و مدیر محصول ارزش را تأیید میکنند.
- محافظ: افراد براساس ساعت آنلاین رتبهبندی نمیشوند.
در طول هفته چگونه برنامه را تغییر دهیم؟
برنامه خوب ثابت نیست؛ تاریخچه تغییر را حفظ میکند. هر درخواست تازه یکی از پنج تصمیم را فعال میکند:
- رد: با هدف یا دامنه مسئولیت همراستا نیست.
- صف: ارزش دارد اما این هفته ظرفیت ندارد.
- جایگزینی: وارد میشود و یک تعهد نامبرده خارج میشود.
- کوچکسازی: شاهد حداقلیِ همچنان معتبر تحویل میشود.
- تشدید: وقتی تاریخ، کیفیت، ایمنی یا قرارداد فقط با صاحب اختیار قابلحل است.
برای هر تغییر، درخواست، علت، تعهد جابهجاشده، تصمیمگیر و زمان ثبت شود. پاککردن برنامه اولیه برای سبزکردن داشبورد، امکان یادگیری برآورد را از بین میبرد.
در پایان هفته چه چیزی را بسنجیم؟
پایش پیشرفت میتواند مفید باشد، اما شمردن task بهتنهایی کافی نیست. فراتحلیل Harkin و همکاران ۱۳۸ مطالعه تصادفی و ۱۹٬۹۵۱ شرکتکننده را بررسی کرد و بهطور متوسط اثر مثبتی برای مداخلههای افزایش پایش بر دستیابی هدف یافت؛ بااینحال حوزهها ناهمگون و بسیاری سلامتمحور بودند. خلاصه PubMed پشتوانه علمی «این قالب حتماً موفقیت میآورد» نیست.
- نتیجه پذیرفتهشده: کدام شاهد با معیار Done پذیرفته شد؟
- کار انتقالی: چه چیزی با دلیل scope، dependency، capacity یا estimate منتقل شد؟
- کار برنامهنشده: چه مقدار وارد شد و کدام تعهد را جابهجا کرد؟
- سن WIP: کدام قلم چند هفته باز مانده و چه تصمیمی میخواهد؟
- مصرف فضای تطبیقی: برای کدام ریسک یا فرصت استفاده شد؟
- بدهی نگهداری: آیا حذف نگهداری، مشکل هفته بعد ساخته است؟
- کیفیت: چه خروجی باز شد، رد شد یا بازکاری خواست؟
این داده برای اصلاح سیستم است، نه اثبات ارزش فرد. تعداد ساعت، پیام، task Done یا درصد پُری تقویم بدون نوع کار و پذیرش، KPI قابلاعتماد عملکرد نیست.
قالب قابلکپی برنامه هفتگی
هفته / منطقه زمانی:
هدف فعال دوره:
هدف این هفته:
شاهد و معیار پذیرش:
Commitmentها:
1) نتیجه / شاهد / Done / owner / due / effort range
2) نتیجه / شاهد / Done / owner / due / effort range
الزام ثابت:
نگهداری:
فضای تطبیقی:
Targetها:
Optionها:
Dependency / Waiting / owner / follow-up:
محافظ کیفیت یا ایمنی:
اگر–آنگاههای اصلی:
بلوکهای اجرای آماده:
تغییرهای ثبتشده:
زمان و معیار بازبینی پایان هفته:تعداد Commitmentها قانون ثابت ندارد. از کوچکترین سبدی شروع کنید که نتیجه معنادار میسازد و با داده carryover/WIP آن را اصلاح کنید.
خطاهای رایج در برنامهریزی هفتگی
- فهرست بهجای نتیجه: ۳۰ task دارد اما شاهد پایان را نمیگوید.
- هدفهای موازی زیاد: هر خروجی جهت جدا دارد و هفته coherence ندارد.
- ظرفیت اسمی: جلسه، نگهداری، مراقبت، گذار و انتظار را صفر میگیرد.
- Stretch پنهان: Option را در تقویم تعهد میکند و شکست را به فرد نسبت میدهد.
- Waiting بیمالک: «منتظر پاسخ» تاریخ پیگیری و fallback ندارد.
- شروع بیشتر از پایان: WIP را برای حس پیشرفت زیاد میکند.
- انعطاف بدون تاریخچه: برنامه هر روز عوض میشود اما trade-off ثبت نمیشود.
- سرعت با حذف کیفیت: موعد را با کنارگذاشتن آزمون، امنیت یا پذیرش ظاهراً حفظ میکند.
- carryover اخلاقی: انتقال کار را تنبلی مینامد و خطای دامنه/وابستگی/ظرفیت را نمیبیند.
- کپی Scrum/Kanban: چارچوب تیم محصول را بدون نقش، بافت و نیاز واقعی به زندگی شخصی تحمیل میکند.
اگر تقریباً هر هفته برآوردها میشکنند، مسئله را به انگیزه تقلیل ندهید؛ علل شکست برنامه را از منظر خوشبینی، ظرفیت کاذب، وابستگی و نبود بازخورد عیبیابی کنید.
چکلیست نهایی
- آیا هدف هفته یک ارزش یا تصمیم مشترک دارد؟
- آیا نتیجه، شاهد، پذیرش و محافظ کیفیت از task جدا شدهاند؟
- آیا الزام ثابت، نگهداری و فضای تطبیقی پیش از تعهد کسر شدهاند؟
- آیا effort و waiting بهصورت بازه دیده میشوند؟
- آیا Commitment، Target و Option صریحاند؟
- آیا هر Waiting مالک، پیگیری، اثر تأخیر و fallback دارد؟
- آیا WIP محدود و کار نزدیک Done بر شروع تازه مقدم است؟
- آیا اقدام آماده در تقویم و ابزار/brief آن از قبل مهیاست؟
- آیا triggerها observable و پاسخ آنها دارای owner است؟
- آیا تغییر برنامه trade-off را نگه میدارد؟
- آیا پایان هفته نتیجه پذیرفتهشده، carryover، unplanned work، WIP age و quality دیده میشوند؟
جمعبندی
برنامهریزی هفتگی نتیجهمحور، رقابت برای پرکردن همه ساعتها نیست. از یک هدف فعال شروع کنید، نتیجه را با شاهد و پذیرش تعریف کنید، بار ثابت و نگهداری را از ظرفیت کم کنید، سبد Commitment/Target/Option بسازید و dependency و trigger را پیشاپیش روشن کنید. سپس فقط اقدامهای آماده را به تقویم ببرید و در پایان، outcome پذیرفتهشده و trade-offها را ببینید. برنامه خوب نه آینده را قطعی میکند و نه شما را بابت عدمقطعیت سرزنش؛ تصمیمها را پیش از ازدحام هفته قابلدیدن میکند.
سؤالات متداول
چند هدف برای یک هفته مناسب است؟
عدد جهانی وجود ندارد. یک هدف منسجم میتواند چند خروجی هماهنگ داشته باشد. تعداد را با ظرفیت، اندازه کار، dependency و WIP گذشته تعیین کنید؛ اگر هر خروجی «چرا»ی جدا دارد، احتمالاً چند هدف رقیب ساختهاید.
فرق نتیجه هفتگی با task چیست؟
نتیجه میگوید چه تصمیم، استفاده یا تغییر برای ذینفع ممکن میشود؛ task فعالیتی است که آن نتیجه را میسازد. «تحقیق قیمت» task و «تصمیمپذیرشدن سه سناریوی قیمت با فرضهای روشن» نتیجه است.
اگر یک کار به هفته بعد منتقل شد، برنامه شکست خورده است؟
نه لزوماً. دلیل انتقال را به scope، dependency، capacity، estimate، quality یا تغییر اولویت کد کنید. تکرار یک علت سیستمی نیازمند اصلاح است؛ انتقال شفاف از اعلام Done کاذب بهتر است.
آیا باید تمام ساعات هفته را Time Block کنم؟
خیر. الزام ثابت و اقدامهای آماده را زمانگذاری کنید و برای نگهداری، گذار و نوسان فضا نگه دارید. درصد خالی ثابتی برای همه وجود ندارد؛ buffer باید از variability و ریسک همان هفته بیاید.
برنامه هفتگی شخصی را میتوان عین Sprint اجرا کرد؟
Scrum یک چارچوب کامل برای تیم محصول با نقشها، artifactها و eventهای مشخص است. میتوان از ایده هدف منسجم، Done و adaptation الهام گرفت، اما انتخاب چند بخش آن «Scrum» نیست و لزوماً برای زندگی، مراقبت، کار شیفتی یا پروژه فردی مناسب نیست.
