در کل، یک ویژگی یا داستان به عنوان قسمتی از یک محصول که برخی از قابلیت های مفید و ارزشمند را تحویل مشتری می دهد، تعریف می شود. ویژگی ها یک محصول نرم افزاری با یک هواپیما متفاوتند، اما هر دوی آنها بر روی تحویل ارزش به مشتری تمرکز دارند.تفاوت اصلی در یک داستان و یک ویژگی این است که یک داستان، قطعه ی کوچکی است که قابلیت مفیدی تحویل می دهد، اما ممکن است یک قابلیت کامل را تحویل ندهد با استفاده از ویژگی بررسی اعتبار مشتری،
برای مثال، "ویژگی" چک کردن کامل، نیاز به هفته ها تلاش است در حالیکه یک "داستان" باید بین تا 1 برنامه ریزی تکرار مؤثر داشته باشد. بنابراین در این مورد، داستان های مختلف باید ویژگی کامل را تحویل دهد. در ذیل نمونه ای از داستان کاربر (User story) آورده شده است:
نمونه داستان- قابلیت
ویژگی: به عنوان یک تحلیلگر من نیاز به توانایی چک کردن رتبه بندی اعتباری مشتری دارم.
داستان1 : به عنوان یک تحلیلگر من نیاز به توانایی چک کردن سابقه قبلی پرداخت های مشتری را دارم.
داستان2: به عنوان یک تحلیلگر من نیاز به توانایی چک کردن وضعیت اعتباری مشتری را دارم.
داستان3: به عنوان یک تحلیلگر من نیاز به توانایی محاسبه نرخ اعتباری داخلی بر اساس گزارشات اعتباری را دارم
من از داستان به عنوان کوچکترین قطعه استفاده می کنم به دو دلیل. اولاً اصطلاح"داستان"، برای طیف وسیعی از کارورزان چابک، یک قاعده شده و ثانیاً توسعه ی چابک دارای طبیعت تکاملی است. داستان در طول زمان، به وجود می آید، آنها یک مجموعه ی ثابت از نیازمندی ها می باشند. اصطلاح "داستان" برای ایجاد حس تکاملی به وجود آمده است.
تمرکز داستان ها
تعریف داستان ها می تواند برای اشخاصی که در روش فعالیت تکنیکی تجربه دارند، دشوار باشد. در توسعه ی نرم افزار، برای مثال، تیم ها ممکن است برای فعالیت هایی چون "بهبود واسط کاربر" یا "اجرای یک شمای پایگاه داده" استفاده شوند. این فعالیت ها، کاربرگرا نیستند. مثل "توانایی چک کردن نرخ اعتباری مشتری". شکل ذیل این دو دیدگاه را نشان می دهد: مشتری و تکنیک .این شکل یک معماری لایه ای فنی ویژه ی واسط کاربر، اشیای تجارت، میان افزار و پایگاه داده را نشان می دهد. برنامه های پروژه ی سنتی بر روی مناطق فعالیت تکنیکی تمرکز دارد. داستان ها به عبارت دیگر مشتری گرا هستند.
در برنامه ریزی انتشار )کار اختصاص یافته به تکرارها در یک برنامه ی انتشار(، ما از داستان ها استفاده می کنیم زیرا ما می خواهیم که تیم محصول را در پروسه دخیل کنیم و این هیچ ارتباطی به فعالیت های تکنیکی ندارد. برای برنامه ریزی تکرار، داستان ها به فعالیت های فنی شکسته می شوند و آنگاه تیم توسعه می تواند از آن استفاده کند. این فعالیت های تکنیکی کوچکند زیرا آنها تنها چیزی را اجرا می کنند که مورد نیاز یک داستان است.در سایت مشتری، توسعه دهندگان نرم افزاری در مورد این شکست، شکایت دارند زیرا آنها فعالیت های کوچک را ناکارآمد می دانند. برای مثال، آنها بیان کردند که کد کردن قطعه های کوچک صفحه ی واسط کاربر، مولدتر از انجام کل کار است. همان طور که مدیر محصول در اتاق گفت: " بله، اما آخرین پروژه را به یاد داشته باشید. ما نه ماه بر روی آن کار کردیم بدون اینکه نتیجه ای ببینیم و همه ی آنها اشتباه بودند".نداشتن فهم مشتری قابل شرح یا اثبات، باعث می شود که پروژه ها از سرعت واقعی پیشرفت خود، عقب بمانند و آنگاه با ترکیب وظایف از داستان های مختلف در طول یک تکرار، اکثر ناکارآمدی های درک شده می توانند حذف شوند.برخی از داستان ها، همواره طولانی ترند یا در ظاهر طولانی تر از یک تکرار جهت کامل شدن هستند. معمولاً وقتی تیم ها مجبورند که یک داستان "بزرگ" را به داستان های کوچکتر تجزیه کنند، یک روش را پیدا می کنند.