Friday, November 25, 2011

How to Break a User Story into Tasks

ScrumBoardOne of the vaguest aspects of Scrum is breaking stories into tasks, which is done in (the second half of) the Sprint Planning. Most of the questions I get when training or coaching boil down to one question: “How do I break a user story into tasks”?

Defining The Problem

My favorite definition for a user story is that it is a thin, vertical slice of functionality, describing a small increment in value to the user (or customer).

A task, on the other hand is a step taken by the development team, required to fulfill the requirements of the user story. I further like to define, as a rule of thumb, that a task should take half a day to 2 days to complete.

The question therefore should be what are the steps the team needs to take for the story to be considered complete?

Look at Your Architecture

Explicitly or implicitly, your project has an architecture. It might be anything from a master piece drawn out in painstaking elaboration by a the architecture team, to a high-level conceptual architecture diagram. You should look at the components in your system, and ask your self which components do you need to modify (or add) for the story.

For example, Let’s say that we have a product that is a social networking web site of some sorts. given a story such as In order to broaden my network, as a user, I want to be able to import contacts from Gmail. Looking at a typical architecture for such a product, my tasks could be something like:

  • Add a new Import Contacts page
  • Add a service to get contacts from Gmail
  • Modify the contact class to accommodate Gmail specific data (let’s assume such exists)
  • Modify the contacts data schema

Assuming these tasks are right-sized (4-16 hours), that’s it. If one of these tasks is bigger, break it down. If a task is smaller, merge it with a related one (if such exists. If not, don’t sweat it. My 4-16 rule is just a guideline). We now have all the tasks for us to complete the coding of the story.

Look at the Definition of Done

Of course, just coding your story isn’t sufficient for the story to be truly done. In Scrum, “done” means ready to ship, or as I like to define it: the story is as it will be received by the customer / user. Agile teams have a list of requirements that should  be true for any story they complete. You should look at your Definition of Done (DoD) to see what tasks remain.

For example, let’s say your DoD includes the following:

  • Code Complete
  • Automated UAT (User Acceptance Tests)
  • Documentation is updated
  • Added to shipping package (e.g. InstallShield)

In this case, you should add tasks that help you achieve the story’s DoD. For the above example you might do the following:

  • Write UATs for the story
  • Document the Contacts Import feature

Assuming you didn’t have to add any new assemblies (i.e. libraries, packages, DLLs, executables, etc.), to your installation, you probably wouldn’t have any need to modify your packaging tool. No need to add a task for that.

That’s It!

You now have 6 tasks for the story:

  • Add a new Import Contacts page
  • Add a service to get contacts from Gmail
  • Modify the contact class to accommodate Gmail specific data (let’s assume such exists)
  • Modify the contacts data schema
  • Write UATs for the story
  • Document the Contacts Import feature

You can now estimate how much time each one will take, and are ready to move on, and break down the next story.


  1. Sprint Planning Meeting (2nd part without PO) is about HOW you will realize the story. This is a design meeting which I personally experience as very effective. We always need the full timebox for this meeting because we are going deep into the architecture and design of our application and dicuss HOW it must evolve so that the story can be realized. The tasks and the task estimation are just a by-product.
    If you follow your proposals, the benefits of of Sprint Planning is gone. I think your approach is too simple.
    I like your definitions of story and task.

  2. @Daniel - I don't see how what you said contradicts my method. What I do is simply look at the architecture, and look for components that I need to modify (or add), and note how they need to be modified (or what the new component should do). In the end, it amounts to discussing how the architecture must evolve. We both agree that the architecture evolves, and we both end up with tasks. I just add some rules-of-thumb to the process, because I found that most of the literature doesn't discuss HOW to discuss how the architecture must evolve, and HOW this results in tasks and estimations.

    The only thing I add, is a pass at the DoD, to make sure that it done means done.

    Do you do something that is different? I'd really like to hear of your experience.


  3. @Assaf: What I'm missing in your blog is the team. I recently visited a team that were every developer was tasking (breaking user stories into tasks) on his own. What is the benefit of the tasks in this case? I think it is almost zero. For me, the main benefit of the 2nd part of the sprint planning meeting is to have a deeper comprehension whether you can really achieve what you (the team) have discussed with the Product Owner in the first part of the meeting. It does not matter whether you do this by detailled tasking inclusive hour estimations or just by gut feeling. Important is that the entire Development Team agrees that it can realize the selected Product Backlog Items in that Sprint.
    Our main discussion is on how to evolve the architecture (your first point). Your suggested look on the DoD resulted in our case only in one type of task: Write UATs. Writing Unit Tests, merging back to main, consult Product Owner, etc. are no tasks but explicitly included in the DoD or the expanded Acceptance Tests. The DoD is nothing else than general Acceptance Tests valid for any Product Backlog Item. Only writing UATs is a separate task, because we have a dedicated, embedded tester in our team.

  4. @Daniel, what you're suggesting, to convene and examine their commitment doesn't conflict with my suggestion, but rather completes my suggestion. You describe how to conduct the meeting; I suggested what the tasks should be.

    I suggested to look at the architecture (components) for the source of the right-sized _development_ tasks that you need to develop. The team should then decide WHAT needs to be done with these components.

    I suggested the DoD as the source for other non-coding tasks, such as UAT, documentation, code reviews, etc.

    The architecture and DoD I used was merely an illustrative example, not a real-live one.

    In short, the idea of the post was to be an inspiration for those who need it (like I once did), not gospel.

    Hope this clears things up.

  5. Likeable post - short, simple & clear!

  6. Nice post ! You made my day !

    In my situation, I have to break the user story into task for team members. In our team, there are some members who have not full skill to complete a component like "Add a new Import Contacts page" in the example above.

    We have a designer who can't code but full skill in Photoshop, Illustrator ,etx , a man which have full skill in HTML&CSS but can't code server side, some coder who are prefer backend dev. How should I do in this situation ?
    Should I break "Add a new import Contacts page" into 3 task:
    1. Make a design of new import Contacts page in Photoshop
    2. Convert Photoshop file into HTML&CSS
    3 . Use HTML&CSS source code and write controller to finish import contacts page

    Thanks !

    1. Hi CT,
      The way I do things these days, is that I use the rule-of-thumb that a task should be a unit-of-work that a single developer (or pair, or mob - depending on how you work) can complete in 4-16 hours (optimally 1 day).

      Any functional breakdown that ends up the right size is good.
      If you need to divide it further because it requires multiple skill sets, then by all means do so - one task for the dev, one for the designer.

      Hope this helps,

  7. The post is written in very a good manner and it contains many useful information for me.


Note: Only a member of this blog may post a comment.