How to Write Tasks for User Stories

User stories are typically created by multiple people on a software team and used to organize the direction of a development project. Tasks, on the other hand, are the actionable steps based on user stories that provide team members with direction. The point of writing tasks and distributing them is that it makes feedback actionable, ensures that everyone knows what each team member is working on, and breaks scrum tasks down into independent objectives.

Method 1

Method 1 of 3:

Compiling and Organizing Your User Stories

First, take all of the user feedback, testing data, and review information and compile it together. You can compile a spreadsheet, write the info down on index cards, or just copy and paste reviews into a sharable document. This will give you all of your raw data in one place to make it easier to share and translate.^{[1]XResearch source}
2
Translate the information into concrete user stories. User stories refer to the one-sentence statements that identify what the user wants to do, but can’t. These stories typically follow a template but there are several options available depending on what format makes the most sense to your team. Break each data point down into single sentences using the format of your choosing. Write them down on index cards or in a separate document.^{[2]XResearch source}
- One way to write user stories is to use the INVEST method. INVEST stands for independent, negotiable, valuable, estimated, small, and testable. For example, you may take “I don’t like the that there’s no save feature” and turn it into, “I want a wishlist feature to save products I look at in the shop.”
- The most common template is “As a (type of user), I want (function or action) so that I (valuable feature or benefit).”
- For example, “I hate that I have to click 3 menus to open the interface. It takes to long to get to the administrator menu” can be translated into, “As an administrator, I want faster access to the control UI so I can log into separate accounts easily.”
Advertisement
3
Break epic stories down into smaller stories to make them manageable. Epic stories refer to larger pieces of feedback that include multiple stories. Since stories must only focus on a single aspect of the software, it’s important to separate larger data points into smaller stories to make them more manageable.^{[3]XResearch source}
- For example, “I didn’t like the layout of the buttons. The thumbnails are really hard to read and I’m not sure what the squiggly line tool is for,” could be broken down into “I want the UI layout to be streamlined to make it easier to follow,” “I want adjustable thumbnails to make them more readable,” and, “The purpose of the unlock tool seems unclear and I’d like further instructions.”
Gather all team members in the room and separate the stories up. Give each story to the team member most suited for the task. For example, if a story involves coding, give it a coder. If it involves design or implementation, give it to another team member better suited for the task.^{[4]XResearch source}
Tip: If you have dozens of stories, pick 10-15 high-priority stories to start with. You don’t need to handle all of the stories at once.
Advertisement

Method 2

Method 2 of 3:

Developing Tasks from the Stories

1
Determine what you need to actually do to resolve a user story. Every good user story has a solution. The first step is to consider what actually has to happen for this solution to take place. Assess the user’s issue and jot down a few ideas about how the problem can be solved.^{[5]XResearch source}
- For example, if a story reads, “As a player, I find the first-person camera hard to navigate,” the user’s problem isn’t really with the first-person perspective. It’s with how difficult it is to control their vision. You may consider different camera controls, a new depth of field, or adjusting the camera code.
Tip: You can do this collaboratively if you’d like. Many people find it easier to process stories into tasks by talking about the stories with others in their field.
2
Assess which solutions are most practical when weighing objectives. There are likely multiple ways to compose tasks for every user story. Some of the best solutions will be obvious, but sometimes it can be a little ambiguous. In general, it’s best to always choose the option that is the most practical in terms of implementation and future modification. This way it’s easier to revert changes or make future adjustments.^{[6]XResearch source}
- For example, if a user story reads “As a writer, the limited number of fonts make it hard to present my work,” you could implement a system where users can import fonts from third-party services, but it’s probably a lot easier to just add 15-20 typefaces to the program.
3
Keep your tasks as small as possible to keep objectives clear. No single task should involve multiple objectives or changes. If necessary, break down user stories into 2-3 tasks to keep the objectives clear and manageable.^{[7]XResearch source}
- For example, if a story reads, “I want more accessibility options for the audio and visual components,” you may break it down into, “Implement a colorblind mode,” and, “Add a subtitle feature for hearing-impaired users.”
4
Make sure that tasks can be completed in a single day. If you’re composing a task and it feels like it would take more than 1 day to complete, it needs to be broken down further. Any multi-day task is assuredly too complex to be helpful and breaking it into separate steps will make it much easier to manage your work.^{[8]XResearch source}
- For example, if a task ends up reading “Ensure the user can review their order history after buying products,” you probably need to break it up into, “Write the code for an order history page,” “Compose a script that accesses a user’s previous purchases,” and “Implement the script in the code to test it.”
Advertisement

