{"id":521,"date":"2011-05-13T09:15:12","date_gmt":"2011-05-13T09:15:12","guid":{"rendered":"http:\/\/mikekuphal.azurewebsites.net\/?p=521"},"modified":"2011-05-13T09:15:12","modified_gmt":"2011-05-13T09:15:12","slug":"agile-planning-my-top-five-tips-on-decomposing-user-stories-into-tasks","status":"publish","type":"post","link":"https:\/\/mikekuphal.com\/?p=521","title":{"rendered":"Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks"},"content":{"rendered":"<p><a href=\"https:\/\/mikekuphal.com\/wp-content\/uploads\/2013\/12\/decompose.jpg\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image:none;padding-left:0;padding-right:0;display:inline;float:right;padding-top:0;border:0;\" title=\"Decompose\" src=\"https:\/\/mikekuphal.com\/wp-content\/uploads\/2013\/12\/decompose_thumb.jpg\" alt=\"Decompose\" width=\"209\" height=\"225\" align=\"right\" border=\"0\" \/><\/a>Decomposing a User Story involves taking the result your user is looking for (stated as a User Story) and breaking it down into a number of tasks that the team can work on individually.\u00a0 Here are five tips I have found to be very useful:<\/p>\n<h4>1) Decompose User Stories into tasks as a team<\/h4>\n<p>Group planning is a cornerstone of Agile development.\u00a0 Though it may feel inefficient at times, the benefits are well worth it.\u00a0 See my previous post: <a href=\"https:\/\/mikekuphal.com\/agile-planning-planestimate-as-a-group-really\/\">Agile Planning: Plan\/Estimate As A Group, Really?<\/a> for more information\/details.<\/p>\n<h4>2) Attempt to size your tasks to take one team member between 1\/2 day to 3-4 days to complete<\/h4>\n<p>Motto here equals: Allow a \u201cRace to Done\u201d situation<\/p>\n<p>Creating tasks that are smaller than a handful of hours end up taking to much time administratively to create\/track\/update\/etc.\u00a0 Tasks that are larger than 3\/4 days (some would say that is too big, but teams I have been on have found it to be workable) really should be broken into a couple of tasks if possible.\u00a0 They just take too much time to be able to race to done effectively.\u00a0<\/p>\n<h4>3) Create tasks that result in a deliverable unit of work when completed<\/h4>\n<p>When decomposing a user story, be sure to break the story down into tasks that can be completed in a small amount of time (Point 2) but don\u2019t focus on the time so much as ensuring you are creating tasks that result in a deliverable unit of work.<\/p>\n<p>Don\u2019t break down a \u2018Maintain User\u2019 feature into (like you might have in the past):<\/p>\n<ul>\n<li>Build the UI<\/li>\n<li>Build the biz logic<\/li>\n<li>Build the data tier<\/li>\n<\/ul>\n<p>Instead create vertical slices of functionality when possible:<\/p>\n<ul>\n<li>Implement Add User<\/li>\n<li>Implement Edit User<\/li>\n<li>Implement Delete User<\/li>\n<li>Implement Add\/Edit\/Delete User Automated UI tests<\/li>\n<\/ul>\n<ul>When a team member takes on the \u2018Implement Add User\u2019 task, it\u2019s a contained unit of work, straight forward to know when completed, and also not dependent on other tasks being completed to be able to be tested (like Build UI\/Data tier\/Biz logic all are dependent on each other to deliver functionality to the user).<\/ul>\n<h4>4) Don\u2019t get caught deep diving into the details of each task<\/h4>\n<p><a href=\"https:\/\/mikekuphal.com\/wp-content\/uploads\/2013\/12\/dd.jpg\"><img loading=\"lazy\" decoding=\"async\" style=\"background-image:none;padding-left:0;padding-right:0;display:inline;float:right;padding-top:0;border-width:0;\" title=\"dd\" src=\"https:\/\/mikekuphal.com\/wp-content\/uploads\/2013\/12\/dd_thumb.jpg\" alt=\"dd\" width=\"151\" height=\"123\" align=\"right\" border=\"0\" \/><\/a>This is more difficult in practice than in theory.\u00a0 Knowing that task estimation is just around the corner for the team, it\u2019s natural for a experience developer to what to define all details possible, down to \u2018how many stored procedures are we going to be creating\u2019.\u00a0 This, in theory at least, helps ensure the estimation process will be more precise.\u00a0 I don\u2019t buy into this theory, at least not from a time invested by the team to get this extra level of preciseness. Certainly attempt to ask the functional questions when decomposing a User Story, so hidden functional \u2018gotcha\u2019s are uncovered, but also realize the team is just defining\/sizing effort at this point, not writing up a \u2018development specification\u2019.<\/p>\n<h4>5) Ensure testing\/automation tasks are included<\/h4>\n<p>On the teams I have worked with over the past years, we have always had a group of professional Quality Assurance Analysts.\u00a0 Our Scrum teams are no different so these types of tasks don\u2019t usually get forgotten, but for the many teams that don\u2019t have QA pros integrated into their Agile teams, I can imagine this to be something missed.\u00a0 A motto of \u2018get the functionality to the user as quick as possible\u2019 would seem to lead to that.\u00a0 Just because the team is Agile, doesn\u2019t mean there isn\u2019t any testing that should go on!\u00a0 Automating tasks where appropriate is also very important, given the high amount of regression testing that is needed when sprinting via 2-4 week timeframes.<\/p>\n<p>Next up in this series, <a title=\"Agile Planning: Group Estimate via Planning\u00a0Poker\" href=\"https:\/\/mikekuphal.com\/agile-planning-group-estimate-via-planning-poker\/\">group estimate via Planning Poker<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Decomposing a User Story involves taking the result your user is looking for (stated as a User Story) and breaking it down into a number of tasks that the team can work on individually.\u00a0 Here are five tips I have found to be very useful: 1) Decompose User Stories into tasks as a team Group &hellip; <a href=\"https:\/\/mikekuphal.com\/?p=521\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,5],"tags":[],"class_list":["post-521","post","type-post","status-publish","format-standard","hentry","category-agile","category-scrum"],"_links":{"self":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/posts\/521","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=521"}],"version-history":[{"count":0,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=\/wp\/v2\/posts\/521\/revisions"}],"wp:attachment":[{"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mikekuphal.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}