How to Write Effective Technical Tasks and User Stories

Throughout my career, I’ve worked on many projects. In each one, there were different opinions on technical stories — whether they should exist at all or if they should be created as basic tasks or subtasks attached to a story that covers a specific set of functional requirements. There are always a lot of discussions and meetings regarding them, as every PM, dev, and client team expects different things from the BAs. But that’s what BAs do, after all. We adapt fast and support any team, and client, respectively.

User stories are situational. They depend on the project and the team. Sometimes it also depends on whether the client has already set a system and specific requirements regarding how to structure the backlog. If technical requirements exist in any form, the BAs should know what they cover and how best to structure them.

Identifying Technical Stories and Tasks

First, check out my previous blog on the topic for a refresher on technical stories and tasks.

Consider technical tasks or stories at the start of a project, as they might add quite a significant amount of scope. Teams and clients need to think of infrastructure and all the logic behind it before diving head-first into functionalities.

Some ways you can identify technical stories and tasks are:

• Discussions between the dev team and the client’s technical staff, when available. 
• 1:1 sessions with the technical lead or senior developer to discuss upcoming functionalities. They tend to have insights into some hidden details from a technical perspective. 
• Organizing sync between different technology dev teams, as there may be some cases when they don’t communicate as much as needed (e.g., front-end with back-end team, Android with the iOS team, Android & iOS teams with the back-end team, etc.)
• Think of infrastructure. By infrastructure, I mean two things:
  • Code infrastructure & architecture
  • Cloud infrastructure & architecture

Most of this work should be considered at the start of the project. So if you notice something needs to be discussed, raise awareness!

• Have an end-to-end view of the work to deliver the entire project. Imagining the whole picture and how the final product should look and work can help you identify as many things as possible, not only from a technical perspective. It can also help with narrowing down the technical story type you need. 

Some of the most common types of tasks and stories that can exist in a project are:

• Product Infrastructure
• Team Infrastructure
• Back-end logic to support a feature
• Refactoring
• Bug Fixing
• Spikes
• Technical subtasks

How to Approach Technical Stories or Tasks

• Think of who the “user” is. There is no need for a user in a technical task or a story, as it may not directly benefit anyone from a user perspective. I’ve seen statements like “As a front-end dev, I want an API to be implemented,” which first does not sound right and second is conceptually wrong. And yes, I have created stories like that at some point in my career. I have even seen an attempt to create a story that stated, “As a database, I want a table to be added” sounds nice, right?
• My advice here is:
  • Use simple, plain English
  • Avoid copying and pasting functional or UI/UX stories with just a change of titles
  • Put yourself in others’ shoes. For example, what does the back-end developer needs to know to accomplish their goal? By the way, this applies to all types of stories, not only technical ones
• Keep in mind that not everything should be a story
  • You can use technical tasks
  • Or even subtasks, depending on the project and the agreements you have with the team and the client

Details to Look for in a Back-End Story or Task

• Let’s say you need to create a story or a task for implementing an API. What should you take into account before that?
  • What business needs would be achieved with the implementation of it? If it achieves a certain business need, this can be described in the story narrative (e.g., “push notification engine is integrated with the project, so functionalities for sending notifications for different events to users can be implemented,” “implement an API for listing data to the users so that it can be displayed for them in the profile screen”)
  • What parameters should the API accept to work correctly?
  • What validations should it make to the data?
  • How would data be processed (is there any specific business logic, formulas, or any other type of data transformation)?
  • What results should it provide, and in what format (JSON, XML)?
  • Take error handling and proper error messages into account
• Try to describe the algorithm and the flow of the work in plain English 

Let’s look at an example using pancakes as a substitute for an algorithm.

In mathematics and computer science, an algorithm is a finite sequence of well-defined instructions, typically used to solve a class of specific problems or to perform a computation. Algorithms are specifications for performing calculations, data processing, automated reasoning, decision-making, and other tasks. Understanding algorithms may help you greatly in creating such types of technical issues.

Recipes are very close to algorithms, so if the word algorithm scares you, let’s see what an algorithm for making pancakes looks like. After all, who doesn’t love pancakes?

Here’s the recipe:

Step 1: Decide what type of pancakes you want (crepes, American style, blini, katmi, etc.)

Step 2: Buy ingredients 

• input: money
• output: pancake ingredients

Step 3: Make the batter 

