تغییری را که می‌خواهید ایجاد کنید توصیف کنید
از وضعیتی شروع کنید که مشتریان شما امروز با آن روبه‌رو هستند و تصمیم یا کاری که محصول شما باید بهبود دهد. فهرستی شامل صرافی، کیف پول و هوش مصنوعی، خدمت مورد نظر را توضیح نمی‌دهد. کاربران اصلی، نقطه شروع آن‌ها و نتیجه‌ای را که باید به آن برسند نام ببرید. یک نمونه کامل را با زبان عادی شرح دهید، از جمله اتفاقاتی که بیرون از اپلیکیشن رخ می‌دهد. اگر فرد باید با اپراتور تماس بگیرد، مدارک ارسال کند یا منتظر سیستم دیگری بماند، آن مرحله را هم بیاورید. این روایت از گردش‌کار واقعی به تیم اجرا کمک می‌کند قابلیت‌های غیرضروری را به چالش بکشد و کارهایی را پیدا کند که صرفاً با فهرست کردن صفحه‌ها دیده نمی‌شوند.
تصمیم‌ها را از فرض‌ها جدا کنید
یک ثبت کوتاه با سه دسته بسازید: تصمیم‌هایی که قبلاً گرفته شده‌اند، فرض‌هایی که نیاز به آزمون دارند و پرسش‌هایی که به مالک نیاز دارند. برای مثال، استفاده از ارائه‌دهنده خارجی هویت می‌تواند یک تصمیم باشد، اما توانایی آن برای پشتیبانی از سفر مشتری مورد نظر شما تا زمان راستی‌آزمایی یک فرض باقی می‌ماند. برای هر پرسش باز، فردی مسئول حل آن و پیامد بی‌پاسخ ماندنش را مشخص کنید. این کار مانع می‌شود برآورد، بی‌سروصدا و بر پایه اطلاعات ناقص، به وعده تبدیل شود. گزینه‌های ردشده را وقتی بده‌بستان‌هایشان جهت انتخاب‌شده را توضیح می‌دهد، کوتاه مستند کنید. با تولید شواهد در مرحله کشف، این ثبت را به‌روزرسانی کنید و اجازه ندهید یادداشت‌های جلسه تنها سابقه موجود باشند.
انتشار اول را بر اساس سفرهای کامل تعریف کنید
مجموعه کوچکی از سفرهای مشتری و اپراتور را انتخاب کنید که از ابتدا تا انتها قابل انجام باشند. انتشار اول با تعداد زیادی صفحه پراکنده، دشوارتر از انتشاری محدودتر اما دارای رفتار منسجم ارزیابی می‌شود. مشخص کنید چه چیزهایی شامل می‌شود، چه چیزهایی صریحاً به بعد موکول شده و چه بخشی را باید ارائه‌دهنده دیگری تأمین کند. برای هر سفر، یک نتیجه عادی و یک نتیجه دشوار، مانند درخواست منقضی‌شده یا وابستگی در دسترس نبودنی، مشخص کنید. رکوردهایی را هم اضافه کنید که اپراتور برای توضیح نتیجه لازم دارد. این مرزها به طراحی، مهندسی و ذی‌نفعان کسب‌وکار امکان می‌دهد به‌جای شمردن دکمه‌ها، درباره دامنه کار با مثال‌های مشترک گفتگو کنند.
درباره شواهد و مدیریت تغییر توافق کنید
پیش از پیاده‌سازی، توضیح دهید هر نقطه عطف چگونه بازبینی می‌شود: داده نمایشی، محیط آزمایش، رکوردهای مورد انتظار و فردی که نتیجه را می‌پذیرد. بازبینی طراحی را از پذیرش نرم‌افزارِ در حال کار جدا کنید. همچنین تصمیم بگیرید نیازمندی‌های جدید چگونه وارد پروژه می‌شوند. درخواست تغییر باید نتیجه مطلوب، سفرهای متأثر، وابستگی‌ها و تنظیم پیشنهادی برای دامنه تحویل را توضیح دهد. چنین درخواستی نباید بی‌صدا یک توافق قبلی را در یک پیام چت جایگزین کند. مرحله کشف را با بریف نسخه‌دار، پرسش‌های حل‌نشده و یک گام عملی بعدی به پایان برسانید. ارزش این تمرین در فهم مشترکی است که وقتی افراد دیگری بعداً به پروژه می‌پیوندند نیز همچنان قابل استفاده بماند.