Home > Agile, Scrum > Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks

Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks

DecomposeDecomposing 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.  Here are five tips I have found to be very useful:

1) Decompose User Stories into tasks as a team

Group planning is a cornerstone of Agile development.  Though it may feel inefficient at times, the benefits are well worth it.  See my previous post: Agile Planning: Plan/Estimate As A Group, Really? for more information/details.

2) Attempt to size your tasks to take one team member between 1/2 day to 3-4 days to complete

Motto here equals: Allow a “Race to Done” situation

Creating tasks that are smaller than a handful of hours end up taking to much time administratively to create/track/update/etc.  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.  They just take too much time to be able to race to done effectively. 

3) Create tasks that result in a deliverable unit of work when completed

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’t focus on the time so much as ensuring you are creating tasks that result in a deliverable unit of work.

Don’t break down a ‘Maintain User’ feature into (like you might have in the past):

  • Build the UI
  • Build the biz logic
  • Build the data tier

Instead create vertical slices of functionality when possible:

  • Implement Add User
  • Implement Edit User
  • Implement Delete User
  • Implement Add/Edit/Delete User Automated UI tests
    When a team member takes on the ‘Implement Add User’ task, it’s 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).

4) Don’t get caught deep diving into the details of each task

ddThis is more difficult in practice than in theory.  Knowing that task estimation is just around the corner for the team, it’s natural for a experience developer to what to define all details possible, down to ‘how many stored procedures are we going to be creating’.  This, in theory at least, helps ensure the estimation process will be more precise.  I don’t 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 ‘gotcha’s are uncovered, but also realize the team is just defining/sizing effort at this point, not writing up a ‘development specification’.

5) Ensure testing/automation tasks are included

On the teams I have worked with over the past years, we have always had a group of professional Quality Assurance Analysts.  Our Scrum teams are no different so these types of tasks don’t usually get forgotten, but for the many teams that don’t have QA pros integrated into their Agile teams, I can imagine this to be something missed.  A motto of ‘get the functionality to the user as quick as possible’ would seem to lead to that.  Just because the team is Agile, doesn’t mean there isn’t any testing that should go on!  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.

Next up in this series, group estimate via Planning Poker.

  1. sarit elgamis
    January 25, 2012 at 10:18 am


    we are new in scrum and working exactly the way you say not to in #3.
    the reason we do it is the different skillsets that will accomplish the tasks.
    if there are different people that work in different layers of application how would you suggest to decompose the stories to tasks?


    • January 31, 2012 at 12:02 pm

      @sarit: I understand your question/situation and it’s a common one from what I hear. I would first ask if there is a specific reason the UI person/people (for example) can not work in the other layers? The main point of #3 is to challenge the way of thinking that we have used in the past and instead think from a feature perspective when breaking out tasks. This allows for some decoupling of resource dependencies and gives the team the ability to deliver something to the user at the end of the sprint that is useful.

    • November 17, 2014 at 10:39 am

      We’ve encountered this problem in the past. The easiest way to define such tasks is to qualify how each contributor will participate: “add a new user” could mean two tasks, “implement the add user UI” and “implement the add user REST/controller” and “write incoming Add User requests to the database as a new user”.

  2. Andrei
    March 4, 2012 at 6:10 am

    I really liked your description about task break down.
    I wonder if you can give me a tip of how to solve my team’s problem: we have collected several user stories from the client, but they all seem to be having similar tasks when broke down ( i.e.: Build charts for A is one user story, Build charts for B is another user story ) and each of the user story consists of the same tasks, but applied on A and on B.
    I don’t know if it’s good to split them this way because in the View at least we have a fixed number of chart objects that have to be displayed in the page no matter if there is A or B.
    The ViewModel as well is one single class that has to be modified by the same person.
    So basically when we start doing a task from a specific user story we end up doing for other user stories as well because the functionalities are connected.

    If user stories are very similar, do you know what is the best decision of breaking them down ?


  3. March 6, 2012 at 6:53 am

    @Andrei: The situation you have found yourself in is fairly common. Teams I have been involved with have tackled it a number of different ways. Before getting into possible solutions, I just want to remind you that the goal of a User Story is to deliver a single feature that could be deployed to the customer when completed. From what I am reading, it looks like you could have a higher level User Story that encompasses the Chart A and Chart B user stories. If you go up to that level, you might find some relief with your current situation.

    Assuming that is not a solution you want to follow, I have worked with teams that, given a situation like this, simply make the assumption that one of the User Stories will be implemented first, and place shared infrastructure tasks in that user story. The other user stories end up being broken down into task lists that are simply the tweaks to the shared components to implement it’s extended functionality. This does cause some linear User Story dependency, but that is something that can be easily managed. It’s biggest benefit is that you do truly have a feature to deliver after the first (or any subsequent) user stories are completed without having to complete all features before saying it’s complete.

    Another approach some teams I have been involved with have used is to simply identify one user story as the ‘implementation’ user story and link the other similar user stories to it. When the implementation user story is decomposed/completed (including the functionality of the linked user stories), all user stories are marked as complete.

    I prefer the first strategy, but all have worked for teams I have been on. In the end the most important thing is to deliver the functionality the Product Owner is requesting via their User Stories. Hope the above helps.

  4. Jayson
    October 2, 2012 at 1:07 pm

    Mike, one thing that has always stumped me with the Agile planning process and the short sprints is what to do with deliverables that, based on the solution, require integrated activity across siloed functional teams

    An example: A transactional order system is changing how orders are invoiced; from an order level down to the commodity level. This involves a modification to the UI to provide that visibility, a change to how we are posting that invoice to the financials system, and a change to the billing system to display the invoice correctly. How can these things be separated (UI, post to financials, display on the invoice) and still deliver the entire requirement/story when each of those work items can take anywhere from 60 to 200 hours and are not mutually exclusive?

    • October 10, 2012 at 2:56 pm

      Jayson: I see your dilemma, the siloed functional teams is no doubt your biggest barrier. My assumption is the reason for that is that each team supports a system (or subsystem) of which each are needed to complete the round trip objective of the feature.

      Even with the above, I believe there should be opportunity to break down your main feature into a set of features that accomplish the whole. Given your example, maybe the following: 1) New path through the billing system 2) New path through the invoicing system 3) Path through the data entry system that also executes the new invoicing (1) and billing (2) paths. You certainly could break each of those down further… just try to keep thinking in a vertical slice pattern (even if it’s vertical slices of sub systems since they are implemented by different teams on different schedules/etc).

      Certainly another option would be to break up the siloed functional teams and implement cross functional teams that can tackle the whole vertical slice through the different sub systems. I would assume that would be a difficult change to implement in the short term. Along this thinking though, I have went through the process of breaking up multiple siloed teams like you are talking about into non-functionality based teams (any team can work on any system) using a single backlog and have seen excellent success after the transition was made.

  1. June 13, 2013 at 2:19 pm
  2. December 1, 2013 at 1:16 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: