{"id":122,"date":"2023-12-10T18:05:02","date_gmt":"2023-12-10T18:05:02","guid":{"rendered":"https:\/\/nextagile.ai\/blogs\/?p=122"},"modified":"2025-12-18T12:26:55","modified_gmt":"2025-12-18T12:26:55","slug":"user-stories-techniques","status":"publish","type":"post","link":"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/","title":{"rendered":"What Is User Stories In Agile? And Techniques To Split Them"},"content":{"rendered":"\r\n<p><a href=\"https:\/\/nextagile.ai\/blogs\/agile\/epic-vs-user-stories\/\">User stories<\/a>\u00a0are single line requirements in the form of a story of what an end user wants and why. An ideal user story format followed by the industry is \u201cAs a , i want , so that . The reason why agile requirements are in the form of user stories is fairly simple \u2013 we need to get feedback from the users and we need to get the feedback as early as possible. However, when it comes to a practical scenario, teams tend to pick user stories which are too big to deliver or even showcase in a sprint.<\/p>\r\n\r\n\r\n\r\n<p>There are a lot of practical antipatterns when it comes to writing stories and implementing them.<\/p>\r\n\r\n\r\n\r\n<p>Are your teams doing any of the below mentioned points in your sprints?<\/p>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li>Stories getting spilled to the next sprint because it is too big?<\/li>\r\n\r\n\r\n\r\n<li>Taking tasks from big stories to fill the capacity of the current sprint but committing to deliver the story in a future sprint?<\/li>\r\n\r\n\r\n\r\n<li>Dividing a story and creating a story based on skill set? (Development story, backend story, frontend story, testing story etc)<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<p>If yes, you have landed on the right page, because this blog aims at explaining<\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li>What is a User story and what are its characteristics?<\/li>\r\n\r\n\r\n\r\n<li>INVEST story writing<\/li>\r\n\r\n\r\n\r\n<li><a href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-story-splitting\/\">Vertical and Horizontal slicing<\/a> of a user story<\/li>\r\n\r\n\r\n\r\n<li>Why do we have to split a user story into smaller pieces?<\/li>\r\n\r\n\r\n\r\n<li>Some sample techniques to split the story with examples<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_82_2 ez-toc-wrap-left ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 eztoc-toggle-hide-by-default' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#What_is_a_User_Story\" >What is a User Story?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#Characteristics_of_a_User_Story\" >Characteristics of a User Story<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#INVEST_Story_Writing\" >INVEST Story Writing<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#Breaking_Slicing_a_User_Story\" >Breaking \/ Slicing a User Story<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#Why_do_we_have_to_split_user_stories_into_smaller_pieces\" >Why do we have to split user stories into smaller pieces?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#Techniques_to_Split_User_Stories_into_Smaller_Stories\" >Techniques to Split User Stories into Smaller Stories<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/nextagile.ai\/blogs\/agile\/user-stories-techniques\/#Conclusion\" >Conclusion<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"What_is_a_User_Story\"><\/span>What is a User Story?<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>A\u00a0<a href=\"https:\/\/youtu.be\/czNISV2Re40\" rel=\"nofollow noopener\" target=\"_blank\">User Story<\/a>\u00a0is a simple\/brief one line requirement written in a simple language from a customer \/ user\u2019s point of view. It has 3 parts to it<\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li>Persona<\/li>\r\n\r\n\r\n\r\n<li>Demand<\/li>\r\n\r\n\r\n\r\n<li>Purpose<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p>An Ideal user story is in the form of \u201cAs a , i want , so that &lt; What is the purpose?&gt;<\/p>\r\n\r\n\r\n\r\n<p><strong>Examples<\/strong><\/p>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li>As a , i want to , so that<\/li>\r\n\r\n\r\n\r\n<li>As a , i want , so that i can<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Characteristics_of_a_User_Story\"><\/span>Characteristics of a User Story<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>A user story is a requirement which<\/p>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li><strong>Always has a business value associated with it.<\/strong>\u00a0There are always reasons why a requirement is born, it can be based on consumers feedback, competitive advantage or to generate more revenue.<\/li>\r\n\r\n\r\n\r\n<li><strong>Will Help teams get feedback.<\/strong>\u00a0A user story , when converted to a software should always present itself as a point which can get feedback as quickly as possible. Feedback can be of different levels, is it what my consumer wants? Is it how my consumer wants? Does this add value to the product?<\/li>\r\n\r\n\r\n\r\n<li><strong>Triggers a conversation.<\/strong>\u00a0A user story with enough information should trigger a conversation between a PO and the development team. There has to be common understanding between the teams and the POs in terms of what the PO wants or what the teams need to develop. And user story is the starting point which should trigger a conversation<\/li>\r\n\r\n\r\n\r\n<li><strong>When Delivered, it is usable by someone.<\/strong>\u00a0Delivering an API or a UI screen or writing a login will not help teams to get valuable feedback from a business standpoint. So a user story has to be written in a manner that there is something usable by the end user when delivered<\/li>\r\n\r\n\r\n\r\n<li>Is an Increment to your product. Since agile is a incremental and iterative model, a user story when delivered adds up to the product list of capabilities when delivered<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"INVEST_Story_Writing\"><\/span>INVEST Story Writing<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>Writing a good user story comes with a lot of practice and experience. However, INVEST is one of the most recommended techniques for writing a user story. A PO has to keep in mind the below mentioned points while writing a good user story<\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li>A User story is\u00a0<strong>INDEPENDENT<\/strong>\u00a0of other stories. A story can be worked upon in any priority in the sprint. We should not rely on finishing a less valuable story to start more Valuable story<\/li>\r\n\r\n\r\n\r\n<li>A user story strikes a conversation between the teams and the stakeholders. Scope can be\u00a0<strong>NEGOTIATED<\/strong>\u00a0by the dev teams and <a href=\"https:\/\/nextagile.ai\/blogs\/agile\/what-should-a-product-owner-not-do\/\">product owner<\/a><\/li>\r\n\r\n\r\n\r\n<li>A user story is\u00a0<strong>VALUABLE<\/strong>\u00a0to the end user or the business. When the user story is delivered, user can give feedback or the company can see some business improvements<\/li>\r\n\r\n\r\n\r\n<li>A user story has enough details so that the development team can\u00a0<strong>ESTIMATE<\/strong><\/li>\r\n\r\n\r\n\r\n<li>A user story is\u00a0<strong>SMALL<\/strong>\u00a0enough to be tested and completed in one sprint.We will not wait for 2-3 sprints to get feedback<\/li>\r\n\r\n\r\n\r\n<li>A user story is TESTABLE to check with completeness of the sprint<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Breaking_Slicing_a_User_Story\"><\/span>Breaking \/ Slicing a User Story<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>Checking if we are in the right direction and changing based on the needs is one of the main idea behind agile ways of working. And one way to do that is to get constant feedback from the customer, consumers or the product team.<\/p>\r\n\r\n\r\n\r\n<p>We understand that the requirements come in various sizes. Some requirements are small and some are big. Smaller requirements take less time to deliver and get feedback. But the Million dollar question is \u201chow to get feedback for a big requirement which will take a lot of time to deliver?\u201d and the answer is to break the requirements (User stories) into smaller requirements (User Stories) and deliver it continuously.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Why_do_we_have_to_split_user_stories_into_smaller_pieces\"><\/span>Why do we have to split user stories into smaller pieces?<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>Simply because it is too BIG!!! But also,<\/p>\r\n\r\n\r\n\r\n<ol class=\"wp-block-list\">\r\n<li>The story is so big that we cannot deliver it in one sprint<\/li>\r\n\r\n\r\n\r\n<li>It is too complex and complicated. It might have too many steps and may be difficult to test<\/li>\r\n\r\n\r\n\r\n<li>Smaller stories when completed gives the teams sense of accomplishment<\/li>\r\n\r\n\r\n\r\n<li>We might not have all the information about a story. We might as well finish the part of the story which we know and get it done<\/li>\r\n\r\n\r\n\r\n<li>Not to get stuck!! Smaller stories help teams get feedback and helps in consistent delivery<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n<p><strong>Horizontal and Vertical Slicing of User Stories<\/strong><\/p>\r\n\r\n\r\n\r\n<p>This section talks about one of the important aspects of breaking a big user story into smaller stories. Imagine a big story which needs to be broken down into smaller stories, and this story needs Backend logic, API development, Frontend development and testing as depicted in the picture below. Also, let\u2019s take a sample user story as mentioned below,<\/p>\r\n\r\n\r\n\r\n<p><strong>Sample Story<\/strong>\u00a0: As a consumer, I want to login, so that I can place an order from the system. Now this story will need backend logic to be written, API to be developed, UI to be developed, Integration of API with the UI and then testing<\/p>\r\n\r\n\r\n\r\n<p><strong>Acceptance Criteria:<\/strong><\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li>Login must happen for valid credentials<\/li>\r\n\r\n\r\n\r\n<li>Error must be thrown for invalid credentials<\/li>\r\n\r\n\r\n\r\n<li>Password must be case sensitive<\/li>\r\n\r\n\r\n\r\n<li>Password must be 8 letters long and must contain 1 number, 1 special characters<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p><strong>Horizontal Slicing<\/strong>\u00a0is breaking the story with respect to the layers \/ skillset. We have observed many teams practicing this method where the story is broken down into smaller stories but technology wise. In this case the above mentioned user story will be broken like<\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li>Story to write backend login<\/li>\r\n\r\n\r\n\r\n<li>Story to prepare API<\/li>\r\n\r\n\r\n\r\n<li>Story for UI development<\/li>\r\n\r\n\r\n\r\n<li>Story for testing<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p>This is a bad practice and not recommended because none of the 4 stories (Mentioned above) is testable and releasable. UI alone or API alone when developed cannot be released to the end user \/ PO to get feedback<\/p>\r\n\r\n\r\n<div class=\"wp-block-image\">\r\n<figure class=\"aligncenter\"><img decoding=\"async\" class=\"wp-image-12026\" src=\"https:\/\/benzne.com\/wp-content\/uploads\/2022\/09\/user-stories-slicing.png\" alt=\"user stories slicing\" title=\"\"><\/figure>\r\n<\/div>\r\n\r\n\r\n<p><strong>Vertical Slicing<\/strong>\u00a0is breaking the story with respect to the capabilities\/functionalities\/operations rather than any skillset. In this case, the above example story can be broken down into<\/p>\r\n\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li>As a user, i must be able to login with valid credentials<\/li>\r\n\r\n\r\n\r\n<li>As a user, i must be able to see error when i try to login with invalid credentials<\/li>\r\n\r\n\r\n\r\n<li>As a system, i must validate for password length<\/li>\r\n\r\n\r\n\r\n<li>As a system, i must validate the password condition<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n<p>In this case, all 4 stories can be individually developed, tested and delivered to get feedback and we have broken 1 big story into 4 smaller stories which can be quickly developed and helps the team to get feedback.<\/p>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Techniques_to_Split_User_Stories_into_Smaller_Stories\"><\/span>Techniques to Split User Stories into Smaller Stories<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>There are several techniques followed by different teams to split a big user story into smaller user stories. Below are a few mostly used techniques which we recommend strongly to use for splitting stories.<\/p>\r\n\r\n\r\n<div class=\"wp-block-image\">\r\n<figure class=\"aligncenter\"><img decoding=\"async\" class=\"wp-image-12025\" src=\"https:\/\/benzne.com\/wp-content\/uploads\/2022\/09\/user-stories-split-898x1024.png\" alt=\"user stories split\" title=\"\"><\/figure>\r\n<\/div>\r\n\r\n\r\n<ul class=\"wp-block-list\">\r\n<li><strong>Based on User Roles\/Personas<\/strong>: If your story is too big and multiple roles are involved in completing a transaction, it is better to split the stories as different roles \/ personas contribute differently<\/li>\r\n\r\n\r\n\r\n<li><strong>Based on workflows<\/strong>: If a story has multiple actions \/ steps , one way to break the stories is to create stories for each action.<\/li>\r\n\r\n\r\n\r\n<li><strong>Based on Platforms:<\/strong>\u00a0If the product is catered to users with different environments, you can also break the stories with respect to platforms, web browsers, operating systems<\/li>\r\n\r\n\r\n\r\n<li><strong>Based on CRUD Operations<\/strong>: If a story involves Creating, Replacing, Deleting, Updating of a data set, best way to divide it is with respect to the operations involved<\/li>\r\n\r\n\r\n\r\n<li><strong>Based on Acceptance Criteria<\/strong>: One of the first options and the simplest ways to break a story is with respect to the acceptance criteria. A classic example shown in the image above and also in the Sample Story ( Vertical Slicing )<\/li>\r\n\r\n\r\n\r\n<li><strong>Based on Data Types<\/strong>: A story involving different data types can be broken down into smaller stories for each data type. Multimedia upload can be broken down into photo upload, video upload, audio upload( Just a sample )<\/li>\r\n\r\n\r\n\r\n<li><strong>Business Rules<\/strong>: If you are developing a feature which behaves differently in different regions, or the behavior is rule driven, then you can also break the user story rule wise<\/li>\r\n<\/ul>\r\n<blockquote>\r\n<p><em>Build a winning <a href=\"https:\/\/nextagile.ai\/agile-transformation-consulting\/\">Agile Transformation Roadmap with Leadership Consulting<\/a>. Achieve your goals with tailored strategies and expert guidance.<\/em><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Conclusion\"><\/span>Conclusion<span class=\"ez-toc-section-end\"><\/span><\/h2>\r\n\r\n\r\n\r\n<p>There are several ways \/ techniques to split a user story into smaller pieces. You can use one of the above mentioned techniques or even mix and match the techniques. The intention is to break the stories logically which can be developed, tested and delivered so that we can get quick feedback.<\/p>\r\n\r\n\r\n\r\n<p>This brings our blog on \u201cUser Stories &amp; Techniques to split it\u201d to a conclusion.<br \/>Please reach out to \u201c<a href=\"mailto:consult@nextagile.ai\">consult@nextagile.ai<\/a>\u201d for any suggestions or feedback.<\/p>\r\n\r\n\r\n","protected":false},"excerpt":{"rendered":"<p>User stories\u00a0are single line requirements in the form of a story of what an end user wants and why. An ideal user story format followed by the industry is \u201cAs a , i want , so that . The reason why agile requirements are in the form of user stories is fairly simple \u2013 we&#8230;<\/p>\n","protected":false},"author":6,"featured_media":4568,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[2],"tags":[5,7,6],"class_list":["post-122","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","tag-agile","tag-project-management","tag-scrum"],"_links":{"self":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/122","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/comments?post=122"}],"version-history":[{"count":8,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/122\/revisions"}],"predecessor-version":[{"id":5172,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/posts\/122\/revisions\/5172"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/media\/4568"}],"wp:attachment":[{"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/categories?post=122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nextagile.ai\/blogs\/wp-json\/wp\/v2\/tags?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}