Method 3

Method 3 of 3:

Writing with the SMART Method

1
Make sure that your task is as specific as possible to guide your work. The SMART method is the most popular way to write tasks and review them. To start, make sure that you boil your task down into the most specific terms possible. This will keep you from getting lost in the reeds when you go to complete the task.
- SMART stands for specific, measurable, achievable, relevant, and timed.
- For example, “Add a subtitle feature for hearing-impaired users” is a solid start, but it can be made even more specific by describing the type of feature and when it will be used. You may end up with, “Compose a Java script that generates subtitles based on audio cues in the links users click.”
Tip: You can either write your tasks from scratch using the SMART method, or write a draft and then revise it to ensure that it’s SMART. Do whatever makes the most sense to you.
2
Ensure that your task is measurable so you know when you’re done. If your task isn’t measurable, then you won’t actually know whether you’ve accomplished the thing you set out to do. In programming terms, measurable means that you have a concrete metric to judge whether the job is done.
- For example, “Improve the user controls for the save feature” isn’t really measurable. However, “Implement a ‘Save As’ feature to let the user adjust the file format” can be measured by whether the “Save As” feature functions correctly or not.
3
Compose the task to be achievable based on your skill set and average user. A task is achievable insofar as it’s something you can do on your own, and it’s something the user can reasonably accomplish without help from a third party. If you’ve ever tried to navigate a complicated webpage to find information you knew was there but couldn’t find it, you didn’t accomplish what you set out to do. Similarly, the designer of the page didn’t achieve the end goal of making the information easily identifiable.
- For example, “I am going to ensure that every user uses the program correctly” isn’t particularly reasonable. However, “I am going to create a tutorial that teaches the user how to use the brush tool correctly” is certainly possible.
4
Make sure the task is relevant to the larger goals of the project. If you get hyper-focused on fixing a minor bug that doesn’t actually impact the functionality of the software, there’s no real reason to fix it. Similarly, if a user isn’t going to necessarily care about the format of the script you’re writing, there’s no reason to worry about it.
- This is the best way to cut out unnecessary tasks that don’t really matter. Just ask yourself, “Do I care about this,” “Does this impact the overall goal of the project,” and “Does the end user care about this?” If the answer to these 3 questions is no, you don’t need to do it.
5
Place a deadline on the task to give yourself a timeframe. If a task isn’t bound within the schedule of the project, it isn’t going to happen. Placing a timeframe on the task is the last step. Assess how long it will take to accomplish the task, take a look at your schedule, and give it a deadline.
- For example, “Implement a ‘Save As’ feature to let the user adjust the file format” is a pretty good task. You can give it a literal deadline, or place it in the context of the project. So the final product may look like, “Implement a ‘Save As’ feature to let the user adjust the file format in the next 6 hours,” or, “Implement a ‘Save As’ feature to let the user adjust the file format before we test the final menu interface.”
Advertisement

Expert Q&A

Search

Add New Question

Ask a Question

200 characters left

Include your email address to get a message when this question is answered.

Submit

Tips

If your team has a member with a specific knack for writing tasks, feel free to give all of the user stories to them for task-writing. Then, they can share the tasks with the team and let everyone choose which task they’re going to pick up.
Thanks
Helpful0 Not Helpful0