How To Break Down User Stories Into Smaller Tasks

In this post, I'll talk about my strategy for breaking down user stories into smaller tasks.

What's a User Story?

Before we start, let's define what user stories are. A user story is an informal, natural language description of a software system feature.

One of the common formats used for creating a user story is this:

As a <user with this role>, I should be able to <perform this action> to <achieve this goal>.

Let's look at a real-world example for a blog application:

As a content editor, I should be able to create a draft to work on an article over some time.

Why Do I Need To Define Smaller Tasks?

In my experience, breaking down user stories into smaller tasks can help identify common tasks that were originally spread out across multiple user stories.

Remember, user stories are closer to business requirements and not technical ones.

Here's a good example. Let's say that there are a couple of user stories defined to confirm with a user before proceeding with an action. When we break these user stories down, we'll discover that there's a need for a confirmation popup. Since this is a reusable component, we can better plan who will implement it and when will it be implemented.

Essentially, breaking down user stories into smaller tasks allow devs to:

• Better plan their tasks, therefore, allowing them to provide more accurate estimates
• Have a better bug-fixing experience since issues can be mapped to each specific task instead of the larger-scoped user story
• Reduce duplicate work (as described in the confirmation popup scenario above)

Let's Break It Down

Now, let's work on the real-world example I gave earlier.

When breaking down a user story, I first think of the following categories:

1. Security
2. Pre-conditions
3. Action

Each category can either have one or multiple tasks. Let's discuss in detail in each of their respective sections.

Security

The most important category and is even the first part of the user story. In this category, we'll answer the question:

Who is allowed to perform the action?

The example user story is only targeted at content editors. Therefore, we need to ensure that.

Since the user story is simple enough, I'll only add one task under this category:

• Check that the user should have a Content Editor role.

For more complicated systems, another consideration can be delegation. If a content editor went on leave and has assigned his/her backup editor, the check for this can be another task as well.

Also, the reason why I define the security-related tasks first is that it is going to be used by all the subsequent tasks. This means, that it will be the first task I do and will be implemented as a common/reusable component.

Pre-conditions

The tasks under this category should answer this question:

What needs to be done before the user can perform the action?

Note that these actions should only be performed after the security checks.

For our example user story, the ff. tasks can be added as part of this category:

• Check that the user already has a blog. If not, ask the user to create a blog first.

In some cases, the smaller tasks here might get attached to another user story.

For example, instead of "asking to create a blog", we may link to a "getting started" feature that was defined by a different user story.

That doesn't mean we don't need to ensure these conditions are met first. These checks are still part of the user story.

Action

Now, on to the main requirement. In this category, we answer this question:

How can we enable the action for the user?

Additionally, we should also include validation tasks under this category.

In our case, we'll add the ff. tasks under this category:

• Add a New Draft button to the main navigation.
• Once the New Draft button is clicked, display the main WYSIWYG editor.
• Add a Save button to the WYSIWYG editor.
• Once the Save button is clicked, if there's content in the editor, we create a new draft record and navigate to the draft listing page.
• Once the Save button is clicked, if the editor is empty, we navigate away from the editor.

In the above tasks, everything about the WYSIWYG editor is out of scope. The kind of editor plugin or the other behaviors that should be available in it should all be considered in a separate user story. We just assume that the editor is available for integration.

In Summary

We've reached the end! That one-liner user story has been broken down into 7 smaller tasks.

Just for a quick recap, here are the tasks:

Again, breaking down user stories into smaller tasks enables better task planning and management. It is a necessary step for devs.

Also, there are other approaches to doing this. If you happen to know one, I'd love to hear from you so, share your thoughts in the comments below!

Hey, you! Follow me on Twitter!