• input: ingredients, tools
• output: batter
• data transformation and business logic:
  • Get a bowl
  • Get a whisk
  • Weigh and mix wet ingredient
  • Weigh and mix dry ingredients
  • Combine wet and dry mixes
  • Check batter consistency
  • If the batter is ok, go to baking
  • If the batter is not ok, fix it

Step 4: Cook pancakes 

• inputs: batter, oil, pan
• output: pancakes
• Data transformation and business logic:
  • Get a pan
  • Heat the pan to the correct temperature
  • Oil the pan
  • Add one ladle of the batter
  • Spread the batter in the pan
  • Cook for 1 minute 
  • Flip
  • Cook for one more minute
  • Repeat until no batter is left

Step 5: Eat pancakes 

• inputs: pancakes, fillings, and toppings
• output: you are happy

One More Example — “Password Reset” Functionality

Now that you know how to make pancakes with algorithms, let’s see one last example.

This is a normal functional story for “Password Reset” functionality; nothing special here, nothing too complicated. Of course, there is a technical part and a not-so-small back-end effort.

We should cover that effort in technical stories, tasks, sub-tasks, etc.

Disclaimer: This story will be quite big in the name of science. Some parts of it can be broken down into separate stories or tasks.

Reset Password: Phantom Menace

Narrative

As a user, I want to reset my password In case I forgot the one I set when registering, so I can log into the system.

Acceptance Criteria

• The user can access the reset password screen from the login screen.
• User can enter their email and submit it.
• If the email is associated with an account: “Check your email. We sent instructions for the next steps.”
• If there is no such email, the user sees:  “The email you entered doesn’t match any account.”
• The user receives an email with instructions and a link. (content handled in back-end)
• The reset link redirects the user to the “Reset Password” screen
• New Password (validation based on the back-end)
• Confirm New Password (validation = must be same as new password)
• The new Password may be the same as any prior password
• Users can toggle between hiding and viewing their password
• If both passwords do not match, the user sees a message: “The passwords do not match.”
• Upon submitting the new password, the user is brought to the login screen with the email address filled in.
• The user must fill in the new password on the login screen

Reset Password: Attack of the Back-End

How should we handle the back-end effort?

At the beginning of my career, I made a clone of the same functional story and put [BE] in front of the title, and there we go. The back-end effort was covered. Or is it?

Let’s put ourselves in the shoes of the back-developer who received that story. What will they see?

• The user can enter — the back-end devs do not have UI; they receive parameters
• The reset link redirects to a page — back-end devs do not have pages, and redirects are typically not handled by them
• Users can toggle between hiding & viewing their password — totally not back-end related — purely UX

With that example, there may be something of value in this story for a back-end dev, but a lot of them may need clarification that they should implement features that are not their responsibilities. That’s why we will see how, in my opinion (I REPEAT in MY opinion), this should look more appropriate for the back-end devs.

Reset Password: A New Hope

We can keep the narrative, and we have a clear business need and a user who will directly benefit from it. Again, remember that the example is big and can be broken into multiple stories, but I wanted to cover more things with it. 

Narrative

“As a user, I want to be able to reset my password In case I forget the one I set when registering, so I can log into the system.” 

Now to see how we can adjust the acceptance criteria. 

Acceptance Criteria

• A web service for resetting users’ passwords is implemented. (we state what should be done)
• The web service should receive the user email and should check if there is such a user in the record (input parameters)
• If there is a match, the service should  (describe the algorithm in plain English)
• Return a success message: “Check your email. We sent instructions for the next steps.”
• Generate a reset password link for the user’s request.
• Send an email to the user with the following content: “Dummy content.”
• The link should expire after 24 hours.
• If there is no match, the service should: (validation)
• Return an error message: “The email you entered doesn’t match any account.”
• The reset password service should: (we describe the algorithm in plain English)
• Check if the new and confirmed passwords match and return messages based on the result.
• Accept a new password as a parameter
• Validate the new password
• Min chars
• Max chars
• Alphanumerical
• Save the new password in the user’s record

In that way, we make sure that we capture the business logic and that the algorithm that needs to be implemented by the back-end developers is described understandably, both for them and for the product owner in the project. 

Final Thoughts

Every BA specialist has their style of documenting requirements. But understanding the purpose of technical stories and tasks and identifying and structuring them to serve the different needs of various teams and stakeholders is key to the success of software projects.